* [PATCH v2] ARM: mm: make act_mm() respect THREAD_SIZE
From: Linus Walleij @ 2020-05-15 12:48 UTC (permalink / raw)
To: Russell King
Cc: Linus Walleij, Florian Fainelli, Ard Biesheuvel, linux-arm-kernel
Recent work with KASan exposed the folling hard-coded bitmask
in arch/arm/mm/proc-macros.S:
bic \rd, sp, #8128
bic \rd, \rd, #63
This forms the bitmask 0x1FFF that is coinciding with
(PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming
that THREAD_SIZE is always 8K (8192).
As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into
this bug.
Fix it by this little oneline suggested by Ard:
bic \rd, sp, #(THREAD_SIZE - 1) & ~63
Where THREAD_SIZE is defined using THREAD_SIZE_ORDER.
We have to also include <linux/const.h> since the THREAD_SIZE
expands to use the _AC() macro.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Change from using THREAD_SIZE_ORDER with a hardcoded
page size constant to just using THREAD_SIZE - 1
for the mask.
---
arch/arm/mm/proc-macros.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index 5461d589a1e2..60ac7c5999a9 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -5,6 +5,7 @@
* VMA_VM_FLAGS
* VM_EXEC
*/
+#include <linux/const.h>
#include <asm/asm-offsets.h>
#include <asm/thread_info.h>
@@ -30,7 +31,7 @@
* act_mm - get current->active_mm
*/
.macro act_mm, rd
- bic \rd, sp, #8128
+ bic \rd, sp, #(THREAD_SIZE - 1) & ~63
bic \rd, \rd, #63
ldr \rd, [\rd, #TI_TASK]
.if (TSK_ACTIVE_MM > IMM12_MASK)
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 7/7] firmware: smccc: Add ARCH_SOC_ID support
From: Mark Rutland @ 2020-05-15 12:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200506164411.3284-8-sudeep.holla@arm.com>
On Wed, May 06, 2020 at 05:44:11PM +0100, Sudeep Holla wrote:
> SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
> SiP defined SoC identification value. Add support for the same.
>
> Also using the SoC bus infrastructure, let us expose the platform
> specific SoC atrributes under sysfs. We also provide custom sysfs for
> the vendor ID as JEP-106 bank and identification code.
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
As with the earlier patch referring to SMCCCv1.2 specifically, I'm
somewhat wary of this until the SMCCCv1.2 spec is final. Do we know what
the timeline is for that?
That needn't hold up the pure refactoring/cleanup portions of this
series, and regardless I have some comments below on this patch.
> ---
> drivers/firmware/smccc/Kconfig | 8 ++
> drivers/firmware/smccc/Makefile | 1 +
> drivers/firmware/smccc/soc_id.c | 168 ++++++++++++++++++++++++++++++++
> include/linux/arm-smccc.h | 5 +
> 4 files changed, 182 insertions(+)
> create mode 100644 drivers/firmware/smccc/soc_id.c
>
> diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> index d93f1ab52cb2..15e7466179a6 100644
> --- a/drivers/firmware/smccc/Kconfig
> +++ b/drivers/firmware/smccc/Kconfig
> @@ -15,3 +15,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
> implementation of PSCI_FEATURES(SMCCC_VERSION) which returns
> success on firmware compliant to SMCCC v1.1 and above.
>
> +config ARM_SMCCC_SOC_ID
> + bool "SoC bus device for the ARM SMCCC SOC_ID"
> + depends on HAVE_ARM_SMCCC_DISCOVERY
> + default y
> + select SOC_BUS
> + help
> + Include support for the SoC bus on the ARM SMCCC firmware based
> + platforms providing some sysfs information about the SoC variant.
> diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
> index 6f369fe3f0b9..72ab84042832 100644
> --- a/drivers/firmware/smccc/Makefile
> +++ b/drivers/firmware/smccc/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> #
> obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) += smccc.o
> +obj-$(CONFIG_ARM_SMCCC_SOC_ID) += soc_id.o
> diff --git a/drivers/firmware/smccc/soc_id.c b/drivers/firmware/smccc/soc_id.c
> new file mode 100644
> index 000000000000..dc5dd3f1f59b
> --- /dev/null
> +++ b/drivers/firmware/smccc/soc_id.c
> @@ -0,0 +1,168 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 Arm Limited
> + */
> +
> +#define pr_fmt(fmt) "SMCCC: SOC_ID: " fmt
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/bitfield.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/sys_soc.h>
> +
> +#define SMCCC_SOC_ID_JEP106_BANK_IDX_MASK GENMASK(30, 24)
> +/*
> + * As per the SMC Calling Convention specification v1.2 (ARM DEN 0028C)
> + * Section 7.4 SMCCC_ARCH_SOC_ID bits[23:16] are JEP-106 identification
> + * code with parity bit for the SiP. We can drop the parity bit.
> + */
> +#define SMCCC_SOC_ID_JEP106_ID_CODE_MASK GENMASK(22, 16)
> +#define SMCCC_SOC_ID_IMP_DEF_SOC_ID_MASK GENMASK(15, 0)
> +
> +/* The bank index is equal to the for continuation code bank number - 1 */
> +#define JEP106_BANK_CONT_CODE(x) \
> + (u8)(FIELD_GET(SMCCC_SOC_ID_JEP106_BANK_IDX_MASK, (x)) + 1)
> +#define JEP106_ID_CODE(x) \
> + (u8)(FIELD_GET(SMCCC_SOC_ID_JEP106_ID_CODE_MASK, (x)))
> +#define IMP_DEF_SOC_ID(x) \
> + (u16)(FIELD_GET(SMCCC_SOC_ID_IMP_DEF_SOC_ID_MASK, (x)))
> +
> +static int soc_id_version;
> +static struct soc_device *soc_dev;
> +static struct soc_device_attribute *soc_dev_attr;
> +
> +static int smccc_map_error_codes(unsigned long a0)
> +{
> + if (a0 >= SMCCC_RET_SUCCESS)
> + return 0;
As SMCCC_RET_SUCCESS is 0, and a0 is an unsigned long, this condition is
true for all values of a0.
I don't think this function is particularly helpful, since in the case
of a failure it'd be nicer to log the original FW error code to dmesg
for debugging, so we may as well leave it to the caller to check for
the EOPNOTSUPP / error cases.
e.g. where NOT_SUPPORTED is legitimate callers can do:
unsigned long ret = smccc_call_foo(...);
if (ret == SMCCC_RET_NOT_SUPPORTED)
return 0;
if ((int)ret < 0)
pr_err("FOO returned %lx\n", ret)
return -EINVAL;
}
consume_ret_somehow(ret);
... and where NOT_SUPPORTED is not legitimate, they can avoid the
explicit check for that:
unsigned long ret = smccc_call_foo(...);
if ((int)ret < 0) {
pr_err("FOO returned %lx\n", ret)
return -EINVAL;
}
consume_ret_somehow(ret);
> + else if (a0 == SMCCC_RET_INVALID_PARAMETER)
> + return -EINVAL;
> + else if (a0 == SMCCC_RET_NOT_SUPPORTED)
> + return -EOPNOTSUPP;
> + return -EINVAL;
> +}
> +
> +static int smccc_soc_id_support_check(void)
> +{
> + struct arm_smccc_res res;
> +
> + if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE) {
> + pr_err("%s: invalid SMCCC conduit\n", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_SOC_ID, &res);
> +
> + return smccc_map_error_codes(res.a0);
> +}
Which I think means we may as well get rid of this, too, and fold the
conduit check into the start of smccc_soc_init().
> +
> +static ssize_t
> +jep106_cont_bank_code_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%02x\n", JEP106_BANK_CONT_CODE(soc_id_version));
> +}
For the regs/identification values, we added a '0x' prefix to make it
explicit that the values are hex. Can/should we do that here, or is that
against conventions for soc bus files?
> +
> +static DEVICE_ATTR_RO(jep106_cont_bank_code);
> +
> +static ssize_t
> +jep106_identification_code_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%02x\n", JEP106_ID_CODE(soc_id_version));
> +}
> +
> +static DEVICE_ATTR_RO(jep106_identification_code);
> +
> +static struct attribute *jep106_id_attrs[] = {
> + &dev_attr_jep106_cont_bank_code.attr,
> + &dev_attr_jep106_identification_code.attr,
> + NULL
> +};
> +
> +ATTRIBUTE_GROUPS(jep106_id);
> +
> +static int __init smccc_soc_init(void)
> +{
> + struct device *dev;
> + int ret, soc_id_rev;
> + struct arm_smccc_res res;
> + static char soc_id_str[8], soc_id_rev_str[12];
> +
> + if (arm_smccc_version_get() < ARM_SMCCC_VERSION_1_2)
> + return 0;
> +
> + ret = smccc_soc_id_support_check();
> + if (ret) {
> + pr_info("Feature not implemented, skipping ....\n");
> + return 0;
> + }
As above, I think we should expand smccc_soc_id_support_check() inline
here.
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
> +
> + ret = smccc_map_error_codes(res.a0);
> + if (ret) {
> + pr_err("Failed to fetch version, Err = %d\n", ret);
> + return ret;
> + }
> +
> + soc_id_version = res.a0;
... and I think this'd be clearer like:
arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
if ((int)res.a0) {
pr_err("ARCH_SOC_ID(0) returned error: %lx\n", res.a0);
return -EINVAL;
}
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
> +
> + ret = smccc_map_error_codes(res.a0);
> + if (ret) {
> + pr_err("Failed to fetch revision, Err = %d\n", ret);
> + return ret;
> + }
... likewise:
arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
if ((int)res.a0) {
pr_err("ARCH_SOC_ID(1) returned error: %lx\n", res.a0);
return -EINVAL;
}
> +
> + soc_id_rev = res.a0;
> +
> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> + if (!soc_dev_attr)
> + return -ENOMEM;
> +
> + sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
> + sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
> +
> + soc_dev_attr->soc_id = soc_id_str;
> + soc_dev_attr->revision = soc_id_rev_str;
Is there any expected format for these? e.g. would it make sense to add
a prefix showing that these are JEP codes?
Do we need to care about platform code which might also regsiter a soc
device? ... or do we expect those to be mutually exclusive?
Thanks,
Mark.
> +
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + ret = PTR_ERR(soc_dev);
> + goto free_soc;
> + }
> +
> + dev = soc_device_to_device(soc_dev);
> +
> + ret = devm_device_add_groups(dev, jep106_id_groups);
> + if (ret) {
> + dev_err(dev, "sysfs create failed: %d\n", ret);
> + goto unregister_soc;
> + }
> +
> + pr_info("ID = %s Revision = %s\n", soc_dev_attr->soc_id,
> + soc_dev_attr->revision);
> +
> + return 0;
> +
> +unregister_soc:
> + soc_device_unregister(soc_dev);
> +free_soc:
> + kfree(soc_dev_attr);
> + return ret;
> +}
> +module_init(smccc_soc_init);
> +
> +static void __exit smccc_soc_exit(void)
> +{
> + if (soc_dev)
> + soc_device_unregister(soc_dev);
> + kfree(soc_dev_attr);
> +}
> +module_exit(smccc_soc_exit);
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 8dd54dad1ec5..368dabe99d09 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -69,6 +69,11 @@
> ARM_SMCCC_SMC_32, \
> 0, 1)
>
> +#define ARM_SMCCC_ARCH_SOC_ID \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_32, \
> + 0, 2)
> +
> #define ARM_SMCCC_ARCH_WORKAROUND_1 \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> ARM_SMCCC_SMC_32, \
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Renesas fixes for v5.7 (take two)
From: Geert Uytterhoeven @ 2020-05-15 12:50 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
Hi arm-soc folks,
The following changes since commit b704fc1da9b84d7145db550a13e2b7140f6b419b:
ARM: dts: r7s9210: Remove bogus clock-names from OSTM nodes (2020-04-28 10:15:38 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-fixes-for-v5.7-tag2
for you to fetch changes up to c8e233bfba3b21cb6b9814b4bfe2502478c7b895:
ARM: dts: iwg20d-q7-dbcm-ca: Remove unneeded properties in hdmi@39 (2020-05-15 10:41:35 +0200)
----------------------------------------------------------------
Renesas fixes for v5.7 (take two)
- Fix a wrong clock configuration on R-Mobile A1,
- Minor fixes that are fast-tracked to avoid introducing regressions
during conversion of DT bindings to json-schema.
Thanks for pulling!
----------------------------------------------------------------
Geert Uytterhoeven (1):
ARM: dts: r8a7740: Add missing extal2 to CPG node
Ricardo Cañuelo (3):
arm64: dts: renesas: Make hdmi encoder nodes compliant with DT bindings
ARM: dts: renesas: Make hdmi encoder nodes compliant with DT bindings
ARM: dts: iwg20d-q7-dbcm-ca: Remove unneeded properties in hdmi@39
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 2 --
arch/arm/boot/dts/r8a7740.dtsi | 2 +-
arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 2 --
arch/arm/boot/dts/r8a7790-lager.dts | 2 --
arch/arm/boot/dts/r8a7790-stout.dts | 2 --
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
arch/arm/boot/dts/r8a7791-porter.dts | 2 --
arch/arm/boot/dts/r8a7792-blanche.dts | 2 --
arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++++--------
arch/arm/boot/dts/r8a7793-gose.dts | 2 --
arch/arm/boot/dts/r8a7794-silk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 2 --
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 6 ++----
17 files changed, 7 insertions(+), 41 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] TI K3 SoC DT changes for v5.8
From: Tero Kristo @ 2020-05-15 12:51 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, Kevin Hilman, soc, arm,
linux-arm-kernel@lists.infradead.org
Cc: Nishanth Menon, J, Keerthy, Tomi Valkeinen, Vignesh R, Jyri Sarha
Hello ARM-SoC Maintainers,
Here are the TI K3 SoC DT updates for v5.8.
Updated google doc based on this also.
I will probably send a part #2 on top of this later, there are some
additional DT changes that might be coming in but they were not ready today.
-Tero
---
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
tags/ti-k3-dt-for-v5.8
for you to fetch changes up to cae809434da10402b0fdbd395c6eb924d7aa46f4:
arm64: dts: ti: k3-j721e-main: Add main domain watchdog entries
(2020-04-27 13:39:48 +0300)
----------------------------------------------------------------
Texas Instruments K3 SoC DT updates for v5.8
- Add DSS support for both AM65x and J721e
- Add watchdog support for J721e
- Add EHRPWM support for AM65x
- Add Thermal support for AM65x
----------------------------------------------------------------
Jyri Sarha (1):
arm64: dts: ti: am654: Add DSS node
Keerthy (2):
arm64: dts: ti: am65-wakeup: Add VTM node
arm64: dts: ti: am654: Add thermal zones
Tero Kristo (1):
arm64: dts: ti: k3-j721e-main: Add main domain watchdog entries
Tomi Valkeinen (2):
arm64: dts: ti: k3-j721e-main: Add DSS node
arm64: dts: ti: k3-j721e-common-proc-board: add assigned clks for DSS
Vignesh Raghavendra (1):
arm64: dts: ti: k3-am65-main: Add ehrpwm nodes
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 104
+++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 11 +++
.../boot/dts/ti/k3-am654-industrial-thermal.dtsi | 45 +++++++++
.../boot/dts/ti/k3-j721e-common-proc-board.dts | 20 ++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 75 +++++++++++++++
5 files changed, 255 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-industrial-thermal.dtsi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/7] firmware: smccc: Refactor SMCCC specific bits into separate file
From: Sudeep Holla @ 2020-05-15 12:53 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200515114953.GE67718@C02TD0UTHF1T.local>
On Fri, May 15, 2020 at 12:49:53PM +0100, Mark Rutland wrote:
> On Wed, May 06, 2020 at 05:44:09PM +0100, Sudeep Holla wrote:
> > In order to add newer SMCCC v1.1+ functionality and to avoid cluttering
> > PSCI firmware driver with SMCCC bits, let us move the SMCCC specific
> > details under drivers/firmware/smccc/smccc.c
> >
> > We can also drop conduit and smccc_version from psci_operations structure
> > as SMCCC was the sole user and now it maintains those.
> >
> > No functionality change in this patch though.
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > MAINTAINERS | 9 +++++++++
> > drivers/firmware/Makefile | 3 ++-
> > drivers/firmware/psci/psci.c | 19 ++++---------------
> > drivers/firmware/smccc/Makefile | 3 +++
> > drivers/firmware/smccc/smccc.c | 26 ++++++++++++++++++++++++++
> > include/linux/arm-smccc.h | 11 +++++++++++
> > include/linux/psci.h | 2 --
> > 7 files changed, 55 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/firmware/smccc/Makefile
> > create mode 100644 drivers/firmware/smccc/smccc.c
> >
> > Hi Mark, Lorenzo,
> >
> > I have replicated PSCI entry in MAINTAINERS file and added myself to
> > for SMCCC entry. If you prefer I can merge it under PSCI. Let me know
> > your preference along with other review comments.
>
> > +SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
> > +M: Mark Rutland <mark.rutland@arm.com>
> > +M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > +M: Sudeep Holla <sudeep.holla@arm.com>
> > +L: linux-arm-kernel@lists.infradead.org
> > +S: Maintained
> > +F: drivers/firmware/smccc/
> > +F: include/linux/arm-smccc.h
>
> As per the above, I'm fine with having this separate from the PSCI
> entry, and I'm fine with sharing this maintainership.
>
Thanks.
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
>
> > +/**
> > + * arm_smccc_version_init() - Sets SMCCC version and conduit
> > + * @version: SMCCC version v1.1 or above
> > + * @conduit: SMCCC_CONDUIT_SMC or SMCCC_CONDUIT_HVC
> > + *
> > + * When SMCCCv1.1 or above is not present, defaults to ARM_SMCCC_VERSION_1_0
> > + * and SMCCC_CONDUIT_NONE respectively.
> > + */
> > +void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit);
>
> Given we only expect the PSCI code to call this, could we avoid putting
> this in a header and just define it within psci.c?
>
Sure I will do that, I was playing on safer side to avoid any tools picking on
such trivial things 😄
> Either way:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
Thanks again.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 23/23] arm64: mte: Add Memory Tagging Extension documentation
From: Szabolcs Nagy @ 2020-05-15 12:53 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Richard Earnshaw, nd, Will Deacon, Andrey Konovalov,
Kevin Brodsky, linux-mm, Vincenzo Frascino, Peter Collingbourne,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200515121343.GC22393@gaia>
The 05/15/2020 13:13, Catalin Marinas wrote:
> On Fri, May 15, 2020 at 01:04:33PM +0100, Szabolcs Nagy wrote:
> > The 05/15/2020 12:27, Catalin Marinas wrote:
> > > Thanks Szabolcs. While we are at this, no-one so far asked for the
> > > GCR_EL1.RRND to be exposed to user (and this implies RGSR_EL1.SEED).
> > > Since RRND=1 guarantees a distribution "no worse" than that of RRND=0, I
> > > thought there isn't much point in exposing this configuration to the
> > > user. The only advantage of RRND=0 I see is that the kernel can change
> >
> > it seems RRND=1 is the impl specific algorithm.
>
> Yes, that's the implementation specific algorithm which shouldn't be
> worse than the standard one.
>
> > > the seed randomly but, with only 4 bits per tag, it really doesn't
> > > matter much.
> > >
> > > Anyway, mentioning it here in case anyone is surprised later about the
> > > lack of RRND configurability.
> >
> > i'm not familiar with how irg works.
>
> It generates a random tag based on some algorithm.
>
> > is the seed per process state that's set up at process startup in some
> > way? or shared (and thus effectively irg is non-deterministic in
> > userspace)?
>
> The seed is only relevant if the standard algorithm is used (RRND=0).
i wanted to understand if we can get deterministic
irg behaviour in user space (which may be useful
for debugging to get reproducible tag failures).
i guess if no control is exposed that means non-
deterministic irg. i think this is fine.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Bartosz Golaszewski @ 2020-05-15 12:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAK8P3a0u53rHSW=72CnnbhrY28Z+9f=Yv2K-bbj5OD+2Ds4unA@mail.gmail.com>
pt., 15 maj 2020 o 14:04 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Fri, May 15, 2020 at 9:11 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > czw., 14 maj 2020 o 18:19 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > >
> > > On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > +static unsigned int mtk_mac_intr_read_and_clear(struct mtk_mac_priv *priv)
> > > > +{
> > > > + unsigned int val;
> > > > +
> > > > + regmap_read(priv->regs, MTK_MAC_REG_INT_STS, &val);
> > > > + regmap_write(priv->regs, MTK_MAC_REG_INT_STS, val);
> > > > +
> > > > + return val;
> > > > +}
> > >
> > > Do you actually need to read the register? That is usually a relatively
> > > expensive operation, so if possible try to use clear the bits when
> > > you don't care which bits were set.
> > >
> >
> > I do care, I'm afraid. The returned value is being used in the napi
> > poll callback to see which ring to process.
>
> I suppose the other callers are not performance critical.
>
> For the rx and tx processing, it should be better to just always look at
> the queue directly and ignore the irq status, in particular when you
> are already in polling mode: suppose you receive ten frames at once
> and only process five but clear the irq flag.
>
> When the poll function is called again, you still need to process the
> others, but I would assume that the status tells you that nothing
> new has arrived so you don't process them until the next interrupt.
>
> For the statistics, I assume you do need to look at the irq status,
> but this doesn't have to be done in the poll function. How about
> something like:
>
> - in hardirq context, read the irq status word
> - irq rx or tx irq pending, call napi_schedule
> - if stats irq pending, schedule a work function
> - in napi poll, process both queues until empty or
> budget exhausted
> - if packet processing completed in poll function
> ack the irq and check again, call napi_complete
> - in work function, handle stats irq, then ack it
>
I see your point. I'll try to come up with something and send a new
version on Monday.
> > > > +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> > > > +{
> > > > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > > > + struct net_device *ndev = priv->ndev;
> > > > + int ret;
> > > > +
> > > > + for (;;) {
> > > > + mtk_mac_lock(priv);
> > > > +
> > > > + if (!mtk_mac_ring_descs_available(ring)) {
> > > > + mtk_mac_unlock(priv);
> > > > + break;
> > > > + }
> > > > +
> > > > + ret = mtk_mac_tx_complete_one(priv);
> > > > + if (ret) {
> > > > + mtk_mac_unlock(priv);
> > > > + break;
> > > > + }
> > > > +
> > > > + if (netif_queue_stopped(ndev))
> > > > + netif_wake_queue(ndev);
> > > > +
> > > > + mtk_mac_unlock(priv);
> > > > + }
> > > > +}
> > >
> > > It looks like most of the stuff inside of the loop can be pulled out
> > > and only done once here.
> > >
> >
> > I did that in one of the previous submissions but it was pointed out
> > to me that a parallel TX path may fill up the queue before I wake it.
>
> Right, I see you plugged that hole, however the way you hold the
> spinlock across the expensive DMA management but then give it
> up in each loop iteration feels like this is not the most efficient
> way.
>
Maybe my thinking is wrong here, but I assumed that with a spinlock
it's better to give other threads the chance to run in between each
iteration. I didn't benchmark it though.
> The easy way would be to just hold the lock across the entire
> loop and then be sure you do it right. Alternatively you could
> minimize the locking and only do the wakeup after up do the final
> update to the tail pointer, at which point you know the queue is not
> full because you have just freed up at least one entry.
>
Makes sense, I'll see what I can do.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 6/7] firmware: smccc: Add function to fetch SMCCC version
From: Sudeep Holla @ 2020-05-15 12:57 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Sudeep Holla, Will Deacon, linux-arm-kernel
In-Reply-To: <20200515120811.GF67718@C02TD0UTHF1T.local>
On Fri, May 15, 2020 at 01:08:11PM +0100, Mark Rutland wrote:
> On Wed, May 06, 2020 at 05:44:10PM +0100, Sudeep Holla wrote:
> > For backward compatibility reasons, PSCI maintains SMCCC version as
> > SMCCC didn't provide ARM_SMCCC_VERSION_FUNC_ID until v1.1
> >
> > Let us provide accessors to fetch the SMCCC version in PSCI so that
> > other SMCCC v1.1+ features can use it.
>
> Stale commit message? This was factored out of PSCI in the prior commit.
>
Duh ! Will drop that.
> > Reviewed-by: Steven Price <steven.price@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > drivers/firmware/smccc/smccc.c | 4 ++++
> > include/linux/arm-smccc.h | 9 +++++++++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> > index 488699aae24f..672974df0dfe 100644
> > --- a/drivers/firmware/smccc/smccc.c
> > +++ b/drivers/firmware/smccc/smccc.c
> > @@ -24,3 +24,7 @@ enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
> > return smccc_conduit;
> > }
> >
> > +u32 arm_smccc_version_get(void)
> > +{
> > + return smccc_version;
> > +}
>
> Could we please call this arm_smccc_get_version(), to align with the
> existing arm_smccc_1_1_get_conduit()?
>
Right will fix that. (I may suddenly got into SCMI mode where Greg or
someone asked me change all the function names to have verb at the end 😁)
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index 11fb20bfa8f7..8dd54dad1ec5 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -109,6 +109,15 @@ void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit);
> > */
> > enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void);
> >
> > +/**
> > + * arm_smccc_version_get()
> > + *
> > + * Returns the version to be used for SMCCCv1.1 or later.
> > + *
> > + * When SMCCCv1.1 or above is not present, assumes and returns SMCCCv1.0.
> > + */
> > +u32 arm_smccc_version_get(void);
>
> Can we please reword the last line to something like:
>
> | When SMCCCv1.1 or above is not present, returns SMCCCv1.0, but this
> | does not imply the presence of firmware or a valid conduit. Callers
> | handling SMCCCv1.0 must determine the conduit by other means.
>
Sure
> With all that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
Thanks,
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-15 13:11 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAMRc=Mf_vYt1J-cc6aZ2-Qv_YDEymVoC7ZiwuG9BrXoGMsXepw@mail.gmail.com>
On Fri, May 15, 2020 at 2:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> pt., 15 maj 2020 o 14:04 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > On Fri, May 15, 2020 at 9:11 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > >
> > > > It looks like most of the stuff inside of the loop can be pulled out
> > > > and only done once here.
> > > >
> > >
> > > I did that in one of the previous submissions but it was pointed out
> > > to me that a parallel TX path may fill up the queue before I wake it.
> >
> > Right, I see you plugged that hole, however the way you hold the
> > spinlock across the expensive DMA management but then give it
> > up in each loop iteration feels like this is not the most efficient
> > way.
> >
>
> Maybe my thinking is wrong here, but I assumed that with a spinlock
> it's better to give other threads the chance to run in between each
> iteration. I didn't benchmark it though.
It depends. You want to avoid lock contention (two threads trying to
get the lock at the same time) but you also want to avoid bouncing
around the spinlock between the caches.
In the contention case, what I think would happen here is that the
cleanup thread gives up the lock and the xmit function gets it, but
then the cleanup thread is spinning again, so you are still blocked
on one of the two CPUs but also pay the overhead of synchronizing
between the two.
Holding the lock the whole time would speed up both the good case
(no contention) and the bad case (bouncing the lock) a little bit
because it saves some overhead. Holding the lock for shorter
times (i.e. not during the cache operations) would reduce the
amount of lock-contention but not help in the good case.
Not needing a lock at all is generally best, but getting it right
is tricky ;-)
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
No need to encode the SoC specifics in the bridge driver. For the
imx8mq we can use the mux-input-bridge.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
.../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 ------
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
index 8aff2d68fc33..d2c2d4e19a25 100644
--- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -46,10 +46,6 @@ properties:
- const: phy_ref
- const: lcdif
- mux-controls:
- description:
- mux controller node to use for operating the input mux
-
phys:
maxItems: 1
description:
@@ -151,7 +147,6 @@ required:
- clocks
- compatible
- interrupts
- - mux-controls
- phy-names
- phys
- ports
@@ -180,7 +175,6 @@ examples:
<&clk IMX8MQ_CLK_LCDIF_PIXEL>;
clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- mux-controls = <&mux 0>;
power-domains = <&pgc_mipi>;
resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
<&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
This will be handled via the mux-input-bridge.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
drivers/gpu/drm/bridge/Kconfig | 1 -
drivers/gpu/drm/bridge/nwl-dsi.c | 61 --------------------------------
2 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3886c0f41bdd..11444f841e35 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
select DRM_PANEL_BRIDGE
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
- select MULTIPLEXER
select REGMAP_MMIO
help
This enables the Northwest Logic MIPI DSI Host controller as
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index b14d725bf609..8839f333f39c 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -12,7 +12,6 @@
#include <linux/math64.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
-#include <linux/mux/consumer.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/phy/phy.h>
@@ -44,9 +43,6 @@ enum transfer_direction {
DSI_PACKET_RECEIVE,
};
-#define NWL_DSI_ENDPOINT_LCDIF 0
-#define NWL_DSI_ENDPOINT_DCSS 1
-
struct nwl_dsi_plat_clk_config {
const char *id;
struct clk *clk;
@@ -94,7 +90,6 @@ struct nwl_dsi {
struct reset_control *rst_esc;
struct reset_control *rst_dpi;
struct reset_control *rst_pclk;
- struct mux_control *mux;
/* DSI clocks */
struct clk *phy_ref_clk;
@@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
}
dsi->tx_esc_clk = clk;
- dsi->mux = devm_mux_control_get(dsi->dev, NULL);
- if (IS_ERR(dsi->mux)) {
- ret = PTR_ERR(dsi->mux);
- if (ret != -EPROBE_DEFER)
- DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
- return ret;
- }
-
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
return 0;
}
-static int nwl_dsi_select_input(struct nwl_dsi *dsi)
-{
- struct device_node *remote;
- u32 use_dcss = 1;
- int ret;
-
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_LCDIF);
- if (remote) {
- use_dcss = 0;
- } else {
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_DCSS);
- if (!remote) {
- DRM_DEV_ERROR(dsi->dev,
- "No valid input endpoint found\n");
- return -EINVAL;
- }
- }
-
- DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
- (use_dcss) ? "DCSS" : "LCDIF");
- ret = mux_control_try_select(dsi->mux, use_dcss);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
-
- of_node_put(remote);
- return ret;
-}
-
-static int nwl_dsi_deselect_input(struct nwl_dsi *dsi)
-{
- int ret;
-
- ret = mux_control_deselect(dsi->mux);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to deselect input: %d\n", ret);
-
- return ret;
-}
-
static const struct drm_bridge_timings nwl_dsi_timings = {
.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
};
@@ -1175,12 +1121,6 @@ static int nwl_dsi_probe(struct platform_device *pdev)
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
- ret = nwl_dsi_select_input(dsi);
- if (ret < 0) {
- mipi_dsi_host_unregister(&dsi->dsi_host);
- return ret;
- }
-
drm_bridge_add(&dsi->bridge);
return 0;
}
@@ -1189,7 +1129,6 @@ static int nwl_dsi_remove(struct platform_device *pdev)
{
struct nwl_dsi *dsi = platform_get_drvdata(pdev);
- nwl_dsi_deselect_input(dsi);
mipi_dsi_host_unregister(&dsi->dsi_host);
drm_bridge_remove(&dsi->bridge);
pm_runtime_disable(&pdev->dev);
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 2/6] drm/bridge: Add mux-input bridge
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
This bridge allows to select the input source
via a mux controller. The input source is
determined via DT but it could become rutime
selectable in the future.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
drivers/gpu/drm/bridge/Kconfig | 9 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/mux-input.c | 238 +++++++++++++++++++++++++++++
3 files changed, 248 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/mux-input.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 04f876e985de..3886c0f41bdd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -206,6 +206,15 @@ config DRM_TI_TPD12S015
Texas Instruments TPD12S015 HDMI level shifter and ESD protection
driver.
+config DRM_MUX_INPUT
+ tristate "Bridge to select a video input source"
+ depends on OF
+ depends on DRM_BRIDGE
+ select MULTIPLEXER
+ help
+ Select this option if you want to select the input source to
+ a DRM bridge or panel via a separate mux chip.
+
source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..9f3370ce7e07 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MUX_INPUT) += mux-input.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/mux-input.c b/drivers/gpu/drm/bridge/mux-input.c
new file mode 100644
index 000000000000..24961d41ac30
--- /dev/null
+++ b/drivers/gpu/drm/bridge/mux-input.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Purism SPC
+ */
+
+#include <linux/module.h>
+#include <linux/mux/consumer.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_runtime.h>
+
+#include <drm/drm_bridge.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+
+#define DRV_NAME "mux-input-bridge"
+
+struct mux_input {
+ struct drm_bridge bridge;
+ struct drm_bridge *out;
+ struct device *dev;
+ struct mux_control *mux;
+ unsigned int n_inputs;
+ unsigned int input;
+ struct drm_bridge_timings timings;
+};
+
+static inline struct mux_input *bridge_to_mux_input(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mux_input, bridge);
+}
+
+static void mux_input_bridge_disable(struct drm_bridge *bridge)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+ pm_runtime_put(mux_input->dev);
+}
+
+static void mux_input_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+ pm_runtime_get(mux_input->dev);
+}
+
+static int mux_input_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ struct device *dev;
+ struct device_node *remote;
+ int ret;
+
+ /* Only attach to the selected input */
+ remote = of_graph_get_remote_node(mux_input->dev->of_node,
+ mux_input->input,
+ 0);
+ if (!remote)
+ return -EINVAL;
+
+ if (bridge->dev) {
+ dev = bridge->dev->dev;
+ if (dev->of_node != remote) {
+ DRM_DEV_DEBUG(mux_input->dev,
+ "Not attaching to endpoint %s",
+ dev->of_node->name);
+ return -EINVAL;
+ }
+ }
+ of_node_put(remote);
+
+ ret = drm_of_find_panel_or_bridge(mux_input->dev->of_node,
+ mux_input->n_inputs - 1, 0, &panel,
+ &panel_bridge);
+ if (ret)
+ return ret;
+
+ if (panel) {
+ panel_bridge = drm_panel_bridge_add(panel);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
+ }
+ mux_input->out = panel_bridge;
+
+ if (!mux_input->out)
+ return -EPROBE_DEFER;
+
+ /* Bubble downstream bridge timings upwards */
+ memcpy(&mux_input->timings, mux_input->out->timings,
+ sizeof(mux_input->timings));
+ mux_input->bridge.timings = &mux_input->timings;
+ return drm_bridge_attach(bridge->encoder, mux_input->out, bridge,
+ flags);
+}
+
+static void mux_input_bridge_detach(struct drm_bridge *bridge)
+{ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+ drm_of_panel_bridge_remove(mux_input->dev->of_node,
+ mux_input->n_inputs - 1, 0);
+}
+
+static const struct drm_bridge_funcs mux_input_bridge_funcs = {
+ .pre_enable = mux_input_bridge_pre_enable,
+ .disable = mux_input_bridge_disable,
+ .attach = mux_input_bridge_attach,
+ .detach = mux_input_bridge_detach,
+};
+
+static int mux_input_select_input(struct mux_input *mux_input)
+{
+ int ret;
+
+ DRM_DEV_DEBUG(mux_input->dev, "Using input %d as pixel source\n",
+ mux_input->input);
+ ret = mux_control_try_select(mux_input->mux, mux_input->input);
+ if (ret < 0) {
+ DRM_DEV_ERROR(mux_input->dev, "Failed to select input: %d\n",
+ ret);
+ }
+
+ return ret;
+}
+
+static int mux_input_deselect_input(struct mux_input *mux_input)
+{
+ int ret;
+
+ ret = mux_control_deselect(mux_input->mux);
+ if (ret < 0) {
+ DRM_DEV_ERROR(mux_input->dev, "Failed to deselect input: %d\n",
+ ret);
+ }
+
+ return ret;
+}
+
+static const struct of_device_id mux_input_dt_ids[] = {
+ { .compatible = "mux-input-bridge", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mux_input_dt_ids);
+
+static int mux_input_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct device_node *ep;
+ struct mux_input *mux_input;
+ int ret;
+
+ mux_input = devm_kzalloc(dev, sizeof(*mux_input), GFP_KERNEL);
+ if (!mux_input)
+ return -ENOMEM;
+
+ mux_input->dev = dev;
+
+ /*
+ * The largest numbered port is the output port. It determines
+ * total number of ports.
+ */
+ for_each_endpoint_of_node(np, ep) {
+ struct of_endpoint endpoint;
+
+ of_graph_parse_endpoint(ep, &endpoint);
+ mux_input->n_inputs = max(mux_input->n_inputs,
+ endpoint.port + 1);
+ }
+
+ if (mux_input->n_inputs < 2) {
+ DRM_DEV_ERROR(dev, "Not enough ports %d\n",
+ mux_input->n_inputs);
+ return -EINVAL;
+ }
+
+ if (device_property_read_u32(dev, "default-input",
+ &mux_input->input))
+ mux_input->input = 0;
+
+ if (mux_input->input > mux_input->n_inputs - 2) {
+ DRM_DEV_ERROR(dev, "Invalid default port %d\n",
+ mux_input->input);
+ return -EINVAL;
+ }
+
+ mux_input->mux = devm_mux_control_get(dev, NULL);
+ if (IS_ERR(mux_input->mux)) {
+ ret = PTR_ERR(mux_input->mux);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(dev, "Failed to get mux: %d\n", ret);
+ return ret;
+ }
+
+ mux_input->bridge.driver_private = mux_input;
+ mux_input->bridge.funcs = &mux_input_bridge_funcs;
+ mux_input->bridge.of_node = dev->of_node;
+
+ dev_set_drvdata(dev, mux_input);
+ pm_runtime_enable(dev);
+
+ ret = mux_input_select_input(mux_input);
+ if (ret < 0) {
+ pm_runtime_disable(&pdev->dev);
+ return ret;
+ }
+
+ drm_bridge_add(&mux_input->bridge);
+ return 0;
+}
+
+static int mux_input_remove(struct platform_device *pdev)
+{
+ struct mux_input *mux_input = platform_get_drvdata(pdev);
+
+ mux_input_deselect_input(mux_input);
+ drm_bridge_remove(&mux_input->bridge);
+ pm_runtime_disable(&pdev->dev);
+ return 0;
+}
+
+static struct platform_driver mux_input_driver = {
+ .probe = mux_input_probe,
+ .remove = mux_input_remove,
+ .driver = {
+ .of_match_table = mux_input_dt_ids,
+ .name = DRV_NAME,
+ },
+};
+
+module_platform_driver(mux_input_driver);
+
+MODULE_AUTHOR("Purism SPC");
+MODULE_DESCRIPTION("Mux input bridge");
+MODULE_LICENSE("GPL");
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 0/6] drm/bridge: Add mux input selection bridge
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
This bridge driver allows to select the input to a downstream bridge (or panel)
via device tree.
It can be useful to separate the pixel source selection from the actual bridge
processing the pixel data. E.g. NXP's imx8mq has two display controllers. Both
can feed the pixel data to the NWL DSI IP core. The input selection is done via
a separate mux register elsewhere on the chip, so separating this out avoids SoC
specific code in such drivers.
The current implementation allows to select the input source via device tree.
The long term goal is to allow to switch the input source at run time. This
can be useful to e.g. use the less power hungry display controller for normal
operation but switch to a the other display controller when running full screen
games (since it can detile textures more efficiently).
This was initially suggested by Laurent Pinchart¹. It is similar in spirit to
the video-mux in the media subsystem but for DRM bridges.
Besides the actual driver this series includes the necessary bits to demo the
usage for the Librem5 devkit.
The series is based on linux-next as of next-20200512.
¹ https://lore.kernel.org/dri-devel/20200415021908.GH19819@pendragon.ideasonboard.com/
Guido Günther (6):
dt-bindings: display/bridge: Add binding for input mux bridge
drm/bridge: Add mux-input bridge
dt-bindings: display/bridge/nwl-dsi: Drop mux handling
drm/bridge/nwl-dsi: Drop mux handling
arm64: dts: imx8mq: Add NWL dsi controller
arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel
.../display/bridge/mux-input-bridge.yaml | 123 +++++++++
.../bindings/display/bridge/nwl-dsi.yaml | 6 -
.../dts/freescale/imx8mq-librem5-devkit.dts | 81 ++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++
drivers/gpu/drm/bridge/Kconfig | 10 +-
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/mux-input.c | 238 ++++++++++++++++++
drivers/gpu/drm/bridge/nwl-dsi.c | 61 -----
8 files changed, 483 insertions(+), 68 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
create mode 100644 drivers/gpu/drm/bridge/mux-input.c
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 6/6] arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
Enable MIPI LCD panel output by adding nodes for the NWL DSI host
controller, the mux-input-bridge, the Rocktech panel and the eLCDIF
display controller.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
.../dts/freescale/imx8mq-librem5-devkit.dts | 81 +++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
index 7fc31c71a626..d98f9b8dede8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
@@ -841,6 +841,87 @@ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x19 /* WWAN_RESET */
};
};
+&lcdif {
+ status = "okay";
+
+ port@0 {
+ lcdif_dpi_out: endpoint {
+ remote-endpoint = <&dpi_mux_from_lcdif>;
+ };
+ };
+};
+
+&iomuxc_gpr {
+ mipi_mux: mipi-mux {
+ compatible = "mux-input-bridge";
+ mux-controls = <&mux 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ default-input = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpi_mux_from_lcdif: endpoint {
+ remote-endpoint = <&lcdif_dpi_out>;
+ };
+ };
+
+ port@1 { /* dcss */
+ reg = <1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ dpi_mux_out: endpoint {
+ remote-endpoint = <&nwl_dpi_in>;
+ };
+
+ };
+ };
+ };
+};
+
+&mipi_dsi {
+ status = "okay";
+ panel@0 {
+ compatible = "rocktech,jh057n00900";
+ reg = <0>;
+ backlight = <&backlight_dsi>;
+ reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
+ vcc-supply = <®_2v8_p>;
+ iovcc-supply = <®_1v8_p>;
+ port@0 {
+ panel_in: endpoint {
+ remote-endpoint = <&nwl_dsi_out>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ nwl_dpi_in: endpoint {
+ remote-endpoint = <&dpi_mux_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ nwl_dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
&pgc_gpu {
power-supply = <&buck3_reg>;
};
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
The bridge allows to select the input source via a mux controller.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
.../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
new file mode 100644
index 000000000000..4029cf63ee5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer
+
+maintainers:
+ - Guido Gúnther <agx@sigxcpu.org>
+
+description: |
+ The input multiplexer bridge allows to select an input source
+ via an associated mux controller.
+
+properties:
+ compatible:
+ const: mux-input-bridge
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ default-input:
+ description: The default input to use
+
+ mux-controls:
+ description:
+ mux controller node to use for operating the input mux
+
+ ports:
+ type: object
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^port@[0-9]+":
+ type: object
+ description:
+ At least three nodes containing endpoints connecting to the
+ pixel data inputs and outputs. The last port is always the
+ output port.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ endpoint:
+ description: sub-node describing the input
+ type: object
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+ required:
+ - port@0
+ - port@1
+ - port@2
+
+ additionalProperties: false
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - mux-controls
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ mipi-mux {
+ compatible = "mux-input-bridge";
+ default-input = <0>;
+ mux-controls = <&mux 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpi_mux_from_lcdif: endpoint {
+ remote-endpoint = <&lcdif_dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpi_mux_from_dccss: endpoint {
+ remote-endpoint = <&dcss_dpi_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dpi_mux_out: endpoint {
+ remote-endpoint = <&nwl_dpi_in>;
+ };
+ };
+ };
+ };
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: dts: imx8mq: Add NWL dsi controller
From: Guido Günther @ 2020-05-15 13:12 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Daniel Vetter, Rob Herring,
Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1589548223.git.agx@sigxcpu.org>
Add a node for the Northwestlogic MIPI DSI IP core, "disabled" by
default.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 0142f06ead12..6bbbf44e6be0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -889,6 +889,37 @@ sec_jr2: jr@3000 {
};
};
+ mipi_dsi: mipi-dsi@30a00000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mq-nwl-dsi";
+ reg = <0x30a00000 0x300>;
+ clocks = <&clk IMX8MQ_CLK_DSI_CORE>,
+ <&clk IMX8MQ_CLK_DSI_AHB>,
+ <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
+ <&clk IMX8MQ_CLK_DSI_PHY_REF>,
+ <&clk IMX8MQ_CLK_LCDIF_PIXEL>;
+ clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
+ assigned-clocks = <&clk IMX8MQ_CLK_DSI_AHB>,
+ <&clk IMX8MQ_CLK_DSI_CORE>,
+ <&clk IMX8MQ_CLK_DSI_IPG_DIV>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>,
+ <&clk IMX8MQ_SYS1_PLL_266M>;
+ assigned-clock-rates = <80000000>,
+ <266000000>,
+ <20000000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
+ <&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
+ <&src IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>,
+ <&src IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N>;
+ reset-names = "byte", "dpi", "esc", "pclk";
+ phys = <&dphy>;
+ phy-names = "dphy";
+ power-domains = <&pgc_mipi>;
+ status = "disabled";
+ };
+
dphy: dphy@30a00300 {
compatible = "fsl,imx8mq-mipi-dphy";
reg = <0x30a00300 0x100>;
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Andrew Lunn @ 2020-05-15 13:14 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Arnd Bergmann, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang, Fabien Parent,
linux-kernel@vger.kernel.org, David S . Miller,
Bartosz Golaszewski, John Crispin, Rob Herring,
moderated list:ARM/Mediatek SoC..., Andrew Perepech, Pedro Tsai,
Matthias Brugger, Jakub Kicinski, Mark Lee, Linux ARM,
Heiner Kallweit
In-Reply-To: <CAMRc=MeypzZBHo6dJGKm4JujYyejqHxtdo7Ts95DXuL0VuMYCw@mail.gmail.com>
On Fri, May 15, 2020 at 09:11:14AM +0200, Bartosz Golaszewski wrote:
> czw., 14 maj 2020 o 18:19 Arnd Bergmann <arnd@arndb.de> napisał(a):
> >
> > On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > > family. For now we only support full-duplex.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Looks very nice overall. Just a few things I noticed, and some ideas
> > that may or may not make sense:
> >
> > > +/* This is defined to 0 on arm64 in arch/arm64/include/asm/processor.h but
> > > + * this IP doesn't work without this alignment being equal to 2.
> > > + */
> > > +#ifdef NET_IP_ALIGN
> > > +#undef NET_IP_ALIGN
> > > +#endif
> > > +#define NET_IP_ALIGN 2
> >
> > Maybe you should just define your own macro instead of replacing
> > the normal one then?
> >
>
> I did in an earlier version and was told to use NET_IP_ALIGN but then
> found out its value on arm64 doesn't work for me so I did the thing
> that won't make anybody happy - redefine the existing constant. :)
Hi Bartosz
I did not realise ARM64 set it to 0. As Arnd suggested, please define
your own macro.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Gustavo Pimentel @ 2020-05-15 13:16 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada
Cc: devicetree@vger.kernel.org, Masami Hiramatsu,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Jassi Brar, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1589536743-6684-5-git-send-email-hayashi.kunihiko@socionext.com>
Hi Kunihiko,
On Fri, May 15, 2020 at 10:59:2, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> This gets iATU register area from reg property. In Synopsis DWC version
s/Synopsis/Synopsys
in all patches
> 4.80 or later, since iATU register area is separated from core register
> area, this area is necessary to get from DT independently.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a8dda39..493f105 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(priv->pci.dbi_base))
> return PTR_ERR(priv->pci.dbi_base);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> + if (res) {
> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
> + if (IS_ERR(priv->pci.atu_base))
> + priv->pci.atu_base = NULL;
> + }
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
> priv->base = devm_ioremap_resource(dev, res);
> if (IS_ERR(priv->base))
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 1/5] PCI: dwc: Add msi_host_isr() callback
From: Gustavo Pimentel @ 2020-05-15 13:20 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree@vger.kernel.org, Masami Hiramatsu,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Jassi Brar, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1589536743-6684-2-git-send-email-hayashi.kunihiko@socionext.com>
[+cc Marc; IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) maintainer]
On Fri, May 15, 2020 at 10:58:59, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> This adds msi_host_isr() callback function support to describe
> SoC-dependent service triggered by MSI.
>
> For example, when AER interrupt is triggered by MSI, the callback function
> reads SoC-dependent registers and detects that the interrupt is from AER,
> and invoke AER interrupts related to MSI.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 42fbfe2..7dd1021 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -112,13 +112,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> static void dw_chained_msi_isr(struct irq_desc *desc)
> {
> struct irq_chip *chip = irq_desc_get_chip(desc);
> - struct pcie_port *pp;
> + struct pcie_port *pp = irq_desc_get_handler_data(desc);
>
> - chained_irq_enter(chip, desc);
> + if (pp->ops->msi_host_isr)
> + pp->ops->msi_host_isr(pp);
>
> - pp = irq_desc_get_handler_data(desc);
> + chained_irq_enter(chip, desc);
> dw_handle_msi_irq(pp);
> -
> chained_irq_exit(chip, desc);
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 656e00f..e741967 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
> void (*scan_bus)(struct pcie_port *pp);
> void (*set_num_vectors)(struct pcie_port *pp);
> int (*msi_host_init)(struct pcie_port *pp);
> + void (*msi_host_isr)(struct pcie_port *pp);
> };
>
> struct pcie_port {
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 2/5] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Gustavo Pimentel @ 2020-05-15 13:21 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Rob Herring, Masahiro Yamada, Marc Zyngier
Cc: devicetree@vger.kernel.org, Masami Hiramatsu,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Jassi Brar, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1589536743-6684-3-git-send-email-hayashi.kunihiko@socionext.com>
[+cc Marc; IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) maintainer]
On Fri, May 15, 2020 at 10:59:0, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> The misc interrupts consisting of PME, AER, and Link event, is handled
> by INTx handler, however, these interrupts should be also handled by
> MSI handler.
>
> This adds the function uniphier_pcie_misc_isr() that handles misc
> intterupts, which is called from both INTx and MSI handlers.
> This function detects PME and AER interrupts with the status register,
> and invoke PME and AER drivers related to INTx or MSI.
>
> And this sets the mask for misc interrupts from INTx if MSI is enabled
> and sets the mask for misc interrupts from MSI if MSI is disabled.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 53 +++++++++++++++++++++++-------
> 1 file changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a5401a0..a8dda39 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -44,7 +44,9 @@
> #define PCL_SYS_AUX_PWR_DET BIT(8)
>
> #define PCL_RCV_INT 0x8108
> +#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
> #define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
> +#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
> #define PCL_CFG_BW_MGT_STATUS BIT(4)
> #define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
> #define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
> @@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
>
> static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
> {
> - writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
> + u32 val;
> +
> + val = PCL_RCV_INT_ALL_ENABLE;
> + if (pci_msi_enabled())
> + val |= PCL_RCV_INT_ALL_INT_MASK;
> + else
> + val |= PCL_RCV_INT_ALL_MSI_MASK;
> +
> + writel(val, priv->base + PCL_RCV_INT);
> writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
> }
>
> @@ -231,28 +241,48 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
> .map = uniphier_pcie_intx_map,
> };
>
> -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
> +static void uniphier_pcie_misc_isr(struct pcie_port *pp)
> {
> - struct pcie_port *pp = irq_desc_get_handler_data(desc);
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
> - struct irq_chip *chip = irq_desc_get_chip(desc);
> - unsigned long reg;
> - u32 val, bit, virq;
> + u32 val, virq;
>
> - /* INT for debug */
> val = readl(priv->base + PCL_RCV_INT);
>
> if (val & PCL_CFG_BW_MGT_STATUS)
> dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
> +
> if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
> dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
> - if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
> - dev_dbg(pci->dev, "Root Error\n");
> - if (val & PCL_CFG_PME_MSI_STATUS)
> - dev_dbg(pci->dev, "PME Interrupt\n");
> +
> + if (pci_msi_enabled()) {
> + if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
> + dev_dbg(pci->dev, "Root Error Status\n");
> + virq = irq_linear_revmap(pp->irq_domain, 0);
> + generic_handle_irq(virq);
> + }
> +
> + if (val & PCL_CFG_PME_MSI_STATUS) {
> + dev_dbg(pci->dev, "PME Interrupt\n");
> + virq = irq_linear_revmap(pp->irq_domain, 0);
> + generic_handle_irq(virq);
> + }
> + }
>
> writel(val, priv->base + PCL_RCV_INT);
> +}
> +
> +static void uniphier_pcie_irq_handler(struct irq_desc *desc)
> +{
> + struct pcie_port *pp = irq_desc_get_handler_data(desc);
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + unsigned long reg;
> + u32 val, bit, virq;
> +
> + /* misc interrupt */
> + uniphier_pcie_misc_isr(pp);
>
> /* INTx */
> chained_irq_enter(chip, desc);
> @@ -330,6 +360,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
>
> static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
> .host_init = uniphier_pcie_host_init,
> + .msi_host_isr = uniphier_pcie_misc_isr,
> };
>
> static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-15 13:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <20200514075942.10136-11-brgl@bgdev.pl>
On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> +static int mtk_mac_ring_pop_tail(struct mtk_mac_ring *ring,
> + struct mtk_mac_ring_desc_data *desc_data)
I took another look at this function because of your comment on the locking
the descriptor updates, which seemed suspicious as the device side does not
actually use the locks to access them
> +{
> + struct mtk_mac_ring_desc *desc = &ring->descs[ring->tail];
> + unsigned int status;
> +
> + /* Let the device release the descriptor. */
> + dma_rmb();
> + status = desc->status;
> + if (!(status & MTK_MAC_DESC_BIT_COWN))
> + return -1;
The dma_rmb() seems odd here, as I don't see which prior read
is being protected by this.
> + desc_data->len = status & MTK_MAC_DESC_MSK_LEN;
> + desc_data->flags = status & ~MTK_MAC_DESC_MSK_LEN;
> + desc_data->dma_addr = ring->dma_addrs[ring->tail];
> + desc_data->skb = ring->skbs[ring->tail];
> +
> + desc->data_ptr = 0;
> + desc->status = MTK_MAC_DESC_BIT_COWN;
> + if (status & MTK_MAC_DESC_BIT_EOR)
> + desc->status |= MTK_MAC_DESC_BIT_EOR;
> +
> + /* Flush writes to descriptor memory. */
> + dma_wmb();
The comment and the barrier here seem odd as well. I would have expected
a barrier after the update to the data pointer, and only a single store
but no read of the status flag instead of the read-modify-write,
something like
desc->data_ptr = 0;
dma_wmb(); /* make pointer update visible before status update */
desc->status = MTK_MAC_DESC_BIT_COWN | (status & MTK_MAC_DESC_BIT_EOR);
> + ring->tail = (ring->tail + 1) % MTK_MAC_RING_NUM_DESCS;
> + ring->count--;
I would get rid of the 'count' here, as it duplicates the information
that is already known from the difference between head and tail, and you
can't update it atomically without holding a lock around the access to
the ring. The way I'd do this is to have the head and tail pointers
in separate cache lines, and then use READ_ONCE/WRITE_ONCE
and smp barriers to access them, with each one updated on one
thread but read by the other.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/4] serial: 8250: Fix max baud limit in generic 8250 port
From: Andy Shevchenko @ 2020-05-15 13:48 UTC (permalink / raw)
To: Serge Semin
Cc: Vignesh Raghavendra, Catalin Marinas, linux-mips, Ralf Baechle,
Stefan Roese, Will Deacon, Paul Burton, Russell King, Long Cheng,
linux-serial, Jiri Slaby, Arnd Bergmann, Maxime Ripard,
Alexey Malahov, linux-mediatek, Mika Westerberg, linux-arm-kernel,
Thomas Bogendoerfer, Greg Kroah-Hartman, linux-kernel,
Serge Semin, Lukas Wunner
In-Reply-To: <20200506233136.11842-2-Sergey.Semin@baikalelectronics.ru>
On Thu, May 07, 2020 at 02:31:32AM +0300, Serge Semin wrote:
> Standard 8250 UART ports are designed in a way so they can communicate
> with baud rates up to 1/16 of a reference frequency. It's expected from
> most of the currently supported UART controllers. That's why the former
> version of serial8250_get_baud_rate() method called uart_get_baud_rate()
> with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX)
> and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like
> it was suggested in commit ("serial: 8250_mtk: support big baud rate."),
> caused acceptance of bauds, which was higher than the normal UART
> controllers actually supported. As a result if some user-space program
> requested to set a baud greater than (uartclk / 16) it would have been
> permitted without truncation, but then serial8250_get_divisor(baud)
> (which calls uart_get_divisor() to get the reference clock divisor) would
> have returned a zero divisor. Setting zero divisor will cause an
> unpredictable effect varying from chip to chip. In case of DW APB UART the
> communications just stop.
>
> Lets fix this problem by getting back the limitation of (uartclk +
> tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek
> 8250 UART ports driver developer shouldn't have touched it in the first
> place notably seeing he already provided a custom version of set_termios()
> callback in that glue-driver which took into account the extended baud
> rate values and accordingly updated the standard and vendor-specific
> divisor latch registers anyway.
Some of the hardware support PS != 16 (8250_mid), but for now it lies to UART
core for real UART clock because of its (core) hard cored assumption PS == 16
here and there.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.")
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Long Cheng <long.cheng@mediatek.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mediatek@lists.infradead.org
> ---
> drivers/tty/serial/8250/8250_port.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index f77bf820b7a3..4d83c85a7389 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2615,6 +2615,8 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
> struct ktermios *termios,
> struct ktermios *old)
> {
> + unsigned int tolerance = port->uartclk / 100;
> +
> /*
> * Ask the core to calculate the divisor for us.
> * Allow 1% tolerance at the upper limit so uart clks marginally
> @@ -2623,7 +2625,7 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
> */
> return uart_get_baud_rate(port, termios, old,
> port->uartclk / 16 / UART_DIV_MAX,
> - port->uartclk);
> + (port->uartclk + tolerance) / 16);
> }
>
> void
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error codes
From: Sudeep Holla @ 2020-05-15 13:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Sudeep Holla, Will Deacon, linux-arm-kernel
In-Reply-To: <20200515113801.GC67718@C02TD0UTHF1T.local>
On Fri, May 15, 2020 at 12:38:01PM +0100, Mark Rutland wrote:
> On Wed, May 06, 2020 at 05:44:07PM +0100, Sudeep Holla wrote:
> > Add the definition for SMCCC v1.2 version and new error code added.
> > While at it, also add a note that ARM DEN 0070A is deprecated and is
> > now merged into the main SMCCC specification(ARM DEN 0028C).
> >
> > Reviewed-by: Steven Price <steven.price@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> Hmm... the SMCCC v1.2 doc still seems to be EAC rather than a final
> release.
>
Right, I was told final release sometime in the recent past 😄
I mean April or mid-May, I will check on that but yes I agree on your
concerns.
> I don't expect that this would change, but I am a little hesitant to add
> other stuff based on an unfinalized spec. Do we know when the final
> release will be?
>
I have asked for the same as I write this email.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* kexec: arm: possible overwrite of initrd
From: Corentin Labbe @ 2020-05-15 13:57 UTC (permalink / raw)
To: ebiederm, kexec, linux-arm-kernel, linux; +Cc: linux-kernel
Hello
Following https://lkml.org/lkml/2020/4/6/96 I was able to boot my Cubieboard4 via kexec reliabily.
But now I have started to use kernelCI builds, I got problems.
All sunxi_defconfig kernel works but not multi_v7_defconfig which got:
[ 1.896540] Trying to unpack rootfs image as initramfs...
[ 1.896947] rootfs image is not initramfs (invalid magic at start of compressed archive); looks like an initrd
Then:
[ 3.927732] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[ 3.934489] VFS: Cannot open root device \"(null)\" or unknown-block(0,0): error -6
I have tryed to disable all related RD/RAMFS/compression CONFIGs without change.
Only the size of the kernel seems to matter which let me think that the initrd is overwritten by the kernel.
I use kexec-tools master
This is the output of my kexec run
run kexec with --debug --kexec-syscall --force --initrd /tmp/ramdisk --dtb /tmp/dtb --command-line='console=ttyS0,115200n8 root=/dev/ram0 earlycon=uart,mmio32,0x7000000 ip=dhcp'
Try gzip decompression.
kernel: 0xb65c0008 kernel_size: 0x853200
MEMORY RANGES
0000000020000000-000000009fffffff (0)
zImage header: 0x016f2818 0x00000000 0x00853200
zImage size 0x853200, file size 0x853200
zImage requires 0x00864200 bytes
offset 0x0000b810 tag 0x5a534c4b size 8
Decompressed kernel sizes:
text+data 0x01563f54 bss 0x0005ca84 total 0x015c09d8
Resulting kernel space: 0x01dc8154
Kernel: address=0x20008000 size=0x01dc8154
Initrd: address=0x21dd1000 size=0x01c64369
DT : address=0x23a36000 size=0x000060bb
kexec_load: entry = 0x20008000 flags = 0x280000
nr_segments = 3
segment[0].buf = 0xb65c0008
segment[0].bufsz = 0x853204
segment[0].mem = 0x20008000
segment[0].memsz = 0x854000
segment[1].buf = 0xb495b000
segment[1].bufsz = 0x1c64369
segment[1].mem = 0x21dd1000
segment[1].memsz = 0x1c65000
segment[2].buf = 0x4f030
segment[2].bufsz = 0x60bb
segment[2[ 39.693411] sun7i-dwmac 830000.ethernet eth0: Link is Down
].mem = 0x23a36000
segment[2].memsz = 0x7000
[ 39.709586] kexec_core: Starting new kernel
[ 40.120408] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.6.11-dirty (compile@Red) (gcc version 9.2.0 (Gentoo 9.2.0-r2 p3)) #43 SMP Fri May 15 15:31:20 CEST 2020
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Cubietech Cubieboard4
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] Ignoring RAM at 0x50000000-0xa0000000
[ 0.000000] Consider using a HIGHMEM enabled kernel.
[ 0.000000] cma: Reserved 64 MiB at 0x4c000000
[ 0.000000] percpu: Embedded 20 pages/cpu s49228 r8192 d24500 u81920
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 195072
[ 0.000000] Kernel command line: 'console=ttyS0,115200n8
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 662712K/786432K available (12288K kernel code, 1455K rwdata, 4788K rodata, 2048K init, 370K bss, 58184K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=8.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x2fc/0x494 with crng_init=0
[ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[ 0.000006] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[ 0.000018] Switching to timer-based delay loop, resolution 41ns
[ 0.001476] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.002630] Console: colour dummy device 80x30
[ 0.002953] printk: console [tty0] enabled
[ 0.002997] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
[ 0.003026] pid_max: default: 32768 minimum: 301
[ 0.003201] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003237] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003933] CPU: Testing write buffer coherency: ok
[ 0.004409] CPU0: update cpu_capacity 523
[ 0.004433] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.005032] Setting up static identity map for 0x20300000 - 0x203000ac
[ 0.005475] ARM CCI driver probed
[ 0.005783] sunxi multi cluster SMP support installed
[ 0.006198] rcu: Hierarchical SRCU implementation.
[ 0.008162] EFI services will not be available.
[ 0.008500] smp: Bringing up secondary CPUs ...
[ 0.009318] CPU1: update cpu_capacity 523
[ 0.009324] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.010326] CPU2: update cpu_capacity 523
[ 0.010333] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.011197] CPU3: update cpu_capacity 523
[ 0.011203] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.012178] CPU4: update cpu_capacity 1538
[ 0.012192] CPU4: thread -1, cpu 0, socket 1, mpidr 80000100
[ 0.012208] CPU4: Spectre v2: using ICIALLU workaround
[ 0.013422] CPU5: update cpu_capacity 1538
[ 0.013435] CPU5: thread -1, cpu 1, socket 1, mpidr 80000101
[ 0.013449] CPU5: Spectre v2: using ICIALLU workaround
[ 0.014582] CPU6: update cpu_capacity 1538
[ 0.014596] CPU6: thread -1, cpu 2, socket 1, mpidr 80000102
[ 0.014611] CPU6: Spectre v2: using ICIALLU workaround
[ 0.015757] CPU7: update cpu_capacity 1538
[ 0.015771] CPU7: thread -1, cpu 3, socket 1, mpidr 80000103
[ 0.015787] CPU7: Spectre v2: using ICIALLU workaround
[ 0.016070] smp: Brought up 1 node, 8 CPUs
[ 0.016110] SMP: Total of 8 processors activated (384.00 BogoMIPS).
[ 0.016125] CPU: All CPU(s) started in SVC mode.
[ 0.017054] devtmpfs: initialized
[ 0.027537] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.027597] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[ 0.029778] pinctrl core: initialized pinctrl subsystem
[ 0.032100] thermal_sys: Registered thermal governor 'step_wise'
[ 0.032374] DMI not present or invalid.
[ 0.032934] NET: Registered protocol family 16
[ 0.035272] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.038735] cpuidle: using governor menu
[ 0.038866] No ATAGs?
[ 0.039281] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.039335] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.041953] Serial: AMBA PL011 UART driver
[ 0.044873] sram 20000.sram: can't request region for resource [mem 0x00020000-0x0005ffff]
[ 0.044925] sram 20000.sram: could not map SRAM registers
[ 0.044976] sram: probe of 20000.sram failed with error -16
[ 0.104030] AT91: Could not find identification node
[ 0.105987] iommu: Default domain type: Translated
[ 0.106465] vgaarb: loaded
[ 0.107861] SCSI subsystem initialized
[ 0.108599] usbcore: registered new interface driver usbfs
[ 0.108705] usbcore: registered new interface driver hub
[ 0.108893] usbcore: registered new device driver usb
[ 0.110629] pps_core: LinuxPPS API ver. 1 registered
[ 0.110663] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.110732] PTP clock support registered
[ 0.111020] EDAC MC: Ver: 3.0.0
[ 0.114979] clocksource: Switched to clocksource arch_sys_counter
[ 1.892786] NET: Registered protocol family 2
[ 1.893828] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.893912] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.894090] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.894411] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.894622] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.894725] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.895155] NET: Registered protocol family 1
[ 1.896009] RPC: Registered named UNIX socket transport module.
[ 1.896047] RPC: Registered udp transport module.
[ 1.896077] RPC: Registered tcp transport module.
[ 1.896106] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.896144] PCI: CLS 0 bytes, default 64
[ 1.896540] Trying to unpack rootfs image as initramfs...
[ 1.896947] rootfs image is not initramfs (invalid magic at start of compressed archive); looks like an initrd
[ 2.040365] Freeing initrd memory: 29076K
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: at91: Configure I2C SCL gpio as open drain
From: Codrin Ciubotariu @ 2020-05-15 14:00 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-kernel
Cc: ludovic.desroches, Codrin Ciubotariu, alexandre.belloni, robh+dt
The SCL gpio pin used by I2C bus for recovery needs to be configured as
open drain.
Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
Fixes: a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
Fixes: 8fb82f050cf6 ("ARM: dts: at91: sama5d4: add i2c gpio pinctrl")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 6 +++---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +++---
arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
arch/arm/boot/dts/sama5d4.dtsi | 6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 32435ce1dab2..be33483013e7 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -182,7 +182,7 @@ i2c0: i2c@f8028000 {
pinctrl-0 = <&pinctrl_i2c0_default>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA PIN_PD21 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD22 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
};
@@ -203,7 +203,7 @@ i2c2: i2c@600 {
pinctrl-0 = <&pinctrl_flx0_default>;
pinctrl-1 = <&pinctrl_flx0_gpio>;
sda-gpios = <&pioA PIN_PB28 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PB29 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PB29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
atmel,fifo-size = <16>;
status = "okay";
};
@@ -234,7 +234,7 @@ i2c1: i2c@fc028000 {
pinctrl-0 = <&pinctrl_i2c1_default>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioA PIN_PC6 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PC7 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PC7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
at24@50 {
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e0c6cff1a312..862bf54376f1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -185,7 +185,7 @@ i2c0: i2c@f8028000 {
pinctrl-0 = <&pinctrl_i2c0_default>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA PIN_PD21 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD22 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
i2c-sda-hold-time-ns = <350>;
status = "okay";
@@ -390,7 +390,7 @@ i2c2: i2c@600 {
pinctrl-0 = <&pinctrl_flx4_default>;
pinctrl-1 = <&pinctrl_flx4_gpio>;
sda-gpios = <&pioA PIN_PD12 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD13 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
atmel,fifo-size = <16>;
i2c-analog-filter;
i2c-digital-filter;
@@ -408,7 +408,7 @@ i2c1: i2c@fc028000 {
i2c-digital-filter-width-ns = <35>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioA PIN_PD4 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA PIN_PD5 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA PIN_PD5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
at24@54 {
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index f3ce561b46ab..c53e48445e4d 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -163,7 +163,7 @@ i2c0: i2c@f0014000 {
pinctrl-0 = <&pinctrl_i2c0>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 18>;
@@ -181,7 +181,7 @@ i2c1: i2c@f0018000 {
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioC 26 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioC 27 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioC 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
@@ -367,7 +367,7 @@ i2c2: i2c@f801c000 {
pinctrl-0 = <&pinctrl_i2c2>;
pinctrl-1 = <&pinctrl_i2c2_gpio>;
sda-gpios = <&pioA 18 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 19 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 20>;
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index c9c0316b5b0e..fff679734c9c 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -462,7 +462,7 @@ i2c0: i2c@f8014000 {
pinctrl-0 = <&pinctrl_i2c0>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioA 31 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 32>;
@@ -484,7 +484,7 @@ i2c1: i2c@f8018000 {
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_gpio>;
sda-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioE 30 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioE 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 33>;
@@ -529,7 +529,7 @@ i2c2: i2c@f8024000 {
pinctrl-0 = <&pinctrl_i2c2>;
pinctrl-1 = <&pinctrl_i2c2_gpio>;
sda-gpios = <&pioB 29 GPIO_ACTIVE_HIGH>;
- scl-gpios = <&pioB 30 GPIO_ACTIVE_HIGH>;
+ scl-gpios = <&pioB 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 34>;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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