* [PATCH 3/9] pinctrl: samsung: Remove dead code
From: Krzysztof Kozlowski @ 2016-12-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482495889-6201-4-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 23, 2016 at 01:24:43PM +0100, Marek Szyprowski wrote:
> 'enable' parameter has been removed a while ago, so all code for handling
> it can be simply removed.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/pinctrl/samsung/pinctrl-samsung.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Heinrich Schuchardt @ 2016-12-24 14:00 UTC (permalink / raw)
To: linux-arm-kernel
When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
translation fault below.
The following mail thread relates this kind of problem to TLB (translation
lookaside buffer) broadcasting.
https://lkml.org/lkml/2014/4/15/207
[ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
[ 3163.017287] pgd = ffff80007bf86000
[ 3163.020589] [00000160] *pgd=000000007a8a3003
[ 3163.024733] , *pud=000000007be9c003
[ 3163.028095] , *pmd=0000000000000000
[ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
[ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
[ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
[ 3163.051563] PC is at 0x160
[ 3163.054231] LR is at 0xffff9a9fbc98
[ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
[ 3163.065022] sp : 0000ffffd7180130
[ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
[ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
[ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
[ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
[ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
[ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
[ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
[ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
[ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
[ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
[ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
[ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
[ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
[ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
[ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH] efi/libstub: arm*: Pass latest memory map to the kernel
From: Ard Biesheuvel @ 2016-12-24 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482587963-20183-1-git-send-email-ard.biesheuvel@linaro.org>
As reported by James, the current libstub code involving the annotated
memory map only works somewhat correctly by accident, due to the fact
that a pool allocation happens to be reused immediately, retaining its
former contents on most implementations of the UEFI boot services.
Instead of juggling memory maps, which makes the code more complex than
it needs to be, simply put placeholder values into the FDT for the memory
map parameters, and only write the actual values after ExitBootServices()
has been called.
Reported-by: James Morse <james.morse@arm.com>
Fixes: ed9cc156c42f ("efi/libstub: Use efi_exit_boot_services() in FDT")
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/efistub.h | 8 ----
drivers/firmware/efi/libstub/fdt.c | 87 ++++++++++++++++++++++------------
2 files changed, 56 insertions(+), 39 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index ee49cd23ee63..fac67992bede 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -30,14 +30,6 @@ efi_status_t efi_file_close(void *handle);
unsigned long get_dram_base(efi_system_table_t *sys_table_arg);
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver);
-
efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
void *handle,
unsigned long *new_fdt_addr,
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index a6a93116a8f0..921dfa047202 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -16,13 +16,10 @@
#include "efistub.h"
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver)
+static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+ unsigned long orig_fdt_size,
+ void *fdt, int new_fdt_size, char *cmdline_ptr,
+ u64 initrd_addr, u64 initrd_size)
{
int node, num_rsv;
int status;
@@ -101,25 +98,23 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
if (status)
goto fdt_set_fail;
- fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+ fdt_val64 = U64_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
&fdt_val64, sizeof(fdt_val64));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(map_size);
+ fdt_val32 = U32_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
&fdt_val32, sizeof(fdt_val32));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(desc_size);
status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
&fdt_val32, sizeof(fdt_val32));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(desc_ver);
status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
&fdt_val32, sizeof(fdt_val32));
if (status)
@@ -148,6 +143,43 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
return EFI_LOAD_ERROR;
}
+static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)
+{
+ int node = fdt_path_offset(fdt, "/chosen");
+ u64 fdt_val64;
+ u32 fdt_val32;
+ int err;
+
+ if (node < 0)
+ return EFI_LOAD_ERROR;
+
+ fdt_val64 = cpu_to_fdt64((unsigned long)*map->map);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-start",
+ &fdt_val64, sizeof(fdt_val64));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->map_size);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-size",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->desc_size);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-desc-size",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->desc_ver);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-desc-ver",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ return EFI_SUCCESS;
+}
+
#ifndef EFI_FDT_ALIGN
#define EFI_FDT_ALIGN EFI_PAGE_SIZE
#endif
@@ -243,20 +275,10 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
goto fail;
}
- /*
- * Now that we have done our final memory allocation (and free)
- * we can get the memory map key needed for
- * exit_boot_services().
- */
- status = efi_get_memory_map(sys_table, &map);
- if (status != EFI_SUCCESS)
- goto fail_free_new_fdt;
-
status = update_fdt(sys_table,
(void *)fdt_addr, fdt_size,
(void *)*new_fdt_addr, new_fdt_size,
- cmdline_ptr, initrd_addr, initrd_size,
- memory_map, map_size, desc_size, desc_ver);
+ cmdline_ptr, initrd_addr, initrd_size);
/* Succeeding the first time is the expected case. */
if (status == EFI_SUCCESS)
@@ -266,20 +288,16 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
/*
* We need to allocate more space for the new
* device tree, so free existing buffer that is
- * too small. Also free memory map, as we will need
- * to get new one that reflects the free/alloc we do
- * on the device tree buffer.
+ * too small.
*/
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
- sys_table->boottime->free_pool(memory_map);
new_fdt_size += EFI_PAGE_SIZE;
} else {
pr_efi_err(sys_table, "Unable to construct new device tree.\n");
- goto fail_free_mmap;
+ goto fail_free_new_fdt;
}
}
- sys_table->boottime->free_pool(memory_map);
priv.runtime_map = runtime_map;
priv.runtime_entry_count = &runtime_entry_count;
status = efi_exit_boot_services(sys_table, handle, &map, &priv,
@@ -288,6 +306,16 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
if (status == EFI_SUCCESS) {
efi_set_virtual_address_map_t *svam;
+ status = update_fdt_memmap((void *)*new_fdt_addr, &map);
+ if (status != EFI_SUCCESS) {
+ /*
+ * The kernel won't get far without the memory map, but
+ * may still be able to print something meaningful so
+ * return success here.
+ */
+ return EFI_SUCCESS;
+ }
+
/* Install the new virtual address map */
svam = sys_table->runtime->set_virtual_address_map;
status = svam(runtime_entry_count * desc_size, desc_size,
@@ -319,9 +347,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
pr_efi_err(sys_table, "Exit boot services failed.\n");
-fail_free_mmap:
- sys_table->boottime->free_pool(memory_map);
-
fail_free_new_fdt:
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
--
2.7.4
^ permalink raw reply related
* [GIT PULL] efi: urgent fix for v4.10 with cc to stable
From: Ard Biesheuvel @ 2016-12-24 13:59 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 69973b830859bc6529a7a0468ba0d80ee5117826:
Linux 4.9 (2016-12-11 11:17:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
for you to fetch changes up to bcd5812b8bfb24783f09b53659fae54d1b02d0be:
efi/libstub: arm*: Pass latest memory map to the kernel (2016-12-24 13:19:28 +0000)
----------------------------------------------------------------
* One patch, addressing a major issue in a bugfix that went into stable,
where on ARM/arm64 systems, the EFI memory map address passed to the
kernel via the FDT may be different from the address of the buffer
containing the annotated EFI memory map.
----------------------------------------------------------------
Ard Biesheuvel (1):
efi/libstub: arm*: Pass latest memory map to the kernel
drivers/firmware/efi/libstub/efistub.h | 8 ----
drivers/firmware/efi/libstub/fdt.c | 87 ++++++++++++++++++++++------------
2 files changed, 56 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Fabio Estevam @ 2016-12-24 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R4HarEBjCiGgG2AwnWqdLBGpLKPXAokEbZEdwXRUUa5Fw@mail.gmail.com>
On Thu, Dec 22, 2016 at 6:16 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> So, have we reached a conclusion that a solution based on the code
> below is good enough for now? Further device tree development would
> make it possible to support other triggers on i.MX31 boards. And any
> board that already has dt support can override TRIGGER_HIGH since
> irqd_get_trigger_type() will return something else than IRQ_TYPE_NONE.
I would say that you could send a v2 with the only difference being
the commit log explaining which was the commit that caused the
problem, add a Fixes tag and Cc: stable.
Thanks
^ permalink raw reply
* [PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Fabio Estevam @ 2016-12-24 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211010648.6591-1-vz@mleia.com>
On Sat, Dec 10, 2016 at 11:06 PM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> static const struct of_device_id imx2_wdt_dt_ids[] = {
> - { .compatible = "fsl,imx21-wdt", },
> + { .compatible = "fsl,imx21-wdt", .data = IMX2_WDT_NO_WMCR },
> + { .compatible = "fsl,imx25-wdt", },
> + { .compatible = "fsl,imx27-wdt", .data = IMX2_WDT_NO_WMCR },
> + { .compatible = "fsl,imx31-wdt", .data = IMX2_WDT_NO_WMCR },
> + { .compatible = "fsl,imx35-wdt", },
> + { .compatible = "fsl,imx50-wdt", },
> + { .compatible = "fsl,imx51-wdt", },
> + { .compatible = "fsl,imx53-wdt", },
> + { .compatible = "fsl,imx6q-wdt", },
> + { .compatible = "fsl,imx6sl-wdt", },
> + { .compatible = "fsl,imx6sx-wdt", },
> + { .compatible = "fsl,imx6ul-wdt", },
> + { .compatible = "fsl,imx7d-wdt", },
> + { .compatible = "fsl,vf610-wdt", },
> { /* sentinel */ }
I understand this compatible list is not very nice, but in order to
keep old dtb's working I don't see a better solution, so:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] ARM: dts: imx: remove obsoleted property fsl, spi-num-chipselects
From: Fabio Estevam @ 2016-12-24 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161224054354.28289-1-vz@mleia.com>
On Sat, Dec 24, 2016 at 3:43 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> Since commit b36581df7e78 ("spi: imx: Using existing properties for
> chipselects") the device tree property 'fsl,spi-num-chipselects' is
> unused and it is already marked as obsolete in device tree binding
> documentation. Remove the property from the existing DTS files to
> avoid its reoccurence on copying.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [RFC] arm64/acpi: make ACPI boot preference configurable
From: Ard Biesheuvel @ 2016-12-24 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7eba0601099f75f19021c4259eca75ada06f4511.1482341997.git.jtoppins@redhat.com>
On 21 December 2016 at 17:54, Jonathan Toppins <jtoppins@redhat.com> wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>
This has been discussed at length in the past, and has been rejected
by the arm64 maintainers. (I was the one who proposed the exact same
thing the last time around)
> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is empty. If the dtb passed to the kernel is non-empty then device-tree
> will be chosen as the boot method of choice even if it is not correct.
It should not be up to the kernel to reason about whether the DT is
correct or not. If the firmware passes both, they should both be
correct. I fully understand that there are reasons why ACPI may be
preferable if both are correct, but correctness is not a valid
argument in this discussion.
> To prevent this situation where a system is only intended to be booted
> via ACPI a user can set this kernel configuration so it ignores
> device-tree settings unless ACPI table checks fail.
>
If a system is only intended to be booted via ACPI, it should not
expose a DT via the UEFI configuration table to begin with. Since this
is only an issue in development context (a production system that can
expose either should be configurable via the UEFI setup menu), you
should be able to add a SysPrep entry that clears the UEFI config
table using a separate UEFI app.
I think we need an update to the SBBR to stipulate that DT can be
disabled in the firmware if it is supported in addition to ACPI. In
the mean time, what we could do is update the stub so it appends to
/chosen/bootargs, rather than replace it, allowing the firmware to
pass 'acpi=on' if it absolutely needs to
> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
> ---
> arch/arm64/Kconfig | 13 +++++++++++++
> arch/arm64/kernel/acpi.c | 2 +-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 111742126897..e432e84245b9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -954,6 +954,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
> protocol even if the corresponding data is present in the ACPI
> MADT table.
>
> +config ARM64_PREFER_ACPI
> + bool "Prefer usage of ACPI boot tables over device-tree"
> + depends on ACPI
> + help
> + Normally device-tree is preferred over ACPI on arm64 unless
> + explicitly preferred via kernel command line, something like: acpi=on
> + This configuration changes this default behaviour by pretending
> + the user set acpi=on on the command line. This configuration still
> + allows the user to turn acpi table parsing off via acpi=off. If
> + for some reason the table checks fail the system will still fall
> + back to using device-tree unless the user explicitly sets acpi=force
> + on the command line.
> +
> config CMDLINE
> string "Default kernel command string"
> default ""
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 252a6d9c1da5..b5dfa5752ff7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -43,7 +43,7 @@ int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
> EXPORT_SYMBOL(acpi_pci_disabled);
>
> static bool param_acpi_off __initdata;
> -static bool param_acpi_on __initdata;
> +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
> static bool param_acpi_force __initdata;
>
> static int __init parse_acpi(char *arg)
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH] dmaengine: pl330: Fix runtime PM support for terminated transfers
From: Krzysztof Kozlowski @ 2016-12-24 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b2f2e51-3fac-02d7-5827-b08b97c894c0@samsung.com>
On Fri, Dec 23, 2016 at 10:52:28AM +0100, Marek Szyprowski wrote:
> Hi Krzysztof,
>
>
> On 2016-12-23 03:33, Krzysztof Kozlowski wrote:
> >On Fri, Dec 16, 2016 at 11:39:11AM +0100, Marek Szyprowski wrote:
> >>PL330 DMA engine driver is leaking a runtime reference after any terminated
> >>DMA transactions. This patch fixes this issue by tracking runtime PM state
> >>of the device and making additional call to pm_runtime_put() in terminate_all
> >>callback if needed.
> >>
> >>Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> >>Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>---
> >> drivers/dma/pl330.c | 11 +++++++++++
> >> 1 file changed, 11 insertions(+)
> >>
> >>diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> >>index 030fe05ed43b..9f3dbc8c63d2 100644
> >>--- a/drivers/dma/pl330.c
> >>+++ b/drivers/dma/pl330.c
> >>@@ -448,6 +448,9 @@ struct dma_pl330_chan {
> >> /* for cyclic capability */
> >> bool cyclic;
> >>+
> >>+ /* for runtime pm tracking */
> >>+ bool active;
> >> };
> >> struct pl330_dmac {
> >>@@ -2031,6 +2034,7 @@ static void pl330_tasklet(unsigned long data)
> >> _stop(pch->thread);
> >> spin_unlock(&pch->thread->dmac->lock);
> >> power_down = true;
> >>+ pch->active = false;
> >> } else {
> >> /* Make sure the PL330 Channel thread is active */
> >> spin_lock(&pch->thread->dmac->lock);
> >>@@ -2050,6 +2054,7 @@ static void pl330_tasklet(unsigned long data)
> >> desc->status = PREP;
> >> list_move_tail(&desc->node, &pch->work_list);
> >> if (power_down) {
> >>+ pch->active = true;
> >It's been a while since I was playign with the driver so I don't
> >remember everything... but I can't get the logic behind this.
> >
> >The device is marked as inactive and scheduled to power down. But you
> >mark chanel as active.
>
> Please look 3 lines further. The channel is started again (because this
> is cyclic request), so setting active to true is justified. Even power_down
> is then set to false.
Ahhh, damn the missing context. I looked at full source and it makes
sense now.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/9] Runtime PM for Exynos pin controller driver
From: Anand Moon @ 2016-12-24 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482495889-6201-1-git-send-email-m.szyprowski@samsung.com>
Hi Marek
On 23 December 2016 at 17:54, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Hello,
>
> This patchset is a next step to add support for audio power domain on
> Exynos5 SoCs.
>
> Audio power domain on Exynos5 SoCs contains following hardware modules:
> 1. clock controller
> 2. pin controller
> 3. PL330 DMA controller
> 4. I2S audio controller
>
> Till now it was assumed that pin controller is located in the "always on"
> power domain and lacked runtime power management. This patch finally
> removes such assumption and adds runtime pm support and awareness to this
> driver. To achieve this, some changes in the Exynos platform support code
> were needed, like moving pad retention control to the pin controller driver.
> Some cleanup to the pin controller driver has been also done while changing
> the code. This new feature requires some additional information in the
> device tree, what is handled by patches 1,2 and 9.
>
> Please note that patches are ordered in such a way that the changes can be
> bisected, so the properties are added to dts before the code requiring them.
>
> The other patches related to enabling full support for audio power domain
> can be found here:
> 1. PL330 ADMA controller non-irqsafe runtime PM:
> https://www.spinics.net/lists/arm-kernel/msg550008.html
> 2. Runtime PM for clock controllers (Exynos Audio subsystem will be added
> in v4 soon): https://www.spinics.net/lists/arm-kernel/msg538122.html
>
> Patches are based on linux-next from 2016.12.22.
>
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
>
>
> Patch summary:
>
> Marek Szyprowski (9):
> ARM: dts: exynos: Add PMU syscon to pinctrl nodes
> ARM: dts: exynos: Add pinctrl sleep state for 542x i2s module
> pinctrl: samsung: Remove dead code
> pinctrl: samsung: Use generic of_device_get_match_data helper
> pinctrl: samsung: Move retention control from mach-exynos to the
> pinctrl driver
> pinctrl: samsung: Replace syscore ops with standard platform device
> pm_ops
> pinctrl: samsung: Add property to mark pad state as suitable for power
> down
> pinctrl: samsung: Add runtime PM support
> ARM: dts: exynos: Add audio power domain support to Exynos542x SoCs
>
> .../bindings/pinctrl/samsung-pinctrl.txt | 12 ++
> arch/arm/boot/dts/exynos3250.dtsi | 2 +
> arch/arm/boot/dts/exynos4210.dtsi | 3 +
> arch/arm/boot/dts/exynos4x12.dtsi | 3 +
> arch/arm/boot/dts/exynos5250.dtsi | 4 +
> arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 11 ++
> arch/arm/boot/dts/exynos5420.dtsi | 18 ++-
> arch/arm/mach-exynos/suspend.c | 64 ---------
> drivers/pinctrl/samsung/pinctrl-exynos.c | 148 +++++++++++++++++++++
> drivers/pinctrl/samsung/pinctrl-samsung.c | 126 ++++++++----------
> drivers/pinctrl/samsung/pinctrl-samsung.h | 15 +++
> 11 files changed, 271 insertions(+), 135 deletions(-)
>
Is their core configuration missing to enable audio through HDMI on
Odroid Boards.
I could not get the sound working on Odroid XU4.
.
-Best Regards
Anand Moon
^ permalink raw reply
* [PATCH] PCI: exynos: refactor exynos pcie driver
From: Krzysztof Kozlowski @ 2016-12-24 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482490587-13611-1-git-send-email-pankaj.dubey@samsung.com>
On Fri, Dec 23, 2016 at 04:26:27PM +0530, Pankaj Dubey wrote:
> From: Niyas Ahmed S T <niyas.ahmed@samsung.com>
>
> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
> This patch does refactoring of Exynos PCIe driver to extend support
> for other Exynos SoC.
>
> Following are the main changes done via this patch:
> 1) It adds separate structs for memory, clock resources.
> 2) It add exynos_pcie_ops struct which will allow us to support the
> differences in resources in different Exynos SoC.
>
> No functional change intended.
>
> Signed-off-by: Niyas Ahmed S T <niyas.ahmed@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> This patch set is prepared on top of Krzysztof's for-next and
> PCIe driver cleanup patch [1] by Jaehoon Chung.
>
> [1]: https://lkml.org/lkml/2016/12/19/44
>
>
> drivers/pci/host/pci-exynos.c | 346 ++++++++++++++++++++++++++----------------
> 1 file changed, 217 insertions(+), 129 deletions(-)
(...)
> @@ -573,14 +660,15 @@ static int __exit exynos_pcie_remove(struct platform_device *pdev)
> {
> struct exynos_pcie *exynos_pcie = platform_get_drvdata(pdev);
>
> - clk_disable_unprepare(exynos_pcie->bus_clk);
> - clk_disable_unprepare(exynos_pcie->clk);
> + if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> + exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
>
> return 0;
> }
>
> static const struct of_device_id exynos_pcie_of_match[] = {
> - { .compatible = "samsung,exynos5440-pcie", },
> + { .compatible = "samsung,exynos5440-pcie",
> + .data = &exynos5440_pcie_ops },
A nit, please put brackets in new lines, so:
{
...
},
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
I didn't do a thorough review, though.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
From: Krzysztof Kozlowski @ 2016-12-24 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e12d7cc-2dc1-2708-cabe-987d650ba3c5@samsung.com>
On Fri, Dec 23, 2016 at 11:38:19AM +0100, Marek Szyprowski wrote:
(...)
> >>The main assumption for it is an
> >>observation that there can be only one slave device using each DMA channel.
> >Wait, observation, real requirement or assumption?
> >
> >Later in the code I see adding such requirement.
>
> Well, observation which result in assumption. I cannot imagine a hardware
> which
> shares slave DMA channel between devices. Also none of the existing platform
> does it.
OK for me.
>
> >>Using recently introduced device dependencies (links) infrastructure one can
> >>ensure proper runtime PM state of PL330 DMA controller. In this approach in
> >>pl330_alloc_chan_resources() function a new dependency is being created
> >>between PL330 DMA controller device (as supplier) and given slave device
> >>(as consumer). This way PL330 DMA controller device runtime active counter
> >>is increased when the slave device is resumed and decreased the same time
> >>when given slave device is put to suspend. This way it has been ensured to
> >>keep PL330 DMA controller runtime active if there is an active used of any
> >>of its DMA channels. Slave device pointer is initially stored in per-channel
> >>data in of_dma_xlate callback. This is similar to what has been already
> >>implemented in Exynos IOMMU driver in commit 2f5f44f205cc958b
> >>("iommu/exynos: Use device dependency links to control runtime pm").
> >Sounds convincing... Interesting approach!
> >
> >My doubts are:
> >1. What with more then one slave device? (assumption?)
>
> See above, there are no such cases.
>
> >2. If slave device does not implement runtime PM, then pl330 will be
> > active all the time?
>
> Right, but the goal is to have runtime pm added to all devices in the
> system.
>
> >3. If slave device implements runtime PM in a way that it's enabled in
> > probe and released in remove, then pl330 will be active all the time?
>
> Then it will force power domain to be turned on all the time and even
> optional
> fine-grained irq-safe runtiem pm in pl330 driver won't help much to reduce
> power
> consumption. I assume that the real goal with runtime pm is to let
> respective
> power domains to be turned off, what gives the best results in terms of
> power
> saving.
Indeed existing runtime PM for pl330 was not bringing much benefits of
its own - only clocks were enabled/disabled.
Thanks for clarifications.
(...)
> >>@@ -2113,14 +2089,63 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> >> if (chan_id >= pl330->num_peripherals)
> >> return NULL;
> >>+ if (!pl330->peripherals[chan_id].slave)
> >>+ pl330->peripherals[chan_id].slave = slave;
> >>+ else if (pl330->peripherals[chan_id].slave != slave) {
> >>+ dev_err(pl330->ddma.dev,
> >>+ "Can't use same channel with multiple slave devices!\n");
> >>+ return NULL;
> >>+ }
> >This could be nicely split into separate patch.
>
> Okay, if you want, I can move this change to separate patch.
Yes, please do it. Beside that patch looked fine to me.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-24 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0g4AoU-g4UWZFxLgQ_yfTC7KSBnZ_Ve945d+i58e=GuDQ@mail.gmail.com>
Hi Rafael,
Thank you for your comments, when I was demoing your suggestion,
I got a little bit confusions, please see my comments below.
On 2016/12/22 20:57, Rafael J. Wysocki wrote:
> On Thu, Dec 22, 2016 at 6:35 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> With the platform msi domain created, we can set up the msi domain
>> for a platform device when it's probed.
>>
>> In order to do that, we need to get the domain that the platform
>> device connecting to, so the iort_get_platform_device_domain() is
>> introduced to retrieve the domain from iort.
>>
>> After the domain is retrieved, we need a proper way to set the
>> domain to paltform device, as some platform devices such as an
>> irqchip needs the msi irqdomain to be the interrupt parent domain,
>> we need to get irqdomain before platform device is probed but after
>> the platform device is allocated, so introduce a callback (pre_add_cb)
>> in pdevinfo to prepare firmware related information which is needed
>> for device probe, then set the msi domain in that callback.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Greg KH <gregkh@linuxfoundation.org>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> ---
>> drivers/acpi/acpi_platform.c | 11 +++++++++++
>> drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++
>> drivers/base/platform.c | 3 +++
>> include/linux/acpi_iort.h | 3 +++
>> include/linux/platform_device.h | 3 +++
>> 5 files changed, 63 insertions(+)
>>
>> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
>> index b4c1a6a..5d8d61b4 100644
>> --- a/drivers/acpi/acpi_platform.c
>> +++ b/drivers/acpi/acpi_platform.c
>> @@ -12,6 +12,7 @@
>> */
>>
>> #include <linux/acpi.h>
>> +#include <linux/acpi_iort.h>
>> #include <linux/device.h>
>> #include <linux/err.h>
>> #include <linux/kernel.h>
>> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
>> }
>>
>> /**
>> + * acpi_platform_pre_add_cb - callback before platform device is added, to
>> + * prepare firmware related information which is needed for device probe
>> + */
>> +static void acpi_platform_pre_add_cb(struct device *dev)
>> +{
>> + acpi_configure_pmsi_domain(dev);
>> +}
>> +
>> +/**
>> * acpi_create_platform_device - Create platform device for ACPI device node
>> * @adev: ACPI device node to create a platform device for.
>> * @properties: Optional collection of build-in properties.
>> @@ -109,6 +119,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
>> pdevinfo.num_res = count;
>> pdevinfo.fwnode = acpi_fwnode_handle(adev);
>> pdevinfo.properties = properties;
>> + pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
> Why don't you point that directly to acpi_configure_pmsi_domain()? It
> doesn't look like the wrapper is necessary at all.
I was thinking that we can add something more in the future
if we need to extend the function of the callback, I can just
use acpi_configure_pmsi_domain() here.
>
> And I'm not sure why the new callback is necessary ->
I was demoing your suggestion but...
>
>> if (acpi_dma_supported(adev))
>> pdevinfo.dma_mask = DMA_BIT_MASK(32);
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bc68d93..6b72fcb 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
>> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
>> }
>>
>> +/**
>> + * iort_get_platform_device_domain() - Find MSI domain related to a
>> + * platform device
>> + * @dev: the dev pointer associated with the platform device
>> + *
>> + * Returns: the MSI domain for this device, NULL otherwise
>> + */
>> +static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
>> +{
>> + struct acpi_iort_node *node, *msi_parent;
>> + struct fwnode_handle *iort_fwnode;
>> + struct acpi_iort_its_group *its;
>> +
>> + /* find its associated iort node */
>> + node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
>> + iort_match_node_callback, dev);
>> + if (!node)
>> + return NULL;
>> +
>> + /* then find its msi parent node */
>> + msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
>> + if (!msi_parent)
>> + return NULL;
>> +
>> + /* Move to ITS specific data */
>> + its = (struct acpi_iort_its_group *)msi_parent->node_data;
>> +
>> + iort_fwnode = iort_find_domain_token(its->identifiers[0]);
>> + if (!iort_fwnode)
>> + return NULL;
>> +
>> + return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
>> +}
>> +
>> +void acpi_configure_pmsi_domain(struct device *dev)
>> +{
>> + struct irq_domain *msi_domain;
>> +
>> + msi_domain = iort_get_platform_device_domain(dev);
>> + if (msi_domain)
>> + dev_set_msi_domain(dev, msi_domain);
>> +}
>> +
>> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>> {
>> u32 *rid = data;
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index c4af003..3e68f31 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -537,6 +537,9 @@ struct platform_device *platform_device_register_full(
>> goto err;
>> }
>>
>> + if (pdevinfo->pre_add_cb)
>> + pdevinfo->pre_add_cb(&pdev->dev);
>> +
> -> because it looks like this might be done in acpi_platform_notify()
> for platform devices.
It works and I just simply add the code below:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index f8d6564..e0cd649 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/rwsem.h>
#include <linux/acpi.h>
+#include <linux/acpi_iort.h>
#include <linux/dma-mapping.h>
#include "internal.h"
@@ -315,6 +316,8 @@ static int acpi_platform_notify(struct device *dev)
if (!adev)
goto out;
+ acpi_configure_pmsi_domain(dev);
+
if (type && type->setup)
type->setup(dev);
else if (adev->handler && adev->handler->bind)
Do you suggesting to configure the msi domain in this way?
or add the function in the type->setup() callback (which needs
to introduce a new acpi bus type)?
Thanks
Hanjun
^ permalink raw reply related
* [PATCH v5 6/6] arm64: arch_timer: acpi: add hisi timer errata data
From: Kefeng Wang @ 2016-12-24 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482476669-15596-7-git-send-email-dingtianhong@huawei.com>
On 2016/12/23 15:04, Ding Tianhong wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Add hisi timer specific erratum fixes.
>
> v3: add hisilicon erratum 161601 for ACPI mode.
>
> v4: update some data structures.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> drivers/clocksource/arm_arch_timer.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 212bfa5..7b15d2a 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1089,10 +1089,28 @@ struct gtdt_arch_timer_fixup {
> void *context;
> };
>
> +#ifdef CONFIG_HISILICON_ERRATUM_161601
> +static void __init erratum_workaround_enable(void *context)
> +{
> + u64 erratum = (u64) context;
> +
> + if (erratum & HISILICON_161601) {
> + timer_unstable_counter_workaround = &arch_timer_hisi_161601;
> + static_branch_enable(&arch_timer_read_ool_enabled);
> + pr_info("Enabling workaround for HISILICON ERRATUM 161601\n");
> + }
Use arch_timer_hisi_161601 for context instead of HISILICON_161601 directly,
we can make erratum_workaround_enable more general.
> +}
> +#endif
> +
> /* note: this needs to be updated according to the doc of OEM ID
> * and TABLE ID for different board.
> */
> struct gtdt_arch_timer_fixup arch_timer_quirks[] __initdata = {
> +#ifdef CONFIG_HISILICON_ERRATUM_161601
> + {"HISI", "hip05", 0, &erratum_workaround_enable, (void *) HISILICON_161601},
> + {"HISI", "hip06", 0, &erratum_workaround_enable, (void *) HISILICON_161601},
> + {"HISI", "hip07", 0, &erratum_workaround_enable, (void *) HISILICON_161601},
> +#endif
> };
>
> void __init arch_timer_acpi_quirks_handler(char *oem_id,
>
^ permalink raw reply
* [PATCH] serial: 8250: use initializer instead of memset to clear local struct
From: Masahiro Yamada @ 2016-12-24 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223072026.GA23895@kroah.com>
Hi Greg,
2016-12-23 16:20 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Fri, Dec 23, 2016 at 12:21:48PM +0900, Masahiro Yamada wrote:
>> Leave the way of zero-out to the compiler's decision; the compiler
>> may know a more optimized way than calling memset().
>
> But no, it doesn't, it will leave "blank" areas in the structure with
> bad data in it, which is why we do memset. See the tree-wide fixups we
> made about a year ago for this very issue. Are you sure none of these
> structures get copied to userspace?
I have to admit no security consideration was in my mind.
If we talk about the particular case of struct uart_8250_port,
this structure is allocated in the stack temporarily,
then serial8250_register_8250_port() copies its members to another
structure one by one. So no "blank" area is exposed to the user-space,
I think.
Having said that, we have no good reason to take a risk for this.
So, please feel free to discard this patch.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v5 3/6] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Kefeng Wang @ 2016-12-24 6:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482476669-15596-4-git-send-email-dingtianhong@huawei.com>
On 2016/12/23 15:04, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> The workaround is enabled if the hisilicon,erratum-161601 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> Fix some description for fsl erratum a008585.
>
> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> v3: Significant rework based on feedback, including fix some alignment problem, make the
> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
> visible, add more accurate annotation and modify a bit of logical format to enable
> arch_timer_read_ool_enabled, remove the kernel commandline parameter
> clocksource.arm_arch_timer.hisilicon-161601.
>
> v5: Theoretically the erratum should not occur more than twice in succession when reading
> the system counter, but it is possible that some interrupts may lead to more than twice
> read errors, triggering the warning, so setting the number of retries to 50 which is far
> beyond the number of iterations the loop has been observed to take.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/include/asm/arch_timer.h | 2 +-
> drivers/clocksource/Kconfig | 9 +++++
> drivers/clocksource/arm_arch_timer.c | 70 +++++++++++++++++++++++++++++++---
> 4 files changed, 76 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 405da11..1c1a95f 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,3 +63,4 @@ stable kernels.
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> | | | | |
> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> +| Hisilicon | Hip0{5,6,7} | #161601 | HISILICON_ERRATUM_161601|
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index f882c7c..ebf4cde 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -29,7 +29,7 @@
>
> #include <clocksource/arm_arch_timer.h>
>
> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> extern struct static_key_false arch_timer_read_ool_enabled;
> #define needs_unstable_timer_counter_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 4866f7a..162d820 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -335,6 +335,15 @@ config FSL_ERRATUM_A008585
> value"). The workaround will only be active if the
> fsl,erratum-a008585 property is found in the timer node.
>
> +config HISILICON_ERRATUM_161601
> + bool "Workaround for Hisilicon Erratum 161601"
> + default y
> + depends on ARM_ARCH_TIMER && ARM64
> + help
> + This option enables a workaround for Hisilicon Erratum
> + 161601. The workaround will be active if the hisilicon,erratum-161601
> + property is found in the timer node.
> +
> config ARM_GLOBAL_TIMER
> bool "Support for the ARM global timer" if COMPILE_TEST
> select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index e7406ad..9a82496 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -95,15 +95,18 @@ static int __init early_evtstrm_cfg(char *buf)
> * Architected system timer support.
> */
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if CONFIG_FSL_ERRATUM_A008585 || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL;
> EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
>
> #define FSL_A008585 0x0001
> +#define HISILICON_161601 0x0002
It looks like the DEFINE is useless?
> +
> +static struct arch_timer_erratum_workaround arch_timer_hisi_161601 = {
> + .erratum = HISILICON_161601,
Just a errata description, eg.
.desc = "HISILICON ERRATUM 161601"
then....
> + .read_cntp_tval_el0 = hisi_161601_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = hisi_161601_read_cntv_tval_el0,
> + .read_cntvct_el0 = hisi_161601_read_cntvct_el0,
> +};
> +#endif /* CONFIG_HISILICON_ERRATUM_161601 */
[..]
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> /*
> * Don't use the vdso fastpath if errata require using
> * the out-of-line counter accessor.
> @@ -909,10 +960,19 @@ static int __init arch_timer_of_init(struct device_node *np)
> #ifdef CONFIG_FSL_ERRATUM_A008585
> if (!timer_unstable_counter_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
> timer_unstable_counter_workaround = &arch_timer_fsl_a008585;
> +#endif
> +
> +#ifdef CONFIG_HISILICON_ERRATUM_161601
> + if (!timer_unstable_counter_workaround && of_property_read_bool(np, "hisilicon,erratum-161601"))
> + timer_unstable_counter_workaround = &arch_timer_hisi_161601;
> +#endif
>
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> if (timer_unstable_counter_workaround) {
> static_branch_enable(&arch_timer_read_ool_enabled);
> - pr_info("Enabling workaround for FSL erratum A-008585\n");
> + pr_info("Enabling workaround for %s\n",
> + timer_unstable_counter_workaround->erratum == FSL_A008585 ?
> + "FSL ERRATUM A-008585" : "HISILICON ERRATUM 161601");
......> pr_info("Enabling workaround for %s\n", timer_unstable_counter_workaround->desc)
> }
> #endif
>
>
^ permalink raw reply
* [PATCH] ARM: dts: imx: remove obsoleted property fsl, spi-num-chipselects
From: Vladimir Zapolskiy @ 2016-12-24 5:43 UTC (permalink / raw)
To: linux-arm-kernel
Since commit b36581df7e78 ("spi: imx: Using existing properties for
chipselects") the device tree property 'fsl,spi-num-chipselects' is
unused and it is already marked as obsolete in device tree binding
documentation. Remove the property from the existing DTS files to
avoid its reoccurence on copying.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/boot/dts/imx1-ads.dts | 1 -
arch/arm/boot/dts/imx27-apf27dev.dts | 2 --
arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts | 1 -
arch/arm/boot/dts/imx27-pdk.dts | 1 -
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi | 1 -
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 1 -
arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi | 1 -
arch/arm/boot/dts/imx50-evk.dts | 1 -
arch/arm/boot/dts/imx51-apf51dev.dts | 2 --
arch/arm/boot/dts/imx51-babbage.dts | 1 -
arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi | 1 -
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 1 -
arch/arm/boot/dts/imx53-smd.dts | 1 -
arch/arm/boot/dts/imx53-tqma53.dtsi | 2 --
arch/arm/boot/dts/imx53-tx53.dtsi | 1 -
arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi | 1 -
arch/arm/boot/dts/imx6dl-aristainetos_4.dts | 1 -
arch/arm/boot/dts/imx6q-ba16.dtsi | 1 -
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 1 -
arch/arm/boot/dts/imx6q-cm-fx6.dts | 1 -
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 1 -
arch/arm/boot/dts/imx6q-evi.dts | 3 ---
arch/arm/boot/dts/imx6q-gw5400-a.dts | 1 -
arch/arm/boot/dts/imx6q-marsboard.dts | 1 -
arch/arm/boot/dts/imx6q-novena.dts | 1 -
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-aristainetos.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 3 ---
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-rex.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-ts4900.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-tx6.dtsi | 1 -
arch/arm/boot/dts/imx6sl-evk.dts | 1 -
arch/arm/boot/dts/imx6sx-nitrogen6sx.dts | 1 -
arch/arm/boot/dts/imx6ul-tx6ul.dtsi | 1 -
arch/arm/boot/dts/imx7d-sdb.dts | 1 -
47 files changed, 57 deletions(-)
diff --git a/arch/arm/boot/dts/imx1-ads.dts b/arch/arm/boot/dts/imx1-ads.dts
index f504986..5ea28ee 100644
--- a/arch/arm/boot/dts/imx1-ads.dts
+++ b/arch/arm/boot/dts/imx1-ads.dts
@@ -38,7 +38,6 @@
&cspi1 {
pinctrl-0 = <&pinctrl_cspi1>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx27-apf27dev.dts b/arch/arm/boot/dts/imx27-apf27dev.dts
index bba3f41..5f84b59 100644
--- a/arch/arm/boot/dts/imx27-apf27dev.dts
+++ b/arch/arm/boot/dts/imx27-apf27dev.dts
@@ -77,7 +77,6 @@
};
&cspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi1 &pinctrl_cspi1_cs>;
@@ -95,7 +94,6 @@
};
&cspi2 {
- fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio4 21 GPIO_ACTIVE_LOW>,
<&gpio4 27 GPIO_ACTIVE_LOW>,
<&gpio2 17 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts b/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
index 27846ff..f565357 100644
--- a/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
+++ b/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
@@ -81,7 +81,6 @@
&cspi1 {
pinctrl-0 = <&pinctrl_cspi1>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx27-pdk.dts b/arch/arm/boot/dts/imx27-pdk.dts
index d0ef496..96f442b 100644
--- a/arch/arm/boot/dts/imx27-pdk.dts
+++ b/arch/arm/boot/dts/imx27-pdk.dts
@@ -37,7 +37,6 @@
&cspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi2>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 21 GPIO_ACTIVE_HIGH>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
index 1b62480..4f3e0f4 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
@@ -23,7 +23,6 @@
};
&cspi1 {
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>,
<&gpio4 27 GPIO_ACTIVE_HIGH>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
index cf09e72..2a9198f 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
@@ -69,7 +69,6 @@
&cspi1 {
pinctrl-0 = <&pinctrl_cspi1>, <&pinctrl_cspi1cs1>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>,
<&gpio4 27 GPIO_ACTIVE_LOW>;
};
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
index b4e955e..82fec93 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
@@ -75,7 +75,6 @@
&cspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi1>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx50-evk.dts b/arch/arm/boot/dts/imx50-evk.dts
index 27d763c..dba2d95 100644
--- a/arch/arm/boot/dts/imx50-evk.dts
+++ b/arch/arm/boot/dts/imx50-evk.dts
@@ -26,7 +26,6 @@
&cspi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio4 11 0>, <&gpio4 13 0>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts b/arch/arm/boot/dts/imx51-apf51dev.dts
index 0f3fe29..a5e6091 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -80,7 +80,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>,
<&gpio4 25 GPIO_ACTIVE_HIGH>;
status = "okay";
@@ -89,7 +88,6 @@
&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 28 GPIO_ACTIVE_LOW>,
<&gpio3 27 GPIO_ACTIVE_LOW>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index f097b4f..873cf24 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -178,7 +178,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>,
<&gpio4 25 GPIO_ACTIVE_LOW>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi b/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi
index 16fc69c..b821066 100644
--- a/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi
+++ b/arch/arm/boot/dts/imx51-digi-connectcore-som.dtsi
@@ -24,7 +24,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
index 7282128..1305b05 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
@@ -114,7 +114,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx53-smd.dts b/arch/arm/boot/dts/imx53-smd.dts
index 9f51900..472f6f0 100644
--- a/arch/arm/boot/dts/imx53-smd.dts
+++ b/arch/arm/boot/dts/imx53-smd.dts
@@ -63,7 +63,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio2 30 0>, <&gpio3 19 0>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 91a6a9f..85972f2 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -55,7 +55,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <4>;
cs-gpios = <&gpio2 30 0>, <&gpio3 19 0>,
<&gpio3 24 0>, <&gpio3 25 0>;
status = "disabled";
@@ -249,7 +248,6 @@
&cspi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi>;
- fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio1 18 0>, <&gpio1 19 0>,
<&gpio1 21 0>;
status = "disabled";
diff --git a/arch/arm/boot/dts/imx53-tx53.dtsi b/arch/arm/boot/dts/imx53-tx53.dtsi
index 57e75f1..3a32201 100644
--- a/arch/arm/boot/dts/imx53-tx53.dtsi
+++ b/arch/arm/boot/dts/imx53-tx53.dtsi
@@ -161,7 +161,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <2>;
status = "okay";
cs-gpios = <
diff --git a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
index ba689fb..524192c 100644
--- a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
+++ b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
@@ -129,7 +129,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <4>;
cs-gpios = <&gpio2 30 0>, <&gpio3 19 0>, <&gpio2 16 0>, <&gpio2 17 0>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
index d4c4a22..32a812b 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
@@ -66,7 +66,6 @@
};
&ecspi2 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi b/arch/arm/boot/dts/imx6q-ba16.dtsi
index 308e11c..3577aa7 100644
--- a/arch/arm/boot/dts/imx6q-ba16.dtsi
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -133,7 +133,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index e4a415f..b1be794 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -95,7 +95,6 @@
};
&ecspi5 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi5>;
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index a150bca..ae90d98 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -114,7 +114,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index 908dab6..f28883b 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -104,7 +104,6 @@
&ecspi5 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi5>;
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio1 12 0>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 7c7c1a8..fd2220a 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -90,7 +90,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1cs>;
@@ -98,7 +97,6 @@
};
&ecspi3 {
- fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
<&gpio4 25 GPIO_ACTIVE_LOW>,
<&gpio4 26 GPIO_ACTIVE_LOW>;
@@ -108,7 +106,6 @@
};
&ecspi5 {
- fsl,spi-num-chipselects = <4>;
cs-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>,
<&gpio1 13 GPIO_ACTIVE_LOW>,
<&gpio1 12 GPIO_ACTIVE_LOW>,
diff --git a/arch/arm/boot/dts/imx6q-gw5400-a.dts b/arch/arm/boot/dts/imx6q-gw5400-a.dts
index 747bc10..8e84713 100644
--- a/arch/arm/boot/dts/imx6q-gw5400-a.dts
+++ b/arch/arm/boot/dts/imx6q-gw5400-a.dts
@@ -138,7 +138,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6q-marsboard.dts b/arch/arm/boot/dts/imx6q-marsboard.dts
index f7995c5..51220a3 100644
--- a/arch/arm/boot/dts/imx6q-marsboard.dts
+++ b/arch/arm/boot/dts/imx6q-marsboard.dts
@@ -97,7 +97,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
cs-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;
- fsl,spi-num-chipselects = <1>;
status = "okay";
m25p80 at 0 {
diff --git a/arch/arm/boot/dts/imx6q-novena.dts b/arch/arm/boot/dts/imx6q-novena.dts
index 758bca9..0fa32b2 100644
--- a/arch/arm/boot/dts/imx6q-novena.dts
+++ b/arch/arm/boot/dts/imx6q-novena.dts
@@ -210,7 +210,6 @@
&ecspi3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3_novena>;
- fsl,spi-num-chipselects = <3>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 8c8a049..82652c1 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -175,7 +175,6 @@
/* Apalis SPI1 */
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
@@ -184,7 +183,6 @@
/* Apalis SPI2 */
&ecspi2 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
diff --git a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
index 5e7792d..550e100 100644
--- a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
@@ -176,7 +176,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>,
<&gpio4 10 GPIO_ACTIVE_LOW>,
<&gpio4 11 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi b/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
index 54f4f01..b2debc0 100644
--- a/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
@@ -100,7 +100,6 @@
};
&ecspi4 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 20 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi4>;
diff --git a/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi b/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
index 7fff02c..0d9e96d 100644
--- a/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
@@ -114,7 +114,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH
&gpio4 10 GPIO_ACTIVE_HIGH
&gpio4 11 GPIO_ACTIVE_HIGH>;
@@ -124,7 +123,6 @@
};
&ecspi2 {
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH &gpio2 27 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
@@ -132,7 +130,6 @@
};
&ecspi4 {
- fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 29 GPIO_ACTIVE_HIGH &gpio5 2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi4>;
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index e6faa65..dbad481 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -138,7 +138,6 @@
/* Colibri SSP */
&ecspi4 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi4>;
diff --git a/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi b/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
index b2c083d..d78312c 100644
--- a/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
@@ -29,7 +29,6 @@
};
&ecspi3 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 24 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 54aca3a..ab34f15 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -159,7 +159,6 @@
};
&ecspi3 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
diff --git a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
index 63acd54..e19f3c3 100644
--- a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
@@ -209,7 +209,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 34887a1..e46c914 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -353,7 +353,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
index d80f21a..678ab19 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
@@ -284,7 +284,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..c4d28e9 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -255,7 +255,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index e9801a2..6e5cb6a 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -76,7 +76,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
status = "okay";
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 24 0>;
flash at 0 {
diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi b/arch/arm/boot/dts/imx6qdl-rex.dtsi
index 17704a5..5cf90c24 100644
--- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
@@ -89,7 +89,6 @@
};
&ecspi2 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
@@ -97,7 +96,6 @@
};
&ecspi3 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 52390ba..a2a714d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -124,7 +124,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..b0fa0c8 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -241,7 +241,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 55ef535..63bf95e 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -160,7 +160,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 9 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6qdl-ts4900.dtsi b/arch/arm/boot/dts/imx6qdl-ts4900.dtsi
index 5c26b26..bf17ad5 100644
--- a/arch/arm/boot/dts/imx6qdl-ts4900.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-ts4900.dtsi
@@ -95,7 +95,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
@@ -109,7 +108,6 @@
};
&ecspi2 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
diff --git a/arch/arm/boot/dts/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
index 2bf2e62..1691714 100644
--- a/arch/arm/boot/dts/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
@@ -221,7 +221,6 @@
&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <
&gpio2 30 GPIO_ACTIVE_HIGH
&gpio3 19 GPIO_ACTIVE_HIGH
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index be11882..0a90eea 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -117,7 +117,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 11 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6sx-nitrogen6sx.dts b/arch/arm/boot/dts/imx6sx-nitrogen6sx.dts
index 9b817f3..b54b40a 100644
--- a/arch/arm/boot/dts/imx6sx-nitrogen6sx.dts
+++ b/arch/arm/boot/dts/imx6sx-nitrogen6sx.dts
@@ -142,7 +142,6 @@
};
&ecspi1 {
- fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio2 16 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
diff --git a/arch/arm/boot/dts/imx6ul-tx6ul.dtsi b/arch/arm/boot/dts/imx6ul-tx6ul.dtsi
index 530e9ca..c784a0b 100644
--- a/arch/arm/boot/dts/imx6ul-tx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul-tx6ul.dtsi
@@ -285,7 +285,6 @@
&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
- fsl,spi-num-chipselects = <2>;
cs-gpios = <
&gpio1 29 GPIO_ACTIVE_HIGH
&gpio1 10 GPIO_ACTIVE_HIGH
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 2f33c46..9d15273 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -111,7 +111,6 @@
};
&ecspi3 {
- fsl,spi-num-chipselects = <1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
cs-gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
--
2.10.2
^ permalink raw reply related
* [PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Vladimir Zapolskiy @ 2016-12-24 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223141139.rlsvoonih5lhnnpu@pengutronix.de>
Hello Uwe,
On 12/23/2016 04:11 PM, Uwe Kleine-K?nig wrote:
> On Fri, Dec 23, 2016 at 01:21:20PM +0200, Vladimir Zapolskiy wrote:
>> Hi Uwe,
>>
>> On 12/23/2016 12:01 PM, Uwe Kleine-K?nig wrote:
>>> On Fri, Dec 23, 2016 at 11:27:24AM +0200, Vladimir Zapolskiy wrote:
>>>> On 12/23/2016 10:32 AM, Uwe Kleine-K?nig wrote:
>>>>> Hello,
>>>>>
>>>>> On Fri, Dec 23, 2016 at 10:20:20AM +0200, Vladimir Zapolskiy wrote:
>>>>>> On 12/23/2016 03:55 AM, Guenter Roeck wrote:
>>>>>>> What is the ultimate conclusion of this exchange ?
>>>>>>>
>>>>>>> Are we going to get another version of the patch, or did everyone agree that
>>>>>>> the patch is good as it is and does not require further changes ?
>>>>>>>
>>>>>>
>>>>>> I can not imagine a different fix.
>>>>>
>>>>> my preferred fix would be:
>>>>>
>>>>> - add an imx35 compatible to all newer dtsi
>>>>> - update the driver to only write the wmcr on imx35 compatible devices
>>>>> adding only imx35.
>>>>>
>>>>
>>>> It breaks old DTS vs. new kernel compatibility, I've already mentioned this.
>>>
>>> Correct, and I didn't deny that. In my mail I pointed out the problem
>>> this imposes and I think it's small enough to not justify the complexity
>>> introduced in your proposed change.
>>>
>>
>> I can not statistically estimate well the severity of the problem which was
>> fixed by commit 5fe65ce7cc (all boards with a similar change not found in
>> a bootloader will be affected, I believe) multiplied by the rate of users,
>> who don't update DTB.
>
> I think most people updating the kernel will update the dtb at the same
> time. And for those who don't it should be quickly obvious that
> something is wrong during development if the machine resets
> unexpectedly. Plus I think that most users are not affected anyhow
> (either because their bootloader fixes up accordingly or because most
> machines don't reset when the timer expires because the hardware isn't
> designed accordingly). After all between introduction of i.MX35/i.MX25
> (not later than Thu Jun 4 11:32:12 2009 +0200, commit
> 8c25c36f33157a2e2a1fcd60b6dc00feace80631) and the broken commit
> 5fe65ce7cc (Mon Sep 8 09:14:07 2014 +0200) it seems it wasn't an issue.
>
> With my suggestion the situation on an affected machine with old dtb and
> new kernel is just as it was in these 5 years where nobody complained.
Please feel free to send the revert of 5fe65ce7cc, if you think that
the commit is unneeded.
>
> It's fine to target a bugfree system, and if you want to target that
> that's applaudable. But then please make it easy for others after you to
> not undo your good and add a big comment to the compatible array of the
> driver explaining why they are all listed explicitly and how to prevent
> to have to expand the list further.
Please clarify, what do you mean here by "undo my good"? Revert my fix
and break boot on i.MX31 again or something else?
>
> So yes, my suggestion has a risk, but I think when weighting that
> against the overhead that is introduced in the driver, I'd go the
> simpler way.
What overhead do you mean here? Prolonged time in a loop while finding
a compatible by looking at 10 more values?
That's the price of the accepted commit 5fe65ce7cc and overlooked
incompatibilities in hardware while writing DTSI files for i.MX SoCs.
> That's of course something personal and as it's you who
> seems to have in interest in fixing the driver, it's your way that
> matters more. And if you document your way good enough, I won't stop
> you.
>
We're going round in circles. And I don't understand what do you mean
by "documenting my way" here.
For clarity I do NOT object against changes in DTS, I do NOT object
to shrink the list of compatibles, I object to mix up the requested
DTS changes for practically every i.MX powered board, bug fix and
a new potential bug in one single change. The series of commits is
generally good, but it lacks atomicity property of a fix, and in
the middle of the series users have to update DTB, it is an overkill.
Is it possible to change DTS *only* and fix kernel boot problem? NO.
Is it possible to change driver *only* and fix kernel boot problem? YES.
Conclusion: the problem is within the driver, to solve the problem
it is sufficient to fix the driver.
As I see it what you propose with involving DTS changes is a solution
to *another* problem (boot time performance optimisation? amount of
driver's lines of code? DTS beautification?).
And obviously it makes no sense to send a DTS change plus error-prone
change plus the actual fix to linux-stable then, even if they are
split by commits.
Uwe, I'm disappointed that we still did not come to a conclusion,
would you agree to a compromise?
I'll add a comment to v2:
/*
* The list of compatibles is added to achieve backward compatibility
* between DTS and kernel while fixing the incompatibility between
* i.MX21/i.MX27/i.MX31 and i.MX25/i.MX35/etc. watchdog controllers.
*
* Please do *NOT* extend the list by adding a compatible value for
* a controller, which is compatible with one of the already listed.
*
* You may consider to shrink the list at your own risk, but this may
* break backward compatibility and users may have to update their DTB,
* which is good eventually.
*/
And you send the removal of the comment and compatibles as a *separate*
change, if you find such a long list of compatibles redundant.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2 4/4] clk: rockchip: add new pll-type for rk3328
From: Heiko Stuebner @ 2016-12-24 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482112573-11613-5-git-send-email-zhangqing@rock-chips.com>
Hi Elaine,
Am Montag, 19. Dezember 2016, 09:56:13 CET schrieb Elaine Zhang:
> The rk3328's pll and clock are similar with rk3036's,
> it different with pll_mode_mask,there are different
> control registers bit,
> so these should be independent and separate from
> the series of rk3328s.
not sure I understand this description. In the patch (and TRM excerpt) I see
that the number of parents is down to only xin24m but the general handling is
similar to the rk3036 and thus reuses its operations.
The description makes it sound like there are operational differences (the
"different control register bit" part), so could you clarify this a bit
please?
Also, please move the pll addition before the addition of the clock-controller
in the series and move the pll-type addition also here from the controller
patch.
Some more below:
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> drivers/clk/rockchip/clk-pll.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
> index 6ed605776abd..9650c75f61d1 100644
> --- a/drivers/clk/rockchip/clk-pll.c
> +++ b/drivers/clk/rockchip/clk-pll.c
> @@ -29,6 +29,7 @@
> #define PLL_MODE_SLOW 0x0
> #define PLL_MODE_NORM 0x1
> #define PLL_MODE_DEEP 0x2
> +#define PLL_RK3328_MODE_MASK 0x1
>
> struct rockchip_clk_pll {
> struct clk_hw hw;
> @@ -865,13 +866,17 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, pll_mux = &pll->pll_mux;
> pll_mux->reg = ctx->reg_base + mode_offset;
> pll_mux->shift = mode_shift;
> - pll_mux->mask = PLL_MODE_MASK;
> + if (pll_type == pll_rk3328)
> + pll_mux->mask = PLL_RK3328_MODE_MASK;
> + else
> + pll_mux->mask = PLL_MODE_MASK;
you're missing the other parts handling parents, like num_parents check
and the init.num_parents parameter.
The pll really has only one parent, xin24m, so we should handle this
correctly in the code, instead of having 2 times xin24m in the parent
array coming from the clock controller.
> pll_mux->flags = 0;
> pll_mux->lock = &ctx->lock;
> pll_mux->hw.init = &init;
>
> if (pll_type == pll_rk3036 ||
> pll_type == pll_rk3066 ||
> + pll_type == pll_rk3328 ||
> pll_type == pll_rk3399)
> pll_mux->flags |= CLK_MUX_HIWORD_MASK;
>
> @@ -929,6 +934,12 @@ struct clk *rockchip_clk_register_pll(struct
> rockchip_clk_provider *ctx, else
> init.ops = &rockchip_rk3066_pll_clk_ops;
> break;
> + case pll_rk3328:
> + if (!pll->rate_table || IS_ERR(ctx->grf))
> + init.ops = &rockchip_rk3036_pll_clk_norate_ops;
> + else
> + init.ops = &rockchip_rk3036_pll_clk_ops;
> + break;
please don't duplicate the rk3036-ops assignment, when adding the
pll_rk3328 option to the rk3036 part suffices.
I'd think the pll-patch should look something like the
following (untested, so please test):
--------------- 8< -----------------
Subject: [PATCH] clk: rockchip: add new pll-type for rk3328
The rk3328's pll and clock are similar with rk3036's,
it different with pll_mode_mask,there are different
control registers bit,
so these should be independent and separate from
the series of rk3328s.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/clk/rockchip/clk-pll.c | 18 ++++++++++++++----
drivers/clk/rockchip/clk.h | 1 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6ed6057..99ce483 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -29,6 +29,7 @@
#define PLL_MODE_SLOW 0x0
#define PLL_MODE_NORM 0x1
#define PLL_MODE_DEEP 0x2
+#define PLL_RK3328_MODE_MASK 0x1
struct rockchip_clk_pll {
struct clk_hw hw;
@@ -848,8 +849,9 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx,
struct clk *pll_clk, *mux_clk;
char pll_name[20];
- if (num_parents != 2) {
- pr_err("%s: needs two parent clocks\n", __func__);
+ if ((pll_type != pll_rk3328 && num_parents != 2) ||
+ (pll_type == pll_rk3328 && num_parents != 1)) {
+ pr_err("%s: missing parent clocks\n", __func__);
return ERR_PTR(-EINVAL);
}
@@ -865,13 +867,17 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx,
pll_mux = &pll->pll_mux;
pll_mux->reg = ctx->reg_base + mode_offset;
pll_mux->shift = mode_shift;
- pll_mux->mask = PLL_MODE_MASK;
+ if (pll_type == pll_rk3328)
+ pll_mux->mask = PLL_RK3328_MODE_MASK;
+ else
+ pll_mux->mask = PLL_MODE_MASK;
pll_mux->flags = 0;
pll_mux->lock = &ctx->lock;
pll_mux->hw.init = &init;
if (pll_type == pll_rk3036 ||
pll_type == pll_rk3066 ||
+ pll_type == pll_rk3328 ||
pll_type == pll_rk3399)
pll_mux->flags |= CLK_MUX_HIWORD_MASK;
@@ -884,7 +890,10 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx,
init.flags = CLK_SET_RATE_PARENT;
init.ops = pll->pll_mux_ops;
init.parent_names = pll_parents;
- init.num_parents = ARRAY_SIZE(pll_parents);
+ if (pll_type == pll_rk3328)
+ init.num_parents = 2;
+ else
+ init.num_parents = ARRAY_SIZE(pll_parents);
mux_clk = clk_register(NULL, &pll_mux->hw);
if (IS_ERR(mux_clk))
@@ -918,6 +927,7 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx,
switch (pll_type) {
case pll_rk3036:
+ case pll_rk3328:
if (!pll->rate_table || IS_ERR(ctx->grf))
init.ops = &rockchip_rk3036_pll_clk_norate_ops;
else
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index d67eecc..06acb7e 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -130,6 +130,7 @@ struct clk;
enum rockchip_pll_type {
pll_rk3036,
pll_rk3066,
+ pll_rk3328,
pll_rk3399,
};
--
2.10.2
--------------- 8< -----------------
^ permalink raw reply related
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Suman Anna @ 2016-12-23 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f847af8-6bde-4645-aea4-7e9b02306e39@ti.com>
On 12/23/2016 11:05 AM, Suman Anna wrote:
> Hi Sarang,
>
>>>
>>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>>> firmware loading to complete successfully before calling
>>>> rproc_boot(). The same can be achieved by just setting
>>>> rproc->auto_boot flag. Change this. As a result this change
>>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>>> initialization to the wkup_m3_ipc_probe().
>>>>
>>>> Other than the current usage, the firmware_loading_complete is
>>>> only used in rproc_del() where it's no longer needed. This
>>>> change is in preparation for removing firmware_loading_complete
>>>> completely.
>>>
>>> Based on the comments so far, I am assuming that you are dropping this
>>> series.
>>
>> No, may not be dropping this. Will try to handle it differently in
>> rproc_del() (probably by making use of some state flag).
>>>
>>> In any case, this series did break our PM stack. We definitely don't
>>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>>> need to stay with the wkup_m3_ipc driver.
>>
>> Which scenario did it break? Booting up rproc device before
>> wkup_m3_ipc_probe() causes issues?
>
> Yes, our state machine requires the wkup_m3_ipc driver to control the
> boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
> it is our PM master and is responsible for putting the host processor
> into suspend and waking it up in system suspend/cpuidle paths.
> The remoteproc infrastructure is only used for load/boot, but the Linux
> PM state machine and communication is all controlled by the wkup_m3_ipc
> driver.
>
>>
>> Nevertheless, I think Bjorn's suggestion of just dropping the call to
>> wait_for_completion() and keeping kthread looks good, also because of
>> the fact that rproc_boot() anyways calls request_firmware() and no
>> longer needed to wait on asynchronous loading of firmware.
>
> Yeah, I will have to test this, but looking at current code, this should
> mostly be ok because of the remoteproc core changes w.r.t resource table
> parsing.
Tested with just the wait_for_completion() removed and it works fine. I
can send a patch for the same if you prefer me to send it.
regards
Suman
>
> regards
> Suman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/1] ARM64: dts: meson-gxbb-odroidc2: linux,usable-memory
From: Neil Armstrong @ 2016-12-23 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223125213.5461-1-xypron.glpk@gmx.de>
Le 23/12/2016 13:52, Heinrich Schuchardt a ?crit :
> After reading the fdt u-boot overwrites the reg property of the
> memory node with <0x0 0x0 0x0 0x78000000>.
>
> To override this setting we have to use the property
> linux,usable-memory.
>
> If the first 16MB of the 2GB physical memory are used by
> the Linux kernel oops occur on the Odroid C2.
>
> For the Odroid C2 this patch replaces
> [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and
> usable memory range
> https://lkml.org/lkml/2016/12/12/127
>
> Fixes: 855960342d1e7 ARM64: dts: amlogic: add Hardkernel ODROID-C2
> CC: Neil Armstrong <narmstrong@baylibre.com>
> CC: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..82ab94417940 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -61,7 +61,7 @@
>
> memory at 0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x01000000 0x0 0x7f000000>;
> };
>
> usb_otg_pwr: regulator-usb-pwrs {
>
Hi Heinrich,
Thanks a lot for testing and pushing this patch, indeed I missed this point abou u-boot overwriting reg.
I will test this next week, and hopefully get these merged.
Neil
^ permalink raw reply
* [PATCH] PCI: exynos: refactor exynos pcie driver
From: Jingoo Han @ 2016-12-23 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482490587-13611-1-git-send-email-pankaj.dubey@samsung.com>
On Friday, December 23, 2016 5:56 AM, Pankaj Dubey wrote:
>
> From: Niyas Ahmed S T <niyas.ahmed@samsung.com>
>
> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
> This patch does refactoring of Exynos PCIe driver to extend support
> for other Exynos SoC.
>
> Following are the main changes done via this patch:
> 1) It adds separate structs for memory, clock resources.
What is the reason to separate structs for these?
Please add the reason to this commit message.
It will be helpful.
> 2) It add exynos_pcie_ops struct which will allow us to support the
> differences in resources in different Exynos SoC.
Good. I have no objection.
Best regards,
Jingoo Han
>
> No functional change intended.
>
> Signed-off-by: Niyas Ahmed S T <niyas.ahmed@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> This patch set is prepared on top of Krzysztof's for-next and
> PCIe driver cleanup patch [1] by Jaehoon Chung.
>
> [1]: https://lkml.org/lkml/2016/12/19/44
>
>
> drivers/pci/host/pci-exynos.c | 346 ++++++++++++++++++++++++++-----------
> -----
> 1 file changed, 217 insertions(+), 129 deletions(-)
>
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index 33562cf..2dc54f7 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -17,6 +17,7 @@
> #include <linux/interrupt.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> +#include <linux/of_device.h>
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> @@ -28,16 +29,6 @@
>
> #define to_exynos_pcie(x) container_of(x, struct exynos_pcie, pp)
>
> -struct exynos_pcie {
> - struct pcie_port pp;
> - void __iomem *elbi_base; /* DT 0th resource */
> - void __iomem *phy_base; /* DT 1st resource */
> - void __iomem *block_base; /* DT 2nd resource */
> - int reset_gpio;
> - struct clk *clk;
> - struct clk *bus_clk;
> -};
> -
> /* PCIe ELBI registers */
> #define PCIE_IRQ_PULSE 0x000
> #define IRQ_INTA_ASSERT BIT(0)
> @@ -102,6 +93,122 @@ struct exynos_pcie {
> #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> #define PCIE_PHY_TRSV3_LVCC 0x31c
>
> +struct exynos_pcie_mem_res {
> + void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
> + void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
> + void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL
> */
> +};
> +
> +struct exynos_pcie_clk_res {
> + struct clk *clk;
> + struct clk *bus_clk;
> +};
> +
> +struct exynos_pcie {
> + struct pcie_port pp;
> + struct exynos_pcie_mem_res *mem_res;
> + struct exynos_pcie_clk_res *clk_res;
> + const struct exynos_pcie_ops *ops;
> + int reset_gpio;
> +};
> +
> +struct exynos_pcie_ops {
> + int (*get_mem_resources)(struct platform_device *pdev,
> + struct exynos_pcie *ep);
> + int (*get_clk_resources)(struct exynos_pcie *ep);
> + int (*init_clk_resources)(struct exynos_pcie *ep);
> + void (*deinit_clk_resources)(struct exynos_pcie *ep);
> +};
> +
> +static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
> + struct exynos_pcie *ep)
> +{
> + struct resource *res;
> + struct device *dev = ep->pp.dev;
> +
> + ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
> + if (!ep->mem_res)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ep->mem_res->elbi_base))
> + return PTR_ERR(ep->mem_res->elbi_base);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ep->mem_res->phy_base))
> + return PTR_ERR(ep->mem_res->phy_base);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + ep->mem_res->block_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ep->mem_res->block_base))
> + return PTR_ERR(ep->mem_res->block_base);
> +
> + return 0;
> +}
> +
> +static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
> +{
> + struct device *dev = ep->pp.dev;
> +
> + ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
> + if (!ep->clk_res)
> + return -ENOMEM;
> +
> + ep->clk_res->clk = devm_clk_get(dev, "pcie");
> + if (IS_ERR(ep->clk_res->clk)) {
> + dev_err(dev, "Failed to get pcie rc clock\n");
> + return PTR_ERR(ep->clk_res->clk);
> + }
> +
> + ep->clk_res->bus_clk = devm_clk_get(dev, "pcie_bus");
> + if (IS_ERR(ep->clk_res->bus_clk)) {
> + dev_err(dev, "Failed to get pcie bus clock\n");
> + return PTR_ERR(ep->clk_res->bus_clk);
> + }
> +
> + return 0;
> +}
> +
> +static int exynos5440_pcie_init_clk_resources(struct exynos_pcie *ep)
> +{
> + struct device *dev = ep->pp.dev;
> + int ret;
> +
> + ret = clk_prepare_enable(ep->clk_res->clk);
> + if (ret) {
> + dev_err(dev, "cannot enable pcie rc clock");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(ep->clk_res->bus_clk);
> + if (ret) {
> + dev_err(dev, "cannot enable pcie bus clock");
> + goto err_bus_clk;
> + }
> +
> + return 0;
> +
> +err_bus_clk:
> + clk_disable_unprepare(ep->clk_res->clk);
> +
> + return ret;
> +}
> +
> +static void exynos5440_pcie_deinit_clk_resources(struct exynos_pcie *ep)
> +{
> + clk_disable_unprepare(ep->clk_res->bus_clk);
> + clk_disable_unprepare(ep->clk_res->clk);
> +}
> +
> +static const struct exynos_pcie_ops exynos5440_pcie_ops = {
> + .get_mem_resources = exynos5440_pcie_get_mem_resources,
> + .get_clk_resources = exynos5440_pcie_get_clk_resources,
> + .init_clk_resources = exynos5440_pcie_init_clk_resources,
> + .deinit_clk_resources = exynos5440_pcie_deinit_clk_resources,
> +};
> +
> static void exynos_pcie_writel(void __iomem *base, u32 val, u32 reg)
> {
> writel(val, base + reg);
> @@ -116,155 +223,155 @@ static void exynos_pcie_sideband_dbi_w_mode(struct
> exynos_pcie *ep, bool on)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_ELBI_SLV_AWMISC);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base,
> PCIE_ELBI_SLV_AWMISC);
> if (on)
> val |= PCIE_ELBI_SLV_DBI_ENABLE;
> else
> val &= ~PCIE_ELBI_SLV_DBI_ENABLE;
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_ELBI_SLV_AWMISC);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val,
> PCIE_ELBI_SLV_AWMISC);
> }
>
> static void exynos_pcie_sideband_dbi_r_mode(struct exynos_pcie *ep, bool
> on)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_ELBI_SLV_ARMISC);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base,
> PCIE_ELBI_SLV_ARMISC);
> if (on)
> val |= PCIE_ELBI_SLV_DBI_ENABLE;
> else
> val &= ~PCIE_ELBI_SLV_DBI_ENABLE;
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_ELBI_SLV_ARMISC);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val,
> PCIE_ELBI_SLV_ARMISC);
> }
>
> static void exynos_pcie_assert_core_reset(struct exynos_pcie *ep)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_CORE_RESET);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_CORE_RESET);
> val &= ~PCIE_CORE_RESET_ENABLE;
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_CORE_RESET);
> - exynos_pcie_writel(ep->elbi_base, 0, PCIE_PWR_RESET);
> - exynos_pcie_writel(ep->elbi_base, 0, PCIE_STICKY_RESET);
> - exynos_pcie_writel(ep->elbi_base, 0, PCIE_NONSTICKY_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_CORE_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_PWR_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_STICKY_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_NONSTICKY_RESET);
> }
>
> static void exynos_pcie_deassert_core_reset(struct exynos_pcie *ep)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_CORE_RESET);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_CORE_RESET);
> val |= PCIE_CORE_RESET_ENABLE;
>
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_CORE_RESET);
> - exynos_pcie_writel(ep->elbi_base, 1, PCIE_STICKY_RESET);
> - exynos_pcie_writel(ep->elbi_base, 1, PCIE_NONSTICKY_RESET);
> - exynos_pcie_writel(ep->elbi_base, 1, PCIE_APP_INIT_RESET);
> - exynos_pcie_writel(ep->elbi_base, 0, PCIE_APP_INIT_RESET);
> - exynos_pcie_writel(ep->block_base, 1, PCIE_PHY_MAC_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_CORE_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_STICKY_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_NONSTICKY_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_APP_INIT_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_APP_INIT_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 1, PCIE_PHY_MAC_RESET);
> }
>
> static void exynos_pcie_assert_phy_reset(struct exynos_pcie *ep)
> {
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_MAC_RESET);
> - exynos_pcie_writel(ep->block_base, 1, PCIE_PHY_GLOBAL_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_MAC_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 1,
> PCIE_PHY_GLOBAL_RESET);
> }
>
> static void exynos_pcie_deassert_phy_reset(struct exynos_pcie *ep)
> {
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_GLOBAL_RESET);
> - exynos_pcie_writel(ep->elbi_base, 1, PCIE_PWR_RESET);
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_COMMON_RESET);
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_CMN_REG);
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_TRSVREG_RESET);
> - exynos_pcie_writel(ep->block_base, 0, PCIE_PHY_TRSV_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 0,
> PCIE_PHY_GLOBAL_RESET);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_PWR_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 0,
> PCIE_PHY_COMMON_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_CMN_REG);
> + exynos_pcie_writel(ep->mem_res->block_base, 0,
> PCIE_PHY_TRSVREG_RESET);
> + exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_TRSV_RESET);
> }
>
> static void exynos_pcie_power_on_phy(struct exynos_pcie *ep)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_COMMON_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_COMMON_POWER);
> val &= ~PCIE_PHY_COMMON_PD_CMN;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_COMMON_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_COMMON_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV0_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV0_POWER);
> val &= ~PCIE_PHY_TRSV0_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV0_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV0_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV1_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV1_POWER);
> val &= ~PCIE_PHY_TRSV1_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV1_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV1_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV2_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV2_POWER);
> val &= ~PCIE_PHY_TRSV2_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV2_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV2_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV3_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV3_POWER);
> val &= ~PCIE_PHY_TRSV3_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV3_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV3_POWER);
> }
>
> static void exynos_pcie_power_off_phy(struct exynos_pcie *ep)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_COMMON_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_COMMON_POWER);
> val |= PCIE_PHY_COMMON_PD_CMN;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_COMMON_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_COMMON_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV0_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV0_POWER);
> val |= PCIE_PHY_TRSV0_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV0_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV0_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV1_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV1_POWER);
> val |= PCIE_PHY_TRSV1_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV1_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV1_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV2_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV2_POWER);
> val |= PCIE_PHY_TRSV2_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV2_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV2_POWER);
>
> - val = exynos_pcie_readl(ep->phy_base, PCIE_PHY_TRSV3_POWER);
> + val = exynos_pcie_readl(ep->mem_res->phy_base,
> PCIE_PHY_TRSV3_POWER);
> val |= PCIE_PHY_TRSV3_PD_TSV;
> - exynos_pcie_writel(ep->phy_base, val, PCIE_PHY_TRSV3_POWER);
> + exynos_pcie_writel(ep->mem_res->phy_base, val,
> PCIE_PHY_TRSV3_POWER);
> }
>
> static void exynos_pcie_init_phy(struct exynos_pcie *ep)
> {
> /* DCC feedback control off */
> - exynos_pcie_writel(ep->phy_base, 0x29, PCIE_PHY_DCC_FEEDBACK);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x29,
> PCIE_PHY_DCC_FEEDBACK);
>
> /* set TX/RX impedance */
> - exynos_pcie_writel(ep->phy_base, 0xd5, PCIE_PHY_IMPEDANCE);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0xd5, PCIE_PHY_IMPEDANCE);
>
> /* set 50Mhz PHY clock */
> - exynos_pcie_writel(ep->phy_base, 0x14, PCIE_PHY_PLL_DIV_0);
> - exynos_pcie_writel(ep->phy_base, 0x12, PCIE_PHY_PLL_DIV_1);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x14, PCIE_PHY_PLL_DIV_0);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x12, PCIE_PHY_PLL_DIV_1);
>
> /* set TX Differential output for lane 0 */
> - exynos_pcie_writel(ep->phy_base, 0x7f, PCIE_PHY_TRSV0_DRV_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x7f,
> PCIE_PHY_TRSV0_DRV_LVL);
>
> /* set TX Pre-emphasis Level Control for lane 0 to minimum */
> - exynos_pcie_writel(ep->phy_base, 0x0, PCIE_PHY_TRSV0_EMP_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x0,
> PCIE_PHY_TRSV0_EMP_LVL);
>
> /* set RX clock and data recovery bandwidth */
> - exynos_pcie_writel(ep->phy_base, 0xe7, PCIE_PHY_PLL_BIAS);
> - exynos_pcie_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV0_RXCDR);
> - exynos_pcie_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV1_RXCDR);
> - exynos_pcie_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV2_RXCDR);
> - exynos_pcie_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV3_RXCDR);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0xe7, PCIE_PHY_PLL_BIAS);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x82,
> PCIE_PHY_TRSV0_RXCDR);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x82,
> PCIE_PHY_TRSV1_RXCDR);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x82,
> PCIE_PHY_TRSV2_RXCDR);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x82,
> PCIE_PHY_TRSV3_RXCDR);
>
> /* change TX Pre-emphasis Level Control for lanes */
> - exynos_pcie_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV0_EMP_LVL);
> - exynos_pcie_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV1_EMP_LVL);
> - exynos_pcie_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV2_EMP_LVL);
> - exynos_pcie_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV3_EMP_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x39,
> PCIE_PHY_TRSV0_EMP_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x39,
> PCIE_PHY_TRSV1_EMP_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x39,
> PCIE_PHY_TRSV2_EMP_LVL);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x39,
> PCIE_PHY_TRSV3_EMP_LVL);
>
> /* set LVCC */
> - exynos_pcie_writel(ep->phy_base, 0x20, PCIE_PHY_TRSV0_LVCC);
> - exynos_pcie_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV1_LVCC);
> - exynos_pcie_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV2_LVCC);
> - exynos_pcie_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV3_LVCC);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0x20,
> PCIE_PHY_TRSV0_LVCC);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0xa0,
> PCIE_PHY_TRSV1_LVCC);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0xa0,
> PCIE_PHY_TRSV2_LVCC);
> + exynos_pcie_writel(ep->mem_res->phy_base, 0xa0,
> PCIE_PHY_TRSV3_LVCC);
> }
>
> static void exynos_pcie_assert_reset(struct exynos_pcie *exynos_pcie)
> @@ -295,25 +402,27 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *exynos_pcie)
> exynos_pcie_init_phy(exynos_pcie);
>
> /* pulse for common reset */
> - exynos_pcie_writel(exynos_pcie->block_base, 1,
> PCIE_PHY_COMMON_RESET);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> udelay(500);
> - exynos_pcie_writel(exynos_pcie->block_base, 0,
> PCIE_PHY_COMMON_RESET);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
>
> exynos_pcie_deassert_core_reset(exynos_pcie);
> dw_pcie_setup_rc(pp);
> exynos_pcie_assert_reset(exynos_pcie);
>
> /* assert LTSSM enable */
> - exynos_pcie_writel(exynos_pcie->elbi_base, PCIE_ELBI_LTSSM_ENABLE,
> - PCIE_APP_LTSSM_ENABLE);
> + exynos_pcie_writel(exynos_pcie->mem_res->elbi_base,
> + PCIE_ELBI_LTSSM_ENABLE, PCIE_APP_LTSSM_ENABLE);
>
> /* check if the link is up or not */
> if (!dw_pcie_wait_for_link(pp))
> return 0;
>
> - while (exynos_pcie_readl(exynos_pcie->phy_base,
> + while (exynos_pcie_readl(exynos_pcie->mem_res->phy_base,
> PCIE_PHY_PLL_LOCKED) == 0) {
> - val = exynos_pcie_readl(exynos_pcie->block_base,
> + val = exynos_pcie_readl(exynos_pcie->mem_res->block_base,
> PCIE_PHY_PLL_LOCKED);
> dev_info(dev, "PLL Locked: 0x%x\n", val);
> }
> @@ -325,8 +434,8 @@ static void exynos_pcie_clear_irq_pulse(struct
> exynos_pcie *ep)
> {
> u32 val;
>
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_IRQ_PULSE);
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_IRQ_PULSE);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_IRQ_PULSE);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_PULSE);
> }
>
> static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
> @@ -336,7 +445,7 @@ static void exynos_pcie_enable_irq_pulse(struct
> exynos_pcie *ep)
> /* enable INTX interrupt */
> val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
> IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_IRQ_EN_PULSE);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_PULSE);
> }
>
> static irqreturn_t exynos_pcie_irq_handler(int irq, void *arg)
> @@ -363,9 +472,9 @@ static void exynos_pcie_msi_init(struct exynos_pcie
> *ep)
> dw_pcie_msi_init(pp);
>
> /* enable MSI interrupt */
> - val = exynos_pcie_readl(ep->elbi_base, PCIE_IRQ_EN_LEVEL);
> + val = exynos_pcie_readl(ep->mem_res->elbi_base, PCIE_IRQ_EN_LEVEL);
> val |= IRQ_MSI_ENABLE;
> - exynos_pcie_writel(ep->elbi_base, val, PCIE_IRQ_EN_LEVEL);
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_LEVEL);
> }
>
> static void exynos_pcie_enable_interrupts(struct exynos_pcie *exynos_pcie)
> @@ -425,7 +534,8 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
> struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
> u32 val;
>
> - val = exynos_pcie_readl(exynos_pcie->elbi_base,
> PCIE_ELBI_RDLH_LINKUP);
> + val = exynos_pcie_readl(exynos_pcie->mem_res->elbi_base,
> + PCIE_ELBI_RDLH_LINKUP);
> if (val == PCIE_ELBI_LTSSM_ENABLE)
> return 1;
>
> @@ -503,7 +613,6 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
> struct exynos_pcie *exynos_pcie;
> struct pcie_port *pp;
> struct device_node *np = dev->of_node;
> - struct resource *res;
> int ret;
>
> exynos_pcie = devm_kzalloc(dev, sizeof(*exynos_pcie), GFP_KERNEL);
> @@ -513,59 +622,37 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
> pp = &exynos_pcie->pp;
> pp->dev = dev;
>
> - exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> -
> - exynos_pcie->clk = devm_clk_get(dev, "pcie");
> - if (IS_ERR(exynos_pcie->clk)) {
> - dev_err(dev, "Failed to get pcie rc clock\n");
> - return PTR_ERR(exynos_pcie->clk);
> - }
> - ret = clk_prepare_enable(exynos_pcie->clk);
> - if (ret)
> - return ret;
> + exynos_pcie->ops = (const struct exynos_pcie_ops *)
> + of_device_get_match_data(dev);
>
> - exynos_pcie->bus_clk = devm_clk_get(dev, "pcie_bus");
> - if (IS_ERR(exynos_pcie->bus_clk)) {
> - dev_err(dev, "Failed to get pcie bus clock\n");
> - ret = PTR_ERR(exynos_pcie->bus_clk);
> - goto fail_clk;
> - }
> - ret = clk_prepare_enable(exynos_pcie->bus_clk);
> - if (ret)
> - goto fail_clk;
> + exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - exynos_pcie->elbi_base = devm_ioremap_resource(dev, res);
> - if (IS_ERR(exynos_pcie->elbi_base)) {
> - ret = PTR_ERR(exynos_pcie->elbi_base);
> - goto fail_bus_clk;
> + if (exynos_pcie->ops && exynos_pcie->ops->get_mem_resources) {
> + ret = exynos_pcie->ops->get_mem_resources(pdev, exynos_pcie);
> + if (ret)
> + return ret;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - exynos_pcie->phy_base = devm_ioremap_resource(dev, res);
> - if (IS_ERR(exynos_pcie->phy_base)) {
> - ret = PTR_ERR(exynos_pcie->phy_base);
> - goto fail_bus_clk;
> - }
> + if (exynos_pcie->ops && exynos_pcie->ops->get_clk_resources) {
> + ret = exynos_pcie->ops->get_clk_resources(exynos_pcie);
> + if (ret)
> + return ret;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> - exynos_pcie->block_base = devm_ioremap_resource(dev, res);
> - if (IS_ERR(exynos_pcie->block_base)) {
> - ret = PTR_ERR(exynos_pcie->block_base);
> - goto fail_bus_clk;
> + ret = exynos_pcie->ops->init_clk_resources(exynos_pcie);
> + if (ret)
> + return ret;
> }
>
> ret = exynos_add_pcie_port(exynos_pcie, pdev);
> if (ret < 0)
> - goto fail_bus_clk;
> + goto fail_probe;
>
> platform_set_drvdata(pdev, exynos_pcie);
> return 0;
>
> -fail_bus_clk:
> - clk_disable_unprepare(exynos_pcie->bus_clk);
> -fail_clk:
> - clk_disable_unprepare(exynos_pcie->clk);
> +fail_probe:
> + if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> + exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
> return ret;
> }
>
> @@ -573,14 +660,15 @@ static int __exit exynos_pcie_remove(struct
> platform_device *pdev)
> {
> struct exynos_pcie *exynos_pcie = platform_get_drvdata(pdev);
>
> - clk_disable_unprepare(exynos_pcie->bus_clk);
> - clk_disable_unprepare(exynos_pcie->clk);
> + if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> + exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
>
> return 0;
> }
>
> static const struct of_device_id exynos_pcie_of_match[] = {
> - { .compatible = "samsung,exynos5440-pcie", },
> + { .compatible = "samsung,exynos5440-pcie",
> + .data = &exynos5440_pcie_ops },
> {},
> };
>
> --
> 2.7.4
^ permalink raw reply
* [PATCH] ARM: keystone: dts: fix netcp clocks and add names
From: Grygorii Strashko @ 2016-12-23 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <94626755-2ef9-960c-d55a-f6c6d5c1adb7@oracle.com>
On 12/08/2016 04:13 PM, Santosh Shilimkar wrote:
> On 12/8/2016 1:11 PM, Grygorii Strashko wrote:
>> From: Murali Karicheri <m-karicheri2@ti.com>
>>
>> Fix the pa clock to point to the clkpa which has clock rate of 1/3 of PA
>> PLL clock and add clock names.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>
> Hi Arnd,
>
> Can you please pick this fix as well if possible in your
> non critical fixes branch ?
Sry, that I'm disturbing you, but was this patch applied somewhere?
--
regards,
-grygorii
^ permalink raw reply
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Suman Anna @ 2016-12-23 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9092e066-b2ad-ee42-de5f-d66b84a10cfd@codeaurora.org>
Hi Sarang,
>>
>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>> firmware loading to complete successfully before calling
>>> rproc_boot(). The same can be achieved by just setting
>>> rproc->auto_boot flag. Change this. As a result this change
>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>> initialization to the wkup_m3_ipc_probe().
>>>
>>> Other than the current usage, the firmware_loading_complete is
>>> only used in rproc_del() where it's no longer needed. This
>>> change is in preparation for removing firmware_loading_complete
>>> completely.
>>
>> Based on the comments so far, I am assuming that you are dropping this
>> series.
>
> No, may not be dropping this. Will try to handle it differently in
> rproc_del() (probably by making use of some state flag).
>>
>> In any case, this series did break our PM stack. We definitely don't
>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>> need to stay with the wkup_m3_ipc driver.
>
> Which scenario did it break? Booting up rproc device before
> wkup_m3_ipc_probe() causes issues?
Yes, our state machine requires the wkup_m3_ipc driver to control the
boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
it is our PM master and is responsible for putting the host processor
into suspend and waking it up in system suspend/cpuidle paths.
The remoteproc infrastructure is only used for load/boot, but the Linux
PM state machine and communication is all controlled by the wkup_m3_ipc
driver.
>
> Nevertheless, I think Bjorn's suggestion of just dropping the call to
> wait_for_completion() and keeping kthread looks good, also because of
> the fact that rproc_boot() anyways calls request_firmware() and no
> longer needed to wait on asynchronous loading of firmware.
Yeah, I will have to test this, but looking at current code, this should
mostly be ok because of the remoteproc core changes w.r.t resource table
parsing.
regards
Suman
^ permalink raw reply
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Suman Anna @ 2016-12-23 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b7457597-d69c-4d2c-5229-0678d7c41f48@codeaurora.org>
Hi Sarang,
On 12/22/2016 06:07 PM, Sarangdhar Joshi wrote:
> On 12/22/2016 5:02 AM, Bjorn Andersson wrote:
>> On Wed 21 Dec 19:16 PST 2016, Suman Anna wrote:
>>
>>> Hi Sarang,
>>>
>>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>>> firmware loading to complete successfully before calling
>>>> rproc_boot(). The same can be achieved by just setting
>>>> rproc->auto_boot flag. Change this. As a result this change
>>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>>> initialization to the wkup_m3_ipc_probe().
>>>>
>>>> Other than the current usage, the firmware_loading_complete is
>>>> only used in rproc_del() where it's no longer needed. This
>>>> change is in preparation for removing firmware_loading_complete
>>>> completely.
>>>
>>> Based on the comments so far, I am assuming that you are dropping this
>>> series.
>>>
>>
>> Following up on those comments only revealed that we have several other
>> similar race conditions, so I'm hoping that Sarangdhar will continue to
>> work on fixing those - and in this process get rid of this completion.
>>
>>> In any case, this series did break our PM stack. We definitely don't
>>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>>> need to stay with the wkup_m3_ipc driver.
>>>
>>
>> Reviewing the wkup_m3 situation again I see that as we have moved the
>> resource table parsing to the rproc_boot() path there's no longer any
>> need for the wkup_m3_ipc driver to wait for the remoteproc-core-internal
>> completion.
>>
>> If rproc_get_by_phandle() returns non-NULL it is initialized. We still
>> don't want to call rproc_boot() from wkup_m3_ipc_probe(), so let's keep
>> the wkup_m3_rproc_boot_thread().
>
> Did you mean it's okay to call rproc_boot() from wkup_m3_ipc_probe()?
> rproc_boot() calls request_firmware() anyways and so there is no need to
> wait for completion of asynchronous firmware loading.
No, please retain the kthread. I think you miss the purpose of this wait
for completion originally. Before all the core changes in 4.9, the
resource table is parsed in the first asynchronous loading step, and we
had to wait for that step to complete. Now that there's no table parsing
during the request_firmware_no_wait() for non auto-boot, we can get away
from the need for a synchronzition call.
>
>>
>> Sarangdhar, could you update the wkup_m3_ipc patch to just drop the
>> wait_for_completion() call?
>
> Sure, assuming we should still keep the rproc_boot() call in the kthread.
Yep.
regards
Suman
^ 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