* [PATCH 2/3] arm64: acpi, efi: fix alignment fault in accessing ACPI tables at kdump
From: AKASHI Takahiro @ 2018-06-15 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org>
This is a fix against the issue that crash dump kernel may hang up
during booting, which can happen on any ACPI-based system with "ACPI
Reclaim Memory."
(kernel messages after panic kicked off kdump)
(snip...)
Bye!
(snip...)
ACPI: Core revision 20170728
pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
Internal error: Oops: 96000021 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
task: ffff000008d05180 task.stack: ffff000008cc0000
PC is at acpi_ns_lookup+0x25c/0x3c0
LR is at acpi_ds_load1_begin_op+0xa4/0x294
(snip...)
Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
Call trace:
(snip...)
[<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
[<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
[<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
[<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
[<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
[<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
[<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
[<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
[<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
[<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
[<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
[<ffff000008badc20>] acpi_early_init+0x9c/0xd0
[<ffff000008b70d50>] start_kernel+0x3b4/0x43c
Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
---[ end trace c46ed37f9651c58e ]---
Kernel panic - not syncing: Fatal exception
Rebooting in 10 seconds..
(diagnosis)
* This fault is a data abort, alignment fault (ESR=0x96000021)
during reading out ACPI table.
* Initial ACPI tables are normally stored in system ram and marked as
"ACPI Reclaim memory" by the firmware.
* After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
memory as MEMBLOCK_NOMAP"), those regions are differently handled
as they are "memblock-reserved", without NOMAP bit.
* So they are now excluded from device tree's "usable-memory-range"
which kexec-tools determines based on a current view of /proc/iomem.
* When crash dump kernel boots up, it tries to accesses ACPI tables by
mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
since they are no longer part of mapped system ram.
* Given that ACPI accessor/helper functions are compiled in without
unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
any unaligned access to ACPI tables can cause a fatal panic.
With this patch, acpi_os_ioremap() always honors memory attribute
information provided by the firmware (EFI) and retaining cacheability
allows the kernel safe access to ACPI tables.
Please note that arm_enable_runtime_services() is now renamed to
efi_enter_virtual_mode() due to the similarity to x86's.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Suggested-by: James Morse <james.morse@arm.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by and Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
(for older version)
---
arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++-------
arch/arm64/kernel/acpi.c | 11 +++--------
drivers/firmware/efi/arm-runtime.c | 27 ++++++++++++---------------
3 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..d53c95f4e1a9 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
#ifndef _ASM_ACPI_H
#define _ASM_ACPI_H
+#include <linux/efi.h>
#include <linux/memblock.h>
#include <linux/psci.h>
#include <asm/cputype.h>
+#include <asm/io.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -29,18 +31,22 @@
/* Basic configuration for ACPI */
#ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
/* ACPI table mapping after acpi_permanent_mmap is set */
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
+ /* For normal memory we already have a cacheable mapping. */
+ if (memblock_is_map_memory(phys))
+ return (void __iomem *)__phys_to_virt(phys);
+
/*
- * EFI's reserve_regions() call adds memory with the WB attribute
- * to memblock via early_init_dt_add_memory_arch().
+ * We should still honor the memory's attribute here because
+ * crash dump kernel possibly excludes some ACPI (reclaim)
+ * regions from memblock list.
*/
- if (!memblock_is_memory(phys))
- return ioremap(phys, size);
-
- return ioremap_cache(phys, size);
+ return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
}
#define acpi_os_ioremap acpi_os_ioremap
@@ -125,7 +131,10 @@ static inline const char *acpi_get_enable_method(int cpu)
* for compatibility.
*/
#define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ return __acpi_get_mem_attribute(addr);
+}
#endif /* CONFIG_ACPI_APEI */
#ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..ed46dc188b22 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/cpumask.h>
+#include <linux/efi.h>
#include <linux/efi-bgrt.h>
#include <linux/init.h>
#include <linux/irq.h>
@@ -29,13 +30,9 @@
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
+#include <asm/pgtable.h>
#include <asm/smp_plat.h>
-#ifdef CONFIG_ACPI_APEI
-# include <linux/efi.h>
-# include <asm/pgtable.h>
-#endif
-
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -239,8 +236,7 @@ void __init acpi_boot_table_init(void)
}
}
-#ifdef CONFIG_ACPI_APEI
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
{
/*
* According to "Table 8 Map: EFI memory types to AArch64 memory
@@ -261,4 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
}
-#endif
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 5889cbea60b8..566ef0a9edb5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void)
* non-early mapping of the UEFI system table and virtual mappings for all
* EFI_MEMORY_RUNTIME regions.
*/
-static int __init arm_enable_runtime_services(void)
+void __init efi_enter_virtual_mode(void)
{
u64 mapsize;
if (!efi_enabled(EFI_BOOT)) {
pr_info("EFI services will not be available.\n");
- return 0;
+ return;
+ }
+
+ mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
+
+ if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
+ pr_err("Failed to remap EFI memory map\n");
+ return;
}
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
- return 0;
+ return;
}
if (efi_enabled(EFI_RUNTIME_SERVICES)) {
pr_info("EFI runtime services access via paravirt.\n");
- return 0;
+ return;
}
pr_info("Remapping and enabling EFI services.\n");
- mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
-
- if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
- pr_err("Failed to remap EFI memory map\n");
- return -ENOMEM;
- }
-
if (!efi_virtmap_init()) {
pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
- return -ENOMEM;
+ return;
}
/* Set up runtime services function pointers */
efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
-
- return 0;
}
-early_initcall(arm_enable_runtime_services);
void efi_virtmap_load(void)
{
--
2.17.0
^ permalink raw reply related
* [PATCH 3/3] init: map UEFI memory map early if on arm or arm64
From: AKASHI Takahiro @ 2018-06-15 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075623.13454-1-takahiro.akashi@linaro.org>
As ACPI tables may not always be properly aligned, those regions should
be mapped cacheable in order to allow the kernel safe access to them.
UEFI memory map contains necessary information for mappings, and we want
to make sure that it should get accessible before any acpi_os_ioremap()'s.
So, in this patch, efi_enter_virtual_mode(), which was previously named
efi_enable_runtime_services() and invoked via early_initcall on arm/arm64,
is now moved early enough as the first access will occur in
acpi_load_tables() of acpi_early_init().
See a relevant commit:
arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
init/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/init/main.c b/init/main.c
index 3b4ada11ed52..532fc0d02353 100644
--- a/init/main.c
+++ b/init/main.c
@@ -694,6 +694,9 @@ asmlinkage __visible void __init start_kernel(void)
debug_objects_mem_init();
setup_per_cpu_pageset();
numa_policy_init();
+ if (IS_ENABLED(CONFIG_EFI) &&
+ (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)))
+ efi_enter_virtual_mode();
acpi_early_init();
if (late_time_init)
late_time_init();
--
2.17.0
^ permalink raw reply related
* [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Maxime Ripard @ 2018-06-15 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614193659.29261-1-clabbe.montjoie@gmail.com>
On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> ending boot.
> This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> Since the crypto hardware is not implemented, all registers are read as 0.
> So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
>
> The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> more complex and prevent a case that never happen on real hardware.
>
> The best way to fix is to check at probe time if we run on a virtual
> machine with hardware emulated but non-implemented and prevent
> sun4i-ss to be loaded in that case.
> Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> disabled since they will fail crypto selftests.
>
> Tested-on: qemu-cubieboard
> Tested-on: cubieboard2
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> index a81d89b3b7d8..a178e80adcf3 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> * I expect to be a sort of Security System Revision number.
> * Since the A80 seems to have an other version of SS
> * this info could be useful
> + * Detect virtual machine with non-implemented hardware
> + * (qemu-cubieboard) by checking the register value after a write to it.
> + * On non-implemented hardware, all registers are read as 0.
> + * On real hardware we should have a value > 0.
> */
> writel(SS_ENABLED, ss->base + SS_CTL);
> v = readl(ss->base + SS_CTL);
> + if (!v) {
> + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> + err = -ENODEV;
> + goto error_rst;
> + }
This is wrong way to tackle the issue. There's multiple reason why
this could happen (for example the device not being clocked, or
maintained in reset). There's nothing specific about qemu here, and
the fundamental issue isn't that the device isn't functional in qemu,
it's that qemu lies about which hardware it can emulate in the DT it
passes to the kernel.
There's no way this can scale, alone from the fact that qemu should
patch the DT according to what it can do. Not trying to chase after
each and every device that is broken in qemu.
NAK.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/52b1b32c/attachment.sig>
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-15 8:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
Droid 4 has non-removable battery, yet the charge counter is reset to
near zero on each boot of linux.
Unfortunately, that makes charge counter pretty much useless on d4, as
the "battery full" and "battery empty" limits will be different during
each boot.
Is it possible that we reset the cpcap needlessly, or something like
that?
unicsy_demo (github.com:pavelmachek/unicsy_demo.git) was updated to
read the charge counter, and attempt to estimate battery percentages
from that. Use monitor/batmond... warning -- it provides a _lot_ of
information.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/57bfea84/attachment.sig>
^ permalink raw reply
* [RFC] cpcap: allow modifying voltages and currents
From: Pavel Machek @ 2018-06-15 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
This allows user to disable the green LED, so that it can be used for
other notifications. It also allows him to set lower voltage limits,
and adjust current: lower current and voltage limits will result in
longer battery lifetime.
Currently I'm using
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
attributes to control it. Do we have something suitable for LED
control? Are the current/voltage limits ok to use?
Best regards,
Pavel
diff --git a/drivers/power/supply/cpcap-battery.c b/drivers/power/supply/cpcap-battery.c
index 98ba078..839e365 100644
--- a/drivers/power/supply/cpcap-battery.c
+++ b/drivers/power/supply/cpcap-battery.c
@@ -3,7 +3,7 @@
*
* Copyright (C) 2017 Tony Lindgren <tony@atomide.com>
*
- * Some parts of the code based on earlie Motorola mapphone Linux kernel
+ * Some parts of the code based on earlier Motorola mapphone Linux kernel
* drivers:
*
* Copyright (C) 2009-2010 Motorola, Inc.
diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c
index e4905be..7de07ae 100644
--- a/drivers/power/supply/cpcap-charger.c
+++ b/drivers/power/supply/cpcap-charger.c
@@ -93,6 +93,17 @@
#define CPCAP_REG_CRM_VCHRG_4V42 CPCAP_REG_CRM_VCHRG(0xe)
#define CPCAP_REG_CRM_VCHRG_4V44 CPCAP_REG_CRM_VCHRG(0xf)
+static int voltage_to_register(int microvolt)
+{
+ switch (microvolt/1000) {
+ case 3800: return CPCAP_REG_CRM_VCHRG_3V80;
+ case 4100: return CPCAP_REG_CRM_VCHRG_4V10;
+ case 4200: return CPCAP_REG_CRM_VCHRG_4V20;
+ case 4350: return CPCAP_REG_CRM_VCHRG_4V35;
+ default: return -EINVAL;
+ }
+}
+
/*
* CPCAP_REG_CRM charge currents. These seem to match MC13783UG.pdf
* values in "Table 8-3. Charge Path Regulator Current Limit
@@ -116,6 +127,18 @@
#define CPCAP_REG_CRM_ICHRG_1A596 CPCAP_REG_CRM_ICHRG(0xe)
#define CPCAP_REG_CRM_ICHRG_NO_LIMIT CPCAP_REG_CRM_ICHRG(0xf)
+static int current_to_register(int microamp)
+{
+ switch (microamp/1000) {
+ case 0: return CPCAP_REG_CRM_ICHRG_0A000;
+ case 70: return CPCAP_REG_CRM_ICHRG_0A070;
+ case 177: return CPCAP_REG_CRM_ICHRG_0A177;
+ case 532: return CPCAP_REG_CRM_ICHRG_0A532;
+ case 1596: return CPCAP_REG_CRM_ICHRG_1A596;
+ default: return -EINVAL;
+ }
+}
+
enum {
CPCAP_CHARGER_IIO_BATTDET,
CPCAP_CHARGER_IIO_VOLTAGE,
@@ -142,6 +165,10 @@ struct cpcap_charger_ddata {
atomic_t active;
int status;
+
+ int led_enabled;
+ int limit_current;
+ int limit_voltage;
};
struct cpcap_interrupt_desc {
@@ -163,11 +190,17 @@ struct cpcap_charger_ints_state {
bool battdetb;
};
+#define POWER_SUPPLY_PROP_INDICATION POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT
+
static enum power_supply_property cpcap_charger_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_CURRENT_NOW,
+
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+ POWER_SUPPLY_PROP_INDICATION,
};
static bool cpcap_charger_battery_found(struct cpcap_charger_ddata *ddata)
@@ -229,6 +262,7 @@ static int cpcap_charger_get_property(struct power_supply *psy,
val->intval = ddata->status;
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* FIXME? Display voltage even when not charging? */
if (ddata->status == POWER_SUPPLY_STATUS_CHARGING)
val->intval = cpcap_charger_get_charge_voltage(ddata) *
1000;
@@ -245,6 +279,50 @@ static int cpcap_charger_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_ONLINE:
val->intval = ddata->status == POWER_SUPPLY_STATUS_CHARGING;
break;
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ // -> charger -- current limit
+ val->intval = ddata->limit_current;
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ val->intval = ddata->limit_voltage;
+ break;
+ case POWER_SUPPLY_PROP_INDICATION:
+ val->intval = ddata->led_enabled;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int cpcap_charger_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct cpcap_charger_ddata *ddata = dev_get_drvdata(psy->dev.parent);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ printk("charge current: %d\n", val->intval);
+ if (current_to_register(val->intval) < 0)
+ return -EINVAL;
+ ddata->limit_current = val->intval;
+ schedule_delayed_work(&ddata->detect_work, 0);
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ printk("charge voltage: %d\n", val->intval);
+ if (voltage_to_register(val->intval) < 0)
+ return -EINVAL;
+ ddata->limit_voltage = val->intval;
+ schedule_delayed_work(&ddata->detect_work, 0);
+ break;
+ case POWER_SUPPLY_PROP_INDICATION:
+ printk("hack indication: %d\n", val->intval);
+ ddata->led_enabled = !!val->intval;
+ schedule_delayed_work(&ddata->detect_work, 0);
+ break;
default:
return -EINVAL;
}
@@ -296,7 +374,7 @@ static int cpcap_charger_set_state(struct cpcap_charger_ddata *ddata,
}
error = regmap_update_bits(ddata->reg, CPCAP_REG_CRM, 0x3fff,
- CPCAP_REG_CRM_CHRG_LED_EN |
+ ddata->led_enabled * CPCAP_REG_CRM_CHRG_LED_EN |
trickle_current |
CPCAP_REG_CRM_FET_OVRD |
CPCAP_REG_CRM_FET_CTRL |
@@ -440,16 +518,38 @@ static void cpcap_usb_detect(struct work_struct *work)
return;
if (cpcap_charger_vbus_valid(ddata) && s.chrgcurr1) {
- int max_current;
+ int m_voltage, m_current;
+ int reg_current, reg_voltage;
if (cpcap_charger_battery_found(ddata))
- max_current = CPCAP_REG_CRM_ICHRG_1A596;
+ m_current = 1596000;
else
- max_current = CPCAP_REG_CRM_ICHRG_0A532;
+ m_current = 532000;
+
+ if (m_current > ddata->limit_current)
+ m_current = ddata->limit_current;
+
+ m_voltage = 4350000;
+ if (m_voltage > ddata->limit_voltage)
+ m_voltage = ddata->limit_voltage;
+
+ printk("Charging, %d uV, %d uA\n", m_voltage, m_current);
+
+ reg_voltage = voltage_to_register(m_voltage);
+ if (reg_voltage < 0) {
+ dev_err(ddata->dev, "%s impossible voltage\n", __func__);
+ return;
+ }
+
+ reg_current = current_to_register(m_current);
+ if (reg_current < 0) {
+ dev_err(ddata->dev, "%s impossible current\n", __func__);
+ return;
+ }
error = cpcap_charger_set_state(ddata,
- CPCAP_REG_CRM_VCHRG_4V35,
- max_current, 0);
+ reg_voltage,
+ reg_current, 0);
if (error)
goto out_err;
} else {
@@ -579,12 +679,27 @@ static int cpcap_charger_init_iio(struct cpcap_charger_ddata *ddata)
return error;
}
+static int cpcap_charger_property_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ case POWER_SUPPLY_PROP_INDICATION:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
static const struct power_supply_desc cpcap_charger_usb_desc = {
.name = "usb",
.type = POWER_SUPPLY_TYPE_USB,
.properties = cpcap_charger_props,
.num_properties = ARRAY_SIZE(cpcap_charger_props),
.get_property = cpcap_charger_get_property,
+ .set_property = cpcap_charger_set_property,
+ .property_is_writeable = cpcap_charger_property_is_writeable,
};
#ifdef CONFIG_OF
@@ -619,6 +734,10 @@ static int cpcap_charger_probe(struct platform_device *pdev)
if (!ddata->reg)
return -ENODEV;
+ ddata->limit_current = 1596000;
+ ddata->limit_voltage = 4350000;
+ ddata->led_enabled = 1;
+
INIT_LIST_HEAD(&ddata->irq_list);
INIT_DELAYED_WORK(&ddata->detect_work, cpcap_usb_detect);
INIT_DELAYED_WORK(&ddata->vbus_work, cpcap_charger_vbus_work);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/b6a49a75/attachment.sig>
^ permalink raw reply related
* [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Corentin Labbe @ 2018-06-15 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615075754.b3ivyagjsomiafwk@flea>
On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > ending boot.
> > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > Since the crypto hardware is not implemented, all registers are read as 0.
> > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> >
> > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > more complex and prevent a case that never happen on real hardware.
> >
> > The best way to fix is to check at probe time if we run on a virtual
> > machine with hardware emulated but non-implemented and prevent
> > sun4i-ss to be loaded in that case.
> > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > disabled since they will fail crypto selftests.
> >
> > Tested-on: qemu-cubieboard
> > Tested-on: cubieboard2
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index a81d89b3b7d8..a178e80adcf3 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > * I expect to be a sort of Security System Revision number.
> > * Since the A80 seems to have an other version of SS
> > * this info could be useful
> > + * Detect virtual machine with non-implemented hardware
> > + * (qemu-cubieboard) by checking the register value after a write to it.
> > + * On non-implemented hardware, all registers are read as 0.
> > + * On real hardware we should have a value > 0.
> > */
> > writel(SS_ENABLED, ss->base + SS_CTL);
> > v = readl(ss->base + SS_CTL);
> > + if (!v) {
> > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > + err = -ENODEV;
> > + goto error_rst;
> > + }
>
> This is wrong way to tackle the issue. There's multiple reason why
> this could happen (for example the device not being clocked, or
> maintained in reset). There's nothing specific about qemu here, and
> the fundamental issue isn't that the device isn't functional in qemu,
> it's that qemu lies about which hardware it can emulate in the DT it
> passes to the kernel.
>
> There's no way this can scale, alone from the fact that qemu should
> patch the DT according to what it can do. Not trying to chase after
> each and every device that is broken in qemu.
>
> NAK.
>
My fix detect also when the device is badly clocked.
So since it could fix problem unrelated to qemu, I will send a V2 with updated comment.
Regards
^ permalink raw reply
* [PATCH v2] mmc: sdhci-of-arasan: Add quirk for unstable clocks
From: Helmut Grohne @ 2018-06-15 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da0ebcb3-b19a-86a6-8462-87a1c0e81fff@intel.com>
Some controllers immediately report SDHCI_CLOCK_INT_STABLE after
enabling the clock even when the clock is not stable. When used in
conjunction with older/slower cards, this can result in:
mmc0: error -84 whilst initialising SD card
When the stable reporting is broken, we simply wait for the maximum
stabilization period.
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 2 ++
drivers/mmc/host/sdhci-of-arasan.c | 16 ++++++++++++++++
2 files changed, 18 insertions(+)
Changes since v1 (RFC):
* Use an arasan-specific quirk in the ->set_clock() callback as requested by
Adrian Hunter.
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 60481bfc3d31..c0e0f04a8504 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -39,6 +39,8 @@ Optional Properties:
- xlnx,fails-without-test-cd: when present, the controller doesn't work when
the CD line is not connected properly, and the line is not connected
properly. Test mode can be used to force the controller to function.
+ - xlnx,int-clock-stable-broken: when present, the controller always reports
+ that the internal clock is stable even when it is not.
Example:
sdhci at e0100000 {
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index c33a5f7393bd..f7fe26c75150 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -102,6 +102,9 @@ struct sdhci_arasan_data {
/* Controller does not have CD wired and will not function normally without */
#define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
+/* Controller immediately reports SDHCI_CLOCK_INT_STABLE after enabling the
+ * internal clock even when the clock isn't stable */
+#define SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE BIT(1)
};
static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
@@ -207,6 +210,16 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
sdhci_set_clock(host, clock);
+ if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE)
+ /*
+ * Some controllers immediately report SDHCI_CLOCK_INT_STABLE
+ * after enabling the clock even though the clock is not
+ * stable. Trying to use a clock without waiting here results
+ * in EILSEQ while detecting some older/slower cards. The
+ * chosen delay is the maximum delay from sdhci_set_clock.
+ */
+ msleep(20);
+
if (ctrl_phy) {
phy_power_on(sdhci_arasan->phy);
sdhci_arasan->is_phy_on = true;
@@ -759,6 +772,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
+ if (of_property_read_bool(np, "xlnx,int-clock-stable-broken"))
+ sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE;
+
pltfm_host->clk = clk_xin;
if (of_device_is_compatible(pdev->dev.of_node,
--
2.11.0
^ permalink raw reply related
* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
From: Maxime Ripard @ 2018-06-15 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-12-jernej.skrabec@siol.net>
Hi,
On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> TV TCONs connected to TCON TOP have to enable additional gate in order
> to work.
>
> Add support for such TCONs.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 08747fc3ee71..0afb5a94a414 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> dev_err(dev, "Couldn't get the TCON bus clock\n");
> return PTR_ERR(tcon->clk);
> }
> +
> + if (tcon->quirks->has_tcon_top_gate) {
> + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> + if (IS_ERR(tcon->top_clk)) {
> + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> + return PTR_ERR(tcon->top_clk);
> + }
> + clk_prepare_enable(tcon->top_clk);
> + }
> +
Is it required for the TCON itself to operate, or does the TCON
requires the TCON TOP, which in turn requires that clock to be
functional?
I find it quite odd to have a clock that isn't meant for a particular
device to actually be wired to another device. I'm not saying this
isn't the case, but it would be a first.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/d5a22b93/attachment.sig>
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-15 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615080014.GA29192@amd>
On Fri 2018-06-15 10:00:14, Pavel Machek wrote:
> Hi!
>
> Droid 4 has non-removable battery, yet the charge counter is reset to
> near zero on each boot of linux.
>
> Unfortunately, that makes charge counter pretty much useless on d4, as
> the "battery full" and "battery empty" limits will be different during
> each boot.
Hmm, and could we refrain from providing "power" values?
I was thinking great, we have hardware that does proper power
measuerement for us. No.... it is driver providing synthetic
values. As userland has enough information to do that itself, I
believe we should not do this in kernel.
diff --git a/drivers/power/supply/cpcap-battery.c b/drivers/power/supply/cpcap-battery.c
index 839e365..1610026 100644
--- a/drivers/power/supply/cpcap-battery.c
+++ b/drivers/power/supply/cpcap-battery.c
@@ -490,24 +490,6 @@ static int cpcap_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
val->intval = latest->counter_uah;
break;
- case POWER_SUPPLY_PROP_POWER_NOW:
- tmp = (latest->voltage / 10000) * latest->current_ua;
- val->intval = div64_s64(tmp, 100);
- break;
- case POWER_SUPPLY_PROP_POWER_AVG:
- if (cached) {
- tmp = cpcap_battery_cc_get_avg_current(ddata);
- tmp *= (latest->voltage / 10000);
- val->intval = div64_s64(tmp, 100);
- break;
- }
- sample = latest->cc.sample - previous->cc.sample;
- accumulator = latest->cc.accumulator - previous->cc.accumulator;
- tmp = cpcap_battery_cc_to_ua(ddata, sample, accumulator,
- latest->cc.offset);
- tmp *= ((latest->voltage + previous->voltage) / 20000);
- val->intval = div64_s64(tmp, 100);
- break;
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
if (cpcap_battery_full(ddata))
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/2ce5a36e/attachment.sig>
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
From: Maxime Ripard @ 2018-06-15 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2481282.yoIGH2ksVh@jernej-laptop>
On Wed, Jun 13, 2018 at 06:03:21PM +0200, Jernej ?krabec wrote:
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > + * allwinner,sun8i-r40-tcon-top
> > > + - reg: base address and size of the memory-mapped region.
> > > + - clocks: phandle to the clocks feeding the TCON TOP
> > > + * bus: TCON TOP interface clock
> > > + - clock-names: clock name mentioned above
> > > + - resets: phandle to the reset line driving the DRC
> >
> > s/DRC/TCON TOP/ ?
>
> Yes, copy & paste issue
>
> >
> > > + * rst: TCON TOP reset line
> >
> > Remaining consistent with the clock name would be great
>
> You mean "ahb"? I noticed that most other nodes with reset lines don't have a
> name associated. Maybe I could just drop it and use first specified reset?
It's called bus in the binding, but yes. And yeah, we can drop the
name as well.
> >
> > > + - reset-names: reset name mentioned above
> > > + - #clock-cells : must contain 1
> >
> > An example would be nice here
>
> You mean node example? with ports? In the past, Rob was against examples
> unless really necessary. Node from R40 DTSI can serve as an example.
Ok.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/6770fcf3/attachment.sig>
^ permalink raw reply
* [PATCH v3 16/27] docs: Fix more broken references
From: Matthias Brugger @ 2018-06-15 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1bf52a721005b2017434acc54ec5ddc152d6fe4.1528990947.git.mchehab+samsung@kernel.org>
On 14/06/18 18:09, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
for mt6397.txt:
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> .../devicetree/bindings/clock/st/st,clkgen.txt | 8 ++++----
> .../devicetree/bindings/clock/ti/gate.txt | 2 +-
> .../devicetree/bindings/clock/ti/interface.txt | 2 +-
> .../bindings/cpufreq/cpufreq-mediatek.txt | 2 +-
> .../devicetree/bindings/devfreq/rk3399_dmc.txt | 2 +-
> .../bindings/gpu/arm,mali-midgard.txt | 2 +-
> .../bindings/gpu/arm,mali-utgard.txt | 2 +-
> .../devicetree/bindings/mfd/mt6397.txt | 2 +-
> .../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
> .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 +-
> .../devicetree/bindings/net/dsa/ksz.txt | 2 +-
> .../devicetree/bindings/net/dsa/mt7530.txt | 2 +-
> .../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +-
> .../bindings/power/wakeup-source.txt | 2 +-
> .../devicetree/bindings/usb/rockchip,dwc3.txt | 2 +-
> Documentation/hwmon/ina2xx | 2 +-
> Documentation/maintainer/pull-requests.rst | 2 +-
> Documentation/translations/ko_KR/howto.rst | 2 +-
> MAINTAINERS | 18 +++++++++---------
> drivers/net/ethernet/intel/Kconfig | 8 ++++----
> drivers/soundwire/stream.c | 8 ++++----
> fs/Kconfig.binfmt | 2 +-
> fs/binfmt_misc.c | 2 +-
> 23 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> index 7364953d0d0b..45ac19bfa0a9 100644
> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
> @@ -31,10 +31,10 @@ This binding uses the common clock binding[1].
> Each subnode should use the binding described in [2]..[7]
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt
> -[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt
> -[7] Documentation/devicetree/bindings/clock/st,quadfs.txt
> -[8] Documentation/devicetree/bindings/clock/st,flexgen.txt
> +[3] Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
> +[4] Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
> +[7] Documentation/devicetree/bindings/clock/st/st,quadfs.txt
> +[8] Documentation/devicetree/bindings/clock/st/st,flexgen.txt
>
>
> Required properties:
> diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt
> index 03f8fdee62a7..56d603c1f716 100644
> --- a/Documentation/devicetree/bindings/clock/ti/gate.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
> @@ -10,7 +10,7 @@ will be controlled instead and the corresponding hw-ops for
> that is used.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/clock/gate-clock.txt
> +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
> [3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
>
> Required properties:
> diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt
> index 3111a409fea6..3f4704040140 100644
> --- a/Documentation/devicetree/bindings/clock/ti/interface.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt
> @@ -9,7 +9,7 @@ companion clock finding (match corresponding functional gate
> clock) and hardware autoidle enable / disable.
>
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/clock/gate-clock.txt
> +[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
>
> Required properties:
> - compatible : shall be one of:
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> index d36f07e0a2bb..0551c78619de 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> @@ -8,7 +8,7 @@ Required properties:
> "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
> source (usually MAINPLL) when the original CPU PLL is under
> transition and not stable yet.
> - Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
> + Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
> generic clock consumer properties.
> - operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
> for detail.
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> index d6d2833482c9..fc2bcbe26b1e 100644
> --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -12,7 +12,7 @@ Required properties:
> - clocks: Phandles for clock specified in "clock-names" property
> - clock-names : The name of clock used by the DFI, must be
> "pclk_ddr_mon";
> -- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
> +- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
> for details.
> - center-supply: DMC supply node.
> - status: Marks the node enabled/disabled.
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> index 039219df05c5..18a2cde2e5f3 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -34,7 +34,7 @@ Optional properties:
> - mali-supply : Phandle to regulator for the Mali device. Refer to
> Documentation/devicetree/bindings/regulator/regulator.txt for details.
>
> -- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
> +- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
> for details.
>
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> index c1f65d1dac1d..63cd91176a68 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -44,7 +44,7 @@ Optional properties:
>
> - memory-region:
> Memory region to allocate from, as defined in
> - Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> - mali-supply:
> Phandle to regulator for the Mali device, as defined in
> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index d1df77f4d655..0ebd08af777d 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -12,7 +12,7 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
> It is interfaced to host controller using SPI interface by a proprietary hardware
> called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
> See the following for pwarp node definitions:
> -Documentation/devicetree/bindings/soc/pwrap.txt
> +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
>
> This document describes the binding for MFD device and its sub module.
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> index dd2c06540485..4d21ffdb0fc1 100644
> --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> @@ -9,7 +9,7 @@ Required properties:
>
> The prcm node may contain several subdevices definitions:
> - see Documentation/devicetree/clk/sunxi.txt for clock devices
> - - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset
> + - see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
> controller devices
>
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index a58c173b7ab9..0419a63f73a0 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -62,7 +62,7 @@ Required properties for a slot (Deprecated - Recommend to use one slot per host)
> rest of the gpios (depending on the bus-width property) are the data lines in
> no particular order. The format of the gpio specifier depends on the gpio
> controller.
> -(Deprecated - Refer to Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
> +(Deprecated - Refer to Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt)
>
> Example:
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> index fd23904ac68e..a700943218ca 100644
> --- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/ksz.txt
> @@ -6,7 +6,7 @@ Required properties:
> - compatible: For external switch chips, compatible string must be exactly one
> of: "microchip,ksz9477"
>
> -See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
> +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required and optional properties.
>
> Examples:
> diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> index a9bc27b93ee3..aa3527f71fdc 100644
> --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> @@ -31,7 +31,7 @@ Required properties for the child nodes within ports container:
> - phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
> "cpu".
>
> -See Documentation/devicetree/bindings/dsa/dsa.txt for a list of additional
> +See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required, optional properties and how the integrated switch subnodes must
> be specified.
>
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> index b31d6bbeee16..726ec2875223 100644
> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> @@ -14,7 +14,7 @@ Required properties:
> datasheet
> - interrupts: Should contain one interrupt specifier for the GPC interrupt
> - clocks: Must contain an entry for each entry in clock-names.
> - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
> + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> - clock-names: Must include the following entries:
> - ipg
>
> diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt
> index 5d254ab13ebf..cfd74659fbed 100644
> --- a/Documentation/devicetree/bindings/power/wakeup-source.txt
> +++ b/Documentation/devicetree/bindings/power/wakeup-source.txt
> @@ -22,7 +22,7 @@ List of legacy properties and respective binding document
> 3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt
> 4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
> Documentation/devicetree/bindings/mfd/tc3589x.txt
> - Documentation/devicetree/bindings/input/ads7846.txt
> + Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> 5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
> 6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt
> 7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
> diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> index 50a31536e975..252a05c5d976 100644
> --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> @@ -16,7 +16,7 @@ A child node must exist to represent the core DWC3 IP block. The name of
> the node is not important. The content of the node is defined in dwc3.txt.
>
> Phy documentation is provided in the following places:
> -Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
> +Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
>
> Example device nodes:
>
> diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
> index cfd31d94c872..72d16f08e431 100644
> --- a/Documentation/hwmon/ina2xx
> +++ b/Documentation/hwmon/ina2xx
> @@ -53,7 +53,7 @@ bus supply voltage.
>
> The shunt value in micro-ohms can be set via platform data or device tree at
> compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
> -refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
> +refer to the Documentation/devicetree/bindings/hwmon/ina2xx.txt for bindings
> if the device tree is used.
>
> Additionally ina226 supports update_interval attribute as described in
> diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst
> index a19db3458b56..22b271de0304 100644
> --- a/Documentation/maintainer/pull-requests.rst
> +++ b/Documentation/maintainer/pull-requests.rst
> @@ -41,7 +41,7 @@ named ``char-misc-next``, you would be using the following command::
>
> that will create a signed tag called ``char-misc-4.15-rc1`` based on the
> last commit in the ``char-misc-next`` branch, and sign it with your gpg key
> -(see :ref:`Documentation/maintainer/configure_git.rst <configuregit>`).
> +(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`).
>
> Linus will only accept pull requests based on a signed tag. Other
> maintainers may differ.
> diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
> index 624654bdcd8a..a8197e072599 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -160,7 +160,7 @@ mtk.manpages at gmail.com? ??????? ?? ?? ????.
> ??? ??? ??? ?? ?? ???? ???? ???? ??
> ????.
>
> - :ref:`Documentation/process/stable_kernel_rules.rst <stable_kernel_rules>`
> + :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
> ? ??? ???? ?? ??? ????? ??? ???? ???
> ????? ??? ??? ? ??? ??? ?? ????
> ??? ?? ???? ????.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ec65e33e2cf1..5871dd5060f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4513,7 +4513,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/ili9225.c
> -F: Documentation/devicetree/bindings/display/ili9225.txt
> +F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
>
> DRM DRIVER FOR INTEL I810 VIDEO CARDS
> S: Orphan / Obsolete
> @@ -4599,13 +4599,13 @@ DRM DRIVER FOR SITRONIX ST7586 PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/st7586.c
> -F: Documentation/devicetree/bindings/display/st7586.txt
> +F: Documentation/devicetree/bindings/display/sitronix,st7586.txt
>
> DRM DRIVER FOR SITRONIX ST7735R PANELS
> M: David Lechner <david@lechnology.com>
> S: Maintained
> F: drivers/gpu/drm/tinydrm/st7735r.c
> -F: Documentation/devicetree/bindings/display/st7735r.txt
> +F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt
>
> DRM DRIVER FOR TDFX VIDEO CARDS
> S: Orphan / Obsolete
> @@ -4824,7 +4824,7 @@ M: Eric Anholt <eric@anholt.net>
> S: Supported
> F: drivers/gpu/drm/v3d/
> F: include/uapi/drm/v3d_drm.h
> -F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
> +F: Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
> T: git git://anongit.freedesktop.org/drm/drm-misc
>
> DRM DRIVERS FOR VC4
> @@ -5735,7 +5735,7 @@ M: Madalin Bucur <madalin.bucur@nxp.com>
> L: netdev at vger.kernel.org
> S: Maintained
> F: drivers/net/ethernet/freescale/fman
> -F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +F: Documentation/devicetree/bindings/net/fsl-fman.txt
>
> FREESCALE QORIQ PTP CLOCK DRIVER
> M: Yangbo Lu <yangbo.lu@nxp.com>
> @@ -8700,7 +8700,7 @@ M: Guenter Roeck <linux@roeck-us.net>
> L: linux-hwmon at vger.kernel.org
> S: Maintained
> F: Documentation/hwmon/max6697
> -F: Documentation/devicetree/bindings/i2c/max6697.txt
> +F: Documentation/devicetree/bindings/hwmon/max6697.txt
> F: drivers/hwmon/max6697.c
> F: include/linux/platform_data/max6697.h
>
> @@ -9080,7 +9080,7 @@ M: Martin Donnelly <martin.donnelly@ge.com>
> M: Martyn Welch <martyn.welch@collabora.co.uk>
> S: Maintained
> F: drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c
> -F: Documentation/devicetree/bindings/video/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
> +F: Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
>
> MEGARAID SCSI/SAS DRIVERS
> M: Kashyap Desai <kashyap.desai@broadcom.com>
> @@ -10728,7 +10728,7 @@ PARALLEL LCD/KEYPAD PANEL DRIVER
> M: Willy Tarreau <willy@haproxy.com>
> M: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
> S: Odd Fixes
> -F: Documentation/misc-devices/lcd-panel-cgram.txt
> +F: Documentation/auxdisplay/lcd-panel-cgram.txt
> F: drivers/misc/panel.c
>
> PARALLEL PORT SUBSYSTEM
> @@ -13291,7 +13291,7 @@ M: Vinod Koul <vkoul@kernel.org>
> L: alsa-devel at alsa-project.org (moderated for non-subscribers)
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> S: Supported
> -F: Documentation/sound/alsa/compress_offload.txt
> +F: Documentation/sound/designs/compress-offload.rst
> F: include/sound/compress_driver.h
> F: include/uapi/sound/compress_*
> F: sound/core/compress_offload.c
> diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
> index 14d287bed33c..1ab613eb5796 100644
> --- a/drivers/net/ethernet/intel/Kconfig
> +++ b/drivers/net/ethernet/intel/Kconfig
> @@ -33,7 +33,7 @@ config E100
> to identify the adapter.
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e100.txt>.
> + <file:Documentation/networking/e100.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called e100.
> @@ -49,7 +49,7 @@ config E1000
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called e1000.
> @@ -94,7 +94,7 @@ config IGB
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called igb.
> @@ -130,7 +130,7 @@ config IGBVF
> <http://support.intel.com>
>
> More specific information on configuring the driver is in
> - <file:Documentation/networking/e1000.txt>.
> + <file:Documentation/networking/e1000.rst>.
>
> To compile this driver as a module, choose M here. The module
> will be called igbvf.
> diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
> index 8974a0fcda1b..4b5e250e8615 100644
> --- a/drivers/soundwire/stream.c
> +++ b/drivers/soundwire/stream.c
> @@ -1291,7 +1291,7 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_prepare_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1348,7 +1348,7 @@ static int _sdw_enable_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_enable_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1400,7 +1400,7 @@ static int _sdw_disable_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_disable_stream(struct sdw_stream_runtime *stream)
> {
> @@ -1456,7 +1456,7 @@ static int _sdw_deprepare_stream(struct sdw_stream_runtime *stream)
> *
> * @stream: Soundwire stream
> *
> - * Documentation/soundwire/stream.txt explains this API in detail
> + * Documentation/driver-api/soundwire/stream.rst explains this API in detail
> */
> int sdw_deprepare_stream(struct sdw_stream_runtime *stream)
> {
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index 57a27c42b5ac..56df483de619 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -168,7 +168,7 @@ config BINFMT_MISC
> will automatically feed it to the correct interpreter.
>
> You can do other nice things, too. Read the file
> - <file:Documentation/binfmt_misc.txt> to learn how to use this
> + <file:Documentation/admin-guide/binfmt-misc.rst> to learn how to use this
> feature, <file:Documentation/admin-guide/java.rst> for information about how
> to include Java support. and <file:Documentation/admin-guide/mono.rst> for
> information about how to include Mono-based .NET support.
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index 4de191563261..4b5fff31ef27 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -4,7 +4,7 @@
> * Copyright (C) 1997 Richard G?nther
> *
> * binfmt_misc detects binaries via a magic or filename extension and invokes
> - * a specified wrapper. See Documentation/binfmt_misc.txt for more details.
> + * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more details.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Riku Voipio @ 2018-06-15 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51d3d738-cdf5-2992-bba5-c3e1f34096c2@infradead.org>
On Wed, 13 Jun 2018 at 21:22, Geoff Levand <geoff@infradead.org> wrote:
>
> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> a work-around for HPE ProLiant m400 APEI firmware problems.
>
> The work-around disables APEI when CONFIG_ACPI_APEI is set and
> m400 firmware is detected. Without this fixup m400 systems
> experience errors like these on startup:
>
> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> [Hardware Error]: event severity: fatal
> [Hardware Error]: Error 0, type: fatal
> [Hardware Error]: section_type: memory error
> [Hardware Error]: error_status: 0x0000000000001300
> [Hardware Error]: error_type: 10, invalid address
> Kernel panic - not syncing: Fatal hardware error!
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> Hi,
>
> It seems unlikely there will be any m400 firmware updates to fix
> this problem. APEI support is desired for new ARM64 servers coming
> to market. Distros are now forced to have their own fixes, not
> enable APEI, or let m400 users fend for themselves.
Thanks for working on this. This patch works well on m400 with APEI enabled.
Tested-by: Riku Voipio <riku.voipio@linaro.org>
> -Geoff
>
> arch/arm64/kernel/acpi.c | 40 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 7b09487ff8fb..3c315c2c7476 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -31,6 +31,8 @@
> #include <asm/cpu_ops.h>
> #include <asm/smp_plat.h>
>
> +#include <acpi/apei.h>
> +
> #ifdef CONFIG_ACPI_APEI
> # include <linux/efi.h>
> # include <asm/pgtable.h>
> @@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
> + * problems.
> + */
> +static void __init acpi_fixup_m400_quirks(void)
> +{
> + acpi_status status;
> + struct acpi_table_header *header;
> +#if !defined(CONFIG_ACPI_APEI)
> + int hest_disable = HEST_DISABLED;
> +#endif
> +
> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> + return;
> +
> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> +
> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> + hest_disable = HEST_DISABLED;
> + pr_info("Disabled APEI for m400.\n");
> + }
> +
> + acpi_put_table(header);
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -232,11 +261,14 @@ void __init acpi_boot_table_init(void)
> if (acpi_disabled) {
> if (earlycon_acpi_spcr_enable)
> early_init_dt_scan_chosen_stdout();
> - } else {
> - acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> - if (IS_ENABLED(CONFIG_ACPI_BGRT))
> - acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> + return;
> }
> +
> + acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
> + if (IS_ENABLED(CONFIG_ACPI_BGRT))
> + acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> +
> + acpi_fixup_m400_quirks();
> }
>
> #ifdef CONFIG_ACPI_APEI
> --
> 2.14.1
>
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Alex Bennée @ 2018-06-15 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528976546-25999-4-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> This patch ensures this my delaying restoration of current's
> TIF_SVE until after the call to fpsimd_save().
this *by* delaying
--
Alex Benn?e
^ permalink raw reply
* [PATCH v3 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Hans Verkuil @ 2018-06-15 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614074652.162796-2-keiichiw@chromium.org>
On 14/06/18 09:46, Keiichi Watanabe wrote:
> Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and
> make V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control
> is used to select a desired profile for VP8 encoder, and query for
> supported profiles by VP8 encoder/decoder.
>
> Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
> contains 'VPX', it works only for VP8 because supported profiles usually differ
> between VP8 and VP9. In addition, this contorol cannot be used for querying
typo: contorol -> control
> since it is not a menu control but an integer control, which cannot return an
> arbitrary set of supported profiles.
>
> The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
> controls for other codec profiles. (e.g. H264)
>
> In addition, this patch also fixes the use of
> V4L2_CID_MPEG_VIDEO_VPX_PROFILE in drivers of Qualcomm's venus and
> Samsung's s5p-mfc.
>
> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> ---
> .../media/uapi/v4l/extended-controls.rst | 27 ++++++++++++++++---
> drivers/media/platform/qcom/venus/core.h | 2 +-
> .../media/platform/qcom/venus/hfi_helper.h | 12 ++++-----
> .../media/platform/qcom/venus/vdec_ctrls.c | 10 ++++---
> drivers/media/platform/qcom/venus/venc.c | 14 +++++-----
> .../media/platform/qcom/venus/venc_ctrls.c | 12 +++++----
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++++------
> drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
> include/uapi/linux/v4l2-controls.h | 11 +++++++-
> 9 files changed, 79 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index 03931f9b1285..de99eafb0872 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1955,9 +1955,30 @@ enum v4l2_vp8_golden_frame_sel -
> ``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
> Quantization parameter for a P frame for VP8.
>
> -``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
> - Select the desired profile for VPx encoder. Acceptable values are 0,
> - 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> +.. _v4l2-mpeg-video-vp8-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
> + (enum)
> +
> +enum v4l2_mpeg_video_vp8_profile -
> + This control allows to select the profile for VP8 encoder.
> + This is also used to enumerate supported profiles by VP8 encoder or decoder.
> + Possible values are:
> +
> +
> +
One empty line is enough.
> +.. flat-table::
> + :header-rows: 0
> + :stub-columns: 0
> +
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
> + - Profile 0
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
> + - Profile 1
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
> + - Profile 2
> + * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
> + - Profile 3
>
>
> High Efficiency Video Coding (HEVC/H.265) Control Reference
> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> index 0360d295f4c8..f242e7f9f6a2 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -159,7 +159,7 @@ struct venc_controls {
> struct {
> u32 mpeg4;
> u32 h264;
> - u32 vpx;
> + u32 vp8;
> } profile;
> struct {
> u32 mpeg4;
> diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
> index 55d8eb21403a..07bf49dd2ec6 100644
> --- a/drivers/media/platform/qcom/venus/hfi_helper.h
> +++ b/drivers/media/platform/qcom/venus/hfi_helper.h
> @@ -333,12 +333,12 @@
> #define HFI_VC1_LEVEL_3 0x00000040
> #define HFI_VC1_LEVEL_4 0x00000080
>
> -#define HFI_VPX_PROFILE_SIMPLE 0x00000001
> -#define HFI_VPX_PROFILE_ADVANCED 0x00000002
> -#define HFI_VPX_PROFILE_VERSION_0 0x00000004
> -#define HFI_VPX_PROFILE_VERSION_1 0x00000008
> -#define HFI_VPX_PROFILE_VERSION_2 0x00000010
> -#define HFI_VPX_PROFILE_VERSION_3 0x00000020
> +#define HFI_VP8_PROFILE_SIMPLE 0x00000001
> +#define HFI_VP8_PROFILE_ADVANCED 0x00000002
> +#define HFI_VP8_PROFILE_VERSION_0 0x00000004
> +#define HFI_VP8_PROFILE_VERSION_1 0x00000008
> +#define HFI_VP8_PROFILE_VERSION_2 0x00000010
> +#define HFI_VP8_PROFILE_VERSION_3 0x00000020
>
> #define HFI_DIVX_FORMAT_4 0x1
> #define HFI_DIVX_FORMAT_5 0x2
> diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> index 032839bbc967..f4604b0cd57e 100644
> --- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> @@ -29,7 +29,7 @@ static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
> break;
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> ctr->profile = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
> @@ -54,7 +54,7 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> switch (ctrl->id) {
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> ret = hfi_session_get_property(inst, ptype, &hprop);
> if (!ret)
> ctr->profile = hprop.profile_level.profile;
> @@ -130,8 +130,10 @@ int vdec_ctrl_init(struct venus_inst *inst)
> if (ctrl)
> ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
>
> - ctrl = v4l2_ctrl_new_std(&inst->ctrl_handler, &vdec_ctrl_ops,
> - V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
> + ctrl = v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &vdec_ctrl_ops,
> + V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
> if (ctrl)
> ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
>
> diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
> index 6b2ce479584e..aa54dd005c3e 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -223,17 +223,17 @@ static int venc_v4l2_to_hfi(int id, int value)
> case V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC:
> return HFI_H264_ENTROPY_CABAC;
> }
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> switch (value) {
> case 0:
> default:
> - return HFI_VPX_PROFILE_VERSION_0;
> + return HFI_VP8_PROFILE_VERSION_0;
> case 1:
> - return HFI_VPX_PROFILE_VERSION_1;
> + return HFI_VP8_PROFILE_VERSION_1;
> case 2:
> - return HFI_VPX_PROFILE_VERSION_2;
> + return HFI_VP8_PROFILE_VERSION_2;
> case 3:
> - return HFI_VPX_PROFILE_VERSION_3;
> + return HFI_VP8_PROFILE_VERSION_3;
> }
> case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
> switch (value) {
> @@ -756,8 +756,8 @@ static int venc_set_properties(struct venus_inst *inst)
> level = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> ctr->level.h264);
> } else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_VP8) {
> - profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> - ctr->profile.vpx);
> + profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + ctr->profile.vp8);
> level = 0;
> } else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_MPEG4) {
> profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE,
> diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c
> index 21e938a28662..e5162b78609d 100644
> --- a/drivers/media/platform/qcom/venus/venc_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
> @@ -101,8 +101,8 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
> ctr->profile.h264 = ctrl->val;
> break;
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> - ctr->profile.vpx = ctrl->val;
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> + ctr->profile.vp8 = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
> ctr->level.mpeg4 = ctrl->val;
> @@ -248,6 +248,11 @@ int venc_ctrl_init(struct venus_inst *inst)
> V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES,
> 0, V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
>
> + v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
> + V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
> +
> v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> V4L2_CID_MPEG_VIDEO_BITRATE, BITRATE_MIN, BITRATE_MAX,
> BITRATE_STEP, BITRATE_DEFAULT);
> @@ -256,9 +261,6 @@ int venc_ctrl_init(struct venus_inst *inst)
> V4L2_CID_MPEG_VIDEO_BITRATE_PEAK, BITRATE_MIN, BITRATE_MAX,
> BITRATE_STEP, BITRATE_DEFAULT_PEAK);
>
> - v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> - V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
> -
> v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
> V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP, 1, 51, 1, 26);
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 570f391f2cfd..3ad4f5073002 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -692,12 +692,12 @@ static struct mfc_control controls[] = {
> .default_value = 10,
> },
> {
> - .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
> - .type = V4L2_CTRL_TYPE_INTEGER,
> - .minimum = 0,
> - .maximum = 3,
> - .step = 1,
> - .default_value = 0,
> + .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
> + .type = V4L2_CTRL_TYPE_MENU,
> + .minimum = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
> + .maximum = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
> + .default_value = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
> + .menu_skip_mask = 0,
> },
> {
> .id = V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP,
> @@ -2057,7 +2057,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
> p->codec.vp8.rc_p_frame_qp = ctrl->val;
> break;
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> p->codec.vp8.profile = ctrl->val;
> break;
> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
> @@ -2711,4 +2711,3 @@ void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx)
> f.fmt.pix_mp.pixelformat = DEF_DST_FMT_ENC;
> ctx->dst_fmt = find_format(&f, MFC_FMT_ENC);
> }
> -
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index d29e45516eb7..e7e6340b395e 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> "Use Previous Specific Frame",
> NULL,
> };
> + static const char * const vp8_profile[] = {
> + "0",
> + "1",
> + "2",
> + "3",
> + NULL,
> + };
>
> static const char * const flash_led_mode[] = {
> "Off",
> @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return mpeg4_profile;
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> return vpx_golden_frame_sel;
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> + return vp8_profile;
> case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
> return jpeg_chroma_subsampling;
> case V4L2_CID_DV_TX_MODE:
> @@ -839,7 +848,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP: return "VPX Maximum QP Value";
> case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
> case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
> - case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
>
> /* HEVC controls */
> case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
> @@ -1180,6 +1189,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> case V4L2_CID_DEINTERLACING_MODE:
> case V4L2_CID_TUNE_DEEMPHASIS:
> case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> + case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
> case V4L2_CID_DETECT_MD_MODE:
> case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 8d473c979b61..2001823c3072 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -587,7 +587,16 @@ enum v4l2_vp8_golden_frame_sel {
> #define V4L2_CID_MPEG_VIDEO_VPX_MAX_QP (V4L2_CID_MPEG_BASE+508)
> #define V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP (V4L2_CID_MPEG_BASE+509)
> #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
> -#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
> +
> +#define V4L2_CID_MPEG_VIDEO_VP8_PROFILE (V4L2_CID_MPEG_BASE+511)
> +enum v4l2_mpeg_video_vp8_profile {
> + V4L2_MPEG_VIDEO_VP8_PROFILE_0 = 0,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_1 = 1,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_2 = 2,
> + V4L2_MPEG_VIDEO_VP8_PROFILE_3 = 3,
> +};
> +/* Deprecated alias for compatibility reasons. */
> +#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
>
> /* CIDs for HEVC encoding. */
>
> --
> 2.18.0.rc1.242.g61856ae69a-goog
>
Regards,
Hans
^ permalink raw reply
* [PATCH v3 6/7] mmc: sunxi: Add runtime_pm support
From: Ulf Hansson @ 2018-06-15 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1caa07d2-17ad-18aa-9216-037c06b36281@arm.com>
On 14 June 2018 at 16:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Maxime,
>
> On 16/04/18 15:23, Maxime Ripard wrote:
>> So far, even if our card was not in use, we didn't shut down our MMC
>> controller, which meant that it was still active and clocking the bus.
>>
>> While this obviously means that we could save some power there, it also
>> creates issues when it comes to EMC control since we'll have a perfect peak
>> at the card clock rate.
>>
>> Let's implement runtime_pm with autosuspend so that we will shut down the
>> controller when it's not been in use for quite some time.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>> ---
>> drivers/mmc/host/sunxi-mmc.c | 48 +++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 0165da0d022a..0253deb153a4 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -35,6 +35,7 @@
>> #include <linux/of_gpio.h>
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/regulator/consumer.h>
>> #include <linux/reset.h>
>> #include <linux/scatterlist.h>
>> @@ -969,6 +970,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> unsigned long flags;
>> u32 imask;
>>
>> + if (enable)
>> + pm_runtime_get_noresume(host->dev);
>> +
>> spin_lock_irqsave(&host->lock, flags);
>>
>> imask = mmc_readl(host, REG_IMASK);
>> @@ -981,6 +985,9 @@ static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>> }
>> mmc_writel(host, REG_IMASK, imask);
>> spin_unlock_irqrestore(&host->lock, flags);
>> +
>> + if (!enable)
>> + pm_runtime_put_noidle(host->mmc->parent);
>> }
>>
>> static void sunxi_mmc_hw_reset(struct mmc_host *mmc)
>> @@ -1394,6 +1401,11 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>> if (ret)
>> goto error_free_dma;
>>
>> + pm_runtime_set_active(&pdev->dev);
>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_enable(&pdev->dev);
>> +
>> ret = mmc_add_host(mmc);
>> if (ret)
>> goto error_free_dma;
>> @@ -1414,6 +1426,7 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
>> struct sunxi_mmc_host *host = mmc_priv(mmc);
>>
>> mmc_remove_host(mmc);
>> + pm_runtime_force_suspend(&pdev->dev);
>> disable_irq(host->irq);
>> sunxi_mmc_disable(host);
>> dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
>> @@ -1422,10 +1435,45 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static int sunxi_mmc_runtime_resume(struct device *dev)
>> +{
>> + struct mmc_host *mmc = dev_get_drvdata(dev);
>> + struct sunxi_mmc_host *host = mmc_priv(mmc);
>> + int ret;
>> +
>> + ret = sunxi_mmc_enable(host);
>> + if (ret)
>> + return ret;
>> +
>> + sunxi_mmc_init_host(host);
>> + sunxi_mmc_set_bus_width(host, mmc->ios.bus_width);
>> + sunxi_mmc_set_clk(host, &mmc->ios);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_mmc_runtime_suspend(struct device *dev)
>> +{
>> + struct mmc_host *mmc = dev_get_drvdata(dev);
>> + struct sunxi_mmc_host *host = mmc_priv(mmc);
>> +
>> + sunxi_mmc_reset_host(host);
>> + sunxi_mmc_disable(host);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct dev_pm_ops sunxi_mmc_pm_ops = {
>> + SET_RUNTIME_PM_OPS(sunxi_mmc_runtime_suspend,
>> + sunxi_mmc_runtime_resume,
>> + NULL)
>> +};
>> +
>> static struct platform_driver sunxi_mmc_driver = {
>> .driver = {
>> .name = "sunxi-mmc",
>> .of_match_table = of_match_ptr(sunxi_mmc_of_match),
>> + .pm = &sunxi_mmc_pm_ops,
>> },
>> .probe = sunxi_mmc_probe,
>> .remove = sunxi_mmc_remove,
>>
>
> This patch has the unfortunate impact of killing my A20 system
> (cubietruck), as of 9a8e1e8cc2c02c57c4e941651a8481a633506c91:
>
> [...]
> [ 3.286649] NET: Registered protocol family 10
> [ 3.291898] mmcblk0: p1
> [ 3.295297] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [ 3.302773] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 3.305787] Segment Routing with IPv6
> [ 3.312225] mip6: Mobile IPv6
> [ 3.316166] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [ 3.316246] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 3.323721] ip6_gre: GRE over IPv6 tunneling driver
> [ 3.333954] NET: Registered protocol family 17
> [ 3.338837] 9pnet: Installing 9P2000 support
> [ 3.343379] NET: Registered protocol family 37
> [ 3.347885] Key type dns_resolver registered
> [ 3.352214] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 3.352217] openvswitch: Open vSwitch switching datapath
> [ 3.352620] mpls_gso: MPLS GSO support
> [ 3.367001] ThumbEE CPU extension supported.
>
> and that's where it stops. No message, just a hard lockup (I suppose
> that both the CPUs are trying to access some device that is now not
> clocked).
Seems like a reasonable analyze.
>
> With a working kernel, I see SATA and the wifi SDIO being probed.
>
> Happy to help testing stuff if you have any idea.
In principle I would start with avoiding having the sunxi-mmc driver
to probe. Or bail out early in probe, whichever is the easiest for
you.
The point is, if the sunxi-mmc driver doesn't even enable its clock,
it would be interesting to see if there are other that depends on it.
One could also play with clk_disable_unused(), the
late_initcall_sync(), which can be turned off with the module
parameter "clk_ignore_unused".
Anyway, to hide/fix the problem for now, we could add a call to
pm_runtime_get_noresume() before the sunxi-driver calls
pm_runtime_enable().
Kind regards
Uffe
^ permalink raw reply
* [PATCH 4/4] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-15 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1f730ca-da21-1756-b781-b6552fb28101@microchip.com>
Thanks all for the reviews and comments, I will work on a new series.
> On 14/06/2018 at 10:51, Ben Whitten wrote:
> > Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
> > arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159
> ++++++++++++++++++
> > arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 96 +++++++++++
> > arch/arm/boot/dts/at91-som60.dtsi | 229
> ++++++++++++++++++++++++++
> > 5 files changed, 581 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
> > create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 486ab59..4d3d9ca 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -63,7 +63,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> > at91-sama5d4ek.dtb \
> > at91-vinco.dtb \
>
> About where you added dtbs...
>
> > at91-wb50n.dtb \
> > - at91-gatwick.dtb
> > + at91-gatwick.dtb \
> > + at91-dvk_som60.dtb
>
> 1/ As they are based on sama5d3, I would like to see them between
> "at91-sama5d2_xplained.dtb" and "sama5d31ek.dtb"
> 2/ within this range, please sort all these 4 alphabetically
> 3/ don't laugh at me, I try to deal with our historical way of "sorting"
> entries in this Makefile for AT91... ;-)
>
> BTW, I realize now that your "at91-wb45n.dtb" entry from patch 1 should
> go just after the "at91-kizboxmini.dts" (alphabetical order in
> at91sam9x5 "location").
>
>
> > dtb-$(CONFIG_ARCH_ATLAS6) += \
> > atlas6-evb.dtb
> > dtb-$(CONFIG_ARCH_ATLAS7) += \
> > diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts
> b/arch/arm/boot/dts/at91-dvk_som60.dts
> > new file mode 100644
> > index 0000000..ededd5b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_som60.dts
> > @@ -0,0 +1,95 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +/dts-v1/;
> > +#include "at91-som60.dtsi"
> > +#include "at91-dvk_su60_somc.dtsi"
> > +#include "at91-dvk_su60_somc_lcm.dtsi"
> > +
> > +/ {
> > + model = "Laird DVK SOM60";
> > + compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36",
> "atmel,sama5d3", "atmel,sama5";
> > +
> > + chosen {
> > + stdout-path = &dbgu;
> > + tick-timer = &pit;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + status = "okay";
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +};
> > +
> > +&ssc0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +};
> > +
> > +&usart1 {
> > + status = "okay";
> > +};
> > +
> > +&usart2 {
> > + status = "okay";
> > +};
> > +
> > +&usart3 {
> > + status = "okay";
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > +&dbgu {
> > + status = "okay";
> > +};
> > +
> > +&pit {
> > + status = "okay";
> > +};
> > +
> > +&adc0 {
> > + status = "okay";
> > +};
> > +
> > +&can1 {
> > + status = "okay";
> > +};
> > +
> > +&macb0 {
> > + status = "okay";
> > +};
> > +
> > +&macb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb2 {
> > + status = "okay";
> > +};
> > +
> > diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > new file mode 100644
> > index 0000000..6031c2f
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base
> board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +
> > +/ {
> > + sound {
> > + compatible = "atmel,asoc-wm8904";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
> > +
> > + atmel,model = "wm8904 @ DVK-SOM60";
> > + atmel,audio-routing =
> > + "Headphone Jack", "HPOUTL",
> > + "Headphone Jack", "HPOUTR",
> > + "IN2L", "Line In Jack",
> > + "IN2R", "Line In Jack",
> > + "Mic", "MICBIAS",
> > + "IN1L", "Mic";
> > +
> > + atmel,ssc-controller = <&ssc0>;
> > + atmel,audio-codec = <&wm8904>;
> > +
> > + status = "okay";
> > + };
> > +};
> > +
> > +&mmc0 {
> > + status = "okay";
> > +
> > + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3
> &pinctrl_mmc0_cd>;
> > + slot at 0 {
> > + bus-width = <4>;
> > + cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
> > + cd-inverted;
> > + };
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +
> > + /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
> > + spi-flash at 0 {
> > + compatible = "mxicy,mx25u4035", "jedec,spi-nor";
> > + spi-max-frequency = <33000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&ssc0 {
> > + atmel,clk-from-rk-pin;
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > +
> > + wm8904: wm8904 at 1a {
> > + compatible = "wlf,wm8904";
> > + reg = <0x1a>;
> > + clocks = <&pck2>;
> > + clock-names = "mclk";
> > + };
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +
> > + eeprom at 87 {
> > + compatible = "giantec,24c32";
>
> It must work, however...
>
> I read in recent patches on dts directory that :
>
> "We now require all at24 users to use the "atmel,<model>" fallback in
> device tree for different manufacturers."
>
> Moreover, I don't see giantec in the vendor prefix list.
I see, I have added parts which are compatible and made note what the real
part is, should I typically be adding the real part to the compatible list and
update vendor prefixes if necessary?
>
> > + reg = <87>;
> > + pagesize = <32>;
> > + };
> > +};
> > +
> > +&usart1 {
> > + status = "okay";
> > +};
> > +
> > +&usart2 {
> > + status = "okay";
> > +};
> > +
> > +&usart3 {
> > + status = "okay";
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > +&dbgu {
> > + status = "okay";
> > +};
> > +
> > +&pit {
> > + status = "okay";
> > +};
> > +
> > +&adc0 {
> > + status = "okay";
> > +};
> > +
> > +&can1 {
> > + status = "okay";
> > +};
> > +
> > +&macb0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + ethernet-phy at 7 {
> > + reg = <7>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_geth_int>;
> > + interrupt-parent = <&pioB>;
> > + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> > + txen-skew-ps = <800>;
> > + txc-skew-ps = <3000>;
> > + rxdv-skew-ps = <400>;
> > + rxc-skew-ps = <3000>;
> > + rxd0-skew-ps = <400>;
> > + rxd1-skew-ps = <400>;
> > + rxd2-skew-ps = <400>;
> > + rxd3-skew-ps = <400>;
> > + };
> > +};
> > +
> > +&macb1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + ethernet-phy at 1 {
> > + reg = <1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_eth_int>;
> > + interrupt-parent = <&pioC>;
> > + interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
> > + };
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > +
> > +&usb2 {
> > + status = "okay";
> > +};
> > +
> > diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > new file mode 100644
> > index 0000000..d98c644
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
> > @@ -0,0 +1,96 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD
> board
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +
> > +/ {
> > + ahb {
> > + apb {
> > + pinctrl at fffff200 {
> > + board {
> > + pinctrl_lcd_ctp_int: lcd_ctp_int {
> > + atmel,pins =
> > + <AT91_PIOC 28
> AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&hlcdc_pwm 0 50000 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <6>;
> > + status = "okay";
> > + };
> > +
> > + panel: panel {
> > + /* Actually Winstar WF70GTIAGDNG0 */
> > + compatible = "innolux,at070tn92", "simple-panel";
> > + backlight = <&backlight>;
> > + power-supply = <&vcc_lcd_reg>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + panel_input: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&hlcdc_panel_output>;
> > + };
> > + };
> > + };
> > +
> > + vcc_lcd_reg: fixedregulator_lcd {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VCC LCM";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + status = "okay";
> > + };
> > +};
> > +
> > +&i2c1 {
> > + status = "okay";
> > +
> > + ft5426 at 56 {
> > + /* Actually FT5426 */
> > + compatible = "edt,edt-ft5406";
> > + reg = <56>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcd_ctp_int>;
> > +
> > + interrupt-parent = <&pioC>;
> > + interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
> > +
> > + touchscreen-size-x = <800>;
> > + touchscreen-size-y = <480>;
> > + };
> > +};
> > +
> > +&hlcdc {
> > + status = "okay";
> > +
> > + hlcdc-display-controller {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
> > +
> > + port at 0 {
> > + hlcdc_panel_output: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&panel_input>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-
> som60.dtsi
> > new file mode 100644
> > index 0000000..1843284
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/at91-som60.dtsi
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * at91-som60.dtsi - Device Tree file for the SOM60 module
> > + *
> > + * Copyright (C) 2018 Laird,
> > + * 2018 Ben Whitten <ben.whitten@lairdtech.com>
> > + *
> > + */
> > +#include "sama5d36.dtsi"
> > +
> > +/ {
> > + model = "Laird SOM60";
> > + compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3",
> "atmel,sama5";
> > +
> > + chosen {
> > + stdout-path = &dbgu;
> > + };
> > +
> > + memory {
> > + reg = <0x20000000 0x8000000>;
> > + };
> > +
> > + clocks {
> > + slow_xtal {
> > + clock-frequency = <32768>;
> > + };
> > +
> > + main_xtal {
> > + clock-frequency = <12000000>;
> > + };
> > + };
> > +
> > + ahb {
> > + apb {
> > + pinctrl at fffff200 {
> > + board {
> > + pinctrl_mmc0_cd: mmc0_cd {
> > + atmel,pins =
> > + <AT91_PIOE 31
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_mmc0_en: mmc0_en {
> > + atmel,pins =
> > + <AT91_PIOE 30
> AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> > + };
> > +
> > + pinctrl_nand0_wp: nand0_wp {
> > + atmel,pins =
> > + <AT91_PIOE 14
> AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> > + };
> > +
> > + pinctrl_usb_vbus: usb_vbus {
> > + atmel,pins =
> > + <AT91_PIOE 20
> AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* Conflicts with USART2_SCK
> */
> > + };
> > +
> > + pinctrl_usart2_sck: usart2_sck {
> > + atmel,pins =
> > + <AT91_PIOE 20
> AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_VBUS */
> > + };
> > +
> > + pinctrl_usb_oc: usb_oc {
> > + atmel,pins =
> > + <AT91_PIOE 15
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with
> USART3_SCK */
> > + };
> > +
> > + pinctrl_usart3_sck: usart3_sck {
> > + atmel,pins =
> > + <AT91_PIOE 15
> AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_OC */
> > + };
> > +
> > + pinctrl_usba_vbus: usba_vbus {
> > + atmel,pins =
> > + <AT91_PIOC 14
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_geth_int: geth_int {
> > + atmel,pins =
> > + <AT91_PIOB 25
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with
> USART1_SCK */
> > + };
> > +
> > + pinctrl_usart1_sck: usart1_sck {
> > + atmel,pins =
> > + <AT91_PIOB 25
> AT91_PERIPH_A AT91_PINCTRL_NONE>; /* Conflicts with GETH_INT */
> > + };
> > +
> > + pinctrl_eth_int: eth_int {
> > + atmel,pins =
> > + <AT91_PIOC 10
> AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> > + };
> > +
> > + pinctrl_pck2_as_audio_mck:
> pck2_as_audio_mck {
> > + atmel,pins =
> > + <AT91_PIOC 15
> AT91_PERIPH_B AT91_PINCTRL_NONE>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&mmc0 {
> > + slot at 0 {
> > + reg = <0>;
> > + bus-width = <8>;
> > + };
> > +};
> > +
> > +&mmc1 {
> > + status = "okay";
> > + slot at 0 {
> > + reg = <0>;
> > + bus-width = <4>;
> > + };
> > +};
> > +
> > +&spi0 {
> > + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> > +};
> > +
> > +&usart0 {
> > + atmel,use-dma-rx;
> > + atmel,use-dma-tx;
> > + status = "okay";
> > + pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
> > +};
> > +
> > +&usart1 {
> > + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> > +};
> > +
> > +&usart2 {
> > + pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
> > +};
> > +
> > +&usart3 {
> > + pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
> > +};
> > +
> > +&adc0 {
> > + pinctrl-0 = <
> > + &pinctrl_adc0_adtrg
> > + &pinctrl_adc0_ad0
> > + &pinctrl_adc0_ad1
> > + &pinctrl_adc0_ad2
> > + &pinctrl_adc0_ad3
> > + &pinctrl_adc0_ad4
> > + &pinctrl_adc0_ad5
> > + >;
> > +};
> > +
> > +&macb0 {
> > + phy-mode = "rgmii";
> > +};
> > +
> > +&macb1 {
> > + phy-mode = "rmii";
> > +};
> > +
> > +
> > +&ebi {
> > + pinctrl-0 = <&pinctrl_ebi_nand_addr>;
> > + pinctrl-names = "default";
> > + status = "okay";
> > +};
> > +
> > +&nand_controller {
> > + status = "okay";
> > +
> > + nand: nand at 3 {
> > + reg = <0x3 0x0 0x2>;
> > + atmel,rb = <0>;
> > + nand-bus-width = <8>;
> > + nand-ecc-mode = "hw";
> > + nand-ecc-strength = <8>;
> > + nand-ecc-step-size = <512>;
> > + nand-on-flash-bbt;
> > + label = "atmel_nand";
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + ubootspl at 0 {
> > + label = "u-boot-spl";
> > + reg = <0x0 0x20000>;
> > + };
> > +
> > + uboot at 20000 {
> > + label = "u-boot";
> > + reg = <0x20000 0x80000>;
> > + };
> > +
> > + ubootenv at a0000 {
> > + label = "u-boot-env";
> > + reg = <0xa0000 0x20000>;
> > + };
> > +
> > + ubootenv at c0000 {
> > + label = "u-boot-env";
> > + reg = <0xc0000 0x20000>;
> > + };
> > +
> > + ubi at e0000 {
> > + label = "ubi";
> > + reg = <0xe0000 0xfe00000>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&usb0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usba_vbus>;
> > + atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&usb1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
> > + num-ports = <3>;
> > + atmel,vbus-gpio = <0
> > + &pioE 20 GPIO_ACTIVE_HIGH
> > + 0>;
> > + atmel,oc-gpio = <0
> > + &pioE 15 GPIO_ACTIVE_LOW
> > + 0>;
> > +};
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Maxime Ripard @ 2018-06-15 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615081554.GA3047@Red>
On Fri, Jun 15, 2018 at 10:15:54AM +0200, Corentin Labbe wrote:
> On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > > ending boot.
> > > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > > Since the crypto hardware is not implemented, all registers are read as 0.
> > > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> > >
> > > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > > more complex and prevent a case that never happen on real hardware.
> > >
> > > The best way to fix is to check at probe time if we run on a virtual
> > > machine with hardware emulated but non-implemented and prevent
> > > sun4i-ss to be loaded in that case.
> > > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > > disabled since they will fail crypto selftests.
> > >
> > > Tested-on: qemu-cubieboard
> > > Tested-on: cubieboard2
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > index a81d89b3b7d8..a178e80adcf3 100644
> > > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > > * I expect to be a sort of Security System Revision number.
> > > * Since the A80 seems to have an other version of SS
> > > * this info could be useful
> > > + * Detect virtual machine with non-implemented hardware
> > > + * (qemu-cubieboard) by checking the register value after a write to it.
> > > + * On non-implemented hardware, all registers are read as 0.
> > > + * On real hardware we should have a value > 0.
> > > */
> > > writel(SS_ENABLED, ss->base + SS_CTL);
> > > v = readl(ss->base + SS_CTL);
> > > + if (!v) {
> > > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > > + err = -ENODEV;
> > > + goto error_rst;
> > > + }
> >
> > This is wrong way to tackle the issue. There's multiple reason why
> > this could happen (for example the device not being clocked, or
> > maintained in reset). There's nothing specific about qemu here, and
> > the fundamental issue isn't that the device isn't functional in qemu,
> > it's that qemu lies about which hardware it can emulate in the DT it
> > passes to the kernel.
> >
> > There's no way this can scale, alone from the fact that qemu should
> > patch the DT according to what it can do. Not trying to chase after
> > each and every device that is broken in qemu.
> >
> > NAK.
> >
>
> My fix detect also when the device is badly clocked.
In which case, the proper fix is to enable the clock, not throw the
kernel's arm up in the air.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/6969fcc6/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 05/27] docs: Fix some broken references
From: Coly Li @ 2018-06-15 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <29adfe49571ad1395871a4f72154f45ef361297f.1528990947.git.mchehab+samsung@kernel.org>
On 2018/6/15 12:08 AM, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked if the produced result is valid, removing a few
> false-positives.
>
> Acked-by: Takashi Iwai <tiwai@suse.de>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../admin-guide/kernel-parameters.txt | 4 ++--
> .../bindings/input/rotary-encoder.txt | 2 +-
> Documentation/driver-api/gpio/consumer.rst | 2 +-
> Documentation/kprobes.txt | 4 ++--
> Documentation/trace/coresight.txt | 2 +-
> Documentation/trace/ftrace-uses.rst | 2 +-
> Documentation/trace/histogram.txt | 2 +-
> Documentation/trace/intel_th.rst | 2 +-
> Documentation/trace/tracepoint-analysis.rst | 6 +++---
> Documentation/translations/ja_JP/howto.rst | 4 ++--
> .../translations/zh_CN/magic-number.txt | 4 ++--
> .../zh_CN/video4linux/omap3isp.txt | 4 ++--
> MAINTAINERS | 20 +++++++++----------
> arch/Kconfig | 2 +-
> arch/arm/include/asm/cacheflush.h | 2 +-
> arch/arm64/include/asm/cacheflush.h | 2 +-
> arch/microblaze/include/asm/cacheflush.h | 2 +-
> arch/um/Kconfig.um | 2 +-
> arch/unicore32/include/asm/cacheflush.h | 2 +-
> arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
> arch/xtensa/include/asm/cacheflush.h | 4 ++--
> block/Kconfig | 2 +-
> certs/Kconfig | 2 +-
> crypto/asymmetric_keys/asymmetric_type.c | 2 +-
> crypto/asymmetric_keys/signature.c | 2 +-
> drivers/char/Kconfig | 2 +-
> drivers/clk/clk.c | 4 ++--
> drivers/clk/ingenic/cgu.h | 2 +-
> drivers/gpu/vga/Kconfig | 2 +-
> drivers/gpu/vga/vgaarb.c | 2 +-
> drivers/input/joystick/Kconfig | 10 +++++-----
> drivers/input/joystick/walkera0701.c | 2 +-
> drivers/input/misc/Kconfig | 4 ++--
> drivers/input/misc/rotary_encoder.c | 2 +-
> drivers/input/mouse/Kconfig | 6 +++---
> drivers/input/mouse/alps.c | 2 +-
> drivers/input/touchscreen/wm97xx-core.c | 2 +-
> drivers/lightnvm/pblk-rb.c | 2 +-
> drivers/md/bcache/Kconfig | 2 +-
> drivers/md/bcache/btree.c | 2 +-
> drivers/md/bcache/extents.c | 2 +-
> drivers/media/dvb-core/dvb_ringbuffer.c | 2 +-
> drivers/media/pci/meye/Kconfig | 2 +-
> drivers/media/platform/pxa_camera.c | 4 ++--
> .../soc_camera/sh_mobile_ceu_camera.c | 2 +-
> drivers/media/radio/Kconfig | 2 +-
> drivers/media/radio/si470x/Kconfig | 2 +-
> drivers/media/usb/dvb-usb-v2/lmedm04.c | 2 +-
> drivers/media/usb/zr364xx/Kconfig | 2 +-
> drivers/parport/Kconfig | 6 +++---
> drivers/staging/media/bcm2048/TODO | 2 +-
> include/keys/asymmetric-subtype.h | 2 +-
> include/keys/asymmetric-type.h | 2 +-
> include/linux/assoc_array.h | 2 +-
> include/linux/assoc_array_priv.h | 2 +-
> include/linux/circ_buf.h | 2 +-
> include/linux/ftrace.h | 2 +-
> include/linux/rculist_nulls.h | 2 +-
> include/uapi/linux/prctl.h | 2 +-
> include/xen/interface/io/kbdif.h | 2 +-
> kernel/cgroup/cpuset.c | 2 +-
> kernel/trace/Kconfig | 16 +++++++--------
> lib/Kconfig | 2 +-
> security/selinux/hooks.c | 2 +-
> sound/core/Kconfig | 4 ++--
> sound/drivers/Kconfig | 4 ++--
> sound/pci/Kconfig | 10 +++++-----
> tools/include/uapi/linux/prctl.h | 2 +-
> tools/lib/api/fs/fs.c | 2 +-
> tools/perf/util/bpf-prologue.c | 2 +-
> .../config/custom-timeline-functions.cfg | 4 ++--
> 71 files changed, 113 insertions(+), 113 deletions(-)
[snip]
> diff --git a/drivers/md/bcache/Kconfig b/drivers/md/bcache/Kconfig
> index 4d200883c505..17bf109c58e9 100644
> --- a/drivers/md/bcache/Kconfig
> +++ b/drivers/md/bcache/Kconfig
> @@ -5,7 +5,7 @@ config BCACHE
> Allows a block device to be used as cache for other devices; uses
> a btree for indexing and the layout is optimized for SSDs.
>
> - See Documentation/bcache.txt for details.
> + See Documentation/admin-guide/bcache.rst for details.
>
> config BCACHE_DEBUG
> bool "Bcache debugging"
> diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> index 2a0968c04e21..547c9eedc2f4 100644
> --- a/drivers/md/bcache/btree.c
> +++ b/drivers/md/bcache/btree.c
> @@ -18,7 +18,7 @@
> * as keys are inserted we only sort the pages that have not yet been written.
> * When garbage collection is run, we resort the entire node.
> *
> - * All configuration is done via sysfs; see Documentation/bcache.txt.
> + * All configuration is done via sysfs; see Documentation/admin-guide/bcache.rst.
> */
>
> #include "bcache.h"
> diff --git a/drivers/md/bcache/extents.c b/drivers/md/bcache/extents.c
> index c334e6666461..1d096742eb41 100644
> --- a/drivers/md/bcache/extents.c
> +++ b/drivers/md/bcache/extents.c
> @@ -18,7 +18,7 @@
> * as keys are inserted we only sort the pages that have not yet been written.
> * When garbage collection is run, we resort the entire node.
> *
> - * All configuration is done via sysfs; see Documentation/bcache.txt.
> + * All configuration is done via sysfs; see Documentation/admin-guide/bcache.rst.
> */
>
> #include "bcache.h"
For the bcache part, it is good to me.
Reviewed-by: Coly Li <colyli@suse.de>
Thanks for the fix.
Coly Li
^ permalink raw reply
* [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
From: Maxime Ripard @ 2018-06-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614153548.9644-1-wens@csie.org>
On Thu, Jun 14, 2018 at 11:35:44PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> This series is the remaining A64 syscon changes from the R40 DWMAC
> series. The series aligns how the A64 system control exports a regmap
> for the sun8i DWMAC driver to access with what we've done for the R40.
>
> Originally the A64 used the generic syscon for this bit of hardware.
> But this block also contains mapping bits for the onboard SRAM, used
> by various peripherals, and other vendor specific bits we may use in
> the future. It is by no means generic. And we already have a device
> tree binding and driver for the SRAM part.
>
> The first patch make the SRAM control device export a regmap, exposing
> a single EMAC control register, for the DWMAC driver to consume.
>
> The second and third patches rename the A64 compatible string to read
> "system control", which is what the block is named in the user manual.
>
> The last patch fixes up the device node, and also adds the lone mappable
> SRAM block, which is needed by the Display Engine.
For the serie:
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/9fbf8015/attachment.sig>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] crypto: sun4i-ss: prevent deadlock on emulated hardware
From: Corentin Labbe @ 2018-06-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615090412.xgw35ga5cvc6w3h3@flea>
On Fri, Jun 15, 2018 at 11:04:12AM +0200, Maxime Ripard wrote:
> On Fri, Jun 15, 2018 at 10:15:54AM +0200, Corentin Labbe wrote:
> > On Fri, Jun 15, 2018 at 09:57:54AM +0200, Maxime Ripard wrote:
> > > On Thu, Jun 14, 2018 at 09:36:59PM +0200, Corentin Labbe wrote:
> > > > Running a qemu emulated cubieboard with sun4i-ss driver enabled led to a never
> > > > ending boot.
> > > > This is due to sun4i-ss deadlocked and taking all cpu in an infinite loop.
> > > > Since the crypto hardware is not implemented, all registers are read as 0.
> > > > So sun4i-ss will never progress in any operations. (TX_CNT being always 0)
> > > >
> > > > The first idea is to add a "TX_CNT always zero timeout" but this made cipher/hash loops
> > > > more complex and prevent a case that never happen on real hardware.
> > > >
> > > > The best way to fix is to check at probe time if we run on a virtual
> > > > machine with hardware emulated but non-implemented and prevent
> > > > sun4i-ss to be loaded in that case.
> > > > Letting sun4i-ss to load is useless anyway since all crypto algorithm will be
> > > > disabled since they will fail crypto selftests.
> > > >
> > > > Tested-on: qemu-cubieboard
> > > > Tested-on: cubieboard2
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10 ++++++++++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > index a81d89b3b7d8..a178e80adcf3 100644
> > > > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > > > @@ -341,9 +341,18 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> > > > * I expect to be a sort of Security System Revision number.
> > > > * Since the A80 seems to have an other version of SS
> > > > * this info could be useful
> > > > + * Detect virtual machine with non-implemented hardware
> > > > + * (qemu-cubieboard) by checking the register value after a write to it.
> > > > + * On non-implemented hardware, all registers are read as 0.
> > > > + * On real hardware we should have a value > 0.
> > > > */
> > > > writel(SS_ENABLED, ss->base + SS_CTL);
> > > > v = readl(ss->base + SS_CTL);
> > > > + if (!v) {
> > > > + dev_err(&pdev->dev, "Qemu with non-implemented SS detected.\n");
> > > > + err = -ENODEV;
> > > > + goto error_rst;
> > > > + }
> > >
> > > This is wrong way to tackle the issue. There's multiple reason why
> > > this could happen (for example the device not being clocked, or
> > > maintained in reset). There's nothing specific about qemu here, and
> > > the fundamental issue isn't that the device isn't functional in qemu,
> > > it's that qemu lies about which hardware it can emulate in the DT it
> > > passes to the kernel.
> > >
> > > There's no way this can scale, alone from the fact that qemu should
> > > patch the DT according to what it can do. Not trying to chase after
> > > each and every device that is broken in qemu.
> > >
> > > NAK.
> > >
> >
> > My fix detect also when the device is badly clocked.
>
> In which case, the proper fix is to enable the clock, not throw the
> kernel's arm up in the air.
>
By badly I mean "not clocked" or "with the wrong frequencies".
I could change the clock rate range test to exit (it issue only a warning for now).
But I think this fix detect all cases and still permit someone to play with overclocking/downclocking.
Regards
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: Avoid mistaken attempts to save SVE state for vcpus
From: Dave Martin @ 2018-06-15 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87po0szb4h.fsf@linaro.org>
On Fri, Jun 15, 2018 at 09:50:54AM +0100, Alex Benn?e wrote:
>
> Dave Martin <Dave.Martin@arm.com> writes:
> > This patch ensures this my delaying restoration of current's
> > TIF_SVE until after the call to fpsimd_save().
>
> this *by* delaying
No Reviewed-my? ;)
I'll repost for the bh_disable/irqsave changes anyway, so I can fix
typos at low effort.
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 0/4] add mailbox support for i.MX7D
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
20180615 changes v2:
- DT: use mailbox@ instead of mu@
- DT: change interrupts description
- clk: use imx_clk_gate4 instead of imx_clk_gate2
- imx-mailbox: remove last_tx_done support
- imx-mailbox: fix module description
This patches are providing support for mailbox (Messaging Unit)
for i.MX7D.
Functionality was tested on PHYTEC phyBOARD-Zeta i.MX7D with
Linux running on all cores: ARM Cortex-A7 and ARM Cortex-M4.
Both parts of i.MX messaging Unit are visible for all CPUs available
on i.MX7D. Communication worked independent of MU side in combination
with CPU. For example MU-A used on ARM Cortex-A7 and MU-B used on ARM Cortex-M4
or other ways around.
The question to NXP developers: are there are limitations or
recommendations about MU vs CPU combination? The i.MX7D documentation
talks about "Processor A" and "Processor B". It is not quite clear what
processor it actually is (A7 or M4).
Oleksij Rempel (4):
clk: imx7d: add IMX7D_MU_ROOT_CLK
dt-bindings: mailbox: provide imx-mailbox documentation
ARM: dts: imx7s: add i.MX7 messaging unit support
mailbox: Add support for i.MX7D messaging unit
.../bindings/mailbox/imx-mailbox.txt | 35 +++
arch/arm/boot/dts/imx7s.dtsi | 18 ++
drivers/clk/imx/clk-imx7d.c | 1 +
drivers/mailbox/Kconfig | 6 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/imx-mailbox.c | 288 ++++++++++++++++++
6 files changed, 350 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
create mode 100644 drivers/mailbox/imx-mailbox.c
--
2.17.1
^ permalink raw reply
* [PATCH v2 1/4] clk: imx7d: add IMX7D_MU_ROOT_CLK
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
This clock is needed for iMX mailbox driver
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/clk/imx/clk-imx7d.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d3cc94..c7159bfac77a 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 0x4250, 0);
+ clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate4("mu_root_clk", "ipg_root_clk", base + 0x4270, 0);
clks[IMX7D_CAAM_CLK] = imx_clk_gate4("caam_clk", "ipg_root_clk", base + 0x4240, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", "usb_hsic_post_div", base + 0x4690, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", "ahb_root_clk", base + 0x4480, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: mailbox: provide imx-mailbox documentation
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../bindings/mailbox/imx-mailbox.txt | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
new file mode 100644
index 000000000000..1577b86f1206
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
@@ -0,0 +1,35 @@
+i.MX Messaging Unit
+===================
+
+The i.MX Messaging Unit (MU) contains two register sets: "A" and "B". In most
+cases they are accessible from all Processor Units. On one hand, at least for
+mailbox functionality, it makes no difference which application or processor is
+using which set of the MU. On other hand, the register sets for each of the MU
+parts are not identical.
+
+Required properties:
+- compatible : Shell be one of:
+ "fsl,imx7s-mu-a" and "fsl,imx7s-mu-b" for i.MX7S or i.MX7D
+- reg : physical base address of the mailbox and length of
+ memory mapped region.
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be 1.
+- interrupts : The interrupt number
+- clocks : phandle to the input clock.
+
+Example:
+ mu0a: mailbox at 30aa0000 {
+ compatible = "fsl,imx7s-mu-a";
+ reg = <0x30aa0000 0x28>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ };
+
+ mu0b: mailbox at 30ab0000 {
+ compatible = "fsl,imx7s-mu-b";
+ reg = <0x30ab0000 0x28>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: imx7s: add i.MX7 messaging unit support
From: Oleksij Rempel @ 2018-06-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-1-o.rempel@pengutronix.de>
Define the Messaging Unit (MU) for i.MX7 in the processor's dtsi.
The respective driver is added in the next commit.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/imx7s.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index d9437e773b37..87a82c1f4dfd 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1008,6 +1008,24 @@
status = "disabled";
};
+ mu0a: mailbox at 30aa0000 {
+ compatible = "fsl,imx7s-mu-a";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ status = "disabled";
+ };
+
+ mu0b: mailbox at 30ab0000 {
+ compatible = "fsl,imx7s-mu-b";
+ reg = <0x30ab0000 0x10000>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_MU_ROOT_CLK>;
+ #mbox-cells = <1>;
+ status = "disabled";
+ };
+
usbotg1: usb at 30b10000 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
reg = <0x30b10000 0x200>;
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox