* [PATCH] arm64/dts/ls2080a-rdb: remove disable status of pca9547
From: Shawn Guo @ 2017-01-02 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482213787-27814-1-git-send-email-meng.yi@nxp.com>
On Tue, Dec 20, 2016 at 02:03:07PM +0800, Meng Yi wrote:
> pca9547 won't probed since its status property is disabled.
> while there are devices connected to it, we need remove status
> property to let ds3232 and adt7461 probed correctly.
>
> Signed-off-by: Meng Yi <meng.yi@nxp.com>
Changed subject prefix to 'arm64: dts: ls2080a-rdb: ', and applied the
patch.
Shawn
^ permalink raw reply
* [PATCH] ARM: dts: imx28: Add simple-card support
From: Shawn Guo @ 2017-01-02 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220153516.19222-1-joerg.krause@embedded.rocks>
On Tue, Dec 20, 2016 at 04:35:16PM +0100, J?rg Krause wrote:
> Add simple-card support to SAIF0 and SAIF1.
>
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
Applied, thanks.
^ permalink raw reply
* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Sylwester Nawrocki @ 2017-01-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230155312.oupgyip7wtqwcuy2@kozik-lap>
On 12/30/2016 04:53 PM, Krzysztof Kozlowski wrote:
>
> Any comments on this? I guess it won't come as late-late-4.10, so can
> you pull it for v4.11?
>> Sylwester Nawrocki (1):
>> ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
We need this patch in v4.10 to avoid possible I2S and MMC regressions
on selected s3c24xx SoC, since the DMA clients are already modified.
If the patch goes in only for v4.11 it would be good to mark it for
inclusion in v4.10 stable kernels.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6dl: Add Engicam i.CoreM6 DualLite/Solo RQS initial support
From: Shawn Guo @ 2017-01-02 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482508935-9414-1-git-send-email-jagan@openedev.com>
On Fri, Dec 23, 2016 at 05:02:14PM +0100, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> i.CoreM6 DualLite/Solo modules are system on module solutions manufactured
> by Engicam with following characteristics:
> CPU NXP i.MX6 DL, 800MHz
> RAM 1GB, 32, 64 bit, DDR3-800/1066
> NAND SLC,512MB
> Power supply Single 5V
> MAX LCD RES FULLHD
>
> and more info at
> http://www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-icore-rqs.dts | 51 ++++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-icore-rqs.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index cccdbcb..51f8dae 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -349,6 +349,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-gw553x.dtb \
> imx6dl-hummingboard.dtb \
> imx6dl-icore.dtb \
> + imx6dl-icore-rqs.dtb \
> imx6dl-nit6xlite.dtb \
> imx6dl-nitrogen6x.dtb \
> imx6dl-phytec-pbab01.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-icore-rqs.dts b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> new file mode 100644
> index 0000000..5c19927
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (C) 2016 Amarula Solutions B.V.
> + * Copyright (C) 2016 Engicam S.r.l.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
Please take a look at the following patch.
https://patchwork.kernel.org/patch/9475057/
Shawn
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-icore-rqs.dtsi"
> +
> +/ {
> + model = "Engicam i.CoreM6 DualLite/Solo RQS Starter Kit";
> + compatible = "engicam,imx6-icore-rqs", "fsl,imx6dl";
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series
From: M'boumba Cedric Madianga @ 2017-01-02 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102041433.GM3573@localhost>
Hi Vinod,
> So you should order fixes first and then new additions.
> Fixes go in for current release whereas the rest for next one.
Ok thanks for the info.
> I have applied two to fixes and rest to updated, patch 5 didn't apply, please
> resend that one.
I have tried to apply patch 5 on top of slave-dma/fixes branch but I
don't have any issue.
So, I am going to resend this patch in order to be sure that there is no diff.
Best regards,
Cedric
^ permalink raw reply
* [PATCH v4 2/4] ARM: da850: don't add the emac clock to the clock lookup table twice
From: Sekhar Nori @ 2017-01-02 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481124138-27337-3-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 07 December 2016 08:52 PM, Bartosz Golaszewski wrote:
> Similarly to the aemif clock - this screws up the linked list of clock
> children. Create a separate clock for mdio inheriting the rate from
> emac_clk.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied with change in headline (see comment on 1/4). Also added a
comment explaining why mdio clk is needed.
> ---
> arch/arm/mach-davinci/da850.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index e9d019c..6b1fbac 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -319,6 +319,11 @@ static struct clk emac_clk = {
> .gpsc = 1,
> };
>
/*
* In order to avoid adding the emac_clk to the clock lookup table twice (and
* screwing up the linked list in the process) create a separate clock for
* mdio inheriting the rate from emac_clk.
*/
> +static struct clk mdio_clk = {
> + .name = "mdio",
> + .parent = &emac_clk,
> +};
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4 3/4] ARM: da850: coding style fix
From: Sekhar Nori @ 2017-01-02 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481124138-27337-4-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 07 December 2016 08:52 PM, Bartosz Golaszewski wrote:
> Fix alignment of the clock lookup table entries.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/fixes-non-critical
Thanks,
Sekhar
^ permalink raw reply
* [PATCH RESEND] dmaengine: stm32-dma: Rework starting transfer management
From: M'boumba Cedric Madianga @ 2017-01-02 9:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch reworks the way to manage transfer starting.
Now, starting DMA is only allowed when the channel is not busy.
Then, stm32_dma_start_transfer is declared as void.
At least, after each transfer completion, we start the next transfer if a
new descriptor as been queued in the issued list during an ongoing
transfer.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3056ce7..adb846c 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -421,7 +421,7 @@ static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "SFCR: 0x%08x\n", sfcr);
}
-static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
+static void stm32_dma_start_transfer(struct stm32_dma_chan *chan)
{
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
struct virt_dma_desc *vdesc;
@@ -432,12 +432,12 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
- return ret;
+ return;
if (!chan->desc) {
vdesc = vchan_next_desc(&chan->vchan);
if (!vdesc)
- return -EPERM;
+ return;
chan->desc = to_stm32_dma_desc(vdesc);
chan->next_sg = 0;
@@ -471,7 +471,7 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
chan->busy = true;
- return 0;
+ dev_dbg(chan2dev(chan), "vchan %p: started\n", &chan->vchan);
}
static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
@@ -552,15 +552,13 @@ static void stm32_dma_issue_pending(struct dma_chan *c)
{
struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
unsigned long flags;
- int ret;
spin_lock_irqsave(&chan->vchan.lock, flags);
- if (!chan->busy) {
- if (vchan_issue_pending(&chan->vchan) && !chan->desc) {
- ret = stm32_dma_start_transfer(chan);
- if ((!ret) && (chan->desc->cyclic))
- stm32_dma_configure_next_sg(chan);
- }
+ if (vchan_issue_pending(&chan->vchan) && !chan->desc && !chan->busy) {
+ dev_dbg(chan2dev(chan), "vchan %p: issued\n", &chan->vchan);
+ stm32_dma_start_transfer(chan);
+ if (chan->desc->cyclic)
+ stm32_dma_configure_next_sg(chan);
}
spin_unlock_irqrestore(&chan->vchan.lock, flags);
}
--
1.9.1
^ permalink raw reply related
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2017-01-02 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com>
> -----Original Message-----
> From: Rafal Ozieblo
> Sent: 28 grudnia 2016 14:23
> Subject: RE: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
>
> > +static void gem_ptp_tx_hwtstamp(struct macb *bp, struct sk_buff *skb,
> > + int peer_ev)
> > +{
> > + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> > + struct timespec64 ts;
> > + u64 ns;
> > +
> > + /* PTP Peer Event Frame packets */
> > + if (peer_ev) {
> > + ts.tv_sec = gem_readl(bp, PEFTSL);
> > + ts.tv_nsec = gem_readl(bp, PEFTN);
> > +
> > + /* PTP Event Frame packets */
> > + } else {
> > + ts.tv_sec = gem_readl(bp, EFTSL);
> > + ts.tv_nsec = gem_readl(bp, EFTN);
> > + }
> I'm wondering what is a difference between timestamp in transmit buffer descriptor (Word 2 and 3) and PTP Event Frame Transmitted Seconds/Nanoseconds Register (0x1E0, 0x1E4).
>
According Cadence Hardware team:
"It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
The question is are you sure that you read timestamp for current frame? (not for the next frame).
^ permalink raw reply
* How should we handle variable address space sizes (Re: [RFC 3/4] x86/mm: define TASK_SIZE as current->mm->task_size)
From: Kirill A. Shutemov @ 2017-01-02 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrXMCVOmVcQYxF_ghPdEjLuNNqbcnoRKRVpJegsQ=SPEFQ@mail.gmail.com>
On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> > Keep task's virtual address space size as mm_struct field which
> > exists for a long time - it's initialized in setup_new_exec()
> > depending on the new task's personality.
> > This way TASK_SIZE will always be the same as current->mm->task_size.
> > Previously, there could be an issue about different values of
> > TASK_SIZE and current->mm->task_size: e.g, a 32-bit process can unset
> > ADDR_LIMIT_3GB personality (with personality syscall) and
> > so TASK_SIZE will be 4Gb, which is larger than mm->task_size = 3Gb.
> > As TASK_SIZE *and* current->mm->task_size are used both in code
> > frequently, this difference creates a subtle situations, for example:
> > one can mmap addresses > 3Gb, but they will be hidden in
> > /proc/pid/pagemap as it checks mm->task_size.
> > I've moved initialization of mm->task_size earlier in setup_new_exec()
> > as arch_pick_mmap_layout() initializes mmap_legacy_base with
> > TASK_UNMAPPED_BASE, which depends on TASK_SIZE.
>
> I don't like this patch so much because I think that we should figure
> out how this will all work in the long run first. I've added some
> more people to the thread because other arches have similar issues and
> because x86 is about to get considerably more complicated (choices
> include 3GB, 4GB, 47-bit, and 56-bit (the latter IIRC)).
>
> Here are a few of my thoughts on the matter. This isn't all that well
> thought out:
>
> The address space limit, especially if CRIU is in play, isn't really a
> hard limit. For example, you could allocate high memory then lower
> the limit. Similarly, I see no reason that an x32 program should be
> forbidden from mapping some high addresses or, similarly, that an i386
> program can't (if it really wanted to) do a 64-bit mmap() and get a
> high address.
>
> On that note, can we just *delete* the task_size check from pagemap?
> It's been there since the very beginning:
>
> commit 85863e475e59afb027b0113290e3796ee6020b7d
> Author: Matt Mackall <mpm@selenic.com>
> Date: Mon Feb 4 22:29:04 2008 -0800
>
> maps4: add /proc/pid/pagemap interface
>
> and there's no explanation for why it's needed.
>
> So maybe we should have a *number* (not a bit) that indicates the
> maximum address that mmap() will return unless an override is in use.
> Since common practice seems to be to stick this in the personality
> field, we may need some fancy encoding. Executing a setuid binary
> needs to reset to the default, and personality handles that.
If we want to be able to specify arbitrary address as maximum, a fancy
encoding would need to claim 51 bits (63 VA - 12 in-page address) on x86
from the persona flag.
To me, it's stretching personality interface too far.
Maybe it's easier to reset the rlimit for suid binaries?
--
Kirill A. Shutemov
^ permalink raw reply
* [RFC 1/4] mm: remove unused TASK_SIZE_OF()
From: Kirill A. Shutemov @ 2017-01-02 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230155634.8692-2-dsafonov@virtuozzo.com>
On Fri, Dec 30, 2016 at 06:56:31PM +0300, Dmitry Safonov wrote:
> All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
> TASK_SIZE_MAX since:
> commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
> FSBASE/GSBASE upper limits"),
> commit a06db751c321 ("pagemap: check permissions and capabilities at
> open time"),
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mips at linux-mips.org
> Cc: linux-parisc at vger.kernel.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-s390 at vger.kernel.org
> Cc: sparclinux at vger.kernel.org
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
I've noticed this too.
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH v2] drivers: remoteproc: constify rproc_ops structures
From: Bjorn Andersson @ 2017-01-02 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483267417-7850-1-git-send-email-bhumirks@gmail.com>
On Sun 01 Jan 02:43 PST 2017, Bhumika Goyal wrote:
> Declare rproc_ops structures as const as they are only passed as an
> argument to the function rproc_alloc. This argument is of type const, so
> rproc_ops structures having this property can be declared const too.
Thanks Bhumika, applied.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v4 4/4] ARM: da850: fix da850_set_pll0rate()
From: Sekhar Nori @ 2017-01-02 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481124138-27337-5-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 07 December 2016 08:52 PM, Bartosz Golaszewski wrote:
> This function is confusing - its second argument is an index to the
> freq table, not the requested clock rate in Hz, but it's used as the
> set_rate callback for the pll0 clock. It leads to an oops when the
> caller doesn't know the internals and passes the rate in Hz as
> argument instead of the cpufreq index since this argument isn't bounds
> checked either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Also: update the davinci cpufreq driver. It's the only user of this
> clock and currently it passes the cpufreq table index to
> clk_set_rate(), which is confusing. Make it pass the requested clock
> rate in Hz.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to v4.11/fixes-non-critical
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: imx: Add rtc support to i.MX31 PDK board.
From: Magnus Lilja @ 2017-01-02 10:18 UTC (permalink / raw)
To: linux-arm-kernel
Enable support for i.MX31 RTC on the PDK board.
Tested on actual hardware.
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
---
arch/arm/mach-imx/mach-mx31_3ds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
index 12b8a52..c6a12ac 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -710,6 +710,7 @@ static void __init mx31_3ds_init(void)
imx31_add_imx_keypad(&mx31_3ds_keymap_data);
imx31_add_imx2_wdt();
+ imx31_add_mxc_rtc();
imx31_add_imx_i2c0(&mx31_3ds_i2c0_data);
imx31_add_spi_imx0(&spi0_pdata);
--
2.7.4
^ permalink raw reply related
* [PATCH] bus: da850-mstpri: fix my e-mail address
From: Sekhar Nori @ 2017-01-02 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482141491-26924-1-git-send-email-bgolaszewski@baylibre.com>
On Monday 19 December 2016 03:28 PM, Bartosz Golaszewski wrote:
> I noticed my e-mail address is wrong in this one. This patch fixes it.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/fixes-non-critical
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: imx: Add rtc support to i.MX31 PDK board.
From: Fabio Estevam @ 2017-01-02 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483352282-28970-1-git-send-email-lilja.magnus@gmail.com>
On Mon, Jan 2, 2017 at 8:18 AM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Enable support for i.MX31 RTC on the PDK board.
>
> Tested on actual hardware.
>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] ARM: dts: da850-lcdk: add gpio-keys
From: Sekhar Nori @ 2017-01-02 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482141234-11546-1-git-send-email-bgolaszewski@baylibre.com>
On Monday 19 December 2016 03:23 PM, Bartosz Golaszewski wrote:
> Add a gpio-keys node for two user buttons present on the board.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 1/2] provide lock-less versions of clk_{enable|disable}
From: Sekhar Nori @ 2017-01-02 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5112fcf8-8a10-bfd3-3c37-c3a956eacd15@ti.com>
On Sunday 18 December 2016 09:21 PM, Sekhar Nori wrote:
> ARM: davinci: Make __clk_{enable,disable} functions public
>
> In some cases, there is a need to enable a clock as part of clock
> enable callback of a different clock. For example, USB 2.0 PHY clock
> enable requires USB 2.0 clock to be enabled. In this case, it is safe to
> instead call __clk_enable() since the clock framework lock is already
> taken. calling clk_enable() causes recursive locking error.
>
> A similar case arises in the clock disable path.
>
> To enable such usage, make __clk_{enable,disable} functions publicly
> available outside of clock.c. Also, call them
> davinci_clk_{enable|disable} now to be consistent with how other
> davinci-specific clock functions are named.
>
> Note that these functions are not exported to drivers. They are meant
> for usage in platform specific clock management code.
Applied to 'fixes' with above commit text.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 2/2] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2017-01-02 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481302773-14181-2-git-send-email-abailon@baylibre.com>
On Friday 09 December 2016 10:29 PM, Alexandre Bailon wrote:
> Everytime the usb20 phy is enabled, there is a
> "sleeping function called from invalid context" BUG.
> In addition, there is a recursive locking happening
> because of the recurse call to clk_enable().
>
> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
> before to invoke the callback usb20_phy_clk_enable().
> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
> which may sleep.
> replace clk_prepare_enable() by davinci_clk_enable().
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> Suggested-by: David Lechner <david@lechnology.com>
Applied to 'fixes' branch.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Sekhar Nori @ 2017-01-02 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <750eaa32-ca29-b140-eec6-cec4350cf304@ti.com>
On Wednesday 14 December 2016 03:27 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
>> The label is also 'display', but change it to 'lcdc' to make it clear
>> what the underlying hardware is.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..6b0ef3d 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -458,7 +458,7 @@
>> dma-names = "tx", "rx";
>> };
>>
>> - display: display at 213000 {
>> + lcdc: display at 213000 {
>> compatible = "ti,da850-tilcdc";
>> reg = <0x213000 0x1000>;
>> interrupts = <52>;
>>
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied with Tomi's reviewed-by.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbb47a8f-07be-19d6-e77b-f5c06fd39c61@codeaurora.org>
Hi Archit,
On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>
>
> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>> THS8135 is a configurable video DAC, but no configuration is actually
>> necessary to make it work.
>>
>> For now use the dumb-vga-dac driver to support it.
>
> Queued to drm-misc-next
This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
to v4.10?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx
From: Nicolas Ferre @ 2017-01-02 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213162756.16139-1-richard.genoud@gmail.com>
Le 13/12/2016 ? 17:27, Richard Genoud a ?crit :
> If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
> continues to send data until it is emptied.
> This cause problems with the flow control (CTS is asserted and data are
> still sent).
>
> So, disabling the transmitter in atmel_stop_tx is a sane thing to do.
>
> Tested on at91sam9g35-cm(DMA)
> Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)
>
> Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/tty/serial/atmel_serial.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> NB: this is not for the 4.10 merge window, I'm just sending it now to
> have some comments if someone is againts it.
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 168b10cad47b..f9d42de5ab2d 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -481,6 +481,14 @@ static void atmel_stop_tx(struct uart_port *port)
> /* disable PDC transmit */
> atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTDIS);
> }
> +
> + /*
> + * Disable the transmitter.
> + * This is mandatory when DMA is used, otherwise the DMA buffer
> + * is fully transmitted.
> + */
> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
> +
> /* Disable interrupts */
> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>
> @@ -513,6 +521,9 @@ static void atmel_start_tx(struct uart_port *port)
>
> /* Enable interrupts */
> atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
> +
> + /* re-enable the transmitter */
> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
> }
>
> /*
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Sekhar Nori @ 2017-01-02 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ad07b84-7f5a-6467-e310-52c3efc66d3d@ti.com>
On Wednesday 14 December 2016 03:24 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied to v4.11/dt with Tomi's reviewed-by.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
From: Peter Senna Tschudin @ 2017-01-02 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com>
On 01 January, 2017 21:24 CET, Peter Senna Tschudin <peter.senna@collabora.com> wrote:
[ ... ]
> +static void ge_b850v3_lvds_dp_detach(struct drm_bridge *bridge)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge
> + = bridge_to_ge_b850v3_lvds_dp(bridge);
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> +
> + /* Disable interrupts */
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_EN_REG, ~STDP4028_DPTX_IRQ_CONFIG);
~STDP4028_DPTX_IRQ_CONFIG? Argh! Will fix this and resend after reviews...
[ ... ]
^ permalink raw reply
* [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Sekhar Nori @ 2017-01-02 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-6-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 13 December 2016 03:39 PM, Bartosz Golaszewski wrote:
> At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
> is 37.5 MHz[1]. We must filter out any mode for which the calculated
> pixel clock rate would exceed this value.
>
> Specify the max-pixelclock property for the display node for
> da850-lcdk.
>
> [1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
This wiki page is not really a TI datasheet and can change without
notice. I changed this to refer to
http://www.ti.com/lit/ds/symlink/am1808.pdf (SPRS653E, revised March
2014), table 6-110.
Applied to v4.11/dt
Thanks,
Sekhar
^ 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