* [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-12 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480475340-21893-3-git-send-email-rick.chang@mediatek.com>
Hi Rick,
On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang@mediatek.com> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
<snip...>
> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> +
> + q_data = &ctx->out_q;
> + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> + return true;
> + }
> +
> + q_data = &ctx->cap_q;
> + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> + return true;
> + }
> + return false;
<snip...>
> +static void mtk_jpeg_device_run(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + unsigned long flags;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + struct mtk_jpeg_bs bs;
> + struct mtk_jpeg_fb fb;
> + int i;
> +
> + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i, 0);
> + buf_state = VB2_BUF_STATE_DONE;
> + goto dec_end;
> + }
> +
> + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return;
> + }
This only detects source change if multiple OUPUT buffers are queued.
It does not catch the source change in the following scenario:
- OUPUT buffers for jpeg1 enqueued
- OUTPUT queue STREAMON
- userspace creates CAPTURE buffers
- CAPTURE buffers enqueued
- CAPTURE queue STREAMON
- decode
- OUTPUT queue STREAMOFF
- userspace recreates OUTPUT buffers for jpeg2
- OUTPUT buffers for jpeg2 enqueued
- OUTPUT queue STREAMON
In the above sequence if jpeg2's decoded size is larger than jpeg1 the
function fails to detect that the existing CAPTURE buffers are not big
enough to hold the decoded data.
A possible fix is to pass *dst_buf to
mtk_jpeg_check_resolution_change(), and check in the function that all
the dst_buf planes are large enough to hold the decoded data.
> +
> + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> + goto dec_end;
> +
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> + &jpeg_src_buf->dec_param, &bs, &fb);
> +
> + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> + return;
> +
> +dec_end:
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
<snip...>
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Chen-Yu Tsai @ 2016-12-12 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d70f2809-102c-a3de-c77c-43af27bbcbbc@arm.com>
On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> I was observing that the new sunxi-ng clock code apparently explicitly
> turns off _all_ clocks that are not used or needed. I find this rather
> unfortunate, as I wanted to use the THS temperature sensor from ARM
> Trusted Firmware to implement emergency shutdown or DVFS throttling.
> That works until the clock framework finds the clock (as enumerated in
> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
> clock register and bit 8 in the respective clock gate register.
> Turning them manually back on via /dev/mem or removing the THS clock
> from the sunxi-ng driver fixes this for me.
>
> This was not happening with the old Allwinner clocks, since the kernel
> wouldn't even know about it if there was no driver and the clock wasn't
> mentioned in the DT.
>
> Now with sunxi-ng even though the THS clock is not actually referenced
> or used in the DT, the kernel turns it off. I would expect that upon
> entering the kernel all unneeded clocks are turned off anyway, so there
> is no need to mess with clocks that have no user, but are enumerated in
> the ccu driver.
I can't say that's absolutely true (wink).
>
> I wonder if this kills simplefb as well, for instance, since I believe
> that U-Boot needs to turn on certain clocks and relies on them staying up.
The simplefb bindings takes clocks and regulators expressly for the
purpose of keeping them enabled.
>
> So my questions:
> 1) Is this expected behaviour?
Yes.
> 2) If yes, should it really be?
> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
> clock alone, preferably via DT? Although the sunxi-ng clocks take
> control over the whole CCU unit, I wonder if it should really mess with
> clocks there are not referenced in the DT.
As it owns the whole CCU unit, why not? And how would it know if some
clock is referenced or not, unless going through the whole device tree?
Furthermore, nothing prevents another device driver from referencing
said clock and turning it off when it's not in use. Think THS driver
with runtime PM.
Are you also mapping the THS to secure only? Otherwise nothing would
prevent Linux from also claiming it.
>
> Maybe there is some way to reference those clocks via some dummy driver
> or DT node to avoid this behaviour? Is there any prior art in this respect?
If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
to its flags is the proper option. This is done in the clk driver though.
If you just don't want the clk subsystem to disable unused clks at boot
time, you can add "clk_ignore_unused" to the kernel boot parameters.
I think this is more of a hack and debugging tool though.
About dummy drivers, simplefb comes to mind again. But simplefb disables
them when it gets kicked out by the drm driver. Maybe there are other
examples.
Regards
ChenYu
> I think this issue will affect more future users (thinking of EFI RTC,
> EFI graphics, etc.), so I wanted to start a discussion on this.
>
> Any input welcome.
>
> Cheers,
> Andre.
>
> P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
> temperature sensor (THS) and programs a shutdown value. It programs the
> respective interrupt as secure and registers an IRQ handler in ATF to
> shutdown the system or take other appropriate matters to avoid
> overheating. Additionally the sensor is exported via the generic SCPI
> interface, so the existing scpi-hwmon driver picks it up and reports it
> to whoever is interested in Linux land via the normal interfaces.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7900ae24-6803-a271-944c-8830f718fef0@free.fr>
On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> [ Dropping Mans to preserve his peace-of-mind ]
>
> On 09/12/2016 18:56, Vinod Koul wrote:
> > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> >> On 09/12/2016 18:17, Vinod Koul wrote:
> >>
> >>> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>>>
> >>>> What concrete solution do you propose?
> >>>
> >>> I have already proposed two solutions.
> >>>
> >>> A) Request a channel only when you need it. Obviously we can't do virtual
> >>> channels with this (though we should still use virt-channels framework).
> >>> The sbox setup and teardown can be done as part of channel request and
> >>> freeup. PL08x already does this.
> >>>
> >>> Downside is that we can only have as many consumers at a time as channels.
> >>>
> >>> I have not heard any technical reason for not doing this apart from drivers
> >>> grab the channel at probe, which is incorrect and needs to be fixed
> >>> irrespective of the problem at hand.
> >>>
> >>> This is my preferred option.
> >>
> >> There is one important drawback with this solution. If a driver calls
> >> dma_request_chan() when no channels are currently available, it will
> >> get -EBUSY. If there were a flag in dma_request_chan to be put to
> >> sleep (with timeout) until a channel is available, then it would
> >> work. But busy waiting in the client driver is a waste of power.
> >
> > Right, but in that case the fallback would be PIO mode, and if that is
> > not availble (IIRC some f your devices don't) then reject the usage with
> > EAGAIN.
>
> Maybe I'm missing something, but I don't see how that would help.
> Take the NAND Flash controller driver, for instance. PIO is not
> an option, because the ECC engine is tied to DMA.
>
> And failing with -EAGAIN doesn't help the busy looping situation.
> The caller should be put on some kind of queue to wait for a
> "channel ready" event.
So if you go down this route then we have do a bit of engineering for this
solutions to solve the hardware issue.
Can you tell me the clients for this controller and channels available?
In this case possibly we can dedicate one for NAND and keep the ones with
PIO mode dynamic in nature.. But yes it is not an elegant one.
--
~Vinod
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206121346.GF2498@arm.com>
On 12/06/2016 05:43 PM, Will Deacon wrote:
> On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
>> On 12/02/2016 04:38 PM, Will Deacon wrote:
>>> On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
>>>> Extend the trace_clock to support the arch timer cycle
>>>> counter so that we can get the monotonic cycle count
>>>> in the traces. This will help in correlating the traces with the
>>>> timestamps/events in other subsystems in the soc which share
>>>> this common counter for driving their timers.
>>>
>>> I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
>>> particular, the "perf" trace_clock hangs off sched_clock, which should
>>> be backed by the architected counter anyway. What does the cycle counter in
>>> isolation tell you, given that the frequency isn't architected?
>>>
>>> I think I'm missing something here.
>>>
>>
>> Having cycle counter would help in the cases where we want to correlate the
>> time with other subsystems which are outside cpu subsystem.
>
> Do you have an example of these subsystems? Can they be used to generate
> trace data with mainline?
Some of the subsystems i can list are Modem(on a mobilephone), GPU or
video subsystem, or a DSP among others.
>
>> local_clock or even the perf track_clock uses sched_clock which gets
>> suspended during system suspend. Yes, they are backed up by the
>> architected counter but they ignore the cycles spent in suspend.i
>
> Does mono_raw solve this (also hangs off the architected counter and is
> supported in the vdso)?
Doesn't seem like. Any of the existing clock sources are designed not
show the jump, when there is a suspend and resume. Even though they run
out of architected counter they just cane give exact correlation with
the counter. Furthermore, during the initial kernel boot, these just run
out of jiffies clock source. They also not account for the time spent in
boot loaders.
>
>> so, when comparing with monotonically increasing cycle counter, other
>> clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
>
> Does this mean we need a way to expose the frequency to userspace, too?
Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency
of system timer and is available to EL0.
>
> Will
>
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
Project.
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-12 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
On 10/12/16 06:29, Russell King - ARM Linux wrote:
> On Wed, Dec 07, 2016 at 02:33:53PM +0000, Vladimir Murzin wrote:
>> Hi Linus,
>>
>> On 07/12/16 14:11, Linus Walleij wrote:
>>> Another target I had in mind was the Integrator which
>>> incidentally supports a bunch of the old noMMU core
>>> tiles where we can swap in an ARM946, which I guess
>>> could work with this?
>>
>> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
>> reported it did a trick for Versatile, there is a good chance it would work
>> for Integrator too ;)
>
> My views on gluing multiplatform and nommu together have already been
> stated several times, and remain unchanged.
>
> Greg's patch looks almost sane, but what I'd like to see is instead of
> directly doing this:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
>
> we could do:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> default y if ARM_SINGLE_ARCH_VERSATILE
>
> adding the versatile entry in the upper level choice (where it always used
> to be) but with "ARM_SINGLE_ARCH_VERSATILE" instead.
>
> This would have the effect of allowing the multiplatform-converted stuff
> to start being used on nommu (again) but without running into the problems
> I've highlighted.
Thanks for the feedback Russell. Let me re-spin this patch with
this in mind.
Regards
Greg
^ permalink raw reply
* [PATCHv2 4/4] ARM: versatile: support configuring versatile machine for, no-MMU
From: Greg Ungerer @ 2016-12-12 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
Allow the arm versatile machine to be configured for no-MMU operation.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
This patch adds a versatile platform selection in the upper level arm
system type menu - where it appeared in older kernel versions - when
configuring for the no-MMU case. There is no visible change to the way
versatile is selected for the MMU enabled case.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 11 +++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 5 +++--
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..8960e7a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,17 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARCH_VERSATILE
+ bool "ARM Ltd. Versatile family"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select GPIOLIB
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..3f393e4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARCH_VERSATILE
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index c257d40..c03a8c8 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,6 +1,7 @@
config ARCH_VERSATILE
- bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
+ default y if ARM_SINGLE_ARCH_VERSATILE
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
--
1.9.1
^ permalink raw reply related
* [PATCH] mmc: sdhci-xenon: fix device_node_continue.cocci warnings
From: Ziji Hu @ 2016-12-12 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612092006080.1960@hadrien>
Hi Julia,
On 2016/12/10 3:08, Julia Lawall wrote:
> Device node iterators put the previous value of the index variable, so an
> explicit put causes a double put.
>
> Generated by: scripts/coccinelle/iterators/device_node_continue.cocci
>
> CC: Hu Ziji <huziji@marvell.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
>
> Please check on this. I have only seen the code shown below, but the rule
> normally has a lot false positive rate.
>
Thank you.
It seems that the check is right. I will correct it.
Thank you.
Best regards,
Hu Ziji
> url:
> https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/mmc-Add-support-to-Marvell-Xenon-SD-Host-Controller/20161210-002602
> base:
> :::::: branch date: 2 hours ago
> :::::: commit date: 2 hours ago
>
>
> Please take the patch only if it's a positive warning. Thanks!
>
> sdhci-xenon.c | 1 -
> 1 file changed, 1 deletion(-)
>
> --- a/drivers/mmc/host/sdhci-xenon.c
> +++ b/drivers/mmc/host/sdhci-xenon.c
> @@ -423,7 +423,6 @@ static int xenon_child_node_of_parse(str
> MMC_CAP2_NO_SD |
> MMC_CAP2_NO_SDIO;
> }
> - of_node_put(child);
> }
>
> return 0;
>
^ permalink raw reply
* [PATCH 2/2] kcov: make kcov work properly with KASLR enabled
From: Dmitry Vyukov @ 2016-12-12 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3f9c3a3-349d-65ff-6c84-51878cfd8072@linux.com>
On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov <alex.popov@linux.com> wrote:
> On 11.12.2016 12:32, Dmitry Vyukov wrote:
>> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov <alex.popov@linux.com> wrote:
>>> Subtract KASLR offset from the kernel addresses reported by kcov.
>>> Tested on x86_64 and AArch64 (Hikey LeMaker).
>>>
>>> Signed-off-by: Alexander Popov <alex.popov@linux.com>
>>> ---
>>> kernel/kcov.c | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> I think generally this is the right thing to do.
>>
>> There are 2 pending patches for kcov by +Quentin (hopefully in mm):
>> "kcov: add AFL-style tracing"
>> "kcov: size of arena is now given in bytes"
>> https://groups.google.com/forum/#!topic/syzkaller/gcqbIhKjGcY
>> https://groups.google.com/d/msg/syzkaller/gcqbIhKjGcY/KQFryjBKCAAJ
>>
>> Your patch probably conflicts with them.
>> Should you base them on top of these patches, so that Andrew can merge
>> it without conflicts?
>
> Excuse me, I can't find these patches in:
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> git://git.cmpxchg.org/linux-mmots.git
>
> Could you point at the tree which I can rebase onto?
> Should I cherry-pick Quentin's patches manually?
Quentin, do you know destiny of your patches? They does not seem to be
in mm tree.
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: mickael guene @ 2016-12-12 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fulus094.fsf@dell.be.48ers.dk>
Hi all,
You can find an R toolchain here:
https://github.com/mickael-guene/fdpic_manifest/releases/download/v7-r-1.0.1/toolset-v7-r-1.0.1-0-gbdcc6a7c-armv7-r.tgz
It's an fdpic toolset for cortex-r cpu class. gcc version is
quite old (4.7).
Note also that generated code may crash on class A cpu due to
generation of udiv/sdiv which is optional for class A.
(cortex a15 is ok but not a9).
Hope it helps
Regards
Mickael
On 12/11/2016 09:01 PM, Peter Korsgaard wrote:
>>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
>
> Hi,
>
> >> You can build a toolchain and initramfs with Buildroot. Have a look at
> >> the stm32f429 nommu config:
> >>
> >> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
>
> > iiuc, it builds one for Cortex-M. i already had a file system w/
> > busybox compiled using a Cortex-M toolchain (stolen from
> > Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
> > VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
> > above mentioned also would have the same effect.
>
> Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
> thought the 'M' instruction set was a pure subset of the 'A'.
>
> > And in buildroot, couldn't see Cortex R option in menuconfig, and
> > selecting Cortex-A's excludes flat binary target & presents only with
> > ELF.
>
> We indeed don't have cortex-R support. I'm not aware of any cortex-R
> Linux support.
>
> When you select a cortex-A variant, then we enable MMU support by
> default, but you can disable it under toolchain options (Enable MMU) and
> then the flat binary option is available.
>
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Jiancheng Xue @ 2016-12-12 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb89c03e-ea67-d339-b222-6f0e08988563@gmail.com>
On 2016/12/9 23:07, Marty Plummer wrote:
> On 12/04/2016 08:03 PM, Jiancheng Xue wrote:
>> Hi Arnd,
>>
>> On 2016/10/17 21:48, Arnd Bergmann wrote:
>>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>>
>>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>>
>>>
>>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>>> patches for Hi3520, which I think is closely related to this one.
>>> Please try to work together so the patches don't conflict. It should
>>> be fairly straightforward since you are basically doing the same
>>> change here.
>>>
>> Marty hasn't give any replies about this thread until now. I reviewed
>> the patch for Hi3520. And I think this patch won't conflict with Hi3520.
>> Could you help us to ack this patch?
>>
>> Thanks,
>> Jiancheng
>>
>>
> Hello all
>
> Sorry for my lack of activity, I've just been very busy lately with real
> world considerations (well, real world but related to this; I have
> another board based on hi3521a I've been tinkering with, trying to get
> the manuf. to release gpl source via the sfconfservancy). I've not given
> up on the project, however, since devices like this really need updates
> in light of the recent botnets targeting devices of this sort as
> manpower.
Do you have any objections to this patch? If not, I hope this patch can
be merged in 4.10. Thank you.
Regards,
Jiancheng
^ permalink raw reply
* [PATCH] serial: mxs-auart: support CMSPAR termios cflag
From: Wolfgang Ocker @ 2016-12-12 7:21 UTC (permalink / raw)
To: linux-arm-kernel
If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled.
Tested on an i.MX28 system
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
v2: require PARENB to be also set in termios' c_cflag for CMSPAR
---
drivers/tty/serial/mxs-auart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 770454e0dfa3..fd819ea26762 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -95,6 +95,7 @@
#define AUART_LINECTRL_BAUD_DIVFRAC_SHIFT 8
#define AUART_LINECTRL_BAUD_DIVFRAC_MASK 0x00003f00
#define AUART_LINECTRL_BAUD_DIVFRAC(v) (((v) & 0x3f) << 8)
+#define AUART_LINECTRL_SPS (1 << 7)
#define AUART_LINECTRL_WLEN_MASK 0x00000060
#define AUART_LINECTRL_WLEN(v) (((v) & 0x3) << 5)
#define AUART_LINECTRL_FEN (1 << 4)
@@ -1014,6 +1015,8 @@ static void mxs_auart_settermios(struct uart_port *u,
ctrl |= AUART_LINECTRL_PEN;
if ((cflag & PARODD) == 0)
ctrl |= AUART_LINECTRL_EPS;
+ if (cflag & CMSPAR)
+ ctrl |= AUART_LINECTRL_SPS;
}
u->read_status_mask = 0;
--
2.10.0
^ permalink raw reply related
* [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-12-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210094429.yp26sfoz54oqy3dz@lukather>
Hi Maxime,
On 10/12/2016 10:44, Maxime Ripard wrote:
> Hi,
>
> Just some minor comments.
>
> On Fri, Dec 09, 2016 at 11:22:36AM +0100, Quentin Schulz wrote:
>> + /*
>> + * Since the thermal sensor needs the IP to be in touchscreen mode and
>> + * there is no register to know if the IP has finished its transition
>> + * between the two modes, a delay is required when switching modes. This
>> + * slows down ADC readings while the latter are critical data to the
>
> The latter between what and what?
>
>> + * user. Disabling CONFIG_THERMAL_OF in kernel configuration allows the
>> + * user to avoid registering the thermal sensor (thus unavailable) and
>
> Isn't it obvious that it's not going to be available if you do not
> register it?
>
>> + * does not switch between modes thus "quicken" the ADC readings.
>> + * The thermal sensor should be enabled by default since the SoC
>> + * temperature is usually more critical than ADC readings.
>
> This last sentence should be in the Kconfig help. You cannot expect
> that all your users will read all the source code they want to compile
> :)
>
> Overall, I think this comment is kind of missing the point, maybe
> something like:
>
> /*
> * Since the controller needs to be in touchscreen mode for its
> * thermal sensor to operate properly, and that switching between the
> * two modes needs a delay, always registering in the thermal
> * framework will significantly slow down the conversion rate of the
> * ADCs.
> *
> * Therefore, instead of depending on THERMAL_OF in Kconfig, we only
> * register the sensor if that option is enabled, eventually leaving
> * that choice to the user.
> */
>
> Would be much clearer.
>
>> + */
>> +
>> + if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> + /*
>> + * This driver is a child of an MFD which has a node in the DT but not
>> + * its children. Therefore, the resulting devices of this driver do not
>
> Wrong indentation for the comment, and saying why the MFD children
> don't have a node in the DT (backward compatibility) would be nice.
>
Thanks for the comments, that's indeed much clearer.
>> + * have an of_node variable.
>> + * However, its parent (the MFD driver) has an of_node variable and
>> + * since devm_thermal_zone_of_sensor_register uses its first argument to
>> + * match the phandle defined in the node of the thermal driver with the
>> + * of_node of the device passed as first argument and the third argument
>> + * to call ops from thermal_zone_of_device_ops, the solution is to use
>> + * the parent device as first argument to match the phandle with its
>> + * of_node, and the device from this driver as third argument to return
>> + * the temperature.
>> + */
>> + tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
>> + info,
>> + &sun4i_ts_tz_ops);
>
> I don't think tzd is used anywhere else in your function, it can be
> made local to this block.
>
ACK.
Thanks,
Quentin
--
Quentin Schulz, 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: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/a1ddfd4a/attachment.sig>
^ permalink raw reply
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Lee Jones @ 2016-12-12 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> + programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 2/8] MFD: add STM32 Timers driver
From: Lee Jones @ 2016-12-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-3-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> This hardware block could at used at same time for PWM generation
> and IIO timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
>
> version 6:
> - rename files to stm32-timers
> - rename functions to stm32_timers_xxx
>
> version 5:
> - fix Lee comments about detect function
> - add missing dependency on REGMAP_MMIO
>
> version 4:
> - add a function to detect Auto Reload Register (ARR) size
> - rename the structure shared with other drivers
>
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/mfd/Kconfig | 11 ++++++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/stm32-timers.h | 71 +++++++++++++++++++++++++++++++++++
> 4 files changed, 164 insertions(+)
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 include/linux/mfd/stm32-timers.h
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df644..4ec1906 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1607,6 +1607,17 @@ config MFD_STW481X
> in various ST Microelectronics and ST-Ericsson embedded
> Nomadik series.
>
> +config MFD_STM32_TIMERS
> + tristate "Support for STM32 Timers"
> + depends on (ARCH_STM32 && OF) || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP
> + select REGMAP_MMIO
> + help
> + Select this option to enable STM32 timers driver used
> + for PWM and IIO Timer. This driver allow to share the
> + registers between the others drivers.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..11a52f8 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,5 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +
> +obj-$(CONFIG_MFD_STM32_TIMERS) += stm32-timers.o
> diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
> new file mode 100644
> index 0000000..68d115e
> --- /dev/null
> +++ b/drivers/mfd/stm32-timers.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/mfd/stm32-timers.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +
> +static const struct regmap_config stm32_timers_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 0x400,
> +};
> +
> +static void stm32_timers_get_arr_size(struct stm32_timers *ddata)
> +{
> + /*
> + * Only the available bits will be written so when readback
> + * we get the maximum value of auto reload register
> + */
> + regmap_write(ddata->regmap, TIM_ARR, ~0L);
> + regmap_read(ddata->regmap, TIM_ARR, &ddata->max_arr);
> + regmap_write(ddata->regmap, TIM_ARR, 0x0);
> +}
> +
> +static int stm32_timers_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stm32_timers *ddata;
> + struct resource *res;
> + void __iomem *mmio;
> +
> + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mmio = devm_ioremap_resource(dev, res);
> + if (IS_ERR(mmio))
> + return PTR_ERR(mmio);
> +
> + ddata->regmap = devm_regmap_init_mmio_clk(dev, "clk_int", mmio,
> + &stm32_timers_regmap_cfg);
> + if (IS_ERR(ddata->regmap))
> + return PTR_ERR(ddata->regmap);
> +
> + ddata->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddata->clk))
> + return PTR_ERR(ddata->clk);
> +
> + stm32_timers_get_arr_size(ddata);
> +
> + platform_set_drvdata(pdev, ddata);
> +
> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +}
> +
> +static const struct of_device_id stm32_timers_of_match[] = {
> + { .compatible = "st,stm32-timers", },
> + { /* end node */ },
> +};
> +MODULE_DEVICE_TABLE(of, stm32_timers_of_match);
> +
> +static struct platform_driver stm32_timers_driver = {
> + .probe = stm32_timers_probe,
> + .driver = {
> + .name = "stm32-timers",
> + .of_match_table = stm32_timers_of_match,
> + },
> +};
> +module_platform_driver(stm32_timers_driver);
> +
> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timers");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> new file mode 100644
> index 0000000..d030004
> --- /dev/null
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _LINUX_STM32_GPTIMER_H_
> +#define _LINUX_STM32_GPTIMER_H_
> +
> +#include <linux/clk.h>
> +#include <linux/regmap.h>
> +
> +#define TIM_CR1 0x00 /* Control Register 1 */
> +#define TIM_CR2 0x04 /* Control Register 2 */
> +#define TIM_SMCR 0x08 /* Slave mode control reg */
> +#define TIM_DIER 0x0C /* DMA/interrupt register */
> +#define TIM_SR 0x10 /* Status register */
> +#define TIM_EGR 0x14 /* Event Generation Reg */
> +#define TIM_CCMR1 0x18 /* Capt/Comp 1 Mode Reg */
> +#define TIM_CCMR2 0x1C /* Capt/Comp 2 Mode Reg */
> +#define TIM_CCER 0x20 /* Capt/Comp Enable Reg */
> +#define TIM_PSC 0x28 /* Prescaler */
> +#define TIM_ARR 0x2c /* Auto-Reload Register */
> +#define TIM_CCR1 0x34 /* Capt/Comp Register 1 */
> +#define TIM_CCR2 0x38 /* Capt/Comp Register 2 */
> +#define TIM_CCR3 0x3C /* Capt/Comp Register 3 */
> +#define TIM_CCR4 0x40 /* Capt/Comp Register 4 */
> +#define TIM_BDTR 0x44 /* Break and Dead-Time Reg */
> +
> +#define TIM_CR1_CEN BIT(0) /* Counter Enable */
> +#define TIM_CR1_ARPE BIT(7) /* Auto-reload Preload Ena */
> +#define TIM_CR2_MMS (BIT(4) | BIT(5) | BIT(6)) /* Master mode selection */
> +#define TIM_SMCR_SMS (BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
> +#define TIM_SMCR_TS (BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
> +#define TIM_DIER_UIE BIT(0) /* Update interrupt */
> +#define TIM_SR_UIF BIT(0) /* Update interrupt flag */
> +#define TIM_EGR_UG BIT(0) /* Update Generation */
> +#define TIM_CCMR_PE BIT(3) /* Channel Preload Enable */
> +#define TIM_CCMR_M1 (BIT(6) | BIT(5)) /* Channel PWM Mode 1 */
> +#define TIM_CCER_CC1E BIT(0) /* Capt/Comp 1 out Ena */
> +#define TIM_CCER_CC1P BIT(1) /* Capt/Comp 1 Polarity */
> +#define TIM_CCER_CC1NE BIT(2) /* Capt/Comp 1N out Ena */
> +#define TIM_CCER_CC1NP BIT(3) /* Capt/Comp 1N Polarity */
> +#define TIM_CCER_CC2E BIT(4) /* Capt/Comp 2 out Ena */
> +#define TIM_CCER_CC3E BIT(8) /* Capt/Comp 3 out Ena */
> +#define TIM_CCER_CC4E BIT(12) /* Capt/Comp 4 out Ena */
> +#define TIM_CCER_CCXE (BIT(0) | BIT(4) | BIT(8) | BIT(12))
> +#define TIM_BDTR_BKE BIT(12) /* Break input enable */
> +#define TIM_BDTR_BKP BIT(13) /* Break input polarity */
> +#define TIM_BDTR_AOE BIT(14) /* Automatic Output Enable */
> +#define TIM_BDTR_MOE BIT(15) /* Main Output Enable */
> +#define TIM_BDTR_BKF (BIT(16) | BIT(17) | BIT(18) | BIT(19))
> +#define TIM_BDTR_BK2F (BIT(20) | BIT(21) | BIT(22) | BIT(23))
> +#define TIM_BDTR_BK2E BIT(24) /* Break 2 input enable */
> +#define TIM_BDTR_BK2P BIT(25) /* Break 2 input polarity */
> +
> +#define MAX_TIM_PSC 0xFFFF
> +#define TIM_CR2_MMS_SHIFT 4
> +#define TIM_SMCR_TS_SHIFT 4
> +#define TIM_BDTR_BKF_MASK 0xF
> +#define TIM_BDTR_BKF_SHIFT 16
> +#define TIM_BDTR_BK2F_SHIFT 20
> +
> +struct stm32_timers {
> + struct clk *clk;
> + struct regmap *regmap;
> + u32 max_arr;
> +};
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2016-12-12 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-1-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
>
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
>
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
>
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
>
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
> - pwm channels, complementary output, counter size, break input
> - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>
> The following patches enable PWM and IIO Timer features for STM32 platforms.
>
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver
> on the top of them to be able to share the registers.
>
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to
> describe the differences between hardware blocks
>
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
>
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
>
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>
> The matrix of possible connections between blocks is quite complex so we use
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
>
> At run time IIO timer hardware blocks can configure (through "master_mode"
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
>
> By using "slave_mode" IIO device attribute timer can also configure on which
> event (level, rising edge) of the block is enabled.
>
> Since we can use trigger from one hardware to control an other block, we can
> use a pwm to control an other one. The following example shows how to configure
> pwm1 and pwm3 to make pwm3 generate pulse only when pwm1 pulse level is high.
>
> /sys/bus/iio/devices # ls
> iio:device0 iio:device1 trigger0 trigger1
>
> configure timer1 to use pwm1 channel 0 as output trigger
> /sys/bus/iio/devices # echo 'OC1REF' > iio\:device0/master_mode
> configure timer3 to enable only when input is high
> /sys/bus/iio/devices # echo 'gated' > iio\:device1/slave_mode
> /sys/bus/iio/devices # cat trigger0/name
> tim1_trgo
> configure timer2 to use timer1 trigger is input
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
>
> configure pwm3 channel 0 to generate a signal with a period of 100ms and a
> duty cycle of 50%
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 100000000 > pwm0/period
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
> here pwm3 channel 0, as expected, doesn't start because has to be triggered by
> pwm1 channel 0
>
> configure pwm1 channel 0 to generate a signal with a period of 1s and a
> duty cycle of 50%
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 0 > export
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1000000000 > pwm0/period
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1 > pwm0/enable
> finally pwm1 starts and pwm3 only generates pulse when pwm1 signal is high
>
> An other example to use a timer as source of clock for another device.
> Here timer1 is used a source clock for pwm3:
>
> /sys/bus/iio/devices # echo 100000 > trigger0/sampling_frequency
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
> /sys/bus/iio/devices # echo 'external_clock' > iio\:device1/slave_mode
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1000000 > pwm0/period
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
>
> Benjamin Gaignard (8):
> MFD: add bindings for STM32 Timers driver
> MFD: add STM32 Timers driver
> PWM: add pwm-stm32 DT bindings
> PWM: add PWM driver for STM32 plaftorm
> IIO: add bindings for STM32 timer trigger driver
> IIO: add STM32 timer trigger driver
> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> ARM: dts: stm32: Enable pw1 and pwm3 for stm32f469-disco
>
> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 +
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++
> arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> drivers/iio/Kconfig | 2 +-
> drivers/iio/Makefile | 1 +
> drivers/iio/timer/Kconfig | 13 +
> drivers/iio/timer/Makefile | 1 +
> drivers/iio/timer/stm32-timer-trigger.c | 466 +++++++++++++++++++++
> drivers/iio/trigger/Kconfig | 1 -
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 434 +++++++++++++++++++
> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
> include/linux/mfd/stm32-timers.h | 71 ++++
> 20 files changed, 1612 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> create mode 100644 drivers/iio/timer/Kconfig
> create mode 100644 drivers/iio/timer/Makefile
> create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 drivers/pwm/pwm-stm32.c
> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> create mode 100644 include/linux/mfd/stm32-timers.h
This has really come together nicely.
Great work Benjamin.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Boris Brezillon @ 2016-12-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
best_rate is reported as potentially uninitialized by gcc.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/clk/bcm/clk-bcm2835.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index eaf82f49dede..0d14409097e7 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1029,7 +1029,7 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
struct bcm2835_cprman *cprman = clock->cprman;
const struct bcm2835_clock_data *data = clock->data;
- unsigned long best_rate;
+ unsigned long best_rate = 0;
u32 curdiv, mindiv, maxdiv;
struct clk_hw *parent;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-12-12 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Hi all,
I forgot to add a question to my cover letter so here it is:
The X-Powers AXP209 and AXP223 PMICs allow to not limit the maximal
current for the VBUS power supply.[1]
(If a Chinese-speaking person could check it's the same for the AXP221
that would be great also[2]).
In the get_property (axp20x_usb_power_get_property) of the power supply
driver, I see that we use -1 as value for "no limit". Should we use the
same (-1) value for the set_property (axp20x_usb_power_set_property) to
disable max current limit?
[1] http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf page 33,
REG 30H, BITS 0 & 1
[2]
http://dl.linux-sunxi.org/AXP/AXP221%20Datasheet%20V1.2%2020130326%20.pdf
page 33, REG 30H, BITS 0 & 1 => ??? is written for when the BIT(1) is
set.
Thanks,
Quentin
On 09/12/2016 12:04, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
>
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
>
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
>
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
>
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
>
> Quentin Schulz (11):
> power: supply: axp20x_usb_power: use of_device_id data field instead
> of device_is_compatible
> mfd: axp20x: add volatile and writeable reg ranges for VBUS power
> supply driver
> power: supply: axp20x_usb_power: set min voltage and max current from
> sysfs
> Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
> power: supply: axp20x_usb_power: add 100mA max current limit for
> AXP223
> mfd: axp20x: add separate MFD cell for AXP223
> ARM: dtsi: add DTSI for AXP223
> ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
> ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
> ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
> ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
>
> .../bindings/power/supply/axp20x_usb_power.txt | 5 +
> arch/arm/boot/dts/axp223.dtsi | 58 +++++++++++
> arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
> arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
> .../boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
> drivers/mfd/axp20x.c | 32 +++++-
> drivers/power/supply/axp20x_usb_power.c | 116 ++++++++++++++++++---
> 8 files changed, 197 insertions(+), 22 deletions(-)
> create mode 100644 arch/arm/boot/dts/axp223.dtsi
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Arnd Bergmann @ 2016-12-12 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481529653-28133-1-git-send-email-boris.brezillon@free-electrons.com>
On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> best_rate is reported as potentially uninitialized by gcc.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
I wonder why I didn't get that. Which compiler version did you use?
Arnd
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2016-12-12 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584CB481.3040902@redhat.com>
Hi Don,
On 11/12/2016 03:05, Don Dutile wrote:
> On 12/08/2016 04:36 AM, Auger Eric wrote:
>> Hi,
>>
>> On 15/11/2016 14:09, Eric Auger wrote:
>>> Following LPC discussions, we now report reserved regions through
>>> iommu-group sysfs reserved_regions attribute file.
>>
>>
>> While I am respinning this series into v4, here is a tentative summary
>> of technical topics for which no consensus was reached at this point.
>>
>> 1) Shall we report the usable IOVA range instead of reserved IOVA
>> ranges. Not discussed at/after LPC.
>> x I currently report reserved regions. Alex expressed the need to
>> report the full usable IOVA range instead (x86 min-max range
>> minus MSI APIC window). I think this is meaningful for ARM
>> too where arm-smmu might not support the full 64b range.
>> x Any objection we report the usable IOVA regions instead?
>>
>> 2) Shall the kernel check collision with MSI window* when userspace
>> calls VFIO_IOMMU_MAP_DMA?
>> Joerg/Will No; Alex yes
>> *for IOVA regions consumed downstream to the IOMMU: everyone says NO
>>
>> 3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no
> Um, I'm missing context, but the only thing I recall saying no to wrt RMRR
> is that _any_ device that has an RMRR cannot be assigned to a guest.
Yes that was my understanding
> Or, are you saying, RMRR's should be exposed in the guest os? if so, then
> you have my 'no' there.
>
>> My current series does not expose them in iommu group sysfs.
>> I understand we can expose the RMRR regions in the iomm group sysfs
>> without necessarily supporting RMRR requiring device assignment.
> This sentence doesn't make sense to me.
> Can you try re-wording it?
> I can't tell what RMRR has to do w/device assignment, other than what I
> said above.
> Exposing RMRR's in sysfs is not an issue in general.
Sorry for the confusion. I Meant we can expose RMRR regions as part of
the reserved regions through the iommu group sysfs API without
supporting device assignment of devices that has RMRR.
Hope it clarifies
Eric
>
>> We can also add this support later.
>>
>> Thanks
>>
>> Eric
>>
>>
>>>
>>> Reserved regions are populated through the IOMMU get_resv_region
>>> callback
>>> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
>>> arm-smmu.
>>>
>>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>>> IOMMU_RESV_NOMAP reserved region.
>>>
>>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
>>> 1MB large) and the PCI host bridge windows.
>>>
>>> The series integrates a not officially posted patch from Robin:
>>> "iommu/dma: Allow MSI-only cookies".
>>>
>>> This series currently does not address IRQ safety assessment.
>>>
>>> Best Regards
>>>
>>> Eric
>>>
>>> Git: complete series available at
>>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>>
>>> History:
>>> RFC v2 -> v3:
>>> - switch to an iommu-group sysfs API
>>> - use new dummy allocator provided by Robin
>>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>>> the reserved regions
>>> - at the moment ARM MSI base address/size is left unchanged compared
>>> to v2
>>> - we currently report reserved regions and not usable IOVA regions as
>>> requested by Alex
>>>
>>> RFC v1 -> v2:
>>> - fix intel_add_reserved_regions
>>> - add mutex lock/unlock in vfio_iommu_type1
>>>
>>>
>>> Eric Auger (10):
>>> iommu/dma: Allow MSI-only cookies
>>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>>> iommu: Add new reserved IOMMU attributes
>>> iommu: iommu_alloc_resv_region
>>> iommu: Do not map reserved regions
>>> iommu: iommu_get_group_resv_regions
>>> iommu: Implement reserved_regions iommu-group sysfs file
>>> iommu/vt-d: Implement reserved region get/put callbacks
>>> iommu/arm-smmu: Implement reserved region get/put callbacks
>>> vfio/type1: Get MSI cookie
>>>
>>> drivers/iommu/amd_iommu.c | 20 +++---
>>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
>>> drivers/iommu/dma-iommu.c | 116
>>> ++++++++++++++++++++++++++-------
>>> drivers/iommu/intel-iommu.c | 50 ++++++++++----
>>> drivers/iommu/iommu.c | 141
>>> ++++++++++++++++++++++++++++++++++++----
>>> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
>>> include/linux/dma-iommu.h | 7 ++
>>> include/linux/iommu.h | 49 ++++++++++----
>>> 8 files changed, 391 insertions(+), 70 deletions(-)
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Stephen Rothwell @ 2016-12-12 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3107859.uaKLk6DMRd@wuerfel>
Hi Arnd,
On Mon, 12 Dec 2016 09:12:36 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > best_rate is reported as potentially uninitialized by gcc.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I wonder why I didn't get that. Which compiler version did you use?
Gcc-5.2.0 powerpc-le hosted cross compiler.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.10
From: Simon Horman @ 2016-12-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC fixes for v4.10.
This provides an sd0_uhs node rather than duplicate sdh0 nodes
resolving an error introduced in a clean-up patch.
This pull request is based on "Second Round of Renesas ARM Based SoC DT
Updates for v4.10", tagged as renesas-arm64-dt2-for-v4.10,
which you have already pulled. The error corrected by this change
was introduced in that pull-request.
The following changes since commit 5de68961cf5618c1ce5bb15848b36121247f23d5:
arm64: dts: r8a7796: Add device node for PRR (2016-11-21 10:18:53 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes-for-v4.10
for you to fetch changes up to 8ebcb400af619ee0ddeb39c06fc35511b20cc697:
arm64: dts: h3ulcb: Provide sd0_uhs node (2016-12-08 14:29:17 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC Fixes for v4.10
* Provide sd0_uhs node
----------------------------------------------------------------
Simon Horman (1):
arm64: dts: h3ulcb: Provide sd0_uhs node
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] arm64: dts: h3ulcb: Provide sd0_uhs node
From: Simon Horman @ 2016-12-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481530910.git.horms+renesas@verge.net.au>
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6ffb0517421a..dbea2c3d8f0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -169,7 +169,7 @@
power-source = <3300>;
};
- sdhi0_pins_uhs: sd0 {
+ sdhi0_pins_uhs: sd0_uhs {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Boris Brezillon @ 2016-12-12 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3107859.uaKLk6DMRd@wuerfel>
On Mon, 12 Dec 2016 09:12:36 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > best_rate is reported as potentially uninitialized by gcc.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I wonder why I didn't get that. Which compiler version did you use?
>
In case you're interested, my gcc [1] failed to detect it as well, and
this is not the first time it happens :-/.
[1]gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Arnd Bergmann @ 2016-12-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212093130.6e348a61@bbrezillon>
On Monday, December 12, 2016 9:31:30 AM CET Boris Brezillon wrote:
> On Mon, 12 Dec 2016 09:12:36 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > > best_rate is reported as potentially uninitialized by gcc.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > I wonder why I didn't get that. Which compiler version did you use?
> >
>
> In case you're interested, my gcc [1] failed to detect it as well, and
> this is not the first time it happens :-/.
>
> [1]gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
No, I see it now with gcc-7, it only just turned up in linux-next.
I ran into it right away with an allmodconfig build. You were
probably testing based on an earlier v4.9-rc release that had
the warning globally disabled.
Arnd
^ permalink raw reply
* [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211214232.GA2552@katana>
Hi Wolfram,
Thanks for your comments.
I will fix all of them + build errors reported by build-bot in the V6.
Best regards,
Cedric Madianga
2016-12-11 22:42 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
> Hi,
>
>> +config I2C_STM32F4
>> + tristate "STMicroelectronics STM32F4 I2C support"
>> + depends on ARCH_STM32 || COMPILE_TEST
>
> Double space.
>
>> +#define STM32F4_I2C_MIN_FREQ 2
>> +#define STM32F4_I2C_MAX_FREQ 42
>
> Those two must be unsigned to fix the build error (e.g. 2U) reported by
> build-bot.
>
> Also, I get the following build warnings:
>
> CC drivers/i2c/busses/i2c-stm32f4.o
> drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_handle_rx_addr?:
> drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
> u32 sr2;
> ^~~
> drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_isr_event?:
> drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
> u32 real_status, possible_status, ien, sr2;
>
> I assume those are reads to clear the register, so we really don't need
> to save the value in a variable.
>
> Rest is looking good.
>
> Thanks,
>
> Wolfram
>
^ 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