* [PATCH] clk: imx6: don't restrict LDB mux changes on QuadPlus
From: Lucas Stach @ 2017-01-13 17:39 UTC (permalink / raw)
To: linux-arm-kernel
The LDB mux/gate layout has been fixed on QuadPlus, so there is no need
to restrict the LDB mux changes on this hardware, as the erratum
preventing this from working properly is gone.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 42ffc1c92bab..c07df719b8a3 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -592,15 +592,20 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
imx6q_mmdc_ch1_mask_handshake(base);
- /*
- * The LDB_DI0/1_SEL muxes are registered read-only due to a hardware
- * bug. Set the muxes to the requested values before registering the
- * ldb_di_sel clocks.
- */
- init_ldb_clks(np, base);
+ if (clk_on_imx6qp()) {
+ clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
+ clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_flags("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
+ } else {
+ /*
+ * The LDB_DI0/1_SEL muxes are registered read-only due to a hardware
+ * bug. Set the muxes to the requested values before registering the
+ * ldb_di_sel clocks.
+ */
+ init_ldb_clks(np, base);
- clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
- clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ }
clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL] = imx_clk_mux_flags("ipu1_di0_pre_sel", base + 0x34, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
clk[IMX6QDL_CLK_IPU1_DI1_PRE_SEL] = imx_clk_mux_flags("ipu1_di1_pre_sel", base + 0x34, 15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
clk[IMX6QDL_CLK_IPU2_DI0_PRE_SEL] = imx_clk_mux_flags("ipu2_di0_pre_sel", base + 0x38, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
--
2.11.0
^ permalink raw reply related
* [PATCH 12/37] PCI: dwc: Create a new config symbol to enable pci dwc host
From: Joao Pinto @ 2017-01-13 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-13-git-send-email-kishon@ti.com>
Hi Kishon,
?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Now that pci designware host has a separate file, create a new
> config symbol to select the host only driver. This is in preparation
> to enable endpoint support to designware driver.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/Kconfig | 26 +++++++++++++++-----------
> drivers/pci/dwc/Makefile | 3 ++-
> drivers/pci/dwc/pcie-designware.h | 29 +++++++++++++++++++++++++----
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
You are already working in a base where dwc/ already exists. I know you made a
rename / re-structure patch for pci, but I think it was not yet accepted, right?
I don't see it in any of Bjorn' dev branches.
Thanks.
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 8b08519..d0bdfb5 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -3,13 +3,17 @@ menu "DesignWare PCI Core Support"
>
> config PCIE_DW
> bool
> +
> +config PCIE_DW_HOST
> + bool
> depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW
>
> config PCI_DRA7XX
> bool "TI DRA7xx PCIe controller"
> depends on OF && HAS_IOMEM && TI_PIPE3
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Enables support for the PCIe controller in the DRA7xx SoC. There
> are two instances of PCIe controller in DRA7xx. This controller can
> @@ -18,7 +22,7 @@ config PCI_DRA7XX
> config PCIE_DW_PLAT
> bool "Platform bus based DesignWare PCIe Controller"
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> ---help---
> This selects the DesignWare PCIe controller support. Select this if
> you have a PCIe controller on Platform bus.
> @@ -32,21 +36,21 @@ config PCI_EXYNOS
> depends on SOC_EXYNOS5440 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCI_IMX6
> bool "Freescale i.MX6 PCIe controller"
> depends on SOC_IMX6Q || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCIE_SPEAR13XX
> bool "STMicroelectronics SPEAr PCIe controller"
> depends on ARCH_SPEAR13XX || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe support on SPEAr13XX SoCs.
>
> @@ -55,7 +59,7 @@ config PCI_KEYSTONE
> depends on ARCH_KEYSTONE || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCI controller support on Keystone
> SoCs. The PCI controller on Keystone is based on Designware hardware
> @@ -67,7 +71,7 @@ config PCI_LAYERSCAPE
> depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> depends on PCI_MSI_IRQ_DOMAIN
> select MFD_SYSCON
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on Layerscape SoCs.
>
> @@ -76,7 +80,7 @@ config PCI_HISI
> bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on HiSilicon
> Hip05 and Hip06 SoCs
> @@ -86,7 +90,7 @@ config PCIE_QCOM
> depends on (ARCH_QCOM || COMPILE_TEST) && OF
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Qualcomm SoCs. The
> PCIe controller uses the Designware core plus Qualcomm-specific
> @@ -97,7 +101,7 @@ config PCIE_ARMADA_8K
> depends on ARCH_MVEBU || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCIe controller support on
> Armada-8K SoCs. The PCIe controller on Armada-8K is based on
> @@ -109,7 +113,7 @@ config PCIE_ARTPEC6
> depends on MACH_ARTPEC6 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs. This PCIe controller uses the DesignWare core.
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 3b57e55..a2df13c 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_PCIE_DW) += pcie-designware.o pcie-designware-host.o
> +obj-$(CONFIG_PCIE_DW) += pcie-designware.o
> +obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
> obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
> obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
> obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index 808d17b..8f3dcb2 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -162,10 +162,6 @@ struct dw_pcie {
>
> int dw_pcie_read(void __iomem *addr, int size, u32 *val);
> int dw_pcie_write(void __iomem *addr, int size, u32 val);
> -irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> -void dw_pcie_msi_init(struct pcie_port *pp);
> -void dw_pcie_setup_rc(struct pcie_port *pp);
> -int dw_pcie_host_init(struct pcie_port *pp);
>
> u32 dw_pcie_readl_dbi(struct dw_pcie *pci, u32 reg);
> void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
> @@ -175,4 +171,29 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> int type, u64 cpu_addr, u64 pci_addr,
> u32 size);
> void dw_pcie_setup(struct dw_pcie *pci);
> +
> +#ifdef CONFIG_PCIE_DW_HOST
> +irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> +void dw_pcie_msi_init(struct pcie_port *pp);
> +void dw_pcie_setup_rc(struct pcie_port *pp);
> +int dw_pcie_host_init(struct pcie_port *pp);
> +#else
> +static inline irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> +{
> + return IRQ_NONE;
> +}
> +
> +static inline void dw_pcie_msi_init(struct pcie_port *pp)
> +{
> +}
> +
> +static inline void dw_pcie_setup_rc(struct pcie_port *pp)
> +{
> +}
> +
> +static inline int dw_pcie_host_init(struct pcie_port *pp)
> +{
> + return 0;
> +}
> +#endif
> #endif /* _PCIE_DESIGNWARE_H */
>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Andrew Jones @ 2017-01-13 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112165629.nbczamlqlpsqaauh@hawk.localdomain>
On Thu, Jan 12, 2017 at 05:56:29PM +0100, Andrew Jones wrote:
> On Thu, Jan 12, 2017 at 01:29:24PM +0100, Paolo Bonzini wrote:
> >
> >
> > On 11/01/2017 17:28, Alex Benn?e wrote:
> > > So we can have portable formatting of uint32_t types. However there is
> > > a catch. Different compilers can use legally subtly different types
> > > though so we need to probe the compiler defined intdef.h first.
> >
> > Interesting, what platform has long uint32_t? I thought the issue was
> > whether 64-bit is long or "long long".
> >
> > Paolo
> >
> > > Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> > > ---
> > > Makefile | 1 +
> > > configure | 13 +++++++++++++
> > > lib/libcflat.h | 9 +++++++++
> > > 3 files changed, 23 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index a32333b..9822d9a 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> > > CFLAGS += $(fno_stack_protector)
> > > CFLAGS += $(fno_stack_protector_all)
> > > CFLAGS += $(wno_frame_address)
> > > +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
> > >
> > > CXXFLAGS += $(CFLAGS)
> > >
> > > diff --git a/configure b/configure
> > > index 995c8fa..127868c 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> > > ln -fs $testdir/run $testdir-run
> > > fi
> > >
> > > +# check if uint32_t needs a long format modifier
> > > +cat << EOF > lib_test.c
> > > +#include <inttypes.h>
> > > +EOF
> > > +
> > > +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>
> This won't work with cross compilers that don't have inttypes.h in their
> path (like mine). How about something like
Paolo,
I see you merged the above. As I stated in this mail, that doesn't work
for my environment, neither arm nor powerpc cross-compile for me now...
Please replace with something like I proposed below. We can probably
replace the awk with a grep though.
Thanks,
drew
>
> cat << EOF > lib_test.c
> __UINT32_TYPE__
> EOF
> u32_long="`aarch64-linux-gnu-gcc lib_test.c -E | awk '/unsigned/ && $2 == "long"'`"
>
> Although I feel there should be a compiler macro way to do this without
> a need for configure/makefile trickery at all...
>
> Thanks,
> drew
>
>
> > > +exit=$?
> > > +if [ $exit -eq 0 ]; then
> > > + u32_long=true
> > > +fi
> > > +rm -f lib_test.c
> > > +
> > > # check for dependent 32 bit libraries
> > > if [ "$arch" != "arm" ]; then
> > > cat << EOF > lib_test.c
> > > @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> > > FIRMWARE=$firmware
> > > ENDIAN=$endian
> > > PRETTY_PRINT_STACKS=$pretty_print_stacks
> > > +U32_LONG_FMT=$u32_long
> > > EOF
> > > diff --git a/lib/libcflat.h b/lib/libcflat.h
> > > index 380395f..e80fc50 100644
> > > --- a/lib/libcflat.h
> > > +++ b/lib/libcflat.h
> > > @@ -58,12 +58,21 @@ typedef _Bool bool;
> > > #define true 1
> > >
> > > #if __SIZEOF_LONG__ == 8
> > > +# define __PRI32_PREFIX
> > > # define __PRI64_PREFIX "l"
> > > # define __PRIPTR_PREFIX "l"
> > > #else
> > > +#if defined(__U32_LONG_FMT__)
> > > +# define __PRI32_PREFIX "l"
> > > +#else
> > > +# define __PRI32_PREFIX
> > > +#endif
> > > # define __PRI64_PREFIX "ll"
> > > # define __PRIPTR_PREFIX
> > > #endif
> > > +#define PRId32 __PRI32_PREFIX "d"
> > > +#define PRIu32 __PRI32_PREFIX "u"
> > > +#define PRIx32 __PRI32_PREFIX "x"
> > > #define PRId64 __PRI64_PREFIX "d"
> > > #define PRIu64 __PRI64_PREFIX "u"
> > > #define PRIx64 __PRI64_PREFIX "x"
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions
From: Christoph Hellwig @ 2017-01-13 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-17-git-send-email-kishon@ti.com>
Hi Kishon,
a couple comments on the configfs layout based on my experiments with
your previous drop to implement a NVMe device using it.
I don't think most of these configfs files should be present here, as
they are properties of the implemented PCIe devices. E.g. for my
NVMe device they will be sort of hardcoded most of the time, as they
would be for other devices that would always have a fixed vendor/device/
class ID, cacheline size, etc.
In the end what we'll to be able to do here is to be able to create
a directory for each function driver, which then can create it's own
attributes inside it.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: Tony Lindgren @ 2017-01-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311234-21978-2-git-send-email-ravibabu@ti.com>
* Ravi Babu <ravibabu@ti.com> [170113 04:41]:
> The SPL size for DRA74x platform has increased and
> is now more than 64KB. Increase QSPI SPL partition
> size to 256KB for DRA74x EVM.
>
> QSPI partition numbering changes because of this.
And this will break the existing partitions potentially..
See what was discussed on the list few days ago in thread
"[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND
partition table".
It's best to have these left empty or as they originally
were and let u-boot configure the partitions.
Regards,
Tony
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
> 1 file changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 132f2be..2784241 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -681,41 +681,29 @@
> */
> partition at 0 {
> label = "QSPI.SPL";
> - reg = <0x00000000 0x000010000>;
> + reg = <0x00000000 0x000040000>;
> };
> partition at 1 {
> - label = "QSPI.SPL.backup1";
> - reg = <0x00010000 0x00010000>;
> - };
> - partition at 2 {
> - label = "QSPI.SPL.backup2";
> - reg = <0x00020000 0x00010000>;
> - };
> - partition at 3 {
> - label = "QSPI.SPL.backup3";
> - reg = <0x00030000 0x00010000>;
> - };
> - partition at 4 {
> label = "QSPI.u-boot";
> reg = <0x00040000 0x00100000>;
> };
> - partition at 5 {
> + partition at 2 {
> label = "QSPI.u-boot-spl-os";
> reg = <0x00140000 0x00080000>;
> };
> - partition at 6 {
> + partition at 3 {
> label = "QSPI.u-boot-env";
> reg = <0x001c0000 0x00010000>;
> };
> - partition at 7 {
> + partition at 4 {
> label = "QSPI.u-boot-env.backup1";
> reg = <0x001d0000 0x0010000>;
> };
> - partition at 8 {
> + partition at 5 {
> label = "QSPI.kernel";
> reg = <0x001e0000 0x0800000>;
> };
> - partition at 9 {
> + partition at 6 {
> label = "QSPI.file-system";
> reg = <0x009e0000 0x01620000>;
> };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] firmware: qcom: scm: Mask APQ8064 core clk dependency
From: Bjorn Andersson @ 2017-01-13 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484175483-25333-1-git-send-email-andy.gross@linaro.org>
On Wed 11 Jan 14:58 PST 2017, Andy Gross wrote:
> This patch masks the core clk requirement for the APQ8064. Until the
> other peripherals correctly describe their clock dependencies or the
> bus driver is put in place to handle the RPM dependencies, this bit
> will remain masked.
>
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> drivers/firmware/qcom_scm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 893f953ea..65d0d9d 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -387,7 +387,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
>
> static const struct of_device_id qcom_scm_dt_match[] = {
> { .compatible = "qcom,scm-apq8064",
> - .data = (void *) SCM_HAS_CORE_CLK,
> + /* FIXME: This should have .data = (void *) SCM_HAS_CORE_CLK */
> },
> { .compatible = "qcom,scm-msm8660",
> .data = (void *) SCM_HAS_CORE_CLK,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3066d614-0676-319a-6149-6d723e1cf35f@ti.com>
On 01/13/2017 06:04 AM, Sekhar Nori wrote:
> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
...
>
> There are couple of checkpatch errors that show up. The compatible
> "lego,ev3" needs to be documented in
> Documentation/devicetree/bindings/arm/davinci.txt
>
> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
> manufacturer name is not clear,
> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
> "24c128"
The mfg is microchip, so I guess I will just go with "24c128"
>
> Finally, lego needs to be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Can you please submit the documentation portions as separate patches in
> a series along with this patch.
Yes.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH] KVM: arm64: Increase number of memslots to 512
From: Marc Zyngier @ 2017-01-13 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGOz-0aD-hV7sDAX70pSGdCj1J4s4xc4qQBwbaKzVZArfRK2AQ@mail.gmail.com>
On 13/01/17 17:25, Linu Cherian wrote:
> On Fri, Jan 13, 2017 at 5:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Hi Linu,
>>
>> On 11/01/17 16:52, linucherian at gmail.com wrote:
>>> From: Linu Cherian <linu.cherian@cavium.com>
>>>
>>> Having only 32 memslots is a real constraint for the maximum number of
>>> PCI devices that can be assigned to a single guest. Assuming each PCI
>>> device/virtual function having two memory BAR regions, we could assign
>>> only 15 devices/virtual functions to a guest.
>>>
>>> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
>>> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
>>>
>>> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
>>> ---
>>> arch/arm/kvm/arm.c | 3 +++
>>> arch/arm64/include/asm/kvm_host.h | 2 +-
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index 8f92efa..a19389b 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>> case KVM_CAP_MAX_VCPUS:
>>> r = KVM_MAX_VCPUS;
>>> break;
>>> + case KVM_CAP_NR_MEMSLOTS:
>>> + r = KVM_USER_MEM_SLOTS;
>>> + break;
>>> case KVM_CAP_MSI_DEVID:
>>> if (!kvm)
>>> r = -EINVAL;
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index e505038..88f017d 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -30,7 +30,7 @@
>>>
>>> #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>>>
>>> -#define KVM_USER_MEM_SLOTS 32
>>> +#define KVM_USER_MEM_SLOTS 508
>>> #define KVM_PRIVATE_MEM_SLOTS 4
>>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>>> #define KVM_HALT_POLL_NS_DEFAULT 500000
>>>
>>
>> I'm not opposed to that patch, but if I may ask: how has that been tested?
>>
>
> I have tested this on Cavium ARM64 SOC, by assigning multiple
> VFs(virtual functions) of a SRIOV device to a single VM. Each VF has
> two memory regions(two BARs) implemented.
>
> Without, this change, when the number of virtual functions assigned to
> the guest crosses 15, qemu aborts with
> "kvm_alloc_slot: no free slot available", during guest kernel booting.
>
> Now, with this change guest kernel boots fine with more than 15 VFs
> assigned(tested upto 29) and also all the PCI VFs assigned to the guest
> get listed under lspci with memory resources configured.
>
> Please let me know if you are looking for more specifics like bootlogs etc.
Let me be more precise. At the moment, KVM on arm64 doesn't support the
delivery of MSIs generated by physical devices into a guest (patches are
in progress, but not merged yet). So unless you used devices that have
no need for interrupts, I don't see how this works.
Can you shed some light on your test process?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc4
From: Kevin Hilman @ 2017-01-13 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Please pull a couple fixes for v4.10-rc.
The branch is based on v4.10-rc3 to not conflict with another DT fix
that when in for -rc2.
Kevin
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-fixes-2
for you to fetch changes up to 64a8225e9f9dec0e5cd2f5640743699056da4e4e:
ARM64: dts: meson-gx: Add reserved memory zone and usable memory range (2017-01-12 17:00:50 -0800)
----------------------------------------------------------------
Amlogic fixes for v4.10-rc4
- odroid-c2: disable DVFS to avoid crashes due to broken SCPI
- fix misc. crashes by adding known reserved memory regions
----------------------------------------------------------------
Neil Armstrong (2):
ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 +++++++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
18 files changed, 111 insertions(+), 19 deletions(-)
^ permalink raw reply
* [RFC PATCH v2 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Kim Phillips @ 2017-01-13 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113170307.GK3253@arm.com>
On Fri, 13 Jan 2017 17:03:07 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 13, 2017 at 10:40:42AM -0600, Kim Phillips wrote:
> > On Fri, 13 Jan 2017 16:03:48 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> > > +#define DRVNAME "arm_spe_pmu"
> >
> > PMU is implied. "arm_spe"?
>
> As stated before, I'm going for consistency here.
me too, but apparently under the user-visible interface domain rather
than the driver source path domain.
> Is it causing any
> real issues on the tooling side?
Intel has a consistent "intel_pt", "intel_bts", and 'pmu' occurs
nowhere in their nomenclature.
Whether good or bad, we currently have "cs_etm". This patch now gives
us "arm_spe_pmu". I'm just trying to save the suffix consistency for
now, esp. since IDK how amenable "cs_etm" is to change, and 'perf list'
calls things "PMU event"s anyway.
I think the root cause might be the device tree node's
"arm,arm-spe-pmu-v1" compatiblity string, which I also find
a bit self-redundant ("arm,arm-"), but I'm not familiar with what's
being denoted there either (e.g., if the latter 'arm-' is an arch
reference, then SPE's might be 'armv8'?). The device tree node isn't
exposed to the user, however.
> > > + if (is_kernel_in_hyp_mode()) {
> > > + if (attr->exclude_kernel != attr->exclude_hv)
> > > + return -EOPNOTSUPP;
> > > + } else if (!attr->exclude_hv) {
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + reg = arm_spe_event_to_pmsfcr(event);
> > > + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return 0;
> > > +}
> >
> > Please insert pr_* statements before blindly returning errors before a
> > better facility becomes available.
>
> That was discussed in the thread I linked to last time:
>
> https://lkml.org/lkml/2015/8/26/661
ok, thanks for pinpointing the exact message this time.
> and there are good reasons not to add those prints.
Processing that message (indentations are now quoting Peter Zijlstra):
> Not really. That is something that's limited to root. Whereas the
> problem is very much wider than that.
For the purposes of the SPE driver discussion, I'm ok limiting the
context of using the SPE as root.
> If you set one bit wrong in the pretty large perf_event_attr you've got
> a fair chance of getting -EINVAL on trying to create the event. Good
> luck finding what you did wrong.
yes, this is the problem, and the SPE introduces a whole new set of
validity requirements that should be being communicated clearly, e.g.,
its restrictive event frequency specification.
> Any user can create events (for their own tasks), this does not require
> root.
I don't think this is relevant to our discussion.
> Allowing users to flip your @debugging flag would be an insta DoS.
I think this is a reference to the non-root case, and might be mitigated
by either using dynamic or ratelimited pr_ versions if it were.
> Furthermore, its very unfriendly in that you have to (manually) go
> correlate random dmesg output with some program action.
Andrew Morton addresses this, and I did read all other follow-ups and
still conclude that adding pr_ messages is 1000x better than not, for
the user, and at least for the time being.
Kim
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d69ff4b-c3a6-5126-2590-2268d3b25f92@lechnology.com>
On 01/13/2017 12:16 PM, David Lechner wrote:
> On 01/13/2017 06:04 AM, Sekhar Nori wrote:
>> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>>
> ...
>>
>> There are couple of checkpatch errors that show up. The compatible
>> "lego,ev3" needs to be documented in
>> Documentation/devicetree/bindings/arm/davinci.txt
>>
>> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
>> manufacturer name is not clear,
>> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
>> "24c128"
>
> The mfg is microchip, so I guess I will just go with "24c128"
I think I have let the device tree bindings doc confuse me. On second
though, I think the correct thing is to included the manufacturer.
>
>>
>> Finally, lego needs to be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>> Can you please submit the documentation portions as separate patches in
>> a series along with this patch.
>
> Yes.
>
>>
>> Thanks,
>> Sekhar
>>
>
^ permalink raw reply
* [GIT PULL] arm64 fixes for 4.10-rc4
From: Catalin Marinas @ 2017-01-13 18:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 41c066f2c4d436c535616fe182331766c57838f0:
arm64: assembler: make adr_l work in modules under KASLR (2017-01-12 18:10:52 +0000)
----------------------------------------------------------------
- Fix huge_ptep_set_access_flags() to return "changed" when any of the
ptes in the contiguous range is changed, not just the last one
- Fix the adr_l assembly macro to work in modules under KASLR
----------------------------------------------------------------
Ard Biesheuvel (1):
arm64: assembler: make adr_l work in modules under KASLR
Huang Shijie (1):
arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
arch/arm64/include/asm/assembler.h | 36 +++++++++++++++++++++++++++---------
arch/arm64/mm/hugetlbpage.c | 2 +-
2 files changed, 28 insertions(+), 10 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-13 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113172154.GL3253@arm.com>
On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > > > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > > > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > > > > From: Will Deacon <will.deacon@arm.com>
> > > > > > >
> > > > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > > > > >
> > > > > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > > >
> > > > > > > <system hangs failing to read partition table>
> > > > > > >
> > > > > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > > > > then requires the vring code to use the DMA API to establish translations,
> > > > > > > otherwise all transactions will result in fatal faults and termination.
> > > > > > >
> > > > > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > > > > (the topology is all described by firmware tables such as device-tree or
> > > > > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > > > > >
> > > > > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > > >
> > > > > > I'd like to better understand then need for this one.
> > > > > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > > > > >
> > > > > > I'd rather we avoided need for more hacks and just
> > > > > > have everyone switch to that.
> > > > >
> > > > > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> > > > >
> > > > > 1. It doesn't exist for legacy devices, which are all we have on the
> > > > > platform in question.
> > > > >
> > > > > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > > > > my patch ;). Thanks.
> > > > >
> > > > > In which case, for non-legacy devices we should definitely be using
> > > > > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > > > > world of flying cars, could we unconditionally set the DMA ops on ARM
> > > > > for legacy devices? The alternative is disabling the SMMU altogether,
> > > > > but that's less than ideal because there are non-virtio devices on the
> > > > > same PCI bus.
> > > > >
> > > >
> > > > I'd rather people didn't use SMMU with legacy devices.
> > >
> > > I'm afraid we've been doing that for two years and the model already
> > > exists in a mature state, being actively used for development and
> > > validation by ARM and our partners. One of the big things its used for
> > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > dropping the SMMU from the picture isn't an option.
> >
> > Oh so this fixes a regression? This is something I didn't realize.
>
> Yes, thanks. The regression came about because we implemented SMMU-backed
> DMA ops and only then was it apparent that the virtio stuff was bypassing
> even with translation enabled (because it wasn't using the DMA API).
Could you point out a commit ID?
> > A "Fixes:" tag can't hurt here. I then wonder
> > might DMA ops ever use a DMA address which isn't a physical address
> > from QEMU point of view? If that happens, this hack breaks
> > because in legacy mode QEMU still uses the GPA.
>
> If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> because we won't swizzle the DMA ops for the master device. If QEMU does
> advertise an SMMU, then we'll allocate DMA addresses to fit within the
> the intersection of the SMMU aperture and device's DMA mask.
Right but doesn't just poking from qemu into phys addresses work
anymore? It used to ...
> > > > Can't you guys just code up the virtio 1 layout in QEMU?
> > > > I took a look and it's not a big deal now that two other
> > > > transports converted, except mmio code in QEMU doesn't
> > > > use linux header to it's a bit messy.
> > > > I'll send a patch to clean that up.
> > >
> > > If the model ever changes in this area (which isn't planned atm), the
> > > right thing to do would be to move to modern virtio. However, we're stuck
> > > with what we have for the forseeable future and it works just fine if we
> > > use the DMA API. If we don't use it, Linux no longer boots because it
> > > installs the SMMU-backed DMA ops for the virtio devices and everything
> > > faults.
> > >
> > > I really don't understand why this is controversial.
> > >
> > I agree we need to keep working things working. I just don't yet
> > understand what change broke things and how did it happen - legacy
> > devices used to just poke at guest PA from QEMU, what does it matter
> > that there are changes in DMA ops if neither host nor guest use them for
> > legacy setups?
>
> The problem is that platforms which advertise an SMMU downstream of the
> (virtual) PCI-RC now automatically have their PCI devices attached to the
> SMMU, so if they don't use the DMA ops then they will fault.
>
> > I guess that's just me now knowing about how DMA ops work on SMMU
> > or missing some other basic point about SMMU.
> >
> > I take your word that it's the right thing to do, but I'd like to figure
> > it out before merging this. I'll read up in the coming days to make
> > sure I understand what the patch does, any pointers welcome.
>
> Ok, thanks. Just shout if you have more questions. I'm also happy with
> only doing this for legacy devices, given that modern virtio has the
> IOMMU flag.
>
> Will
^ permalink raw reply
* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Mark Rutland @ 2017-01-13 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484323429-15231-11-git-send-email-will.deacon@arm.com>
On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> This patch documents the devicetree binding in use for ARM SPE.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> new file mode 100644
> index 000000000000..d6540b491af4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> @@ -0,0 +1,20 @@
> +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
> +
> +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
> +performance sample data using an in-memory trace buffer.
> +
> +** SPE Required properties:
> +
> +- compatible : should be one of:
> + "arm,arm-spe-pmu-v1"
The second "arm" here doesn't seem to add much. Should that be "armv8.2"
instead?
That would roughly match what we do with the architected timers to
describe the specific architectural version.
Otherwise, this looks fine to me.
Thanks,
Mark.
> +- interrupts : Exactly 1 PPI must be listed. For heterogeneous systems where
> + SPE is only supported on a subset of the CPUs, please consult
> + the arm,gic-v3 binding for details on describing a PPI partition.
> +
> +** Example:
> +
> +spe-pmu {
> + compatible = "arm,arm-spe-pmu-v1";
> + interrupts = <GIC_PPI 05 IRQ_TYPE_EDGE_RISING &part1>;
> +};
> --
> 2.1.4
>
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2017-01-13 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111153349.GK3699@e103592.cambridge.arm.com>
On Wed, Jan 11, 2017 at 4:33 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> On Wed, Jan 11, 2017 at 02:49:03PM +0000, Catalin Marinas wrote:
>> On Tue, Jan 10, 2017 at 12:14:23PM +0000, Catalin Marinas wrote:
>> > On Mon, Jan 09, 2017 at 07:06:19PM +0100, Bas van Tiel wrote:
>> > > > I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
>> > > > fine, though I'll leave it longer/overnight (on a Juno board). With the
>> > > > 4K signal stack it was crashing shortly after start.
>> > >
>> > > I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board
>> > > and still see the same behaviour of crashing. Sometimes the process
>> > > is also blocked for a long time before it crashes.
>> > >
>> > > Setting the interval to 200 usec [5 Khz] will help to crash it faster.
>> > >
>> > > To further isolate the issue I will create a kernel module (based on a
>> > > hrtimer) that will sent a periodic signal to the registered process
>> > > and execute the same sighandler logic to check if the problem is still
>> > > there.
>> >
>> > I lowered the interval to 100us (it was 100ms in the original file) and
>> > I can indeed trigger segfault easily on Juno. But it doesn't fail in the
>> > same way every time, I sometimes get permission fault, other times bad
>> > frame.
>>
>> With 100us interval, it segfaults on x86 fairly quickly as well, so I
>> don't think it's a kernel issue.
>
> To be able to take a signal at all, stacks need to be at least SIGSTKSZ
> bytes in practice:
>
>
> diff --git a/context_demo.c b/context_demo.c
> index 2cc63f7..b1f3bbc 100644
> --- a/context_demo.c
> +++ b/context_demo.c
> @@ -22,7 +22,7 @@
>
>
> #define NUMCONTEXTS 10 /* how many contexts to make */
> -#define STACKSIZE 4096 /* stack size */
> +#define STACKSIZE SIGSTKSZ /* stack size */
> #define INTERVAL 100 /* timer interval in nanoseconds */
>
> sigset_t set; /* process wide signal mask */
>
>
> The other issue looks a bit subtler, to do with signal masking.
>
> SIGALRM will be masked on entry to timer_interrupt() and restored on
> return, due to and absence of SA_NODEFER from sa_flags when calling
> sigaction. (Setting SIGALRM in sa_mask also has this effect, but this
> is redundant without SA_NODEFER.)
>
> However, by explicitly clearing this signal from
> signal_context.uc_sigmask, we'll enter scheduler() with SIGALRM
> unmasked. If a new SIGALRM is taken before scheduler() has called
> setcontext(), we'll pile up another signal on signal_stack and call
> schedule() again, still on signal_stack ... and this can repeat
> indefinitely.
>
> There's no need to clear SIGALRM from the signal mask: it will be
> cleared when timer_interrupt() returns after resuming an interrupted
> task (as part of the signal frame restore work done by rt_sigreturn).
> So:
>
> @@ -61,7 +61,6 @@ timer_interrupt(int j, siginfo_t *si, void *old_context)
> signal_context.uc_stack.ss_sp = signal_stack;
> signal_context.uc_stack.ss_size = STACKSIZE;
> signal_context.uc_stack.ss_flags = 0;
> - sigemptyset(&signal_context.uc_sigmask);
> makecontext(&signal_context, scheduler, 1);
>
> /* save running thread, jump to scheduler */
>
> For me, this seems to fix the problem.
>
> It also makes sense of what we've seen: we need either short timer
> intervals, slow machines, or high system load (or some combination) in
> order to take enough extra signals in scheduler() to cause a stack
> overflow.
so the piling up of the signals is because the handling time of the
signal takes more than the influx of signals related to the interval
time => userspace issue (programming error), thank you for the
explanation and pointing this out to userspace.
In my case the unmasking of SIGALRM cannot be done, because that would
hide the fact that the processing is too slow compared to the influx.
I did a rerun of the program on the 64-bit rpi3 and was able to have
an interval of 13 [us] in which the contexts are executing
a while(1) with a few nops for 6 hours (isolcpus, sched_fifo,
prio:99). Going below below 13 [us] the segfault occurs.
>
> I can't see the purpose of running scheduler() in its own context here,
> except so that it doesn't contribute stack overhead to the thread
> stacks (which hardly seems worthwhile, since its overhead is probably a
> lot smaller than the signal overhead anyway -- maybe I'm missing
> something).
The reason is to have an HPC usecase with context scheduling in 1
process on a dedicated isolated core (CONFIG_NO_HZ_FULL). The signal
can be seen as an HW/SW-IRQ that can be elevated above the
main-process at all times when it occurs.
> makeconext() and swapcontext() are obsoleted by POSIX.1-2008 and
> considered non-portable (see makecontext(3), swapcontext(3)). Really,
> the ucontext API should not be used for anything except cooperative
> switching now (certainly this covered the vast majority or real-world
> usage the last time I looked into it).
agree
> For anything else, pthreads
> almost certainly do it better.
>
agree
--
Bas
^ permalink raw reply
* [PATCH] phy: meson8b-usb2: fix offsets for some of the registers
From: Martin Blumenstingl @ 2017-01-13 18:53 UTC (permalink / raw)
To: linux-arm-kernel
The register offsets for REG_DBG_UART (and all following) were off by
0x4. This was not a problem yet because these registers are currently
not used by the driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/phy/phy-meson8b-usb2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-meson8b-usb2.c b/drivers/phy/phy-meson8b-usb2.c
index 33c9f4ba157d..30f56a6a411f 100644
--- a/drivers/phy/phy-meson8b-usb2.c
+++ b/drivers/phy/phy-meson8b-usb2.c
@@ -81,9 +81,9 @@
#define REG_ADP_BC_ACA_PIN_GND BIT(25)
#define REG_ADP_BC_ACA_PIN_FLOAT BIT(26)
-#define REG_DBG_UART 0x14
+#define REG_DBG_UART 0x10
-#define REG_TEST 0x18
+#define REG_TEST 0x14
#define REG_TEST_DATA_IN_MASK GENMASK(3, 0)
#define REG_TEST_EN_MASK GENMASK(7, 4)
#define REG_TEST_ADDR_MASK GENMASK(11, 8)
@@ -93,7 +93,7 @@
#define REG_TEST_DATA_OUT_MASK GENMASK(19, 16)
#define REG_TEST_DISABLE_ID_PULLUP BIT(20)
-#define REG_TUNE 0x1c
+#define REG_TUNE 0x18
#define REG_TUNE_TX_RES_TUNE_MASK GENMASK(1, 0)
#define REG_TUNE_TX_HSXV_TUNE_MASK GENMASK(3, 2)
#define REG_TUNE_TX_VREF_TUNE_MASK GENMASK(7, 4)
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: marvell: add generic-ahci compatibles for CP110 ahci
From: Russell King @ 2017-01-13 18:57 UTC (permalink / raw)
To: linux-arm-kernel
Testing with an Armada 8040 board shows that adding the generic-ahci
compatible to the CP110 AHCI nodes gets us working AHCI on the board.
A previous patch series posted by Thomas Petazzoni was retracted when
it was realised that the IP was supposed to be, and is, compatible
with the standard register layout.
Add this compatible.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 3 ++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 464b491c7291..65ad781d7910 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -128,7 +128,8 @@
};
cpm_sata0: sata at 540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpm_syscon0 1 15>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index b10f4781d8fb..168d667d50a3 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -128,7 +128,8 @@
};
cps_sata0: sata at 540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cps_syscon0 1 15>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] clk: rockchip: add rk3288 isp_in clock ids
From: Heiko Stuebner @ 2017-01-13 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049560-14820-1-git-send-email-jacob-chen@iotwrt.com>
Am Dienstag, 10. Januar 2017, 19:59:17 CET schrieb Jacob Chen:
> Add clock-ids for the isp block of the rk3288.
>
>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/4] clk: rockchip: use rk3288 isp_in clock ids
From: Heiko Stuebner @ 2017-01-13 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049560-14820-2-git-send-email-jacob-chen@iotwrt.com>
Am Dienstag, 10. Januar 2017, 19:59:18 CET schrieb Jacob Chen:
> Reference the newly added isp clock-ids in the clock-tree.
>
>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver
From: Steve Longerbeam @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484308551.31475.23.camel@pengutronix.de>
On 01/13/2017 03:55 AM, Philipp Zabel wrote:
> Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
>> Add bindings documentation for the i.MX media driver.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> Documentation/devicetree/bindings/media/imx.txt | 57 +++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/imx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
>> new file mode 100644
>> index 0000000..254b64a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/imx.txt
>> @@ -0,0 +1,57 @@
>> +Freescale i.MX Media Video Devices
>> +
>> +Video Media Controller node
>> +---------------------------
>> +
>> +This is the parent media controller node for video capture support.
>> +
>> +Required properties:
>> +- compatible : "fsl,imx-media";
> Would you be opposed to calling this "capture-subsystem" instead of
> "imx-media"? We already use "fsl,imx-display-subsystem" and
> "fsl,imx-gpu-subsystem" for the display and GPU compound devices.
sure. Some pie-in-the-sky day when DRM and media are unified,
there could be a single device that handles them all, but for now
I'm fine with "fsl,capture-subsystem".
>> +- ports : Should contain a list of phandles pointing to camera
>> + sensor interface ports of IPU devices
>> +
>> +
>> +fim child node
>> +--------------
>> +
>> +This is an optional child node of the ipu_csi port nodes. If present and
>> +available, it enables the Frame Interval Monitor. Its properties can be
>> +used to modify the method in which the FIM measures frame intervals.
>> +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
>> +Frame Interval Monitor.
>> +
>> +Optional properties:
>> +- fsl,input-capture-channel: an input capture channel and channel flags,
>> + specified as <chan flags>. The channel number
>> + must be 0 or 1. The flags can be
>> + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
>> + IRQ_TYPE_EDGE_BOTH, and specify which input
>> + capture signal edge will trigger the input
>> + capture event. If an input capture channel is
>> + specified, the FIM will use this method to
>> + measure frame intervals instead of via the EOF
>> + interrupt. The input capture method is much
>> + preferred over EOF as it is not subject to
>> + interrupt latency errors. However it requires
>> + routing the VSYNC or FIELD output signals of
>> + the camera sensor to one of the i.MX input
>> + capture pads (SD1_DAT0, SD1_DAT1), which also
>> + gives up support for SD1.
> This is a clever method to get better frame timestamps. Too bad about
> the routing requirements. Can this be used on Nitrogen6X?
Absolutely, this support just needs use of the input-capture channels in the
imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
input capture API, so at this point fsl,input-capture-channel has no effect,
but it does work (tested on SabreAuto).
>
>> +
>> +mipi_csi2 node
>> +--------------
>> +
>> +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
>> +CSI-2 sensors.
>> +
>> +Required properties:
>> +- compatible : "fsl,imx6-mipi-csi2";
> I think this should get an additional "snps,dw-mipi-csi2" compatible,
> since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.
right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
Or should wait until the day this subdev is exported for general use, after
pulling out the gasket specifics?
>
>> +- reg : physical base address and length of the register set;
>> +- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
>> + (the DPHY clock), video_27m, and eim_sel;
> Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
> shared gate bit that gates the HSI clocks as well as the MIPI
> "ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
> csi-2 core, but we are missing shared gate clocks in the clock tree for
> these.
Yes, so many clocks for the MIPI core. Why so many? I would think
there would need to be at most three: a clock for the MIPI CSI-2 core
and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
M-PHY if there is one). I have no clue what all these other clocks are.
But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.
> Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
> video_27m seems fine.
> But I don't get "dphy".
I presume it's the clock for the D-PHY.
> Which input clock would that correspond to?
> "pll_refclk?"
the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.
> Also the pixel clock input is a gate after aclk_podf (which we call
> eim_podf), not aclk_sel (eim_sel).
ok, I'll switch to eim_podf for the pixel clock.
Steve
>
>> +- clock-names : must contain "dphy", "cfg", "pix";
>> +
>> +Optional properties:
>> +- interrupts : must contain two level-triggered interrupts,
>> + in order: 100 and 101;
> regards
> Philipp
>
^ permalink raw reply
* [PATCH v4 0/4] Support for LEGO MINDSTORMS EV3
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for LEGO MINDSTORMS EV3. This is a TI AM1808
based board.
v4 changes:
* New patches for device tree bindings specifications
* Fixed vendor on eeprom device node
v3 changes:
* required defconfig patches have been picked up in linux-davinci tree, so this
is the only patch left in the series
* Added aliases node for consistent naming of serial ports
* Added memory node
* Removed nodes that are not finalized yet
* Renamed button labels to match EV3 users manual
v2 changes:
* Dropped defconfig patches that have already been pick up
* Added some new defconfig patches
* Updated device tree file based on feedback and new available bindings
* Renamed file to include da850- prefix
* Changed button labels
* Fixed LED names
* Added beeper device for sound
* Added regulators for USB and A/DC
* Removed unused pinmux nodes
* Added pinconf for buttons
* Enabled pwms
* Used preferred bindings for flash partitions
* Added A/DC spi device
* Enabled USB
David Lechner (4):
dt-bindings: Add vendor prefix for LEGO
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
dt-bindings: add "microchip,24c128" compatible string
ARM: dts: Add LEGO MINDSTORMS EV3 dts
Documentation/devicetree/bindings/arm/davinci.txt | 4 +
.../devicetree/bindings/eeprom/eeprom.txt | 2 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++
5 files changed, 322 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: Add vendor prefix for LEGO
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
Add a vendor prefix for LEGO Systems A/S
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 61cb272..c1ccfd4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -159,6 +159,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
+lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
licheepi Lichee Pi
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds the board level device tree specification for LEGO MINDSTORMS EV3
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/davinci.txt b/Documentation/devicetree/bindings/arm/davinci.txt
index f0841ce..715622c 100644
--- a/Documentation/devicetree/bindings/arm/davinci.txt
+++ b/Documentation/devicetree/bindings/arm/davinci.txt
@@ -13,6 +13,10 @@ EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
+LEGO MINDSTORMS EV3 (AM1808 based)
+Required root node properties:
+ - compatible = "lego,ev3", "ti,da850";
+
Generic DaVinci Boards
----------------------
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: add "microchip,24c128" compatible string
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds "microchip,24c128" to the list of compatible strings for i2c
eeproms.
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 735bc94..5696eb5 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -10,6 +10,8 @@ Required properties:
"catalyst,24c32"
+ "microchip,24c128"
+
"ramtron,24c64"
"renesas,r1ex24002"
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* Pinconf
* GPIOs
* MicroSD card reader
* UART on input port 1
* Buttons
* LEDs
* Poweroff/reset
* Flash memory
* EEPROM
* USB host port
* USB peripheral port
What is not working/to be added later:
* Speaker - have patch submitted to get pwm-beeper working - maybe someday
it will have a real sound driver that uses PRU
* A/DC chip - have driver submitted and accepted - waiting for ack on
device tree bindings
* Display - waiting for "simple DRM" to be mainlined
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver as
well as PRU UART and PRU I2C drivers
* Battery indication - needs new power supply driver
Note on flash partitions:
These partitions are based on the official EV3 firmware from LEGO. It is
expected that most users of the mainline kernel on EV3 will be booting from
an SD card while retaining the official firmware in the flash memory.
Furthermore, the official firmware uses an ancient U-Boot (2009) that has
no device tree support. So, it makes sense to have this partition table in
the EV3 device tree file. In the unlikely case that anyone does create
their own firmware image with different partitioning, they can use a modern
U-Boot in their own firmware image that modifies the device tree with the
custom partitions.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++++++++++++++++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b7..1a19e7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -130,7 +130,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ da850-lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
new file mode 100644
index 0000000..112ec92
--- /dev/null
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -0,0 +1,313 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner <david@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ aliases {
+ serial1 = &serial1;
+ };
+
+ memory at c0000000 {
+ device_type = "memory";
+ reg = <0xc0000000 0x04000000>;
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 Brick Buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>, <&button_bias>;
+
+ center {
+ label = "Center";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ left {
+ label = "Left";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+
+ back {
+ label = "Back";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+
+ right {
+ label = "Right";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+
+ down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+
+ up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_green {
+ label = "led0:green:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_red {
+ label = "led1:red:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ left_red {
+ label = "led0:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_green {
+ label = "led1:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * This is a 5V current limiting regulator that is shared by USB,
+ * the sensor (input) ports, the motor (output) ports and the A/DC.
+ */
+ vcc5v: regulator1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v_pins>;
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio 101 0>;
+ over-current-gpios = <&gpio 99 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+
+ vcc5v_pins: pinmux_vcc5v {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+&pinconf {
+ status = "okay";
+
+ /* Buttons have external pulldown resistors */
+ button_bias: button-bias-groups {
+ disable {
+ groups = "cp5", "cp24", "cp25", "cp28";
+ bias-disable;
+ };
+ };
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom at 50 {
+ compatible = "microchip,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+
+ flash at 0 {
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ /* Partitions are based on the official firmware from LEGO */
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition at 40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition at 50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition at 250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition at cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+ };
+};
+
+&gpio {
+ status = "okay";
+};
+
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+ vbus-supply = <&vcc5v>;
+};
--
2.7.4
^ 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