* [PATCH 0/3] arm64: dts: Draak: Enable HDMI input and VIN4
From: Jacopo Mondi @ 2018-05-11 9:59 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this series enables HDMI input and VIN4 on R-Car D3 Draak board.
The Draak board has an HDMI input connected to an HDMI decoder that feeds
the VIN capture interface through its parallel video interface.
The series requires the just sent:
[PATCH 0/5] rcar-vin: Add support for digital input on Gen3
and enables image capture operations on D3 Draak board.
The series has been developed on top of media-master tree but applies cleanly
on top of latest renesas-driver.
Geert: would you like a topic branch for this series to be included in
renesas-drivers?
Patches for testing are available at:
git://jmondi.org/linux d3/media-master/driver
git://jmondi.org/linux d3/media-master/dts
git://jmondi.org/linux d3/media-master/test
git://jmondi.org/vin-tests d3
Thanks
j
Jacopo Mondi (3):
dt-bindings: media: rcar-vin: Add R8A77995 support
arm64: dts: renesas: r8a77995: Add VIN4
arm64: dts: renesas: draak: Describe HDMI input
.../devicetree/bindings/media/rcar_vin.txt | 1 +
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 ++++
3 files changed, 80 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/8] arm/arm64: KVM: Formalise end of direct linear map
From: Steve Capper @ 2018-05-11 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9272dd72-7bc9-daf9-2386-ceca04384c1c@arm.com>
On Thu, May 10, 2018 at 06:11:35PM +0100, Marc Zyngier wrote:
> [+Christoffer]
>
> Hi Steve,
Hi Marc,
>
> On 10/05/18 17:23, Steve Capper wrote:
> > We assume that the direct linear map ends at ~0 in the KVM HYP map
> > intersection checking code. This assumption will become invalid later on
> > for arm64 when the address space of the kernel is re-arranged.
> >
> > This patch introduces a new constant PAGE_OFFSET_END for both arm and
> > arm64 and defines it to be ~0UL
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
> > ---
> > arch/arm/include/asm/memory.h | 1 +
> > arch/arm64/include/asm/memory.h | 1 +
> > virt/kvm/arm/mmu.c | 4 ++--
> > 3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> > index ed8fd0d19a3e..45c211fd50da 100644
> > --- a/arch/arm/include/asm/memory.h
> > +++ b/arch/arm/include/asm/memory.h
> > @@ -24,6 +24,7 @@
> >
> > /* PAGE_OFFSET - the virtual address of the start of the kernel image */
> > #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
> > +#define PAGE_OFFSET_END (~0UL)
> >
> > #ifdef CONFIG_MMU
> >
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 49d99214f43c..c5617cbbf1ff 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -61,6 +61,7 @@
> > (UL(1) << VA_BITS) + 1)
> > #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> > (UL(1) << (VA_BITS - 1)) + 1)
> > +#define PAGE_OFFSET_END (~0UL)
> > #define KIMAGE_VADDR (MODULES_END)
> > #define MODULES_END (MODULES_VADDR + MODULES_VSIZE)
> > #define MODULES_VADDR (VA_START + KASAN_SHADOW_SIZE)
> > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> > index 7f6a944db23d..22af347d65f1 100644
> > --- a/virt/kvm/arm/mmu.c
> > +++ b/virt/kvm/arm/mmu.c
> > @@ -1927,10 +1927,10 @@ int kvm_mmu_init(void)
> > kvm_debug("IDMAP page: %lx\n", hyp_idmap_start);
> > kvm_debug("HYP VA range: %lx:%lx\n",
> > kern_hyp_va(PAGE_OFFSET),
> > - kern_hyp_va((unsigned long)high_memory - 1));
> > + kern_hyp_va(PAGE_OFFSET_END));
> >
> > if (hyp_idmap_start >= kern_hyp_va(PAGE_OFFSET) &&
> > - hyp_idmap_start < kern_hyp_va((unsigned long)high_memory - 1) &&
> > + hyp_idmap_start < kern_hyp_va(PAGE_OFFSET_END) &&
>
> This doesn't feel right to me now that we have the HYP randomization
> code merged. The way kern_hyp_va works now is only valid for addresses
> between VA(memblock_start_of_DRAM()) and high_memory.
>
> I fear that you could trigger the failing condition below as you
> evaluate the idmap address against something that is now not a HYP VA.
>
> > hyp_idmap_start != (unsigned long)__hyp_idmap_text_start) {
> > /*
> > * The idmap page is intersecting with the VA space,
> >
Thanks! Yes, this patch is completely spurious, apologies I think I
made a mistake rebasing my V2 series on top of HASLR (originally I replaced
~0LL with PAGE_OFFSET_END in V1). I will drop this patch from the next version
of the series.
>
> I'd appreciate if you could keep me cc'd on this series.
Apologies, I'll be much more careful with git send-email.
Cheers,
--
Steve
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 0/2] Add basic support for Mediatek MT8183 SoC
From: Erin Lo @ 2018-05-11 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <782e13c1-057b-164b-9270-d37c151aa9b4@gmail.com>
On Fri, 2018-05-11 at 10:29 +0200, Matthias Brugger wrote:
> Hi Erin,
>
> Please include the linux-mediatek and arm-linux-kernel mailinglists in the next
> round.
>
> Some comments in the patches.
>
> Regards,
> Matthias
I will add linux-mediatek, linux-arm-kernel, linux-kernel, linux-serial
mailinglists in next round.
Thanks for your reminder.
Regards,
Erin
>
> On 05/11/2018 08:11 AM, Erin Lo wrote:
> > MT8183 is a SoC based on 64bit ARMv8 architecture.
> > It contains 4 CA53 and 4 CA73 cores.
> > MT8183 share many HW IP with MT65xx series.
> > This patchset was tested on MT8183 evaluation board, and boot to shell ok.
> >
> > This series contains document bindings, device tree including interrupt, uart.
> >
> > Ben Ho (1):
> > arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and
> > Makefile
> >
> > Erin Lo (1):
> > dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
> >
> > Documentation/devicetree/bindings/arm/mediatek.txt | 4 +
> > .../interrupt-controller/mediatek,sysirq.txt | 1 +
> > .../devicetree/bindings/serial/mtk-uart.txt | 1 +
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 ++++
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 178 +++++++++++++++++++++
> > 6 files changed, 216 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH V5 2/4] soc: mediatek: pwrap: fix cipher init setting error
From: Matthias Brugger @ 2018-05-11 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525957319-20557-3-git-send-email-argus.lin@mediatek.com>
On 05/10/2018 03:01 PM, argus.lin at mediatek.com wrote:
> From: Argus Lin <argus.lin@mediatek.com>
>
> PWRAP_DEW_CIPHER_LOAD and PWRAP_DEW_CIPHER_START only exist at
> PMIC_mt6397 datasheet. We fix it before merge PMIC_mt6351 driver.
Please don't put info like "We fix it before merge PMIC_mt6351 driver." in the
commit message. You can see this from the git log later and it does not add any
value.
Regards,
Matthias
>
> Fixes: 5ae48040aa47 ("soc: mediatek: PMIC wrap: add mt6323 slave support")
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index e9e054a..9a01e30 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -1080,8 +1080,6 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
>
> switch (wrp->slave->type) {
> case PMIC_MT6397:
> --
> 1.8.1.1.dirty
>
> ************* Email Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
>
^ permalink raw reply
* [PATCH 0/2] Allwinner A64 timer workaround
From: Andre Przywara @ 2018-05-11 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511022751.9096-1-samuel@sholland.org>
Hi,
On 11/05/18 03:27, Samuel Holland wrote:
> Hello,
>
> Several people (including me) have experienced extremely large system
> clock jumps on their A64-based devices, apparently due to the
> architectural timer going backward, which is interpreted by Linux as
> the timer wrapping around after 2^56 cycles.
So I experienced this before, though I didn't see actual clock jumps,
only that subsequent reads of CNTVCT_EL0, both directly via mrs and
indirectly via CLOCK_MONOTONIC, from userland (triggered by a directed
test) *sometimes* went backwards, with a number of '1's in the lower bits.
But that didn't happen on every boot, and I was suspecting that some
timer setup was missing on the hardware/firmware side. And later on I
failed to reproduce it anymore.
So do you see it on every boot, with recent U-Boot/ATF?
Cheers,
Andre.
> Investigation led to discovery of some obvious problems with this SoC's
> architectural timer, and this patch series introduces what I believe is
> the simplest workaround. More details are in the commit message for
> patch 1. Patch 2 simply enables the workaround in the device tree.
>
> Thanks,
> Samuel
>
> Samuel Holland (2):
> arm64: arch_timer: Workaround for Allwinner A64 timer instability
> arm64: dts: allwinner: a64: Enable A64 timer workaround
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 1 +
> drivers/clocksource/Kconfig | 11 ++++++++
> drivers/clocksource/arm_arch_timer.c | 39 +++++++++++++++++++++++++++
> 3 files changed, 51 insertions(+)
>
> --
> 2.16.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process
From: Suzuki K Poulose @ 2018-05-11 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d170336d-8af0-893a-acb2-51900c28ade5@arm.com>
On 11/05/18 09:12, Julien Thierry wrote:
>
>
> On 09/05/18 22:52, Suzuki K Poulose wrote:
>> On 05/04/2018 11:06 AM, Julien Thierry wrote:
>>> Hi,
>>>
>>> In order to prepare the v3 of this patchset, I'd like people's opinion on what this patch does. More below.
>>>
>>> On 17/01/18 11:54, Julien Thierry wrote:
>>>> From: Daniel Thompson <daniel.thompson@linaro.org>
>>>>
>>>> Currently alternatives are applied very late in the boot process (and
>>>> a long time after we enable scheduling). Some alternative sequences,
>>>> such as those that alter the way CPU context is stored, must be applied
>>>> much earlier in the boot sequence.
>>
>>>> +/*
>>>> + * early-apply features are detected using only the boot CPU and checked on
>>>> + * secondary CPUs startup, even then,
>>>> + * These early-apply features should only include features where we must
>>>> + * patch the kernel very early in the boot process.
>>>> + *
>>>> + * Note that the cpufeature logic *must* be made aware of early-apply
>>>> + * features to ensure they are reported as enabled without waiting
>>>> + * for other CPUs to boot.
>>>> + */
>>>> +#define EARLY_APPLY_FEATURE_MASK BIT(ARM64_HAS_SYSREG_GIC_CPUIF)
>>>> +
>>>
>>> Following the change in the cpufeature infrastructure, ARM64_HAS_SYSREG_GIC_CPUIF will have the scope ARM64_CPUCAP_SCOPE_BOOT_CPU in order to be checked early in the boot process.
>>
>> Thats correct.
>>
>>>
>>> Now, regarding the early application of alternative, I am wondering whether we can apply all the alternatives associated with SCOPE_BOOT features that *do not* have a cpu_enable callback.
>>>
>>
>> I don't understand why would you skip the ones that have a "cpu_enable" callback. Could you explain this a bit ? Ideally you should be able to
>> apply the alternatives for features with the SCOPE_BOOT, provided the
>> cpu_enable() callback is written properly.
>>
>
> In my mind the "cpu_enable" callback is the setup a cpu should perform before using the feature (i.e. the code getting patched in by the alternative). So I was worried about the code getting patched by the boot cpu and then have the secondary cpus ending up executing patched code before the cpu_enable for the corresponding feature gets called.
> Or is there a requirement for secondary cpu startup code to be free of alternative code?
There are no imposed restrictions. It is upto the capability to decide
what can be done in cpu_enable() and what can be patched. So, if you
make sure the patched code can be safely executed by secondary it is
fine. May be you could even patch in some code in the early boot up, to
do what you do in "cpu_enable()" for the secondary to safely execute
the patched code.
Anyway, if the secondary CPUs don't have the feature you are going to
panic the system. So I don't think there is a big difference in the
outcome if there is a mismatch, except for a clean message about the
conflict.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: hi3660: Add pcie msi interrupt attribute
From: Yao Chen @ 2018-05-11 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526030149-23985-1-git-send-email-chenyao11@huawei.com>
Add pcie msi interrupt attribute for hi3660 SOC.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..2cef8f4 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -872,6 +872,8 @@
0x0 0x02000000>;
num-lanes = <1>;
#interrupt-cells = <1>;
+ interrupts = <0 283 4>;
+ interrupt-names = "msi";
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1
&gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/2] PCI: kirin: Add MSI support
From: Yao Chen @ 2018-05-11 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526030149-23985-1-git-send-email-chenyao11@huawei.com>
Add support for MSI.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
drivers/pci/dwc/pcie-kirin.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a0..8daab1f 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
return 0;
}
+static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
+{
+ struct pcie_port *pp = arg;
+
+ return dw_handle_msi_irq(pp);
+}
+
+static void kirin_pcie_msi_init(struct pcie_port *pp)
+{
+ dw_pcie_msi_init(pp);
+}
+
+static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
+{
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ kirin_pcie_msi_init(pp);
+}
+
static int kirin_pcie_host_init(struct pcie_port *pp)
{
kirin_pcie_establish_link(pp);
+ kirin_pcie_enable_interrupts(pp);
return 0;
}
@@ -448,6 +467,26 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
static int __init kirin_add_pcie_port(struct dw_pcie *pci,
struct platform_device *pdev)
{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ pci->pp.msi_irq = platform_get_irq(pdev, 0);
+ if (pci->pp.msi_irq < 0) {
+ dev_err(&pdev->dev, "failed to get MSI IRQ (%d)\n",
+ pci->pp.msi_irq);
+ return -ENODEV;
+ }
+ ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
+ kirin_pcie_msi_irq_handler,
+ IRQF_SHARED | IRQF_NO_THREAD,
+ "kirin_pcie_msi", &pci->pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request MSI IRQ %d\n",
+ pci->pp.msi_irq);
+ return ret;
+ }
+ }
+
pci->pp.ops = &kirin_pcie_host_ops;
return dw_pcie_host_init(&pci->pp);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/2] Add MSI support
From: Yao Chen @ 2018-05-11 9:15 UTC (permalink / raw)
To: linux-arm-kernel
Before Version Patches
======================
patch v2
https://www.spinics.net/lists/kernel/msg2797610.html
patch v1
https://www.spinics.net/lists/kernel/msg2796410.html
Changes between V3 and V2
=========================
1. fix issues according to review comments
(1)from Bjorn Helgaas: Check for 'pci->pp.msi_irq < 0'.
(2)from Bjorn Helgaas: Update the message of 'msi irq' in dev_err().
Changes between V2 and V1
=========================
1. seperate DT binding patch.
2. fix issues according to review comments
(1)from Bjorn Helgaas: Update the style of subject and changelog.
(2)from Bjorn Helgaas: Add msi irq number in the message.
(3)from Bjorn Helgaas: Delete unnecessary code 'pci->pp.root_bus_nr = -1'.
(4)from Dmitry Shmidt: Fix typing error. Replace 'interrupts-names' of 'interrupt-names'.
Yao Chen (2):
PCI: kirin: Add MSI support
arm64: dts: hi3660: Add pcie msi interrupt attribute
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
drivers/pci/dwc/pcie-kirin.c | 39 +++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 04/20] arm-nommu: use generic dma_noncoherent_ops
From: Russell King - ARM Linux @ 2018-05-11 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511075945.16548-5-hch@lst.de>
On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation for
> the nommu dma map implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arc/Kconfig | 1 +
> arch/arm/Kconfig | 4 +
> arch/arm/mm/dma-mapping-nommu.c | 139 +++++---------------------------
> 3 files changed, 23 insertions(+), 121 deletions(-)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 89d47eac18b2..3a492a9aeaad 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -9,6 +9,7 @@
> config ARC
> def_bool y
> select ARC_TIMERS
> + select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select ARCH_HAS_SYNC_DMA_FOR_CPU
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select ARCH_HAS_SG_CHAIN
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c43f5bb55ac8..76ddd0064f87 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -12,6 +12,8 @@ config ARM
> select ARCH_HAS_PHYS_TO_DMA
> select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> select ARCH_HAS_STRICT_MODULE_RWX if MMU
> + select ARCH_HAS_SYNC_DMA_FOR_CPU if !MMU
> + select ARCH_HAS_SYNC_DMA_FOR_DEVICE if !MMU
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_HAS_GCOV_PROFILE_ALL
> @@ -27,6 +29,8 @@ config ARM
> select CPU_PM if (SUSPEND || CPU_IDLE)
> select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> select DMA_DIRECT_OPS if !MMU
> + select DMA_NONCOHERENT_OPS if !MMU
> + select DMA_NONCOHERENT_MMAP if !MMU
> select EDAC_SUPPORT
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index f448a0663b10..a74ed6632982 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -12,6 +12,7 @@
> #include <linux/export.h>
> #include <linux/mm.h>
> #include <linux/dma-direct.h>
> +#include <linux/dma-noncoherent.h>
> #include <linux/scatterlist.h>
>
> #include <asm/cachetype.h>
> @@ -26,18 +27,16 @@
> * - MMU/MPU is off
> * - cpu is v7m w/o cache support
> * - device is coherent
> - * otherwise arm_nommu_dma_ops is used.
> + * otherwise dma_noncoherent_ops is used.
> *
> - * arm_nommu_dma_ops rely on consistent DMA memory (please, refer to
> + * dma_noncoherent_ops rely on consistent DMA memory (please, refer to
> * [1] on how to declare such memory).
> *
> * [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> */
>
> -static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t gfp,
> - unsigned long attrs)
> -
> +void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> + gfp_t gfp, unsigned long attrs)
> {
> void *ret;
>
> @@ -65,9 +64,8 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
> return ret;
> }
>
> -static void arm_nommu_dma_free(struct device *dev, size_t size,
> - void *cpu_addr, dma_addr_t dma_addr,
> - unsigned long attrs)
> +void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t dma_addr, unsigned long attrs)
> {
> if (attrs & DMA_ATTR_NON_CONSISTENT) {
> dma_direct_free(dev, size, cpu_addr, dma_addr, attrs);
> @@ -81,9 +79,9 @@ static void arm_nommu_dma_free(struct device *dev, size_t size,
> return;
> }
>
> -static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - unsigned long attrs)
> +int arch_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> {
> int ret;
>
> @@ -93,9 +91,8 @@ static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
> }
>
> -
> -static void __dma_page_cpu_to_dev(phys_addr_t paddr, size_t size,
> - enum dma_data_direction dir)
> +void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
> + size_t size, enum dma_data_direction dir)
Please no. There is a lot of history of these (__dma_page_cpu_to_dev etc)
functions being abused by out of tree drivers, because they think they
know better. This is stopped by making them static and ensuring that
drivers have no access to these functions.
Please do not re-expose these to the global kernel.
While it may make things easier for a cross-architecture point of view,
it makes it a lot easier for people to abuse these private APIs.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Maxime Ripard @ 2018-05-11 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8ab5f472881063b90abe9461933baf6ee325dcd.camel@paulk.fr>
On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > as found on the Ainol AW1 tablet.
> > >
> > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > the two extra lanes per component are grounded.
> > >
> > > In the future, it might become necessary to introduce a dedicated
> > > device-tree property to specify the bus format to use instead of the
> > > default one for the panel. This will allow supporting different bus
> > > formats for the same panel modes.
> > >
> > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> > > 1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
> > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > };
> > >
> > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > + .clock = 40000,
> > > + .hdisplay = 800,
> > > + .hsync_start = 800 + 112,
> > > + .hsync_end = 800 + 112 + 1,
> > > + .htotal = 800 + 112 + 1 + 87,
> > > + .vdisplay = 480,
> > > + .vsync_start = 480 + 141,
> > > + .vsync_end = 480 + 141 + 1,
> > > + .vtotal = 480 + 141 + 1 + 38,
> > > + .vrefresh = 60,
> > > +};
> > > +
> > > +static const struct panel_desc innolux_at070tn90 = {
> > > + .modes = &innolux_at070tn90_mode,
> > > + .num_modes = 1,
> > > + .size = {
> > > + .width = 154,
> > > + .height = 86,
> > > + },
> > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > +};
> > > +
> >
> > I'm not really convinced this is the right approach. You said it
> > yourself, the panel is using a 24-bits interface, and you just happen
> > to have a tablet that routed it using a 18-bits interface instead.
> >
> > That doesn't belong in the driver, especially associated to the
> > compatible, but where the routing is described: in the device
> > tree. And given that the panel interface is a 24 bits panel, if we
> > were to have a default, we should have this one, and not the one
> > fitting your use case.
>
> I fully agree, this is why I suggested introducing a dedicated dt
> property for selecting the bus format (in the commit message). I still
> proposed this patch as a temporary solution, but I'm definitely willing
> to craft a proper solution as well.
>
> Here is an initial proposition:
> 1. Making bus_format an array in struct panel_desc and listing all the
> relevant bus formats that the panel can support there;
I'm not sure this is needed, the input format is always the same in
your case, the panel will always take a 24 bits RGB value. What you
want to change is the encoder output format (and I guess you want that
to be meaningful to enable or not the dithering).
> 2. Introducing an optional "bus-format" dt property that indicates which
> bus format to use, and using the first index of the bus formats array if
> the property is not present;
I guess the width would be enough, and that way we can take the
bus-width format that is already defined (but used in the v4l2
framework, not in DRM yet).
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/29433d16/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx53-ard: Do not hardcode input codes
From: Shawn Guo @ 2018-05-11 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525918089-26242-1-git-send-email-festevam@gmail.com>
On Wed, May 09, 2018 at 11:08:07PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Instead of hardcoding the input codes we can use the symbol name for
> better readability.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
From: Marc Zyngier @ 2018-05-11 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511022751.9096-2-samuel@sholland.org>
[+Mark, who co-maintains the arch timer code with me]
Hi Samuel,
On 11/05/18 03:27, Samuel Holland wrote:
> The Allwinner A64 SoC is known [1] to have an unstable architectural
> timer, which manifests itself most obviously in the time jumping forward
> a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
> timer frequency of 24 MHz, implying that the time went slightly backward
> (and this was interpreted by the kernel as it jumping forward and
> wrapping around past the epoch).
>
> Further investigation revealed instability in the low bits of CNTVCT at
> the point a high bit rolls over. This leads to power-of-two cycle
> forward and backward jumps. (Testing shows that forward jumps are about
> twice as likely as backward jumps.)
>
> Without trapping reads to CNTVCT, a userspace program is able to read it
> in a loop faster than it changes. A test program running on all 4 CPU
> cores that reported jumps larger than 100 ms was run for 13.6 hours and
> reported the following:
>
> Count | Event
> -------+---------------------------
> 9940 | jumped backward 699ms
> 268 | jumped backward 1398ms
> 1 | jumped backward 2097ms
> 16020 | jumped forward 175ms
> 6443 | jumped forward 699ms
> 2976 | jumped forward 1398ms
> 9 | jumped forward 356516ms
> 9 | jumped forward 357215ms
> 4 | jumped forward 714430ms
> 1 | jumped forward 3578440ms
>
> This works out to a jump larger than 100 ms about every 5.5 seconds on
> each CPU core.
>
> The largest jump (almost an hour!) was the following sequence of reads:
> 0x0000007fffffffff ? 0x00000093feffffff ? 0x0000008000000000
>
> Note that the middle bits don't necessarily all read as all zeroes or
> all ones during the anomalous behavior; however the low 11 bits checked
> by the function in this patch have never been observed with any other
> value.
>
> Also note that smaller jumps are much more common, with the smallest
> backward jumps of 2048 cycles observed over 400 times per second on each
> core. (Of course, this is partially due to lower bits rolling over more
> frequently.) Any one of these could have caused the 95 year time skip.
>
> Similar anomalies were observed while reading CNTPCT (after patching the
> kernel to allow reads from userspace). However, the jumps are much less
> frequent, and only small jumps were observed. The same program as before
> (except now reading CNTPCT) observed after 72 hours:
>
> Count | Event
> -------+---------------------------
> 17 | jumped backward 699ms
> 52 | jumped forward 175ms
> 2831 | jumped forward 699ms
> 5 | jumped forward 1398ms
>
> ========================================================================
>
> Because the CPU can read the CNTPCT/CNTVCT registers faster than they
> change, performing two reads of the register and comparing the high bits
> (like other workarounds) is not a workable solution. And because the
> timer can jump both forward and backward, no pair of reads can
> distinguish a good value from a bad one. The only way to guarantee a
> good value from consecutive reads would be to read _three_ times, and
> take the middle value iff the three values are 1) individually unique
> and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
> an anomaly is detected.
>
> However, since there is a distinct pattern to the bad values, we can
> optimize the common case (2046/2048 of the time) to a single read by
> simply ignoring values that match the pattern. This still takes no more
> than 3 cycles in the worst case, and requires much less code.
Thanks for the thorough description of the problem. A couple of questions:
- Have the 000/7ff values of the bottom bits only been experimentally
found? Or do you have more concrete evidence of this is what happens in
the HW?
- Do you have an official erratum number from the silicon vendor, so
that Documentation/arm64/silicon-errata.txt can be kept up to date?
>
> [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
> [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
> [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> drivers/clocksource/Kconfig | 11 ++++++++++
> drivers/clocksource/arm_arch_timer.c | 39 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8e8a09755d10..7a5d434dd30b 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -364,6 +364,17 @@ config ARM64_ERRATUM_858921
> The workaround will be dynamically enabled when an affected
> core is detected.
>
> +config SUN50I_A64_UNSTABLE_TIMER
> + bool "Workaround for Allwinner A64 timer instability"
> + default y
> + depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI
> + select ARM_ARCH_TIMER_OOL_WORKAROUND
> + help
> + This option enables a workaround for instability in the timer on
> + the Allwinner A64 SoC. The workaround will only be active if the
> + allwinner,sun50i-a64-unstable-timer property is found in the
> + timer node.
> +
> config ARM_GLOBAL_TIMER
> bool "Support for the ARM global timer" if COMPILE_TEST
> select TIMER_OF if OF
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 57cb2f00fc07..66ce13578c52 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -319,6 +319,36 @@ static u64 notrace arm64_858921_read_cntvct_el0(void)
> }
> #endif
>
> +#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
> +/*
> + * The low bits of each register can transiently read as all ones or all zeroes
> + * when bit 11 or greater rolls over. Since the value can jump both backward
> + * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), it is simplest to just
> + * ignore register values with all ones or zeros in the low bits.
> + */
> +static u64 notrace sun50i_a64_read_cntpct_el0(void)
> +{
> + u64 val;
> +
> + do {
> + val = read_sysreg(cntpct_el0);
> + } while (((val + 1) & GENMASK(10, 0)) <= 1);
Other workarounds of the same kind have a bounded loop. Have you done
any investigation on how many loops you need@most to sort the timer?
Depending on how many loops you need, it might be worth sticking a WFE
here to just wait for something to happen instead of busy looping.
> +
> + return val;
> +}
> +
> +static u64 notrace sun50i_a64_read_cntvct_el0(void)
> +{
> + u64 val;
> +
> + do {
> + val = read_sysreg(cntvct_el0);
> + } while (((val + 1) & GENMASK(10, 0)) <= 1);
> +
> + return val;
> +}
> +#endif
> +
> #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
> DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround);
> EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
> @@ -408,6 +438,15 @@ static const struct arch_timer_erratum_workaround ool_workarounds[] = {
> .read_cntvct_el0 = arm64_858921_read_cntvct_el0,
> },
> #endif
> +#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
> + {
> + .match_type = ate_match_dt,
> + .id = "allwinner,sun50i-a64-unstable-timer",
> + .desc = "Allwinner A64 timer instability",
> + .read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
> + .read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
> + },
> +#endif
> };
>
> typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm: dts: imx53: Fix LDB OF graph warning
From: Shawn Guo @ 2018-05-11 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525788997.18091.5.camel@pengutronix.de>
On Tue, May 08, 2018 at 04:16:37PM +0200, Philipp Zabel wrote:
> On Tue, 2018-05-08 at 08:59 -0500, Rob Herring wrote:
> > Single child nodes in OF graph don't need an address and now dtc will
> > warn about this:
> >
> > Warning (graph_child_address): /soc/aips at 50000000/ldb at 53fa8008/lvds-channel at 0: graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
> >
> > Since the LDB should always have an output port, fix the warning by
> > adding the output port, 2, to the DT.
> >
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > arch/arm/boot/dts/imx53.dtsi | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> > index 7d647d043f52..1cf2fc9d0a58 100644
> > --- a/arch/arm/boot/dts/imx53.dtsi
> > +++ b/arch/arm/boot/dts/imx53.dtsi
> > @@ -488,6 +488,10 @@
> > remote-endpoint = <&ipu_di0_lvds0>;
> > };
> > };
> > +
> > + port at 2 {
> > + reg = <2>;
> > + };
>
> Now that the reg property of port at 2 is added in the .dtsi, it could be
> removed from the one .dts files that use it:
>
> ----------8<----------
> --- a/arch/arm/boot/dts/imx53-ppd.dts
> +++ b/arch/arm/boot/dts/imx53-ppd.dts
> @@ -559,8 +559,6 @@
> status = "okay";
>
> port at 2 {
> - reg = <2>;
> -
> lvds0_out: endpoint {
> remote-endpoint = <&panel_in_lvds0>;
> };
I incorporate the change and applied patch. Thanks.
Shawn
^ permalink raw reply
* [RFC 1/2] documentation: Add nvmem bindings documentation
From: Srinivas Kandagatla @ 2018-05-11 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180324174638.12621-1-chinnikishore369@gmail.com>
On 24/03/18 17:46, chinnikishore369 at gmail.com wrote:
> From: Nava kishore Manne <navam@xilinx.com>
>
> This patch add the bindings document of zynqmp silicon id driver.
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
I see that you have not included DT maintainers in to/cc list, I can not
accept new drivers whose bindings are not Acked/Reviewed by DT maintainers.
Overall the driver looks fine for me.
thanks,
srini
> ---
> .../devicetree/bindings/nvmem/zynqmp_nvmem.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/zynqmp_nvmem.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/zynqmp_nvmem.txt b/Documentation/devicetree/bindings/nvmem/zynqmp_nvmem.txt
> new file mode 100644
> index 000000000000..94332f160a92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/zynqmp_nvmem.txt
> @@ -0,0 +1,32 @@
> += Zynq UltraScale+ MPSoC nvmem firmware driver binding =
> +
> +Required properties:
> +- compatible: should be "xlnx,zynqmp-nvmem-fw"
> +
> += Data cells =
> +Are child nodes of silicon id, bindings of which as described in
> +bindings/nvmem/nvmem.txt
> +
> +Example:
> +
> + nvmem_firmware {
> + compatible = "xlnx,zynqmp-nvmem-fw";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* Data cells */
> + soc_revision: soc_revision at 0 {
> + reg = <0x0 0x4>;
> + };
> + };
> +
> += Data consumers =
> +Are device nodes which consume nvmem data cells.
> +
> +For example:
> +
> + pcap {
> + ...
> + nvmem-cells = <&soc_revision>;
> + nvmem-cell-names = "soc_revision";
> + };
>
^ permalink raw reply
* [RFC 2/2] nvmem: zynqmp: Added zynqmp nvmem firmware driver
From: Srinivas Kandagatla @ 2018-05-11 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180324174638.12621-2-chinnikishore369@gmail.com>
On 24/03/18 17:46, chinnikishore369 at gmail.com wrote:
> From: Nava kishore Manne <navam@xilinx.com>
>
> This patch adds zynqmp nvmem firmware driver to access the
> SoC revision information from the hardware register.
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> drivers/nvmem/Kconfig | 9 +++++
> drivers/nvmem/Makefile | 2 ++
> drivers/nvmem/zynqmp_nvmem.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 96 insertions(+)
> create mode 100644 drivers/nvmem/zynqmp_nvmem.c
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index ff505af064ba..a9349281d05a 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -175,4 +175,13 @@ config NVMEM_SNVS_LPGPR
> This driver can also be built as a module. If so, the module
> will be called nvmem-snvs-lpgpr.
>
> +config NVMEM_ZYNQMP
> + bool "Xilinx ZYNQMP SoC nvmem firmware support"
> + depends on ARCH_ZYNQMP
> + help
> + This is a driver to access hardware related data like soc revision,
> + IDCODE... etc.
> +
> + If sure, say yes. If unsure, say no.
> +
> endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index e54dcfa6565a..932b4cebcb6c 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -37,3 +37,5 @@ obj-$(CONFIG_MESON_MX_EFUSE) += nvmem_meson_mx_efuse.o
> nvmem_meson_mx_efuse-y := meson-mx-efuse.o
> obj-$(CONFIG_NVMEM_SNVS_LPGPR) += nvmem_snvs_lpgpr.o
> nvmem_snvs_lpgpr-y := snvs_lpgpr.o
> +obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
> +nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
> diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c
...
> +
> +static int zynqmp_nvmem_probe(struct platform_device *pdev)
> +{
> + struct nvmem_device *nvmem;
> +
> + econfig.dev = &pdev->dev;
> + econfig.reg_read = zynqmp_nvmem_read;
> +
> + nvmem = nvmem_register(&econfig);
> + if (IS_ERR(nvmem))
> + return PTR_ERR(nvmem);
> +
You could use devm version of this..
> + platform_set_drvdata(pdev, nvmem);
> +
> + return 0;
> +}
>
...
> +module_platform_driver(zynqmp_nvmem_driver);
> +
> +MODULE_AUTHOR("Michal Simek <michal.simek@xilinx.com>, Nava kishore Manne <navam@xilinx.com>");
> +MODULE_DESCRIPTION("ZynqMP NVMEM driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: allwinner: a64: Update Orange Pi Win/Win Plus
From: Maxime Ripard @ 2018-05-11 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511030124.9356-1-samuel@sholland.org>
Hi Samuel,
On Thu, May 10, 2018 at 10:01:23PM -0500, Samuel Holland wrote:
> Enable the following board hardware features:
> - Gigabit Ethernet
> - SDIO Wi-Fi on mmc1
> - SPI flash on spi0
> - Status LED
> - Dual-role micro-USB connection
>
> Also provide nodes for the UARTs exposed by the 40-pin GPIO header.
>
> A couple of fixes were made:
> - Updating a couple of regulators from the schematic
> - Marking the CPU's power supply as such
All these changes look sane, but you should really split them into
more patches to have one of these changes per patch. We really don't
mind having more patches when it's justified, and this is definitely
the case for both your patches.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/852a4711/attachment.sig>
^ permalink raw reply
* [PATCH] arm: dts: imx: fix IPU OF graph endpoint node names
From: Shawn Guo @ 2018-05-11 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKcz=i0ELosVvuhevMSxa2q8pE+2WcAk57sg8ns5X-mtg@mail.gmail.com>
On Tue, May 08, 2018 at 10:22:29AM -0500, Rob Herring wrote:
> On Tue, May 8, 2018 at 9:06 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi Rob,
> >
> > On Tue, May 8, 2018 at 10:59 AM, Rob Herring <robh@kernel.org> wrote:
> >
> >> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> index 18b65052553d..654cf2c9b073 100644
> >> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> @@ -379,9 +379,6 @@
> >> powerdown-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> >>
> >> port {
> >> - #address-cells = <1>;
> >> - #size-cells = <0>;
> >> -
> >> ov5640_to_mipi_csi2: endpoint {
> >> remote-endpoint = <&mipi_csi2_in>;
> >> clock-lanes = <0>;
> >> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> >> index f019f9900369..c2de2250718c 100644
> >> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> >> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> >> @@ -294,9 +294,6 @@
> >> reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
> >>
> >> port {
> >> - #address-cells = <1>;
> >> - #size-cells = <0>;
> >> -
> >> ov5640_to_mipi_csi2: endpoint {
> >
> > These two changes seem unrelated and I have already fixed them at:
> > https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt&id=1b215c73d1586e6f2586e9a6d6dfaf49cc142b3a
>
> Right. Will drop them.
Applied. The git am command dropped them automatically. Thanks.
Shawn
^ permalink raw reply
* [PATCH v2 1/2] PCI: kirin: Add MSI support
From: chenyao (F) @ 2018-05-11 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140431.GJ173327@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
>
> [+cc Tejun, Wolfram]
>
> On Wed, May 09, 2018 at 04:20:11PM +0800, Yao Chen wrote:
> > Add support for MSI.
> > ...
>
> > @@ -448,6 +467,26 @@ static int kirin_pcie_host_init(struct pcie_port
> > *pp) static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> > struct platform_device *pdev) {
> > + int ret;
> > +
> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> > + if (!pci->pp.msi_irq) {
>
> I think this test is incorrect. platform_get_irq() returns a negative errno
> value when it fails. Most calls test "irq < 0" to check for failure.
>
> There's a lot of duplicated code like this, so maybe we should consider
> putting that check into devm_request_irq(), similar to what
> devm_ioremap_resource() does, so the driver code could look like this:
>
> pci->pp.msi_irq = platform_get_irq(pdev, 0);
> ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq, ...);
> if (ret) {
> dev_err(&pdev->dev, "failed to request MSI IRQ\n");
> return ret;
> }
>
> The basic devm_ioremap_resource() motivation is here: 72f8c0bfa0de ("lib:
> devres: add convenience function to remap a resource") and the same
> considerations seem to apply here.
>
> But that's more than you need to do for *this* series. So for now, I would
> simply fix the test to check for "irq < 0" and update the messages as I
> mention below.
Thank you for pointing out my mistake. I'll fix it.
>
> > + dev_err(&pdev->dev, "failed to get msi irq[%d]\n",
> > + pci->pp.msi_irq);
> > + return -ENODEV;
> > + }
> > + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> > + kirin_pcie_msi_irq_handler,
> > + IRQF_SHARED | IRQF_NO_THREAD,
> > + "kirin_pcie_msi", &pci->pp);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to request msi
> irq[%d]\n",
>
> s/msi irq/MSI IRQ/ in both dev_err() messages above. This is because the
> message is English text (not code), and the convention is that non-words like
> these initialisms written in all caps.
>
> I would style the first one as "failed to get MSI IRQ (%d)" because the %d
> there is a return code, probably -ENXIO.
>
> The second one should be "failed to request MSI IRQ %d" because here
> the %d is the actual IRQ.
>
I'll fix it. Thanks again.
> > + pci->pp.msi_irq);
> > + return ret;
> > + }
> > + }
> > +
> > pci->pp.ops = &kirin_pcie_host_ops;
> >
> > return dw_pcie_host_init(&pci->pp);
> > --
> > 1.9.1
> >
Best regards,
Yao
^ permalink raw reply
* [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
From: Maxime Ripard @ 2018-05-11 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511022751.9096-2-samuel@sholland.org>
On Thu, May 10, 2018 at 09:27:50PM -0500, Samuel Holland wrote:
> The Allwinner A64 SoC is known [1] to have an unstable architectural
> timer, which manifests itself most obviously in the time jumping forward
> a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
> timer frequency of 24 MHz, implying that the time went slightly backward
> (and this was interpreted by the kernel as it jumping forward and
> wrapping around past the epoch).
>
> Further investigation revealed instability in the low bits of CNTVCT at
> the point a high bit rolls over. This leads to power-of-two cycle
> forward and backward jumps. (Testing shows that forward jumps are about
> twice as likely as backward jumps.)
>
> Without trapping reads to CNTVCT, a userspace program is able to read it
> in a loop faster than it changes. A test program running on all 4 CPU
> cores that reported jumps larger than 100 ms was run for 13.6 hours and
> reported the following:
>
> Count | Event
> -------+---------------------------
> 9940 | jumped backward 699ms
> 268 | jumped backward 1398ms
> 1 | jumped backward 2097ms
> 16020 | jumped forward 175ms
> 6443 | jumped forward 699ms
> 2976 | jumped forward 1398ms
> 9 | jumped forward 356516ms
> 9 | jumped forward 357215ms
> 4 | jumped forward 714430ms
> 1 | jumped forward 3578440ms
>
> This works out to a jump larger than 100 ms about every 5.5 seconds on
> each CPU core.
>
> The largest jump (almost an hour!) was the following sequence of reads:
> 0x0000007fffffffff ? 0x00000093feffffff ? 0x0000008000000000
>
> Note that the middle bits don't necessarily all read as all zeroes or
> all ones during the anomalous behavior; however the low 11 bits checked
> by the function in this patch have never been observed with any other
> value.
>
> Also note that smaller jumps are much more common, with the smallest
> backward jumps of 2048 cycles observed over 400 times per second on each
> core. (Of course, this is partially due to lower bits rolling over more
> frequently.) Any one of these could have caused the 95 year time skip.
>
> Similar anomalies were observed while reading CNTPCT (after patching the
> kernel to allow reads from userspace). However, the jumps are much less
> frequent, and only small jumps were observed. The same program as before
> (except now reading CNTPCT) observed after 72 hours:
>
> Count | Event
> -------+---------------------------
> 17 | jumped backward 699ms
> 52 | jumped forward 175ms
> 2831 | jumped forward 699ms
> 5 | jumped forward 1398ms
>
> ========================================================================
>
> Because the CPU can read the CNTPCT/CNTVCT registers faster than they
> change, performing two reads of the register and comparing the high bits
> (like other workarounds) is not a workable solution. And because the
> timer can jump both forward and backward, no pair of reads can
> distinguish a good value from a bad one. The only way to guarantee a
> good value from consecutive reads would be to read _three_ times, and
> take the middle value iff the three values are 1) individually unique
> and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
> an anomaly is detected.
>
> However, since there is a distinct pattern to the bad values, we can
> optimize the common case (2046/2048 of the time) to a single read by
> simply ignoring values that match the pattern. This still takes no more
> than 3 cycles in the worst case, and requires much less code.
That's an awesome commit log, thanks!
For both patches:
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
> [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
> [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
Sigh. So armbian knew about this for more than a year and had a fix,
and didn't judge necessary to report it anywhere. That's some solid,
responsible, development right there...
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/3e662f74/attachment-0001.sig>
^ permalink raw reply
* [PATCH] i2c: i2c-stm32f7: fix documentation typo
From: Pierre-Yves MORDRET @ 2018-05-11 8:20 UTC (permalink / raw)
To: linux-arm-kernel
Some data structure members were either misspelled or missing.
Fixes: aeb068c572 ("i2c: i2c-stm32f7: add driver")
Fixes: 380b8a85e7 ("i2c: i2c-stm32f7: Add initial SMBus protocols support")
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
drivers/i2c/busses/i2c-stm32f7.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 0f87449..62d023e 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -211,11 +211,12 @@ struct stm32f7_i2c_setup {
/**
* struct stm32f7_i2c_timings - private I2C output parameters
- * @prec: Prescaler value
+ * @node: List entry
+ * @presc: Prescaler value
* @scldel: Data setup time
* @sdadel: Data hold time
* @sclh: SCL high period (master mode)
- * @sclh: SCL low period (master mode)
+ * @scll: SCL low period (master mode)
*/
struct stm32f7_i2c_timings {
struct list_head node;
@@ -237,7 +238,7 @@ struct stm32f7_i2c_timings {
* @size: type of SMBus protocol
* @read_write: direction of SMBus protocol
* SMBus block read and SMBus block write - block read process call protocols
- * @smbus_buff: buffer to be used for SMBus protocol transfer. It will
+ * @smbus_buf: buffer to be used for SMBus protocol transfer. It will
* contain a maximum of 32 bytes of data + byte command + byte count + PEC
* This buffer has to be 32-bit aligned to be compliant with memory address
* register in DMA mode.
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: Add compatible string for FRWY-LS1012A
From: Shawn Guo @ 2018-05-11 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-2-git-send-email-Bhaskar.Upadhaya@nxp.com>
On Tue, May 08, 2018 at 11:59:59AM +0530, Bhaskar Upadhaya wrote:
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++++
Bindings should be copied to DT maintainer for ACK. Also, bindings
patch should go before the one using the bindings.
Shawn
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
> index cdb9dd7..0517440 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> @@ -147,6 +147,10 @@ LS1012A ARMv8 based RDB Board
> Required root node properties:
> - compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
>
> +LS1012A ARMv8 based FRWY Board
> +Required root node properties:
> + - compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
> +
> LS1012A ARMv8 based FRDM Board
> Required root node properties:
> - compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process
From: Julien Thierry @ 2018-05-11 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a3afa42-821a-3d4a-3af8-00ba18653a4a@arm.com>
On 09/05/18 22:52, Suzuki K Poulose wrote:
> On 05/04/2018 11:06 AM, Julien Thierry wrote:
>> Hi,
>>
>> In order to prepare the v3 of this patchset, I'd like people's opinion
>> on what this patch does. More below.
>>
>> On 17/01/18 11:54, Julien Thierry wrote:
>>> From: Daniel Thompson <daniel.thompson@linaro.org>
>>>
>>> Currently alternatives are applied very late in the boot process (and
>>> a long time after we enable scheduling). Some alternative sequences,
>>> such as those that alter the way CPU context is stored, must be applied
>>> much earlier in the boot sequence.
>
>>> +/*
>>> + * early-apply features are detected using only the boot CPU and
>>> checked on
>>> + * secondary CPUs startup, even then,
>>> + * These early-apply features should only include features where we
>>> must
>>> + * patch the kernel very early in the boot process.
>>> + *
>>> + * Note that the cpufeature logic *must* be made aware of early-apply
>>> + * features to ensure they are reported as enabled without waiting
>>> + * for other CPUs to boot.
>>> + */
>>> +#define EARLY_APPLY_FEATURE_MASK BIT(ARM64_HAS_SYSREG_GIC_CPUIF)
>>> +
>>
>> Following the change in the cpufeature infrastructure,
>> ARM64_HAS_SYSREG_GIC_CPUIF will have the scope
>> ARM64_CPUCAP_SCOPE_BOOT_CPU in order to be checked early in the boot
>> process.
>
> Thats correct.
>
>>
>> Now, regarding the early application of alternative, I am wondering
>> whether we can apply all the alternatives associated with SCOPE_BOOT
>> features that *do not* have a cpu_enable callback.
>>
>
> I don't understand why would you skip the ones that have a "cpu_enable"
> callback. Could you explain this a bit ? Ideally you should be able to
> apply the alternatives for features with the SCOPE_BOOT, provided the
> cpu_enable() callback is written properly.
>
In my mind the "cpu_enable" callback is the setup a cpu should perform
before using the feature (i.e. the code getting patched in by the
alternative). So I was worried about the code getting patched by the
boot cpu and then have the secondary cpus ending up executing patched
code before the cpu_enable for the corresponding feature gets called.
Or is there a requirement for secondary cpu startup code to be free of
alternative code?
>
>> Otherwise we can keep the macro to list individually each feature that
>> is patchable at boot time as the current patch does (or put this info
>> in a flag within the arm64_cpu_capabilities structure)
>
> You may be able to build up the mask of *available* capabilities with
> SCOPE_BOOT at boot time by playing some trick in the
> setup_boot_cpu_capabilities(), rather than embedding it in the
> capabilities (and then parsing the entire table(s)) or manually keeping
> track of the capabilities by having a separate mask.
>
Yes, I like that idea.
Thanks,
> Suzuki
>
>>
>> Any thoughts or preferences on this?
>>
>> Thanks,
>>
>>> ? #define __ALT_PTR(a,f)??????? ((void *)&(a)->f + (a)->f)
>>> ? #define ALT_ORIG_PTR(a)??????? __ALT_PTR(a, orig_offset)
>>> ? #define ALT_REPL_PTR(a)??????? __ALT_PTR(a, alt_offset)
>>> @@ -105,7 +117,8 @@ static u32 get_alt_insn(struct alt_instr *alt,
>>> __le32 *insnptr, __le32 *altinsnp
>>> ????? return insn;
>>> ? }
>>>
>>> -static void __apply_alternatives(void *alt_region, bool
>>> use_linear_alias)
>>> +static void __apply_alternatives(void *alt_region,? bool
>>> use_linear_alias,
>>> +???????????????? unsigned long feature_mask)
>>> ? {
>>> ????? struct alt_instr *alt;
>>> ????? struct alt_region *region = alt_region;
>>> @@ -115,6 +128,9 @@ static void __apply_alternatives(void
>>> *alt_region, bool use_linear_alias)
>>> ????????? u32 insn;
>>> ????????? int i, nr_inst;
>>>
>>> +??????? if ((BIT(alt->cpufeature) & feature_mask) == 0)
>>> +??????????? continue;
>>> +
>>> ????????? if (!cpus_have_cap(alt->cpufeature))
>>> ????????????? continue;
>>>
>>> @@ -138,6 +154,21 @@ static void __apply_alternatives(void
>>> *alt_region, bool use_linear_alias)
>>> ? }
>>>
>>> ? /*
>>> + * This is called very early in the boot process (directly after we run
>>> + * a feature detect on the boot CPU). No need to worry about other CPUs
>>> + * here.
>>> + */
>>> +void apply_alternatives_early(void)
>>> +{
>>> +??? struct alt_region region = {
>>> +??????? .begin??? = (struct alt_instr *)__alt_instructions,
>>> +??????? .end??? = (struct alt_instr *)__alt_instructions_end,
>>> +??? };
>>> +
>>> +??? __apply_alternatives(®ion, true, EARLY_APPLY_FEATURE_MASK);
>>> +}
>>> +
>>> +/*
>>> ?? * We might be patching the stop_machine state machine, so implement a
>>> ?? * really simple polling protocol here.
>>> ?? */
>>> @@ -156,7 +187,9 @@ static int __apply_alternatives_multi_stop(void
>>> *unused)
>>> ????????? isb();
>>> ????? } else {
>>> ????????? BUG_ON(patched);
>>> -??????? __apply_alternatives(®ion, true);
>>> +
>>> +??????? __apply_alternatives(®ion, true, ~EARLY_APPLY_FEATURE_MASK);
>>> +
>>> ????????? /* Barriers provided by the cache flushing */
>>> ????????? WRITE_ONCE(patched, 1);
>>> ????? }
>>> @@ -177,5 +210,5 @@ void apply_alternatives(void *start, size_t length)
>>> ????????? .end??? = start + length,
>>> ????? };
>>>
>>> -??? __apply_alternatives(®ion, false);
>>> +??? __apply_alternatives(®ion, false, -1);
>>> ? }
>>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>>> index 551eb07..37361b5 100644
>>> --- a/arch/arm64/kernel/smp.c
>>> +++ b/arch/arm64/kernel/smp.c
>>> @@ -453,6 +453,12 @@ void __init smp_prepare_boot_cpu(void)
>>> ?????? * cpuinfo_store_boot_cpu() above.
>>> ?????? */
>>> ????? update_cpu_errata_workarounds();
>>> +??? /*
>>> +???? * We now know enough about the boot CPU to apply the
>>> +???? * alternatives that cannot wait until interrupt handling
>>> +???? * and/or scheduling is enabled.
>>> +???? */
>>> +??? apply_alternatives_early();
>>> ? }
>>>
>>> ? static u64 __init of_get_cpu_mpidr(struct device_node *dn)
>>> --
>>> 1.9.1
>>>
>>
>
--
Julien Thierry
^ permalink raw reply
* [PATCH 1/2] arm64: dts: ls1012a: Add FRWY-LS1012A board support
From: Shawn Guo @ 2018-05-11 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-1-git-send-email-Bhaskar.Upadhaya@nxp.com>
On Tue, May 08, 2018 at 11:59:58AM +0530, Bhaskar Upadhaya wrote:
> FRWY-LS1012A is a different design from LS1012A-FRDM,
> but has some common SoC features. Key feature on this
> board is Micro SD, USB 3.0, DDR, UART.
>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 64 ++++++++++++++++++++++
> 2 files changed, 65 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 86e18ad..d116144 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frwy.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> new file mode 100644
> index 0000000..f69086d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> @@ -0,0 +1,64 @@
> +/*
> + * Device Tree file for NXP LS1012A FRWY Board.
> + *
> + * Copyright 2018 NXP
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 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 library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library 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 "AS IS", 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.
> + */
> +/dts-v1/;
> +
> +#include "fsl-ls1012a.dtsi"
> +
> +/ {
> + model = "LS1012A FRWY Board";
> + compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
> +
> +};
> +
> +&pcie {
> + status = "okay";
> +};
> +
> +&duart0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +};
Please sort these nodes alphabetically in label name.
Shawn
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Use dedicated DT bindings for Odroid X/X2, U3
From: Sylwester Nawrocki @ 2018-05-11 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180511081032epcas2p30f381cf699cb7524d9a143390e9c74b5@epcas2p3.samsung.com>
Use dedicated Odroid audio subsystem DT bindings instead of the simple-card.
This adds support for audio on the HDMI interface.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 ++++++++++++++-----------
arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 +++---
arch/arm/boot/dts/exynos4412-odroidx.dts | 7 +++---
3 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index d7ad07fd48f9..bad08e70358a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -37,20 +37,12 @@
};
sound: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <&link0_codec>;
- simple-audio-card,frame-master = <&link0_codec>;
-
- simple-audio-card,cpu {
+ cpu {
sound-dai = <&i2s0 0>;
- system-clock-frequency = <19200000>;
};
- link0_codec: simple-audio-card,codec {
- sound-dai = <&max98090>;
- clocks = <&i2s0 CLK_I2S_CDCLK>;
+ codec {
+ sound-dai = <&hdmi>, <&max98090>;
};
};
@@ -142,14 +134,25 @@
pinctrl-0 = <>;
};
+&clock {
+ assigned-clocks = <&clock CLK_FOUT_EPLL>;
+ assigned-clock-rates = <45158401>;
+};
+
&clock_audss {
assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
<&clock_audss EXYNOS_MOUT_I2S>,
<&clock_audss EXYNOS_DOUT_SRP>,
- <&clock_audss EXYNOS_DOUT_AUD_BUS>;
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>,
+ <&clock_audss EXYNOS_DOUT_I2S>;
+
assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
- <&clock_audss EXYNOS_MOUT_AUDSS>;
- assigned-clock-rates = <0>, <0>, <192000000>, <19200000>;
+ <&clock_audss EXYNOS_MOUT_AUDSS>;
+
+ assigned-clock-rates = <0>, <0>,
+ <196608001>,
+ <(196608001 / 2)>,
+ <(196608001 / 8)>;
};
&cpu0 {
@@ -498,6 +501,8 @@
pinctrl-0 = <&i2s0_bus>;
pinctrl-names = "default";
status = "okay";
+ assigned-clocks = <&i2s0 CLK_I2S_RCLK_SRC>;
+ assigned-clock-parents = <&clock_audss EXYNOS_SCLK_I2S>;
};
&mixer {
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index bdcd4523cc1c..7a94a423097d 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -113,11 +113,12 @@
};
&sound {
- simple-audio-card,name = "Odroid-U3";
- simple-audio-card,widgets =
+ compatible = "hardkernel,odroid-xu4-audio";
+ model = "Odroid-U3";
+ samsung,audio-widgets =
"Headphone", "Headphone Jack",
"Speakers", "Speakers";
- simple-audio-card,routing =
+ samsung,audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"Headphone Jack", "MICBIAS",
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 2dff129bc2ad..f0d5037f3a5d 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -97,12 +97,13 @@
};
&sound {
- simple-audio-card,name = "Odroid-X";
- simple-audio-card,widgets =
+ compatible = "hardkernel,odroid-xu4-audio";
+ model = "Odroid-X";
+ samsung,audio-widgets =
"Headphone", "Headphone Jack",
"Microphone", "Mic Jack",
"Microphone", "DMIC";
- simple-audio-card,routing =
+ samsung,audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"IN1", "Mic Jack",
--
2.14.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