* [PATCH v1] ARM: dts: imx: add fsl, imx35-wdt compatible to all relevant watchdog nodes
From: Uwe Kleine-König @ 2017-01-17 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117012336.6891-1-vz@mleia.com>
On Tue, Jan 17, 2017 at 03:23:36AM +0200, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX35 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx35-wdt compatible to descriptions of all i.MX35 compatible
> watchdog controllers.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> RFC change is found at https://patchwork.kernel.org/patch/9350007
>
> Changes from RFC to v1:
> * added the same change to devicetree bindings documentation, thanks
> to Baruch Siach for review,
> * replaced a new shared compatible derived from i.MX25 with an earlier
> from i.MX35 SoC one, thanks to Uwe Kleine-K?nig for review.
>
> Compatible "fsl,imx21-wdt" is preserved as a generic one, because
> interface to a watchdog controller on i.MX35 is a superset of the
> interface to a i.MX21 watchdog controller.
One could argue here, but apart from the discussion if this is correct
or not, choosing this way has the upside that teaching the driver after
this change about the i.MX35 type doesn't make the machines based on the
newer type suffer from a breakage for one commit.
> Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 +-
When I created my patch set for this breakage I wondered if the
documentation should point out which are the unique types.
> arch/arm/boot/dts/imx25.dtsi | 3 ++-
> arch/arm/boot/dts/imx50.dtsi | 3 ++-
> arch/arm/boot/dts/imx51.dtsi | 6 ++++--
> arch/arm/boot/dts/imx53.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
> arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
> arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
The imx21 type is also used in
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
What about these?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-17 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhYfhrd-hy=N-FYDEPmumR0=QNzn5xTLxFuKG7apo5qiw@mail.gmail.com>
On 01/17/2017 07:07 AM, Olof Johansson wrote:
> On Mon, Jan 16, 2017 at 2:39 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 01/15/2017 03:43 PM, Andreas F?rber wrote:
>>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>
>>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>>
>>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>>> to handle variants memory sizes.
>>>>>
>>>>> This patch also fixes the memory sizes for the following platforms :
>>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>>
>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>
>>>> Queued for v4.10-rc.
>>>
>>> What is the motivation for this change? I have a local U-Boot patch to
>>> detect the amount of memory available as done downstream, but U-Boot
>>> only updates the reg property that you seem to be abandoning here...
>>>
>>> So for devices that come in multiple RAM configurations - like R-Box Pro
>>> - this would require separate .dts files now! This looks very wrong to
>>> me, especially since I am not aware of other platforms doing the same.
>>> Instead, there's memory reservations for top and bottom done in U-Boot
>>> for reg, plus reserved-memory nodes for anything in the middle.
>>>
>>> Another thing to consider is that uEFI boot (bootefi) handles memory
>>> reservation differently yet again, on the bootloader level. I have had
>>> that working fine on Odroid-C2 and Vega S95.
>>>
>>> So if there's no bug this is fixing (none mentioned in commit message) I
>>> strongly object to this patch.
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Hi Andreas,
>>
>> Like I replied of my RFT patch :
>> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
>> a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
>>
>> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
>> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
>>
>> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
>> their advices.
>
> Is there a way to detect what firmware is running and marking off
> memory from early kernel init instead? That'll take care of the
> concerns about memory size variance as well.
>
>> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
>> running stock u-boot version on various shipped products and Amlogic's own development boards.
>>
>> The bug is easily triggered by running :
>> # stress --vm 4 --vm-bytes 128M --timeout 10s &
>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>> ...
>> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>> ...
>>
>> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
>> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
>>
>> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
>> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
>
> Technically we're not in regression territory here, since the platform
> is obviously still in bringup and these aren't bugs that have been
> introduced in this release. So I think we can take a little while to
> sort out if there's a solution that, even if not ideal, at least is on
> the path towards the proper fix and not away from it -- which this
> seems to be.
>
>
> -Olof
>
Hi Olof, Andreas,
As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
overrides the reg property that is changed by the bootloader to provide the "real" memory size.
As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
recently merged DRM driver.
You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
But it should be confirmed.
Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
fixup for a future DTS cleanup.
Andreas, is this ok for you ?
This issue exists since forever on mainline linux, and even 4.9 has it.
Olof, How could a similar fix go in 4.9 stable ?
Thanks,
Neil
^ permalink raw reply
* [PATCH v29 3/9] arm64: kdump: reserve memory for crash dump kernel
From: AKASHI Takahiro @ 2017-01-17 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113113914.GB26804@leverpostej>
On Fri, Jan 13, 2017 at 11:39:15AM +0000, Mark Rutland wrote:
> On Fri, Jan 13, 2017 at 05:16:18PM +0900, AKASHI Takahiro wrote:
> > On Thu, Jan 12, 2017 at 03:09:26PM +0000, Mark Rutland wrote:
> > > > +static int __init export_crashkernel(void)
>
> > > > + /* Add /chosen/linux,crashkernel-* properties */
>
> > > > + of_remove_property(node, of_find_property(node,
> > > > + "linux,crashkernel-base", NULL));
> > > > + of_remove_property(node, of_find_property(node,
> > > > + "linux,crashkernel-size", NULL));
> > > > +
> > > > + ret = of_add_property(node, &crash_base_prop);
> > > > + if (ret)
> > > > + goto ret_err;
> > > > +
> > > > + ret = of_add_property(node, &crash_size_prop);
> > > > + if (ret)
> > > > + goto ret_err;
>
> > > I very much do not like this.
> > >
> > > I don't think we should be modifying the DT exposed to userspace in this
> > > manner, in the usual boot path, especially given that the kernel itself
> > > does not appear to be a consumer of this property. I do not think that
> > > it is right to use the DT exposed to userspace as a communication
> > > channel solely between the kernel and userspace.
> >
> > As you mentioned in your comments against my patch#9, this property
> > originates from PPC implementation.
> > I added it solely from the sympathy for dt-based architectures.
> >
> > > So I think we should drop the above, and for arm64 have userspace
> > > consistently use /proc/iomem (or perhaps a new kexec-specific file) to
> > > determine the region reserved for the crash kernel, if it needs to know
> > > this.
> >
> > As a matter of fact, my port of kexec-tools doesn't check this property
> > and dropping it won't cause any problem.
>
> Ok. It sounds like we're both happy for this to go, then.
>
> While it's unfortunate that architectures differ, I think we have
> legitimate reasons to differ, and it's preferable to do so. We have a
> different set of constraints (e.g. supporting EFI memory maps), and
> following the PPC approach creates longer term issues for us, making it
> harder to do the right thing consistently.
>
> > > > +/*
> > > > + * reserve_crashkernel() - reserves memory for crash kernel
> > > > + *
> > > > + * This function reserves memory area given in "crashkernel=" kernel command
> > > > + * line parameter. The memory reserved is used by dump capture kernel when
> > > > + * primary kernel is crashing.
> > > > + */
> > > > +static void __init reserve_crashkernel(void)
>
> > > > + memblock_reserve(crash_base, crash_size);
> > >
> > > This will mean that the crash kernel will have a permanent alias in the linear
> > > map which is vulnerable to being clobbered. There could also be issues
> > > with mismatched attributes in future.
> >
> > Good point, I've never thought of that except making the memblock
> > region "reserved."
> >
> > > We're probably ok for now, but in future we'll likely want to fix this
> > > up to remove the region (or mark it nomap), and only map it temporarily
> > > when loading things into the region.
> >
> > Well, I found that the following commit is already in:
> > commit 9b492cf58077
> > Author: Xunlei Pang <xlpang@redhat.com>
> > Date: Mon May 23 16:24:10 2016 -0700
> >
> > kexec: introduce a protection mechanism for the crashkernel
> > reserved memory
> >
> > To make best use of this framework, I'd like to re-use set_memory_ro/rx()
> > instead of removing the region from linear mapping. But to do so,
> > we need to
> > * make memblock_isolate_range() global,
> > * allow set_memory_ro/rx() to be applied to regions in linear mapping
> > since set_memory_ro/rx() works only on page-level mappings.
> >
> > What do you think?
> > (See my tentative solution below.)
>
> Great! I think it would be better to follow the approach of
> mark_rodata_ro(), rather than opening up set_memory_*(), but otherwise,
> it looks like it should work.
I'm not quite sure what the approach of mark_rodata_ro() means, but
I found that using create_mapping_late() may cause two problems:
1) it fails when PTE_CONT bits mismatch between an old and new mmu entry.
This can happen, say, if the memory range for crash dump kernel
starts in the mid of _continuous_ pages.
2) The control code page, of one-page size, is still written out in
machine_kexec() which is called at a crash, and this means that
the range must be writable even after kexec_load(), but
create_mapping_late() does not handle a case of changing attributes
for a single page which is in _section_ mapping.
We cannot make single-page mapping for the control page since the address
of that page is not determined at the boot time.
As for (1), we need to call memblock_isolate_range() to make the region
an independent one.
> Either way, this still leaves us with an RO alias on crashed cores (and
> potential cache attribute mismatches in future). Do we need to read from
> the region later,
I believe not, but the region must be _writable_ as I mentioned in (2) above.
To avoid this issue, we have to move copying the control code page
to machine_kexec_prepare() which is called in kexec_load() and so
the region is writable anyway then.
I want Geoff to affirm that this change is safe.
(See my second solution below.)
> or could we unmap it entirely?
given the change above, I think we can.
Is there any code to re-use especially for unmapping?
Thanks,
-Takahiro AKASHI
> Thanks,
> Mark.
===8<===
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index c0fc3d458195..80a52e9aaf73 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -26,8 +26,6 @@
extern const unsigned char arm64_relocate_new_kernel[];
extern const unsigned long arm64_relocate_new_kernel_size;
-static unsigned long kimage_start;
-
/**
* kexec_image_info - For debugging output.
*/
@@ -68,7 +66,7 @@ void machine_kexec_cleanup(struct kimage *kimage)
*/
int machine_kexec_prepare(struct kimage *kimage)
{
- kimage_start = kimage->start;
+ void *reboot_code_buffer;
kexec_image_info(kimage);
@@ -77,6 +75,21 @@ int machine_kexec_prepare(struct kimage *kimage)
return -EBUSY;
}
+ reboot_code_buffer =
+ phys_to_virt(page_to_phys(kimage->control_code_page));
+
+ /*
+ * Copy arm64_relocate_new_kernel to the reboot_code_buffer for use
+ * after the kernel is shut down.
+ */
+ memcpy(reboot_code_buffer, arm64_relocate_new_kernel,
+ arm64_relocate_new_kernel_size);
+
+ /* Flush the reboot_code_buffer in preparation for its execution. */
+ __flush_dcache_area(reboot_code_buffer, arm64_relocate_new_kernel_size);
+ flush_icache_range((uintptr_t)reboot_code_buffer,
+ arm64_relocate_new_kernel_size);
+
return 0;
}
@@ -147,7 +160,6 @@ static void kexec_segment_flush(const struct kimage *kimage)
void machine_kexec(struct kimage *kimage)
{
phys_addr_t reboot_code_buffer_phys;
- void *reboot_code_buffer;
/*
* New cpus may have become stuck_in_kernel after we loaded the image.
@@ -156,7 +168,6 @@ void machine_kexec(struct kimage *kimage)
!WARN_ON(kimage == kexec_crash_image));
reboot_code_buffer_phys = page_to_phys(kimage->control_code_page);
- reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys);
kexec_image_info(kimage);
@@ -164,26 +175,12 @@ void machine_kexec(struct kimage *kimage)
kimage->control_code_page);
pr_debug("%s:%d: reboot_code_buffer_phys: %pa\n", __func__, __LINE__,
&reboot_code_buffer_phys);
- pr_debug("%s:%d: reboot_code_buffer: %p\n", __func__, __LINE__,
- reboot_code_buffer);
pr_debug("%s:%d: relocate_new_kernel: %p\n", __func__, __LINE__,
arm64_relocate_new_kernel);
pr_debug("%s:%d: relocate_new_kernel_size: 0x%lx(%lu) bytes\n",
__func__, __LINE__, arm64_relocate_new_kernel_size,
arm64_relocate_new_kernel_size);
- /*
- * Copy arm64_relocate_new_kernel to the reboot_code_buffer for use
- * after the kernel is shut down.
- */
- memcpy(reboot_code_buffer, arm64_relocate_new_kernel,
- arm64_relocate_new_kernel_size);
-
- /* Flush the reboot_code_buffer in preparation for its execution. */
- __flush_dcache_area(reboot_code_buffer, arm64_relocate_new_kernel_size);
- flush_icache_range((uintptr_t)reboot_code_buffer,
- arm64_relocate_new_kernel_size);
-
/* Flush the kimage list and its buffers. */
kexec_list_flush(kimage);
@@ -206,7 +203,7 @@ void machine_kexec(struct kimage *kimage)
*/
cpu_soft_restart(kimage != kexec_crash_image,
- reboot_code_buffer_phys, kimage->head, kimage_start, 0);
+ reboot_code_buffer_phys, kimage->head, kimage->start, 0);
BUG(); /* Should never get here. */
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 569ec3325bc8..e4cc170edc0c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -90,6 +90,7 @@ early_param("initrd", early_initrd);
static void __init reserve_crashkernel(void)
{
unsigned long long crash_size, crash_base;
+ int start_rgn, end_rgn;
int ret;
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
@@ -120,6 +121,8 @@ static void __init reserve_crashkernel(void)
return;
}
}
+ memblock_isolate_range(&memblock.memory, crash_base, crash_size,
+ &start_rgn, &end_rgn);
memblock_reserve(crash_base, crash_size);
pr_info("Reserving %lldMB of memory at %lldMB for crashkernel\n",
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17243e43184e..b7c75845407a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -22,6 +22,8 @@
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/kexec.h>
#include <linux/libfdt.h>
#include <linux/mman.h>
#include <linux/nodemask.h>
@@ -817,3 +819,27 @@ int pmd_clear_huge(pmd_t *pmd)
pmd_clear(pmd);
return 1;
}
+
+#ifdef CONFIG_KEXEC_CORE
+void arch_kexec_protect_crashkres(void)
+{
+ flush_tlb_all();
+
+ create_mapping_late(crashk_res.start, __phys_to_virt(crashk_res.start),
+ resource_size(&crashk_res), PAGE_KERNEL_RO);
+
+ /* flush the TLBs after updating live kernel mappings */
+ flush_tlb_all();
+}
+
+void arch_kexec_unprotect_crashkres(void)
+{
+ flush_tlb_all();
+
+ create_mapping_late(crashk_res.start, __phys_to_virt(crashk_res.start),
+ resource_size(&crashk_res), PAGE_KERNEL);
+
+ /* flush the TLBs after updating live kernel mappings */
+ flush_tlb_all();
+}
+#endif
===>8===
^ permalink raw reply related
* [PATCH v2 0/8] ARM: dts: Switch to new DSA binding
From: Gregory CLEMENT @ 2017-01-17 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61c15ec6-6c0d-7865-d140-dba4ca3657a4@gmail.com>
Hi Florian,
On mar., janv. 17 2017, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 01/05/2017 11:29 AM, Florian Fainelli wrote:
>> Hi all,
>>
>> This patch series converts the in-tree users to utilize the new (relatively)
>> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
>> new binding"). The legacy binding node is kept included, but is marked
>> disabled.
>>
>> Changes in v2:
>>
>> - patch 1: Use an hexadecimal reg property
>> - patch 2: fixed the subject
>> - patch 3: s/okay/disabled/ for the legacy DSA node
>> - patches 7/8: fixed a stray whitespace
>>
>> In about 2-3 releases we may consider removing the old DSA binding entirely
>> from the kernel.
>
> Gregory, are you going to take this for 4.11? Thanks
it is my intend but I am waiting for the feedback from Andrew.
Gregory
>
>>
>> Thank you!
>>
>> Florian Fainelli (8):
>> ARM: dts: armada-370-rd: Utilize new DSA binding
>> ARM: dts: armada-385-linksys: Utilize new DSA binding
>> ARM: dts: armada-388-clearfog: Utilize new DSA binding
>> ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
>> ARM: dts: kirkwood-dir665: Utilize new DSA binding
>> ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
>> ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
>> ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
>>
>> arch/arm/boot/dts/armada-370-rd.dts | 44 +++++++++++++++++
>> arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++++++++++++++++++++-
>> arch/arm/boot/dts/armada-388-clearfog.dts | 65 ++++++++++++++++++++++++++
>> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++++++++++++++++++++
>> arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++++++++++++++++++
>> arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 +++++++++++++++++++
>> arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 +++++++++++++++++++
>> arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 +++++
>> arch/arm/boot/dts/kirkwood-rd88f6281.dtsi | 44 +++++++++++++++++
>> 9 files changed, 415 insertions(+), 1 deletion(-)
>>
>
>
> --
> Florian
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: B, Ravi @ 2017-01-17 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113181239.GC2630@atomide.com>
Hi Tony
>* Ravi Babu <ravibabu@ti.com> [170113 04:41]:
>> The SPL size for DRA74x platform has increased and is now more than
>> 64KB. Increase QSPI SPL partition size to 256KB for DRA74x EVM.
>>
>> QSPI partition numbering changes because of this.
>And this will break the existing partitions potentially..
>See what was discussed on the list few days ago in thread "[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table".
>It's best to have these left empty or as they originally were and let u-boot configure the partitions.
Agree with you. For dra7xx platform the SPL size has been increased to 256KB and hence the existing QSPI SPL partition in kernel (64K size) will break when latest mainline u-boot is used.
Here only SPL partition has been changed and other partition & size is NOT changed and kept intact. I feel it will not break the existing partitions for dra7xx platform.
>> Signed-off-by: Ravi Babu <ravibabu@ti.com>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> ---
>> arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
>> 1 file changed, 6 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts
>> b/arch/arm/boot/dts/dra7-evm.dts index 132f2be..2784241 100644
>> --- a/arch/arm/boot/dts/dra7-evm.dts
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -681,41 +681,29 @@
>> */
>> partition at 0 {
>> label = "QSPI.SPL";
>> - reg = <0x00000000 0x000010000>;
>> + reg = <0x00000000 0x000040000>;
>> };
>> partition at 1 {
>> - label = "QSPI.SPL.backup1";
>> - reg = <0x00010000 0x00010000>;
>> - };
>> - partition at 2 {
>> - label = "QSPI.SPL.backup2";
>> - reg = <0x00020000 0x00010000>;
>> - };
>> - partition at 3 {
>> - label = "QSPI.SPL.backup3";
>> - reg = <0x00030000 0x00010000>;
>> - };
>> - partition at 4 {
>> label = "QSPI.u-boot";
>> reg = <0x00040000 0x00100000>;
>> };
>> - partition at 5 {
>> + partition at 2 {
>> label = "QSPI.u-boot-spl-os";
>> reg = <0x00140000 0x00080000>;
>> };
>> - partition at 6 {
>> + partition at 3 {
>> label = "QSPI.u-boot-env";
>> reg = <0x001c0000 0x00010000>;
>> };
>> - partition at 7 {
>> + partition at 4 {
>> label = "QSPI.u-boot-env.backup1";
>> reg = <0x001d0000 0x0010000>;
>> };
>> - partition at 8 {
>> + partition at 5 {
>> label = "QSPI.kernel";
>> reg = <0x001e0000 0x0800000>;
>> };
>> - partition at 9 {
>> + partition at 6 {
>> label = "QSPI.file-system";
>> reg = <0x009e0000 0x01620000>;
>> };
>> --
Regards
Ravi
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-17 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vatedsn1.fsf@belgarion.home>
On 2017-01-17 08:58, Robert Jarzmik wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> When using the a device with edge-triggered interrupts, such as MSIs,
>> the interrupt handler has to ensure that there is a point in time during
>> its execution where all interrupts sources are silent so that a new
>> event can trigger a new interrupt again.
>>
>> This is achieved here by looping over SSSR evaluation. We need to take
>> into account that SSCR1 may be changed by the transfer handler, thus we
>> need to redo the mask calculation, at least regarding the volatile
>> interrupt enable bit (TIE).
>
> I'd like moreover to add a question here.
>
> In pxa architecture, SPI interrupts are already edge-triggered, and it's working
> well. The interrupt source disabling is not disabled, but the interrupt
> controller doesn't trigger an interrupt anymore (as it is masked), yet it marks
> it as pending if an interrupt arrives while the interrupt handler is running.
>
> All of this is handled by the interrupt core. My question is why for Intel MSI's
> is it necessary to make a change in the driver instead or relying on the
> interrupt core as for the pxa ?
If someone was using this driver with edge-triggered interrupt sources
so far, it was probably slower hardware and some luck (I've seen this
when driving fast-clocked devices vs. slower ones - only the latter
exposed the bug). Or that hardware did some temporary masking at
interrupt controller level while the handler was running. But that is
also not by design. It's the driver's task to ensure that all interrupt
sources are addressed once when returning from an edge-triggered
handler, and that is missing in this one.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH 2/3] dts: teach newer i.MX machines to have the i.MX35 type watchdog
From: Uwe Kleine-König @ 2017-01-17 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0586b2cd-6cbb-2e8a-9cd6-d7220708931d@mleia.com>
Hello Vladimir,
On Mon, Jan 16, 2017 at 11:48:40PM +0200, Vladimir Zapolskiy wrote:
> On 01/16/2017 10:43 PM, Uwe Kleine-K?nig wrote:
> > On Mon, Jan 16, 2017 at 04:35:26PM -0200, Fabio Estevam wrote:
> >> On Mon, Jan 9, 2017 at 7:50 AM, Uwe Kleine-K?nig
> >> <u.kleine-koenig@pengutronix.de> wrote:
> >>> Only i.MX35 and newer feature a WMCR register that should be written to. Older
> >>> SoCs hang when this address is written.
> >>>
> >>> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> >>
> >> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> >>
> >> Only a minor nit: Subject could: ARM: dts: imx: teach...
> >
> > Ack. To reference the commit id of the first patch in the third I can
> > prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
> >
>
> This is too early for changes, which are not reviewed by Linux watchdog masters.
>
> As I emphasized multiple times in our discussions your series is organized
> improperly, it has interdependencies between DTS and driver, it lacks
> atomicity feature of a proper fix, in the middle it breaks backward compatibility
> with old DTB, all that makes it impossible to send an atomic fix for linux-stable,
Oh, I must have missed that. In my inbox there are two replys to my
series, the one I reply to being the first to mention these critics.
Regarding your critics:
- organized improperly: that alone is too abstract to understand what
you mean.
- interdependencies between DTS and driver, lacks atomicity, impossible
to send an atomic fix for linux-stable: I wonder how you want to get
rid of that. Yes there are interdependencies, that's because both
driver and dts need adaption. Well, I could squash together some of
the changes, then there is a single patch that atomically fixes
everything. Personally I prefer to have three commits, each one
changing a single thing and considering all three together as a fix
for stable.
- in the middle it breaks backward compatibility: There are three
patches:
1) watchdog: imx2: Only i.MX35 and later have a WMCR register
2) dts: teach newer i.MX machines to have the i.MX35 type watchdog
3) watchdog: imx2: add compatibility for new i.MX35 type watchdog
Before the first patch we have:
- newer i.mx dtsi wrongly claims to have i.mx21 type watchdog
- watchdog handles i.MX21 as if it were i.MX35
After the first patch we have:
- newer i.mx dtsi wrongly claims to have i.mx21 type watchdog
And after the second everything is fine (assuming a dtb not older
than the kernel). So each patch fixes a single thing.
Yes, after the first patch machines having an i.MX35 type watchdog
might have a problem. That's because there are two things to fix (so
there are two patches): The driver must know about the new type and
the dts must make use of it. And fixing the first makes the second
visible, but doesn't introduce it (after all the i.MX35 dtsi is wrong
claiming to have the i.MX21 type).
Now that there are machines known that suffer from the problem under
discussion it's obvious that we want the changes from the third patch.
Personally I don't care much if it stays separate or is squashed into
the first one.
> some of the changes are captured from mine ones without preserving the authorship
> or even a reported-by credit.
Compared to your v1 the similarities are AFAICT:
- added .data to dt_ids array
- added an if to only conditionally execute the breaking command
- added a new compatible to several dtsi files
All these are necessary to fix the problem discussed here. The way I
implemented the first two ones are different to your way. So IMHO it's
at least questionable if you or I should be the author of the patches I
sent.
I'm ok to add a Reported-by for you. I usually add such a tag only after
a request for it. I missed to ask for that, please excuse this.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Maxime Ripard @ 2017-01-17 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116191449.50397-2-icenowy@aosc.xyz>
On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> controller.
>
> The original driver wired it to OHCI/EHCI controller; however, as the
> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> unusable.
>
> Rename the register (according to its function and the name in BSP
> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> can support both peripheral and host mode (although the host mode of
> MUSB is buggy).
Can you elaborate on that? What's wrong with it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/c5217ff0/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-17 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ziiqdstr.fsf@belgarion.home>
On 2017-01-17 08:54, Robert Jarzmik wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> When using the a device with edge-triggered interrupts, such as MSIs,
>> the interrupt handler has to ensure that there is a point in time during
>> its execution where all interrupts sources are silent so that a new
>> event can trigger a new interrupt again.
>>
>> This is achieved here by looping over SSSR evaluation. We need to take
>> into account that SSCR1 may be changed by the transfer handler, thus we
>> need to redo the mask calculation, at least regarding the volatile
>> interrupt enable bit (TIE).
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Hi Jan,
>
>> + while (1) {
> This bit worries me a bit, as this can be either :
> - hogging the SoC's CPU, endlessly running
> - or even worse, blocking the CPU for ever
>
> The question behind is, should this be done in a top-half, or moved to a irq
> thread ?
Every device with a broken interrupt source can hog CPUs, nothing
special with this one. If you don't close the loop in the handler
itself, you close it over the hardware retriggering the interrupt over
and over again.
So, I don't see a point in offloading to a thread. The normal case is
some TX done (FIFO available) event followed by an RX event, then the
transfer is complete, isn't it?
>
>> + /* Ignore possible writes if we don't need to write */
>> + if (!(sccr1_reg & SSCR1_TIE))
>> + mask &= ~SSSR_TFS;
>>
>> - if (!drv_data->master->cur_msg) {
>> - handle_bad_msg(drv_data);
>> - /* Never fail */
>> - return IRQ_HANDLED;
>> - }
>> + if (!(status & mask))
>> + return ret;
>> +
>> + if (!drv_data->master->cur_msg) {
>> + handle_bad_msg(drv_data);
>> + /* Never fail */
>> + return IRQ_HANDLED;
>> + }
>> +
>> + ret |= drv_data->transfer_handler(drv_data);
> Mmm that looks weird to me, oring a irqreturn.
Not really an uncommon pattern, though.
>
> Imagine that on first iteration the handler returns IRQ_NONE, and on second
> IRQ_HANDLED. This makes ret IRQ_HANDLED. Yet after the first iteration the
> handler should have exited, especially if the interrupt is shared with another
> driver.
That would be a bug in transfer_handler, because we don't enter it
without a reason (status != 0).
>
> Another thing which is along what Andy already said : it would be better
> practice to have this loop in the form :
> do {
> ...
> } while (exit_condition_not_met);
This implies code duplication in order to calculate the condition
(mask...). I can do this if desired, I wouldn't do this to my own code,
though.
Jan
>
> Just for maintainability, it's better, and it concentrates the test on the
> "exit_condition_not_met" in one place, which will enable us to review better the
> algorithm.
>
> Cheers.
>
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Robert Jarzmik @ 2017-01-17 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b15a0910a3ad861fd32161c72559bafa7b71e29.1484592296.git.jan.kiszka@siemens.com>
Jan Kiszka <jan.kiszka@siemens.com> writes:
> When using the a device with edge-triggered interrupts, such as MSIs,
> the interrupt handler has to ensure that there is a point in time during
> its execution where all interrupts sources are silent so that a new
> event can trigger a new interrupt again.
>
> This is achieved here by looping over SSSR evaluation. We need to take
> into account that SSCR1 may be changed by the transfer handler, thus we
> need to redo the mask calculation, at least regarding the volatile
> interrupt enable bit (TIE).
I'd like moreover to add a question here.
In pxa architecture, SPI interrupts are already edge-triggered, and it's working
well. The interrupt source disabling is not disabled, but the interrupt
controller doesn't trigger an interrupt anymore (as it is masked), yet it marks
it as pending if an interrupt arrives while the interrupt handler is running.
All of this is handled by the interrupt core. My question is why for Intel MSI's
is it necessary to make a change in the driver instead or relying on the
interrupt core as for the pxa ?
Cheers.
--
Robert
^ permalink raw reply
* drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes
From: Randy Li @ 2017-01-17 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Hello:
I want to enable the video output at RK3288 Firefly board, but I
found if I enable CONFIG_DRM_FBDEV_EMULATION, the HDMI would crash down
sometimes but sometimes it works. After disable that opinion, I never
meet a problem. I have not verified it with eDP as I meet a big problem
in there.
[ OK ] Stopped LSB: Load kernel modules needed to enable cpufreq scaling.
[ 33.282843] [drm:drm_atomic_helper_commit_cleanup_done
[drm_kms_helper]] *ERROR* [CRTC:27:crtc-0] flip_done timed out
[ 33.361489] ------------[ cut here ]------------
[ 33.366251] WARNING: CPU: 2 PID: 476 at
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm$
vop.c:730 vop_plane_atomic_update+0x1218/0x177c [rockchipdrm]
[ 33.383071] Modules linked in: rockchip_vop_reg rockchipdrm
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sys$
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockch$
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl
backlight fb
[ 33.412751] CPU: 2 PID: 476 Comm: X Tainted: G W
4.10.0-rc3-next-20170111+ #148
[ 33.421182] Hardware name: Rockchip (Device Tree)
[ 33.425905] [<c0112b98>] (unwind_backtrace) from [<c010dab8>]
(show_stack+0x20/0x24)
[ 33.433652] [<c010dab8>] (show_stack) from [<c044973c>]
(dump_stack+0x8c/0xa0)
[ 33.440881] [<c044973c>] (dump_stack) from [<c0125f88>]
(__warn+0xf8/0x110)
[ 33.447839] [<c0125f88>] (__warn) from [<c01260b8>]
(warn_slowpath_null+0x30/0x38)
[ 33.455431] [<c01260b8>] (warn_slowpath_null) from [<bf5cb4dc>]
(vop_plane_atomic_update+0x1218/0x177c [rockchipdrm])
[ 33.466126] [<bf5cb4dc>] (vop_plane_atomic_update [rockchipdrm]) from
[<bf4d8590>] (drm_atomic_helper_commit_planes+0xd4/0x2b8
[drm_kms_helper])
[ 33.479160] [<bf4d8590>] (drm_atomic_helper_commit_planes
[drm_kms_helper]) from [<bf5c6a88>] (rockchip_atomic_commit_tail+0x4$
/0x68 [rockchipdrm])
[ 33.492451] [<bf5c6a88>] (rockchip_atomic_commit_tail [rockchipdrm])
from [<bf4dc714>] (commit_tail+0x50/0xb8 [drm_kms_helper]$
[ 33.504061] [<bf4dc714>] (commit_tail [drm_kms_helper]) from
[<bf4dc870>] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper$
)
[ 33.515850] [<bf4dc870>] (drm_atomic_helper_commit [drm_kms_helper])
from [<bf09318c>] (drm_atomic_commit+0x5c/0x68 [drm])
[ 33.527126] [<bf09318c>] (drm_atomic_commit [drm]) from [<bf4e00f8>]
(restore_fbdev_mode+0x160/0x300 [drm_kms_helper])
[ 33.537952] [<bf4e00f8>] (restore_fbdev_mode [drm_kms_helper]) from
[<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x$
0/0x84 [drm_kms_helper])
[ 33.551590] [<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked
[drm_kms_helper]) from [<bf5c6218>] (rockchip_drm_lastclos$
+0x1c/0x20 [rockchipdrm])
[ 33.565404] [<bf5c6218>] (rockchip_drm_lastclose [rockchipdrm]) from
[<bf07d20c>] (drm_lastclose+0x48/0xd8 [drm])
[ 33.575977] [<bf07d20c>] (drm_lastclose [drm]) from [<bf07d560>]
(drm_release+0x2c4/0x36c [drm])
[ 33.584927] [<bf07d560>] (drm_release [drm]) from [<c02d7b34>]
(__fput+0x9c/0x1e8)
[ 33.592501] [<c02d7b34>] (__fput) from [<c02d7cf0>] (____fput+0x18/0x1c)
[ 33.599206] [<c02d7cf0>] (____fput) from [<c0146ed4>]
(task_work_run+0xcc/0xf0)
[ 33.606519] [<c0146ed4>] (task_work_run) from [<c010d1b0>]
(do_work_pending+0xd0/0xd4)
[ 33.614439] [<c010d1b0>] (do_work_pending) from [<c0108e28>]
(slow_work_pending+0xc/0x20)
[ 33.622674] ---[ end trace 95ed2c3f167607d2 ]---
[ 33.627327] ------------[ cut here ]------------
[ 33.632013] WARNING: CPU: 2 PID: 476 at
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_
vop.c:1017 vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm]
[ 33.648542] Modules linked in: rockchip_vop_reg rockchipdrm
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sysc
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockchi
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl
backlight fb
[ 33.678191] CPU: 2 PID: 476 Comm: X Tainted: G W
4.10.0-rc3-next-20170111+ #148
[ 33.686621] Hardware name: Rockchip (Device Tree)
[ 33.691339] [<c0112b98>] (unwind_backtrace) from [<c010dab8>]
(show_stack+0x20/0x24)
[ 33.699084] [<c010dab8>] (show_stack) from [<c044973c>]
(dump_stack+0x8c/0xa0)
[ 33.706309] [<c044973c>] (dump_stack) from [<c0125f88>]
(__warn+0xf8/0x110)
[ 33.713275] [<c0125f88>] (__warn) from [<c01260b8>]
(warn_slowpath_null+0x30/0x38)
[ 33.720864] [<c01260b8>] (warn_slowpath_null) from [<bf5c83e0>]
(vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm])
[ 33.731208] [<bf5c83e0>] (vop_crtc_atomic_flush [rockchipdrm]) from
[<bf4d868c>] (drm_atomic_helper_commit_planes+0x1d0/0x2b8 [
drm_kms_helper])
[ 33.744159] [<bf4d868c>] (drm_atomic_helper_commit_planes
[drm_kms_helper]) from [<bf5c6a88>] (rockchip_atomic_commit_tail+0x44
/0x68 [rockchipdrm])
[ 33.757451] [<bf5c6a88>] (rockchip_atomic_commit_tail [rockchipdrm])
from [<bf4dc714>] (commit_tail+0x50/0xb8 [drm_kms_helper])
[ 33.769064] [<bf4dc714>] (commit_tail [drm_kms_helper]) from
[<bf4dc870>] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper]
)
[ 33.780861] [<bf4dc870>] (drm_atomic_helper_commit [drm_kms_helper])
from [<bf09318c>] (drm_atomic_commit+0x5c/0x68 [drm])
[ 33.792131] [<bf09318c>] (drm_atomic_commit [drm]) from [<bf4e00f8>]
(restore_fbdev_mode+0x160/0x300 [drm_kms_helper])
[ 33.802956] [<bf4e00f8>] (restore_fbdev_mode [drm_kms_helper]) from
[<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4
0/0x84 [drm_kms_helper])
[ 33.816590] [<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked
[drm_kms_helper]) from [<bf5c6218>] (rockchip_drm_lastclose
+0x1c/0x20 [rockchipdrm])
[ 33.830406] [<bf5c6218>] (rockchip_drm_lastclose [rockchipdrm]) from
[<bf07d20c>] (drm_lastclose+0x48/0xd8 [drm])
[ 33.840975] [<bf07d20c>] (drm_lastclose [drm]) from [<bf07d560>]
(drm_release+0x2c4/0x36c [drm])
[ 33.849923] [<bf07d560>] (drm_release [drm]) from [<c02d7b34>]
(__fput+0x9c/0x1e8)
[ 33.857497] [<c02d7b34>] (__fput) from [<c02d7cf0>] (____fput+0x18/0x1c)
[ 33.864201] [<c02d7cf0>] (____fput) from [<c0146ed4>]
(task_work_run+0xcc/0xf0)
[ 33.871514] [<c0146ed4>] (task_work_run) from [<c010d1b0>]
(do_work_pending+0xd0/0xd4)
[ 33.879434] [<c010d1b0>] (do_work_pending) from [<c0108e28>]
(slow_work_pending+0xc/0x20)
[ 33.887671] ---[ end trace 95ed2c3f167607d3 ]---
[ 33.892322] ------------[ cut here ]------------
[ 33.897058] WARNING: CPU: 2 PID: 476 at
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/drm_atomic_helper.c:15
63 drm_atomic_helper_commit_hw_done+0xc0/0xc8 [drm_kms_helper]
[ 33.913937] Modules linked in: rockchip_vop_reg rockchipdrm
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sysc
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockchi
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl
backlight fb
[ 33.943581] CPU: 2 PID: 476 Comm: X Tainted: G W
4.10.0-rc3-next-20170111+ #148
[ 33.952010] Hardware name: Rockchip (Device Tree)
[ 33.956726] [<c0112b98>] (unwind_backtrace) from [<c010dab8>]
(show_stack+0x20/0x24)
[ 33.964470] [<c010dab8>] (show_stack) from [<c044973c>]
(dump_stack+0x8c/0xa0)
[ 33.971695] [<c044973c>] (dump_stack) from [<c0125f88>]
(__warn+0xf8/0x110)
[ 33.978661] [<c0125f88>] (__warn) from [<c01260b8>]
(warn_slowpath_null+0x30/0x38)
[ 33.986301] [<c01260b8>] (warn_slowpath_null) from [<bf4d9410>]
(drm_atomic_helper_commit_hw_done+0xc0/0xc8 [drm_kms_helper])
[ 33.997686] [<bf4d9410>] (drm_atomic_helper_commit_hw_done
[drm_kms_helper]) from [<bf5c6a90>] (rockchip_atomic_commit_tail+0x4
c/0x68 [rockchipdrm])
[ 34.011062] [<bf5c6a90>] (rockchip_atomic_commit_tail [rockchipdrm])
from [<bf4dc714>] (commit_tail+0x50/0xb8 [drm_kms_helper])
[ 34.022670] [<bf4dc714>] (commit_tail [drm_kms_helper]) from
[<bf4dc870>] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper]
)
[ 34.034458] [<bf4dc870>] (drm_atomic_helper_commit [drm_kms_helper])
from [<bf09318c>] (drm_atomic_commit+0x5c/0x68 [drm])
[ 34.045728] [<bf09318c>] (drm_atomic_commit [drm]) from [<bf4e00f8>]
(restore_fbdev_mode+0x160/0x300 [drm_kms_helper])
[ 34.056555] [<bf4e00f8>] (restore_fbdev_mode [drm_kms_helper]) from
[<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4
0/0x84 [drm_kms_helper])
[ 34.070190] [<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked
[drm_kms_helper]) from [<bf5c6218>] (rockchip_drm_lastclose
+0x1c/0x20 [rockchipdrm])
[ 34.084005] [<bf5c6218>] (rockchip_drm_lastclose [rockchipdrm]) from
[<bf07d20c>] (drm_lastclose+0x48/0xd8 [drm])
[ 34.094581] [<bf07d20c>] (drm_lastclose [drm]) from [<bf07d560>]
(drm_release+0x2c4/0x36c [drm])
[ 34.103526] [<bf07d560>] (drm_release [drm]) from [<c02d7b34>]
(__fput+0x9c/0x1e8)
[ 34.111099] [<c02d7b34>] (__fput) from [<c02d7cf0>] (____fput+0x18/0x1c)
[ 34.117802] [<c02d7cf0>] (____fput) from [<c0146ed4>]
(task_work_run+0xcc/0xf0)
[ 34.125115] [<c0146ed4>] (task_work_run) from [<c010d1b0>]
(do_work_pending+0xd0/0xd4)
[ 34.133034] [<c010d1b0>] (do_work_pending) from [<c0108e28>]
(slow_work_pending+0xc/0x20)
[ 34.141250] ---[ end trace 95ed2c3f167607d4 ]---
[ 34.145921] ------------[ cut here ]------------
[ 34.150566] WARNING: CPU: 2 PID: 476 at
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_
vop.c:828 vop_crtc_enable_vblank+0x1ac/0x1b4 [rockchipdrm]
[ 34.167054] Modules linked in: rockchip_vop_reg rockchipdrm
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sysc
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockchi
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl
backlight fb
[ 34.196651] CPU: 2 PID: 476 Comm: X Tainted: G W
4.10.0-rc3-next-20170111+ #148
[ 34.205078] Hardware name: Rockchip (Device Tree)
[ 34.209794] [<c0112b98>] (unwind_backtrace) from [<c010dab8>]
(show_stack+0x20/0x24)
[ 34.217538] [<c010dab8>] (show_stack) from [<c044973c>]
(dump_stack+0x8c/0xa0)
[ 34.224763] [<c044973c>] (dump_stack) from [<c0125f88>]
(__warn+0xf8/0x110)
[ 34.231729] [<c0125f88>] (__warn) from [<c01260b8>]
(warn_slowpath_null+0x30/0x38)
[ 34.239318] [<c01260b8>] (warn_slowpath_null) from [<bf5c7b7c>]
(vop_crtc_enable_vblank+0x1ac/0x1b4 [rockchipdrm])
[ 34.249693] [<bf5c7b7c>] (vop_crtc_enable_vblank [rockchipdrm]) from
[<bf5c61f0>] (rockchip_drm_crtc_enable_vblank+0x48/0x54 [r
ockchipdrm])
[ 34.262378] [<bf5c61f0>] (rockchip_drm_crtc_enable_vblank
[rockchipdrm]) from [<bf07ff80>] (drm_vblank_enable+0x8c/0xf8 [drm])
[ 34.274077] [<bf07ff80>] (drm_vblank_enable [drm]) from [<bf0800b4>]
(drm_vblank_get+0xc8/0xf0 [drm])
[ 34.283616] [<bf0800b4>] (drm_vblank_get [drm]) from [<bf0800fc>]
(drm_crtc_vblank_get+0x20/0x24 [drm])
[ 34.293239] [<bf0800fc>] (drm_crtc_vblank_get [drm]) from
[<bf4dc00c>] (drm_atomic_helper_wait_for_vblanks.part.0+0xa8/0x2a8 [d
rm_kms_helper])
[ 34.306146] [<bf4dc00c>] (drm_atomic_helper_wait_for_vblanks.part.0
[drm_kms_helper]) from [<bf4dc230>] (drm_atomic_helper_wait
_for_vblanks+0x24/0x28 [drm_kms_helper])
[ 34.321176] [<bf4dc230>] (drm_atomic_helper_wait_for_vblanks
[drm_kms_helper]) from [<bf5c6a9c>] (rockchip_atomic_commit_tail+0
x58/0x68 [rockchipdrm])
[ 34.334725] [<bf5c6a9c>] (rockchip_atomic_commit_tail [rockchipdrm])
from [<bf4dc714>] (commit_tail+0x50/0xb8 [drm_kms_helper])
[ 34.346330] [<bf4dc714>] (commit_tail [drm_kms_helper]) from
[<bf4dc870>] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper]
)
[ 34.358117] [<bf4dc870>] (drm_atomic_helper_commit [drm_kms_helper])
from [<bf09318c>] (drm_atomic_commit+0x5c/0x68 [drm])
[ 34.369386] [<bf09318c>] (drm_atomic_commit [drm]) from [<bf4e00f8>]
(restore_fbdev_mode+0x160/0x300 [drm_kms_helper])
[ 34.380209] [<bf4e00f8>] (restore_fbdev_mode [drm_kms_helper]) from
[<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x4
0/0x84 [drm_kms_helper])
[ 34.393845] [<bf4e171c>] (drm_fb_helper_restore_fbdev_mode_unlocked
[drm_kms_helper]) from [<bf5c6218>] (rockchip_drm_lastclose
+0x1c/0x20 [rockchipdrm])
[ 34.407664] [<bf5c6218>] (rockchip_drm_lastclose [rockchipdrm]) from
[<bf07d20c>] (drm_lastclose+0x48/0xd8 [drm])
[ 34.418237] [<bf07d20c>] (drm_lastclose [drm]) from [<bf07d560>]
(drm_release+0x2c4/0x36c [drm])
[ 34.427179] [<bf07d560>] (drm_release [drm]) from [<c02d7b34>]
(__fput+0x9c/0x1e8)
[ 34.434754] [<c02d7b34>] (__fput) from [<c02d7cf0>] (____fput+0x18/0x1c)
[ 34.441458] [<c02d7cf0>] (____fput) from [<c0146ed4>]
(task_work_run+0xcc/0xf0)
[ 34.448769] [<c0146ed4>] (task_work_run) from [<c010d1b0>]
(do_work_pending+0xd0/0xd4)
[ 34.456688] [<c010d1b0>] (do_work_pending) from [<c0108e28>]
(slow_work_pending+0xc/0x20)
[ 34.464856] ---[ end trace 95ed2c3f167607d5 ]---
--
Randy Li
The third produce department
===========================================================================
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===========================================================================
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Robert Jarzmik @ 2017-01-17 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b15a0910a3ad861fd32161c72559bafa7b71e29.1484592296.git.jan.kiszka@siemens.com>
Jan Kiszka <jan.kiszka@siemens.com> writes:
> When using the a device with edge-triggered interrupts, such as MSIs,
> the interrupt handler has to ensure that there is a point in time during
> its execution where all interrupts sources are silent so that a new
> event can trigger a new interrupt again.
>
> This is achieved here by looping over SSSR evaluation. We need to take
> into account that SSCR1 may be changed by the transfer handler, thus we
> need to redo the mask calculation, at least regarding the volatile
> interrupt enable bit (TIE).
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Hi Jan,
> + while (1) {
This bit worries me a bit, as this can be either :
- hogging the SoC's CPU, endlessly running
- or even worse, blocking the CPU for ever
The question behind is, should this be done in a top-half, or moved to a irq
thread ?
> + /* Ignore possible writes if we don't need to write */
> + if (!(sccr1_reg & SSCR1_TIE))
> + mask &= ~SSSR_TFS;
>
> - if (!drv_data->master->cur_msg) {
> - handle_bad_msg(drv_data);
> - /* Never fail */
> - return IRQ_HANDLED;
> - }
> + if (!(status & mask))
> + return ret;
> +
> + if (!drv_data->master->cur_msg) {
> + handle_bad_msg(drv_data);
> + /* Never fail */
> + return IRQ_HANDLED;
> + }
> +
> + ret |= drv_data->transfer_handler(drv_data);
Mmm that looks weird to me, oring a irqreturn.
Imagine that on first iteration the handler returns IRQ_NONE, and on second
IRQ_HANDLED. This makes ret IRQ_HANDLED. Yet after the first iteration the
handler should have exited, especially if the interrupt is shared with another
driver.
Another thing which is along what Andy already said : it would be better
practice to have this loop in the form :
do {
...
} while (exit_condition_not_met);
Just for maintainability, it's better, and it concentrates the test on the
"exit_condition_not_met" in one place, which will enable us to review better the
algorithm.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Tero Kristo @ 2017-01-17 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0eaa9914-83f1-7716-cf04-1e3dd44df647@ti.com>
On 17/01/17 00:12, Dave Gerlach wrote:
> On 01/13/2017 08:40 PM, Rob Herring wrote:
>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>>>
>>>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>
>>>>> Rob,
>>>>>
>>>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Rob,
>>>>>>>
>>>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>>> will hook into the genpd framework and allow the TI SCI
>>>>>>>>> protocol to
>>>>>>>>> control device power states.
>>>>>>>>>
>>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>>> ---
>>>>>>>>> v2->v3:
>>>>>>>>> Update k2g_pds node docs to show it should be a child
>>>>>>>>> of pmmc
>>>>>>>>> node.
>>>>>>>>> In early versions a phandle was used to point to pmmc and
>>>>>>>>> docs
>>>>>>>>> still
>>>>>>>>> incorrectly showed this.
>>>>>>>>>
>>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59
>>>>>>>>> ++++++++++++++
>>>>>>>>> MAINTAINERS | 2 +
>>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>> 3 files changed, 151 insertions(+)
>>>>>>>>> create mode 100644
>>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..4c9064e512cb
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>> @@ -0,0 +1,59 @@
>>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>>> +---------------------------------------------
>>>>>>>>> +
>>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>>> that
>>>>>>>>> is
>>>>>>>>> +responsible for controlling the state of the IPs that are
>>>>>>>>> present.
>>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>>> system
>>>>>>>>> +controller happens through a protocol known as TI-SCI [1].
>>>>>>>>> This pm
>>>>>>>>> domain
>>>>>>>>> +implementation plugs into the generic pm domain framework and
>>>>>>>>> makes
>>>>>>>>> use
>>>>>>>>> of
>>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>>> +
>>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>>> +
>>>>>>>>> +PM Domain Node
>>>>>>>>> +==============
>>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>>> PMMC,
>>>>>>>>> +which in this case is the single implementation as documented
>>>>>>>>> by the
>>>>>>>>> generic
>>>>>>>>> +PM domain bindings in
>>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>>> +Because this relies on the TI SCI protocol to communicate with
>>>>>>>>> the
>>>>>>>>> PMMC
>>>>>>>>> it
>>>>>>>>> +must be a child of the pmmc node.
>>>>>>>>> +
>>>>>>>>> +Required Properties:
>>>>>>>>> +--------------------
>>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>>> +
>>>>>>>>> +Example (K2G):
>>>>>>>>> +-------------
>>>>>>>>> + pmmc: pmmc {
>>>>>>>>> + compatible = "ti,k2g-sci";
>>>>>>>>> + ...
>>>>>>>>> +
>>>>>>>>> + k2g_pds: k2g_pds {
>>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> +PM Domain Consumers
>>>>>>>>> +===================
>>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>>> provide
>>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>>> device
>>>>>>>>> +specific ID that identifies the device.
>>>>>>>>> +
>>>>>>>>> +Required Properties:
>>>>>>>>> +--------------------
>>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>>> node.
>>>>>>>>> +- ti,sci-id: index representing the device id to be passed
>>>>>>>>> oevr SCI
>>>>>>>>> to
>>>>>>>>> + be used for device control.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As I've already stated before, this goes in power-domain cells.
>>>>>>>> When
>>>>>>>> you
>>>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>>>> you
>>>>>>>> you need to specify the ID for each of them in phandle args.
>>>>>>>> This is
>>>>>>>> how
>>>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You think the reasoning for doing it this way provided by both
>>>>>>> Ulf and
>>>>>>> myself on v2 [1] is not valid then?
>>>>>>>
>>>>>>> From Ulf:
>>>>>>>
>>>>>>> To me, the TI SCI ID, is similar to a "conid" for any another
>>>>>>> "device
>>>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>>>> in DT and assign to a device node. The only difference here, is that
>>>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>>>> do with DT bindings.
>>>>>>
>>>>>>> From me:
>>>>>>>
>>>>>>> Yes, you've pretty much hit it on the head. It is not an index
>>>>>>> into a
>>>>>>> list
>>>>>>> of genpds but rather identifies the device *within* a single
>>>>>>> genpd. It
>>>>>>> is
>>>>>>> a
>>>>>>> property specific to each device that resides in a ti-sci-genpd,
>>>>>>> not a
>>>>>>> mapping describing which genpd the device belongs to. The generic
>>>>>>> power
>>>>>>> domain binding is concerned with mapping the device to a specific
>>>>>>> genpd,
>>>>>>> which is does fine for us, but we have a sub mapping for devices
>>>>>>> that
>>>>>>> exist
>>>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>>>
>>>>>>>
>>>>>>> So to summarize, the genpd framework does interpret the phandle
>>>>>>> arg as
>>>>>>> an
>>>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>>>> but
>>>>>>> this is not what I am trying to do, we have multiple devices within
>>>>>>> this
>>>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fix the genpd framework rather than work around it in DT.
>>>>>
>>>>>
>>>>>
>>>>> I still disagree that this has nothing to do with DT bindings, as the
>>>>> current DT binding represents something different already. I am
>>>>> trying to
>>>>> extend it to give me additional information needed for our
>>>>> platforms. Are
>>>>> you saying that we should break what the current DT binding already
>>>>> represents to mean something else?
>>>>
>>>>
>>>> No idea because what's the current binding? From the patch, looks like
>>>> a new binding to me.
>>>
>>>
>>> Yes, ti,sci-id is a new binding. I am referring to the current
>>> meaning of
>>> the "power-domains" binding, which is where you are asking this
>>> property to
>>> be added, in "power-domains" cells. This is documented here [1] in the
>>> kernel, although looking at it I must admit it is not very clear.
>>>
>>> The power-domains cell represents an offset into an array of power
>>> domains,
>>> if you choose to use it. That's what the genpd framework is hard
>>> coded to
>>> interpret it as. This is correct, as it is an index into a static
>>> list of
>>> power domains, used to identify which power domain a device belongs to,
>>> which is exactly what the genpd framework itself is concerned with.
>>> This is
>>> already how it is used in the kernel today.
>>
>> Strictly speaking, the cells are purely for the interpretation of the
>> phandle they are associated with. If some controller wants to have 20
>> cells, then it could assuming a good reason. The reality is we tend to
>> align the meaning of the cells. If genpd is interpreting the cells and
>> not letting the driver for the power domain controller interpret them,
>> then still, genpd needs to be fixed.
>
> Ok, perhaps the genpd folks on the thread can jump in here with any
> thoughts that they have.
>
>>
>> IIRC, initially it was said genpd required 0 cells, hence my confusion.
>>
>>> My ti,sci-id is not an index into a list of power domains, so it
>>> should not
>>> go in the power-domains cells and go against what the power-domains
>>> binding
>>> says that the cell expects. We have one single power domain, and the new
>>> ti,sci-id binding is not something the genpd framework itself is
>>> concerned
>>> with as it's our property to identify a device inside a power domain,
>>> not to
>>> identify which power domain it is associated with.
>>
>> What is the id used for? I can understand why you need to know what
>> power domain a device is in (as power-domains identifies), but not
>> what devices are in a power domain.
>
> We have a system control processor that provides power management
> services to the OS and it responsible for handling the power state of
> each device. This control happens over a communication interface we have
> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
> communication protocol uses these ids to identify each device within the
> power domain so that the control processor can do what is necessary to
> enable that device.
I think a minor detail here that Rob might be missing right now is, that
the ti,sci-id is only controlling the PM runtime handling, and providing
the ID per-device for this purpose only. AFAIK, it is not really
connected to the power domain anymore as such, as we don't have
power-domains / per device anymore as was the case in some earlier
revision of this work.
One could argue though that the whole usage of power-domains is now
moot, as we basically only have implemented one genpd in the whole SoC,
which doesn't really reflect the reality. I wonder if better approach
would be to have this replaced with proper power domains at some point
(if needed), and just have a runtime-pm implementation in place for the
devices that require it.
So, as an example in DT, we would only have:
uart0: serial at 02530c00 {
compatible = "xyz";
...
ti,sci-id = <K2G_DEV_UART0>;
};
This is somewhat analogous to what OMAP family of SoCs have in place
now, under "ti,hwmods" property. I also wonder if the "ti,sci-id" should
be replaced with something like "ti,sci-dev-id" to make its purpose clearer.
-Tero
>
> Regards,
> Dave
>
>>
>> Rob
>>
>
^ permalink raw reply
* [PATCH v3 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
From: Shawn Guo @ 2017-01-17 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484623377-16208-3-git-send-email-baoyou.xie@linaro.org>
On Tue, Jan 17, 2017 at 11:22:57AM +0800, Baoyou Xie wrote:
> This patch adds reset controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [PATCH v3 00/18] FSI device driver introduction
From: Greg KH @ 2017-01-17 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484601768-98079-1-git-send-email-christopher.lee.bostic@gmail.com>
On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bostic at gmail.com wrote:
> From: Chris Bostic <cbostic@us.ibm.com>
<snip>
Only this, and patch 02/18 came through, did something get stuck on your
end?
greg k-h
^ permalink raw reply
* [PATCH 06/12] pinctrl: samsung: Add missing initconst annotation
From: Tomasz Figa @ 2017-01-17 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc0u061nany6SYWRN5W=iKWWSJpZ_W5g68AM9_+oR=B7Q@mail.gmail.com>
2017-01-17 15:34 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Tue, Jan 17, 2017 at 6:44 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> 2017-01-17 4:14 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>>> On Mon, Jan 16, 2017 at 07:45:01AM +0100, Marek Szyprowski wrote:
>>>> Exynos5433 support has been added in parallel to adding initconst
>>>> annotation to most of the init data structures, so add those
>>>> annotations also to Exynos5433 structures.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>> drivers/pinctrl/samsung/pinctrl-exynos.c | 22 +++++++++++-----------
>>>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>>> index bf753a596209..70b94ad10cc1 100644
>>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>>> @@ -1266,7 +1266,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>>>> };
>>>>
>>>> /* pin banks of exynos5433 pin-controller - ALIVE */
>>>> -static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
>>>> +static const struct samsung_pin_bank_data exynos5433_pin_banks0[] __initconst = {
>>>> EXYNOS5433_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
>>>> EXYNOS5433_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
>>>> EXYNOS5433_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
>>>> @@ -1279,28 +1279,28 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>>>> };
>>>
>>> Your change is aligned with existing code... but after I started to look
>>> into it I think this should not be initconst.
>>>
>>> The pin_banks (initconst) are referenced in pin_ctrl (initconst) which
>>> is referenced in samsung_pinctrl_dt_match (NOT initconst). The dt_match
>>> then is used in samsung_pinctrl_driver (for obvious reasons not
>>> initconst).
>>>
>>> We suppress the bind so this looks safe - this data should not be ever used
>>> after init - but it is not correct strictly speaking.
>>>
>>> Let's imagine some weird future platform which will use DT overlays with
>>> pinctrl. I think the overlays could affect the tree after the init
>>> stage.
>>
>> I think it's not very realistic to have a Samsung on-SoC pin
>> controller in an overlay. AFAIR we already assume in several places
>> that this driver fully initializes in init stage, so we can save some
>> memory by discarding this data
>
> Two things here. Either we write proper code or we write code for
> "believe it will work". There is a problem with second approach -
> after some time, the driver will be developed further it your
> assumptions might change... then stuff might get broken because no one
> expected that driver data is discarded. Code working only with some
> assumptions is a more difficult to maintain than code which is
> correct.
We write code that is proper for the assumptions we made during the
design, i.e. design decisions. Otherwise you would end up with the
driver bloated everywhere with handing things that don't make any
sense, which would be definitely _not_ easier to maintain. Of course
we can have some trivial code to enforce the assumptions, as I
mentioned before.
This is a driver for an on-chip low level device that is very, very
unlikely to be hotpluggable and almost any other driver for remaining
on-chip devices depend on it. It doesn't mean that we can't change the
design decision later, if in future it becomes feasible to load
low-level SoC drivers from modules then we can make the driver support
so.
>
> In the same time if you believe your code is "correct" then just mark
> samsung_pinctrl_dt_match initconst... Marking only few parts in the
> chain is broken.
I haven't said that samsung_pinctrl_dt_match should be kept
non-initconst. It's indeed a good idea to make it initconst as well.
>
> Second thing. How much memory you are saving? 5 kB in total? 10 kB? Is
> it worth the risk?
10 kB in one driver. Multiply by the number of similar low level
drivers for all SoCs supported by ARM v7 multiplatform build and you
can get quite a significant number of memory saved...
>
>> Still, I guess we could add some measure to make sure nothing attempts
>> to probe this driver after the data is discarded.
>
> That could work... but last time I asked for checking the return value
> of match_data then you (I think) and Bartlomiej responded "no sense".
> So please be consistent.
That's because this is already enforced by the design of the driver model...
> Anyway it is not possible to NULL-ify the
> match_data after first probe because samsung_pinctrl_dt_match is
> const. This means you would have to add some crazy logic to check for
> late (from overlays) or second probe and discard it... just because we
> wanted to save some memory and marked initconst something referenced
> from non-initconst section.
...and similarly the assumptions we are talking about in case of this
problem could be enforced the same way. There is already
platform_driver_probe() that is supposed to be used for such on-SoC
non-hotpluggable devices and which triggers a one-time probe.
Unfortunately it is a bit broken currently, because it can't handle
deferred probes.
Anyway, I'm not even insisting that we should keep this initconst
annotation. Just wanted to point out that there are valid reasons for
it to be useful and correct (in terms of the design decisions taken
when writing the driver).
Best regards,
Tomasz
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v4.11
From: Olof Johansson @ 2017-01-17 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbfa1905-d937-7d02-7bbb-5f1a127896cf@arm.com>
Hi,
On Mon, Jan 16, 2017 at 04:22:06PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
> tags/juno-updates-4.11
>
> for you to fetch changes up to ea2dcf9ac3254c964cddd67a032cb3b691fa47ce:
>
> arm64: dts: juno: add missing CoreSight STM component (2017-01-12
> 17:26:49 +0000)
>
> ----------------------------------------------------------------
> ARMv8 Vexpress/Juno DT updates for v4.11
>
> 1. Addition of Coresight support on Juno R1 and R2 variants
>
> 2. Addition of STM(System Trace Macrocell) support on all Juno variants
See comment on one of the patches, not merging until addressed.
Thanks,
-Olof
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
From: Olof Johansson @ 2017-01-17 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484234410-7670-3-git-send-email-sudeep.holla@arm.com>
Hi,
On Thu, Jan 12, 2017 at 7:20 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> This patch builds on top of the existing r0 support and extends it to
> Juno r1/r2 variants.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla at arm.com: minor changelog update and reorganising the common
> coresight components back into juno-base.dtsi to avoid duplication]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
> 3 files changed, 120 insertions(+)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> new file mode 100644
> index 000000000000..89fcef366ff9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> @@ -0,0 +1,102 @@
> + csys1_funnel at 20130000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20130000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + csys1_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&etf1_in_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + csys1_funnel_in_port0: endpoint {
> + slave-mode;
> + };
> + };
> +
> + };
> + };
> +
> + etf1 at 20140000 {
The concept behind device-tree is that you name the nodes based on the
type of device they are. "i2c", "ethernet", etc. Not "eth0", "i2c3",
and so on.
So, this should probably be something else than "etf1", and the
etf->etf0 rename you did somewhere else shouldn't be made either.
csys1_funnel should probably/maybe be named something more generic as well.
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x20140000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* input port */
> + port at 0 {
> + reg = <0>;
> + etf1_in_port: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&csys1_funnel_out_port>;
> + };
> + };
> +
> + /* output port */
> + port at 1 {
> + reg = <0>;
> + etf1_out_port: endpoint {
> + remote-endpoint =
> + <&csys2_funnel_in_port1>;
> + };
> + };
> + };
> + };
> +
> + csys2_funnel at 20150000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x20150000 0 0x1000>;
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* output port */
> + port at 0 {
> + reg = <0>;
> + csys2_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&replicator_in_port0>;
> + };
> + };
> +
> + /* input ports */
> + port at 1 {
> + reg = <0>;
> + csys2_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf0_out_port>;
> + };
> + };
> +
> + port at 2 {
> + reg = <1>;
> + csys2_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf1_out_port>;
> + };
> + };
> +
> + };
> + };
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index eec37feee8fc..d4b85d9d343e 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -178,6 +178,7 @@
> };
>
> #include "juno-base.dtsi"
> + #include "juno-cs-r1r2.dtsi"
Please don't nest dtsi inside a structure like this. We normally let
them stand by themselves at the top of the file instead.
(yes, please fix for juno-base too).
-Olof
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.11 #1
From: Olof Johansson @ 2017-01-17 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e36f6aca-120c-b2a5-52da-06e12e5cfb9f@st.com>
On Mon, Jan 16, 2017 at 04:49:29PM +0100, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 DT updates for v4.11:
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-dt-for-v4.11-1
>
> for you to fetch changes up to d99c66406a846748e26989759caa7e966c1804dd:
>
> ARM: dts: stm32: enable RTC on stm32429i-eval (2017-01-16 14:38:14 +0100)
>
> ----------------------------------------------------------------
> STM32 DT updates for v4.11, round 1.
>
> Highlights:
> ----------
>
> - ADD RTC support on STM32F429 MCU
> - Enable RTC on STM32F469and STM32F429 boards
> - ADD ADC support on STM32F429 MCU
> - Enable ADC on STM32F429 Eval board
> - Add I2S external clock
> - Fix memory size for STM32F429 Disco
>
> Note:
> -----
> First patch "clk: stm32f4: Update DT bindings documentation")
> has already been merged in clock tree.
Ugh. That patch doesn't just update documentation. It also updates the
dt-include file.
So, if it's already been merged into the clock tree, then we can't merge
a separate copy here.
By now, easiest is to hold off making use of it until it's on a shared
branch, i.e. next release. Use the numerical values until then.
> ----------------------------------------------------------------
> Amelie Delaunay (5):
> ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
> ARM: dts: stm32: Add RTC support for STM32F429 MCU
> ARM: dts: stm32: enable RTC on stm32f429-disco
> ARM: dts: stm32: enable RTC on stm32f469-disco
> ARM: dts: stm32: enable RTC on stm32429i-eval
>
> Bruno Herrera (1):
> ARM: dts: stm32: Fix memory size from 8MB to 16MB on stm32f469-disco
> board
>
> Bruno Meirelles Herrera (1):
> ARM: dts: stm32: Add missing USART3 pin config to stm32f469-disco
> board
>
> Fabrice GASNIER (2):
> ARM: dts: stm32: Add ADC support to stm32f429
> ARM: dts: stm32: enable ADC on stm32f429i-eval board
>
> Gabriel Fernandez (3):
> clk: stm32f4: Update DT bindings documentation
> ARM: dts: stm32: Add external I2S clock on stm32f429 MCU
> ARM: dts: stm32: Include auxiliary stm32fx clock definition
How did you generate this pull request? You didn't include a diffstat with it,
which is useful for us to make sure that what we merged is what you expected us
to merge.
Not merging, please revisit based on the above.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.11 (#1)
From: Olof Johansson @ 2017-01-17 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3ye7ul7.fsf@free-electrons.com>
On Fri, Jan 13, 2017 at 06:12:04PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt64 for mvebu for v4.11.
>
> Gregory
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.11-1
>
> for you to fetch changes up to 58a748f7dc29d8a7bb74c6cbba6a82425dbba5cc:
>
> ARM64: dts: marvell: Correct license text (2017-01-03 16:24:34 +0100)
>
> ----------------------------------------------------------------
> mvebu dt64 for 4.11 (part 1)
>
> - Correct license text which was mangled when switching to dual license
> - Add SPI and I2C nodes on Armada 3700(driver support had been already
> merged)
> - Add support for the ethernet switch on the EspressoBin board (driver
> support not yet merged)
>
> ----------------------------------------------------------------
> Alexandre Belloni (1):
> ARM64: dts: marvell: Correct license text
>
> Romain Perier (4):
> arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
> arm64: dts: marvell: Add definition of SPI controller for Armada 3700
> arm64: dts: marvell: Enable spi0 on the board Armada-3720-db
> arm64: dts: marvell: Add I2C definitions for the Armada 3700
>
> arch/arm64/boot/dts/marvell/armada-371x.dtsi | 10 +--
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 44 +++++++++++--
> .../boot/dts/marvell/armada-3720-espressobin.dts | 76 ++++++++++++++++++++--
> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 10 +--
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 39 +++++++++--
> 5 files changed, 154 insertions(+), 25 deletions(-)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.11 (#1)
From: Olof Johansson @ 2017-01-17 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ziiu7ulo.fsf@free-electrons.com>
On Fri, Jan 13, 2017 at 06:11:47PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt for mvebu for v4.11.
>
> Gregory
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.11-1
>
> for you to fetch changes up to 7b7db5ab33d2292d9b037cda0c41a795b094d940:
>
> ARM: dts: turris-omnia: add support for ethernet switch (2017-01-05 13:59:18 +0100)
>
> ----------------------------------------------------------------
> mvebu dt for 4.11 (part 1)
>
> - Add support for the ethernet switch on the Turris Omnia board
> - Clean up and improvement for ClearFog boards
> - Correct license text which was mangled when switching to dual license
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: defconfig64 for v4.11 (#1)
From: Olof Johansson @ 2017-01-17 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871sw6996n.fsf@free-electrons.com>
On Fri, Jan 13, 2017 at 06:11:28PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for defconfig64 for mvebu for v4.11.
>
> Gregory
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig64-4.11-1
>
> for you to fetch changes up to 299d2f0238ec75bd13cc8c69a4cd6dbb9e7837be:
>
> arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K (2017-01-03 16:38:51 +0100)
>
> ----------------------------------------------------------------
> mvebu defconfig64 for 4.11 (part 1)
>
> Update arm64 defconfig by adding XORv2 for Marvell Armada 7K/8K
>
> ----------------------------------------------------------------
> Thomas Petazzoni (1):
> arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/4] ARM: defconfig: exynos: Defconfig for v4.11
From: Olof Johansson @ 2017-01-17 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152030.13586-4-krzk@kernel.org>
On Fri, Jan 13, 2017 at 05:20:30PM +0200, Krzysztof Kozlowski wrote:
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.11
>
> for you to fetch changes up to 74b0ee7579f279dae053053008d29f10f3890c07:
>
> ARM: exynos_defconfig: Enable IP multicast (2016-12-29 16:04:57 +0200)
>
> ----------------------------------------------------------------
> Samsung defconfig update for v4.11:
> 1. Cleanup from old MACHs in s5pv210.
> 2. Enable IP_MULTICAST for libnss-mdns.
>
> ----------------------------------------------------------------
> Krzysztof Kozlowski (1):
> ARM: s5pv210_defconfig: Remove old MACHs
>
> Robie Basak (1):
> ARM: exynos_defconfig: Enable IP multicast
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/4] arm64: dts: exynos: DT for v4.11
From: Olof Johansson @ 2017-01-17 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113152030.13586-3-krzk@kernel.org>
On Fri, Jan 13, 2017 at 05:20:29PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Important:
> 1. Unlike others, this is rebased on v4.10-rc2 because v4.10-rc1 was not
> building on arm64.
> 2. This contains pinctrl change (in header), acked by Linus Walleij.
> Although I kept it on separate branch and merged here, but I did not
> prepare a separate pull request for this one pinctrl change - it is
> just one patch. Anyway it sits on separate branch so this is still
> possible if you need it.
>
> Best regards,
> Krzysztof
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
>
> The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
>
> Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.11
>
> for you to fetch changes up to e4e381133241a27d732e78be09973b89a193eaf7:
>
> arm64: dts: exynos: Enable HDMI/TV path on Exynos5433-TM2 (2017-01-11 18:20:28 +0200)
>
> ----------------------------------------------------------------
> Samsung DeviceTree ARM64 update for v4.11:
> 1. Add bus frequency and voltage scalling on Exynos5433 TM2 device (along with
> necessary bus nodes and Platform Performance Monitoring Unit on Exynos5433).
> 2. Use macros for pinctrl settings on Exynos5433.
> This contains necessary header with bindings.
> 3. Minor cleanups in Exynos5433 DTSI and boards using it.
> 4. Create common DTSI betweem Exynos5433 TM2E and TM2E.
> 5. Add HDMI/TV to Exynos5433 TM2.
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Jacky Bai @ 2017-01-17 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda1a4+yOrzBnKs6J84PS0StwQ68gHxDub_u7i5ofU9s7w@mail.gmail.com>
> Subject: Re: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc
> for imx6sll
>
> On Thu, Jan 12, 2017 at 3:57 AM, Jacky Bai <ping.bai@nxp.com> wrote:
>
> > Another thing is that we can use a pins-tool program developed by NXP
> > to generate the pinctrl configuration code that can be used directly
> > in dts. This tiny program can avoid pin function conflict. As on i.MX,
> > there are so may pins, each pin can be used for up 8 function.
> > Configuring the pins is a time-consuming work. This tools is very useful for
> customer to generate the dts code.
>
> I understand, but every silicon vendor has such a tool, all are different,
> proprietary and unfriendly to programmers and open source developers, who
> need to understand how the hardware is working without magic tools and
> secret data sheets to fix bugs.
>
> For the people working with maintaining the code it is paramount that DTS files
> are self-descriptive.
>
OK. Thanks for your comments. Adding generic-pinconf in imx pinctrl needs some time
to finish and the legacy method still need be here even if generic-pinconf is added.
Do you plan to pick this legacy binding patch for now?
> Yours,
> Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox