* [PATCHv3 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-18 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479431816-5028-1-git-send-email-labbott@redhat.com>
DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
the same support. Rather than add a list of architectures, switch this
to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
appropriate.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: No change, x86 maintainers please ack if you are okay with this.
---
arch/x86/Kconfig | 1 +
lib/Kconfig.debug | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..f533321 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b01e547..5050530 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -603,9 +603,12 @@ config DEBUG_VM_PGFLAGS
If unsure, say N.
+config ARCH_HAS_DEBUG_VIRTUAL
+ bool
+
config DEBUG_VIRTUAL
bool "Debug VM translations"
- depends on DEBUG_KERNEL && X86
+ depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
help
Enable some costly sanity checks in virtual to page code. This can
catch mistakes with virt_to_page() and friends.
--
2.7.4
^ permalink raw reply related
* [PATCHv3 0/6] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2016-11-18 1:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v3 of the series to add CONFIG_DEBUG_VIRTUAL for arm64.
The biggest change from v2 is the conversion of more __pa sites
to __pa_symbol for stricter checks.
With that expansion, having this go through the arm64 tree is going to be
easiest so I'd like to start getting Acks from x86 and mm maintainers.
Thanks,
Laura
Laura Abbott (6):
lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
mm/cma: Cleanup highmem check
arm64: Move some macros under #ifndef __ASSEMBLY__
arm64: Add cast for virt_to_pfn
arm64: Use __pa_symbol for kernel symbols
arm64: Add support for CONFIG_DEBUG_VIRTUAL
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kvm_mmu.h | 4 +-
arch/arm64/include/asm/memory.h | 70 ++++++++++++++++++++++---------
arch/arm64/include/asm/mmu_context.h | 6 +--
arch/arm64/include/asm/pgtable.h | 2 +-
arch/arm64/kernel/acpi_parking_protocol.c | 2 +-
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kernel/hibernate.c | 9 ++--
arch/arm64/kernel/insn.c | 2 +-
arch/arm64/kernel/psci.c | 2 +-
arch/arm64/kernel/setup.c | 8 ++--
arch/arm64/kernel/smp_spin_table.c | 2 +-
arch/arm64/kernel/vdso.c | 4 +-
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/init.c | 11 ++---
arch/arm64/mm/mmu.c | 24 +++++------
arch/arm64/mm/physaddr.c | 39 +++++++++++++++++
arch/x86/Kconfig | 1 +
drivers/firmware/psci.c | 2 +-
lib/Kconfig.debug | 5 ++-
mm/cma.c | 15 +++----
21 files changed, 140 insertions(+), 72 deletions(-)
create mode 100644 arch/arm64/mm/physaddr.c
--
2.7.4
^ permalink raw reply
* [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format
From: Stefan Agner @ 2016-11-18 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1e51fc92dbcc9c31dcdcdfab3eed40d7745308a.1479384571.git.maitysanchayan@gmail.com>
On 2016-11-17 04:16, Sanchayan Maity wrote:
> Current DMA implementation was not handling the continuous selection
> format viz. SPI chip select would be deasserted even between sequential
> serial transfers. Use the cs_change variable and correctly set or
> reset the CONT bit accordingly for case where peripherals require
> the chip select to be asserted between sequential transfers.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> drivers/spi/spi-fsl-dspi.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index aee8c88..164e2e1 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> }
>
> val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> - dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> - SPI_PUSHR_PCS(dspi->cs) |
> - SPI_PUSHR_CTAS(0);
> + if (dspi->cs_change) {
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0);
> + } else {
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0) |
> + SPI_PUSHR_CONT;
> + }
How about:
dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
SPI_PUSHR_PCS(dspi->cs) |
SPI_PUSHR_CTAS(0);
+ if (dspi->cs_change)
+ dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
Avoids code duplication...
--
Stefan
> dspi->tx += tx_word + 1;
>
> dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Sandy Harris @ 2016-11-18 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476794067-28563-1-git-send-email-clabbe.montjoie@gmail.com>
Add Ted T'so to cc list. Shouldn't he be included on anything affecting
the random(4) driver?
On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> From: LABBE Corentin <clabbe.montjoie@gmail.com>
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
Which is it? A PRNG & a HW RNG are quite different things.
It would, in general, be a fairly serious error to treat a PRNG
as a HWRNG.
If it is just a prng (which it appears to be from a quick look
at your code) then it is not clear it is useful since the
random(4) driver already has two PRNGs. It might be
but I cannot tell.
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-18 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582DF05A.9050601@arm.com>
James,
On Thu, Nov 17, 2016 at 06:00:58PM +0000, James Morse wrote:
> Hi Will, Akashi,
>
> On 17/11/16 11:19, Will Deacon wrote:
> > It looks much better, thanks! Just one question below.
> >
>
> > On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> >> diff --git a/mm/memblock.c b/mm/memblock.c
> >> index 7608bc3..fea1688 100644
> >> --- a/mm/memblock.c
> >> +++ b/mm/memblock.c
> >> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> >> (phys_addr_t)ULLONG_MAX);
> >> }
> >>
> >> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> >> +{
> >> + int start_rgn, end_rgn;
> >> + int i, ret;
> >> +
> >> + if (!size)
> >> + return;
> >> +
> >> + ret = memblock_isolate_range(&memblock.memory, base, size,
> >> + &start_rgn, &end_rgn);
> >> + if (ret)
> >> + return;
> >> +
> >> + /* remove all the MAP regions */
> >> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> >> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> >> + memblock_remove_region(&memblock.memory, i);
> >
> > In the case that we have only one, giant memblock that covers base all
> > of base + size, can't we end up with start_rgn = end_rgn = 0? In which
>
> Can this happen? If we only have one memblock that exactly spans
> base:(base+size), memblock_isolate_range() will hit the '@rgn is fully
> contained, record it' code and set start_rgn=0,end_rgn=1. (rbase==base,
> rend==end). We only go round the loop once.
>
> If we only have one memblock that is bigger than base:(base+size) we end up with
> three regions, start_rgn=1,end_rgn=2. The trickery here is the '@rgn intersects
> from above' code decreases the loop counter so we process the same entry twice,
> hitting '@rgn is fully contained, record it' the second time round... so we go
> round the loop four times.
Thank you for your observation.
> I can't see how we hit the:
> > if (rbase >= end)
> > break;
> > if (rend <= base)
> > continue;
>
> code in either case...
Right. So 'end_rgn' will never be expected to be 0 as far as some
intersection exists.
-Takahiro AKASHI
>
>
> Thanks,
>
> James
>
>
> > case, we'd end up accidentally removing the map regions here.
> >
> > The existing code:
> >
> >> - /* remove all the MAP regions above the limit */
> >> - for (i = end_rgn - 1; i >= start_rgn; i--) {
> >> - if (!memblock_is_nomap(&type->regions[i]))
> >> - memblock_remove_region(type, i);
> >> - }
> >
> > seems to handle this.
^ permalink raw reply
* [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: Stefan Agner @ 2016-11-18 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d83f4896d77f577ca92fd70534f6198bb3288d8a.1479384571.git.maitysanchayan@gmail.com>
On 2016-11-17 04:16, Sanchayan Maity wrote:
> Currently dmaengine_prep_slave_single was being called with length
> set to the complete DMA buffer size. This resulted in unwanted bytes
> being transferred to the SPI register leading to clock and MOSI lines
> having unwanted data even after chip select got deasserted and the
> required bytes having been transferred.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> drivers/spi/spi-fsl-dspi.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index b1ee1f5..aee8c88 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>
> dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> dma->tx_dma_phys,
> - DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> + dma->curr_xfer_len *
> + DMA_SLAVE_BUSWIDTH_4_BYTES /
> + (tx_word ? 2 : 1),
> + DMA_MEM_TO_DEV,
Hm, this is getting ridiculous, I think we convert curr_xfer_len from
bytes to DMA transfers in almost every use.
Can we make it be transfer length in actual 4 byte transfers? We then
probably have to convert it to bytes once to subtract from
curr_remaining_bytes, but I think it would simplify code overall...
--
Stefan
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!dma->tx_desc) {
> dev_err(dev, "Not able to get desc for DMA xfer\n");
> @@ -281,7 +284,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>
> dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
> dma->rx_dma_phys,
> - DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
> + dma->curr_xfer_len *
> + DMA_SLAVE_BUSWIDTH_4_BYTES /
> + (tx_word ? 2 : 1),
> + DMA_DEV_TO_MEM,
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!dma->rx_desc) {
> dev_err(dev, "Not able to get desc for DMA xfer\n");
^ permalink raw reply
* [PATCH 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: Stefan Agner @ 2016-11-18 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbdbc8df434dd2af74eb351b799a2812a1c1967e.1479384571.git.maitysanchayan@gmail.com>
On 2016-11-17 04:16, Sanchayan Maity wrote:
> Current DMA implementation had a bug where the DMA transfer would
> exit the loop in dspi_transfer_one_message after the completion of
> a single transfer. This results in a multi message transfer submitted
> with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Looks good to me:
Reviewed-by: Stefan Agner <stefan@agner.ch>
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> drivers/spi/spi-fsl-dspi.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index bc64700..b1ee1f5 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -714,7 +714,7 @@ static int dspi_transfer_one_message(struct
> spi_master *master,
> SPI_RSER_TFFFE | SPI_RSER_TFFFD |
> SPI_RSER_RFDFE | SPI_RSER_RFDFD);
> status = dspi_dma_xfer(dspi);
> - goto out;
> + break;
> default:
> dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
> trans_mode);
> @@ -722,9 +722,13 @@ static int dspi_transfer_one_message(struct
> spi_master *master,
> goto out;
> }
>
> - if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
> - dev_err(&dspi->pdev->dev, "wait transfer complete fail!\n");
> - dspi->waitflags = 0;
> + if (trans_mode != DSPI_DMA_MODE) {
> + if (wait_event_interruptible(dspi->waitq,
> + dspi->waitflags))
> + dev_err(&dspi->pdev->dev,
> + "wait transfer complete fail!\n");
> + dspi->waitflags = 0;
> + }
>
> if (transfer->delay_usecs)
> udelay(transfer->delay_usecs);
^ permalink raw reply
* [-next] i2c: digicolor: use clk_disable_unprepare instead of clk_unprepare
From: Wolfram Sang @ 2016-11-18 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477758677-7831-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Oct 29, 2016 at 04:31:17PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> since clk_prepare_enable() is used to get i2c->clk, we should
> use clk_disable_unprepare() to release it for the error path.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Acked-by: Baruch Siach <baruch@tkos.co.il>
Applied to for-current, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161118/4c311fbd/attachment.sig>
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.9
From: Olof Johansson @ 2016-11-18 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115211057.3b2c35l6pxspzzkp@lukather>
On Tue, Nov 15, 2016 at 10:10:57PM +0100, Maxime Ripard wrote:
> hi Arnd, Olof,
>
> Please pull the following changes for 4.9.
>
> Thanks!
> Maxime
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-fixes-for-4.9
>
> for you to fetch changes up to b7f865ede20c87073216f77fe97f6fc56666e3da:
>
> ARM: dts: sun8i: fix the pinmux for UART1 (2016-10-25 12:51:06 +0200)
>
> ----------------------------------------------------------------
> Allwinner fixes for 4.9
>
> A fix to reintroduce missing pinmux options that turned out not to be
> optional.
>
Merged, thanks for the tag description.
-Olof
^ permalink raw reply
* [GIT PULL] STi DT fix for v4.9-rcs
From: Olof Johansson @ 2016-11-18 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3973615b-e1cb-25b3-fff0-201b56162f1a@st.com>
On Tue, Nov 15, 2016 at 11:38:03AM +0100, Patrice Chotard wrote:
> Hi Arnd, Olof, Kevin
>
> Please consider this set for inclusion into the v4.9-rc.
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-v4.9-rc
>
> for you to fetch changes up to 5bf7b6e86f29f064979d7b3e6dd21c5dd1feb855:
>
> ARM: dts: STiH410-b2260: Fix typo in spi0 chipselect definition (2016-11-15 11:29:25 +0100)
>
> ----------------------------------------------------------------
>
> STi DT fix:
>
> Fix typo cs-gpio to cs-gpios
>
Hi Patrice,
Merged. Tiny nit for the future: It's nice to see a few words of why a
change is needed/what's broken. In this case it's pretty obvious from
the code (SPI is broken without it) but it's good habit to motivate
fixes branches in particular.
-Olof
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9, 2nd round
From: Olof Johansson @ 2016-11-18 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115024353.GT3310@dragon>
On Tue, Nov 15, 2016 at 10:43:55AM +0800, Shawn Guo wrote:
> The following changes since commit 4edd601c5a9c5094daa714e65063e623826f3bcc:
>
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031 (2016-10-24 21:26:01 +0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.9-2
>
> for you to fetch changes up to e3c9d9d6ebfeeeee29c6240e1b5978d40d31d21f:
>
> ARM: dts: imx53-qsb: Fix regulator constraints (2016-11-05 16:18:16 +0800)
>
> ----------------------------------------------------------------
> i.MX fixes for 4.9, 2nd round:
>
> It fixes a boot failure on imx53-qsb board with a DA9053 PMIC, which is
> caused by the regulator core change, commit fa93fd4ecc9c ("regulator:
> core: Ensure we are at least in bounds for our constraints").
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] omap fixes for v4.9-rc cycle
From: Olof Johansson @ 2016-11-18 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582a57e8.0203630a.cc89e.c3f4SMTPIN_ADDED_BROKEN@mx.google.com>
On Mon, Nov 14, 2016 at 04:33:35PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.9/fixes-for-rc-cycle
>
> for you to fetch changes up to 1bc2f5fac34535aeb3878ce32a762a221be7a851:
>
> ARM: dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage (2016-11-14 13:03:21 -0800)
>
> ----------------------------------------------------------------
> Fixes for omaps for v4.9-rc cycle. Except for the omap3 fix for the SoC
> features printed, all these are quite trivial and tiny. The omap5 jack
> detection and gpadc patches are not strictly fixes, but I wanted to get
> binding document typo fixed before it pops up on other boards. The
> gpadc one liner was in the same series and I applied and pushed it out
> already before noticing it could have waited. The list of changes is:
>
> - Fix omap3 SoC features printed
>
> - Make sure OMAP_INTERCONNECT is selected for am43xx only configurations
>
> - Add missing memory node for torpedo
>
> - Initialize uart4_mask properly to avoid writing garbage to PRM registers
>
> - Fix NULL pointer dereference for omap4 volt_data
>
> - Add alias for omap5 gpadc needed by iio drivers
>
> - Enable omap5 jack headset jack detection and fix it's binding typo
>
> - Add missing memory node for logicpd-som-lv
>
> - Fix wrong SMPS6 voltage for VDD-DDR3 for omap5
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.9 (#1)
From: Olof Johansson @ 2016-11-18 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twbfc8fh.fsf@free-electrons.com>
On Thu, Nov 10, 2016 at 10:49:06PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for fixes for mvebu for v4.9.
>
> Gregory
>
> The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
>
> Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.9-1
>
> for you to fetch changes up to 8d897006fe9206d64cbe353310be26d7c911e69d:
>
> arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers (2016-11-09 09:44:08 +0100)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.9 (part 1)
>
> All of them are fixes for arm64 device tree
>
> - 2 for the SPI node on the Armada 7K/8K
> - 1 for the clock node on the Armada 37xx
>
Hi, merged. But please be a bit more descriptive in the pull request of _why_
we should pick it up in the future.
The patches themselves are well described in this case, so looking at those
helped tell that it made sense to include.
No need for a full essay, just a few words about "why" instead of necessarily
just "what" in the tag description!
Thanks,
-Olof
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Olof Johansson @ 2016-11-18 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2278270.0oJqDfoDd9@wuerfel>
On Wed, Nov 09, 2016 at 05:09:12PM +0100, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 12:15:57 PM CET Corey Minyard wrote:
> > On 11/08/2016 09:52 AM, C?dric Le Goater wrote:
> > > O
> > snip
> >
> > >>>> While we're modifying the binding, should we add a compat string for
> > >>>> the ast2500?
> > >>> Well, if the change in this patch is fine for all, may be we can add
> > >>> the ast2500 compat string in a followup patch ?
> > >> Sounds good to me.
> > > OK. So, how do we proceed with this patch ? Who would include it in its
> > > tree ?
> >
> > I don't have anything for 4.9 at the moment. Arnd, if you have
> > something, can
> > you take this? Otherwise I will.
> >
> > And I guess I should add:
> >
> > Acked-by: Corey Minyard <cminyard@mvista.com>
>
> Thanks, I've added it to my todo folder.
>
> Olof, if you do fixes before I do, please pick up this patch with
> Corey's Ack.
Done, applied to fixes.
-Olof
^ permalink raw reply
* [PATCH RFC 01/12] drm/i2c: tda998x: avoid race in tda998x_encoder_mode_set()
From: Russell King - ARM Linux @ 2016-11-18 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c45SW-0005jL-52@rmk-PC.armlinux.org.uk>
On Tue, Nov 08, 2016 at 12:25:00PM +0000, Russell King wrote:
> As priv->audio_params can now be changed at run time, we need to be more
> careful about how we deal with a mode set. We must take the audio lock
> while checking if there's a valid audio configuration.
>
> However, it's slightly worse than that - during mode set, we mute the
> audio, and it must not be unmuted until we have finished the mode set.
> It is possible that the audio side may start while a mode set is in
> progress, so take the audio_mutex lock around the whole mode setting
> procedure.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 088900d78ceb..1cc0433ce9d5 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1074,13 +1074,12 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
>
> tda998x_write_avi(priv, adjusted_mode);
>
> - if (priv->audio_params.format != AFMT_UNUSED) {
> - mutex_lock(&priv->audio_mutex);
> + mutex_lock(&priv->audio_mutex);
> + if (priv->audio_params.format != AFMT_UNUSED)
> tda998x_configure_audio(priv,
> &priv->audio_params,
> adjusted_mode->clock);
> - mutex_unlock(&priv->audio_mutex);
> - }
> + mutex_unlock(&priv->audio_mutex);
> }
> }
>
I've just realised that this (and the following few changes) require this
mutex to be always initialised. Currently, we only initialise the audio
mutex when in DT mode, which is bad. So, I'm going to add this patch in
front of this patch set:
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 088900d78ceb..168c0b4b8f47 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1405,6 +1405,8 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
int rev_lo, rev_hi, ret;
unsigned short cec_addr;
+ mutex_init(&priv->audio_mutex); /* Protect access from audio thread */
+
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
@@ -1519,8 +1521,6 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
priv->vip_cntrl_2 = video;
}
- mutex_init(&priv->audio_mutex); /* Protect access from audio thread */
-
ret = tda998x_get_audio_ports(priv, np);
if (ret)
goto fail;
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Andrew Jeffery @ 2016-11-17 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazPEbU2gmDyke=GTYtjVp8aeauS+PVkp-zuiVoVz7kbw@mail.gmail.com>
On Thu, 2016-11-17 at 10:30 +0100, Linus Walleij wrote:
> > On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> > +* Device tree bindings for the Aspeed LPC Controller
>
> We are going overboard with the lingo sometimes, to the point that we do not
> understand how terse things become.
Sorry for that, it is a bit terse. Sometimes I struggle to gauge how
much context I should provide.
Joel's reply covers the details of your queries below, but I'll make
sure to add the information to the bindings as well.
>
> LPC = Low Pin Count, right?
> Explain that right here: it is a slow external bus, right?
> > +The Aspeed LPC controller contains registers for a variety of functions. Not
> > +all registers for a function are contiguous, and some registers are referenced
> > +by functions outside the LPC controller.
> > +
> > +Note that this is separate from the H8S/2168 compatible register set occupying
> > +the start of the LPC controller address space.
> > +
> > +Some significant functions in the LPC controller:
> > +
> > +* LPC Host Controller
> > +* Host Interface Controller
>
> Host interface to what?
>
> > +* iBT Controller
>
> What is iBT?
>
> > +* SuperIO Scratch registers
>
> Again more context please.
>
> With standards documents, either explain everything or provide
> pointers for the information.
ACK!
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161118/4fa39301/attachment-0001.sig>
^ permalink raw reply
* [PATCH] iommu: mtk: add common-clk dependency
From: Stephen Boyd @ 2016-11-17 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479345958.17679.11.camel@mtksdaap41>
On 11/17, Honghui Zhang wrote:
> On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote:
> > On 11/16, Arnd Bergmann wrote:
> > > After the MT2701 clock driver was added, we get a harmless warning for
> > > the iommu driver that selects it, when compile-testing without
> > > COMMON_CLK.
> > >
> > > warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK)
> > >
> > > Adding a dependency on COMMON_CLK avoids the warning.
> > >
> > > Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Hm.. why is an iommu driver selecting a clk driver? They should
> > be using standard clk APIs so it's not like they need it for
> > build time correctness. Shouldn't we drop the selects instead?
> > Those look to have been introduced a few kernel versions ago, but
> > they were selecting options that didn't exist until a few days
> > ago when I merged the mediatek clk driver. The clk options are
> > user-visible, so it should be possible to select them in the
> > configuration phase.
> >
>
> Hi, Stephen,
> I'm a bit out of date of the current clock code. Mediatek IOMMU v1
> driver will need smi driver to enable iommu clients. And smi driver is
> also respond to enable/disable the susbsys clocks for multi-media HW.
> The relationship between iommu and smi is like the graphics below[1].
>
> EMI (External Memory Interface)
> |
> m4u (Multimedia Memory Management Unit)
> |
> SMI Common(Smart Multimedia Interface Common)
> |
> +----------------+-------
> | |
> | |
> SMI larb0 SMI larb1 ... SoCs have several SMI local
> arbiter(larb).
> (display) (vdec)
> | |
> | |
> +-----+-----+ +----+----+
> | | | | | |
> | | |... | | | ... There are different ports in each
> larb.
> | | | | | |
> OVL0 RDMA0 WDMA0 MC PP VLD
>
>
> When enable SMI driver it will need those subsys clock provider.
> But those clocks providers are disabled in default. Since it's needed by
> smi driver, and smi was select by MTK_IOMMU_V1, I figure it should be
> select by MTK_IOMMU_V1 too.
Ok I understand all that, but I don't understand why that means
we need to have select statements for clk drivers still. If
anything, that logic would mean the SMI driver should select clk
drivers. I hope it isn't doing that.
BTW, I don't understand the mtk_smi_larb_get() API. It looks like
we expect the SMI driver to probe and succeed before the
mtk_smi_larb_get() function is called. That seems fairly brittle
in the face of probe defer or device ordering changes.
The SMI driver actually looks like a bus driver for an
interconnect as well, but drivers/memory is for memory
controllers? Odd but I can get over that.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] arm64: dts: NS2: Add PCI PHYs
From: Jon Mason @ 2016-11-17 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479425103-2119-1-git-send-email-jon.mason@broadcom.com>
PCI PHYs are missing from the Northstar2 DT entries for the 2 PCI buses.
Add them so that PCI devices can be discovered.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index e4cd868..4fcdeca 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -133,6 +133,9 @@
status = "disabled";
+ phys = <&pci_phy0>;
+ phy-names = "pcie-phy";
+
msi-parent = <&msi0>;
msi0: msi at 20020000 {
compatible = "brcm,iproc-msi";
@@ -171,6 +174,9 @@
status = "disabled";
+ phys = <&pci_phy1>;
+ phy-names = "pcie-phy";
+
msi-parent = <&msi4>;
msi4: msi at 50020000 {
compatible = "brcm,iproc-msi";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: NS2: enable sdio1
From: Jon Mason @ 2016-11-17 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479425103-2119-1-git-send-email-jon.mason@broadcom.com>
Enable sdio1 in the Northstar2 SVK device tree file
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 07c69a3e..de8d379 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -161,6 +161,10 @@
status = "ok";
};
+&sdio1 {
+ status = "ok";
+};
+
&nand {
nandcs at 0 {
compatible = "brcm,nandcs";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: NS2: Add sdio1, PCI phys
From: Jon Mason @ 2016-11-17 23:25 UTC (permalink / raw)
To: linux-arm-kernel
The second SDIO seems to have been forgotten to be enabled in the
Northstar2 SVK dts. Also, the PCI PHY entries are missing from the PCI
bus device tree entries.
Jon Mason (2):
arm64: dts: NS2: enable sdio1
arm64: dts: NS2: Add PCI PHYs
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 4 ++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 6 ++++++
2 files changed, 10 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Stephen Boyd @ 2016-11-17 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479259165-1601-2-git-send-email-spjoshi@codeaurora.org>
On 11/15, Sarangdhar Joshi wrote:
> Add SCM DT bindings for Qualcomm's MSM8996 platform.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 13/13] ARM: dts: armada-375: Fixup ethernet child DT warning
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-1-gregory.clement@free-electrons.com>
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3e61c2dd1437..70243d2b8491 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -241,13 +241,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0 at c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1 at c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.2
^ permalink raw reply related
* [PATCH v3 12/13] ARM: dts: armada-375: Fixup memory DT warning
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-1-gregory.clement@free-electrons.com>
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 5ed226236398..64edd59486e0 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.2
^ permalink raw reply related
* [PATCH v3 11/13] ARM: dts: armada-375: Remove skeleton.dtsi
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-1-gregory.clement@free-electrons.com>
The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi").
These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 04333ba3f180..3e61c2dd1437 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -45,7 +45,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
@@ -53,6 +52,9 @@
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
model = "Marvell Armada 375 family SoC";
compatible = "marvell,armada375";
--
2.10.2
^ permalink raw reply related
* [PATCH v3 10/13] ARM: dts: armada-375: Fixup internal-regs DT warning
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-1-gregory.clement@free-electrons.com>
internal-regs has a ranges property so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 120dd7ac40cb..04333ba3f180 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -178,7 +178,11 @@
status = "disabled";
};
- internal-regs {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ internal-regs at f00100000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox