Re: [PATCH v2 5/5] iio: Support triggered events
On Tue, 28 Jul 2015, Vladimir Barinov wrote:
> Support triggered events.
>
> This is useful for chips that has no it's own interrupt sources.
that don't have their own
> It allows to use generic/standalone iio triggeres for those drivers.
triggers
>
> Signed-off-by: Vladimir Barinov
> ---
> Changes in version 2:
> - initially added
>
> drivers/iio/Kconfig| 6 +++
> drivers/iio/Makefile | 1 +
> drivers/iio/industrialio-core.c| 4 +-
> drivers/iio/industrialio-trigger.c | 12 +-
> drivers/iio/industrialio-triggered-event.c | 67
> ++
> include/linux/iio/iio.h| 1 +
> include/linux/iio/triggered_event.h| 11 +
> 7 files changed, 98 insertions(+), 4 deletions(-)
> create mode 100644 drivers/iio/industrialio-triggered-event.c
> create mode 100644 include/linux/iio/triggered_event.h
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 4011eff..8fcc92f 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
> This value controls the maximum number of consumers that a
> given trigger may handle. Default is 2.
>
> +config IIO_TRIGGERED_EVENT
> + tristate
> + select IIO_TRIGGER
> + help
> + Provides helper functions for setting up triggered events.
> +
> source "drivers/iio/accel/Kconfig"
> source "drivers/iio/adc/Kconfig"
> source "drivers/iio/amplifiers/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 698afc2..40dc13e 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
> industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
>
> obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
> +obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
> obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
>
> obj-y += accel/
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 3524b0d..54d71ea 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev
> *indio_dev)
> static void iio_dev_release(struct device *device)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(device);
> - if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
> + if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
> iio_device_unregister_trigger_consumer(indio_dev);
> iio_device_unregister_eventset(indio_dev);
> iio_device_unregister_sysfs(indio_dev);
> @@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
> "Failed to register event set\n");
> goto error_free_sysfs;
> }
> - if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
> + if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
> iio_device_register_trigger_consumer(indio_dev);
>
> if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
> diff --git a/drivers/iio/industrialio-trigger.c
> b/drivers/iio/industrialio-trigger.c
> index d31098e..72b63e7 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device
> *dev,
>
> indio_dev->trig = trig;
>
> - if (oldtrig)
> + if (oldtrig) {
> + if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
> + iio_trigger_detach_poll_func(oldtrig,
> + indio_dev->pollfunc);
> iio_trigger_put(oldtrig);
> - if (indio_dev->trig)
> + }
> + if (indio_dev->trig) {
> iio_trigger_get(indio_dev->trig);
> + if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
> + iio_trigger_attach_poll_func(indio_dev->trig,
> + indio_dev->pollfunc);
> + }
>
> return len;
> }
> diff --git a/drivers/iio/industrialio-triggered-event.c
> b/drivers/iio/industrialio-triggered-event.c
> new file mode 100644
> index 000..c434ce7
> --- /dev/null
> +++ b/drivers/iio/industrialio-triggered-event.c
> @@ -0,0 +1,67 @@
> + /*
> + * Copyright (C) 2015 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * iio_triggered_event_setup() - Setup pollfunc for triggered event
> + * @indio_dev: IIO device structure
> + * @pollfunc_bh: Function which will be used as pollfunc bottom half
> + * @pollf
Re: [PATCH v5 2/5] PCI: designware: Add ARM64 support
On 2015/7/25 11:21, Zhou Wang wrote:
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init. Also set pp->root_bus_nr = 0 in
> each PCIe host driver which is based on pcie-designware. This patch also try
> to use of_pci_get_host_bridge_resources for ARM32 and ARM64 according to the
> suggestion for Gabriele[1]
>
> This patch is based on Gabriele's patch about of_pci_range fix[2]
>
> I have compiled the driver with multi_v7_defconfig. However, I don't have
> ARM32 PCIe related board to do test. It will be appreciated if someone could
> help to test it.
>
Hi James,
If you have time, could you help to test this patch on i.MX 6Quad board?
You need apply Gabriele's patch before applying this patch.
It will be very appreciate and helpful if we can get test result from you.
Thanks and Regards,
Zhou
> Signed-off-by: Zhou Wang
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Gabriele Paoloni
>
> [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> [2] https://patchwork.ozlabs.org/patch/495018/
> ---
> drivers/pci/host/pci-dra7xx.c | 1 +
> drivers/pci/host/pci-exynos.c | 2 +-
> drivers/pci/host/pci-imx6.c| 2 +-
> drivers/pci/host/pci-keystone-dw.c | 2 +-
> drivers/pci/host/pci-keystone.c| 2 +-
> drivers/pci/host/pci-layerscape.c | 2 +-
> drivers/pci/host/pcie-designware.c | 217
> +
> drivers/pci/host/pcie-designware.h | 10 +-
> drivers/pci/host/pcie-spear13xx.c | 2 +-
> 9 files changed, 86 insertions(+), 154 deletions(-)
>
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 80db09e..69364e8 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -275,6 +275,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie
> *dra7xx,
>
> pp = &dra7xx->pp;
> pp->dev = dev;
> + pp->root_bus_nr = 0;
> pp->ops = &dra7xx_pcie_host_ops;
>
> pp->irq = platform_get_irq(pdev, 1);
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index f9f468d..9771bb0 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -530,7 +530,7 @@ static int __init exynos_add_pcie_port(struct pcie_port
> *pp,
> }
> }
>
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
> pp->ops = &exynos_pcie_host_ops;
>
> ret = dw_pcie_host_init(pp);
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 233a196..bec256c 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -551,7 +551,7 @@ static int __init imx6_add_pcie_port(struct pcie_port *pp,
> }
> }
>
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
> pp->ops = &imx6_pcie_host_ops;
>
> ret = dw_pcie_host_init(pp);
> diff --git a/drivers/pci/host/pci-keystone-dw.c
> b/drivers/pci/host/pci-keystone-dw.c
> index f34892e..b1e4135 100644
> --- a/drivers/pci/host/pci-keystone-dw.c
> +++ b/drivers/pci/host/pci-keystone-dw.c
> @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
> *reg_virt)
> void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
> {
> struct pcie_port *pp = &ks_pcie->pp;
> - u32 start = pp->mem.start, end = pp->mem.end;
> + u32 start = pp->mem->start, end = pp->mem->end;
> int i, tr_size;
>
> /* Disable BARs for inbound access */
> diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
> index 734da58..8113832 100644
> --- a/drivers/pci/host/pci-keystone.c
> +++ b/drivers/pci/host/pci-keystone.c
> @@ -309,7 +309,7 @@ static int __init ks_add_pcie_port(struct keystone_pcie
> *ks_pcie,
> return ret;
> }
>
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
> pp->ops = &keystone_pcie_host_ops;
> ret = ks_dw_pcie_host_init(ks_pcie, ks_pcie->msi_intc_np);
> if (ret) {
> diff --git a/drivers/pci/host/pci-layerscape.c
> b/drivers/pci/host/pci-layerscape.c
> index b2328ea1..79ff08c 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -106,7 +106,7 @@ static int ls_add_pcie_port(struct ls_pcie *pcie)
> pp = &pcie->pp;
> pp->dev = pcie->dev;
> pp->dbi_base = pcie->dbi;
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
> pp->ops = &ls_pcie_host_ops;
>
> ret = dw_pcie_host_init(pp);
> diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> index 69486be..6092c84 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -11,6 +11,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -69,16 +70,7 @@
> #def
Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
Hi Stephen! > On 28.07.2015, at 04:51, Stephen Warren wrote: > > >> If this is not acceptable, then where should such a driver go in the >> kernel tree? >> >> It would essentially implement the following: >> bcm2835aux_enable(dev, device-id); >> bcm2835aux_disable(dev, device-id); >> >> Which would just set/clean the bits in the register while holding a lock. > > That sounds reasonable. I'd also expect a function that the client > drivers could call during probe() to look up the device (and implement > deferred probe) and another to release the reference during the client's > remove(). But the bigger question you have not answered is: “where should such an auxiliar driver go in the kernel tree?” i.e. which directory? I really do not want to implement it and then get told: “that should not go here” - been thru too many iterations already… Also I am not sure I understood the “defer” thingy. I thought of actually implementing only 2 functions to use during probe and removal: * bcm2835aux_enable(dev) * bcm2835aux_disable(dev) Both would pick up the “bcrm,aux” property from the device tree (as per “bcrm,aux = <&bcm2835aux 4>”) and set the enable register accordingly holding a lock. I still could leave those 2 functions in the spi driver for now and when someone wants to implement the uart1, then they would need to pull that out into a separate driver. As for interrupt-handler: it was a simple idea that would work fine for the bcm2835aux case to avoid configuring things for the uart, but then you do not want the uart1 to get configured as 'compatible=“ns16650”;’ inside the device-tree, so this is not acceptable anyway (unless there were some way to define “additional” compatibility for a driver without modifying the driver itself). This means we will need to implement a minimal driver for uart1 that wraps ns16650. But as all the drivers (spi-bcm2835aux as well as ns16650) can use FIRQ_SHARED (and do not need to read/write the shared aux_irg registers) the need for a interrupt controller is not there. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
* Suman Anna [150724 09:27]: > Hi Tony, > > On 07/23/2015 11:30 PM, Tony Lindgren wrote: > > * Suman Anna [150723 09:25]: > >> Hi Tony, > >> > >> On 07/23/2015 02:24 AM, Tony Lindgren wrote: > >>> * Suman Anna [150722 09:25]: > On 07/22/2015 12:26 AM, Tony Lindgren wrote: > > > > I don't like using syscon for tinkering directly with SoC registers. > > This is not a SoC-level register, but a register within a sub-module of > the DSP processor sub-system. The DSP_SYSTEM sub-module in general is > described in Section 5.3.3 of the TRM [1], and it implements different > functionalities like the PRCM handshaking, wakeup logic and DSP > subsystem top-level configuration. It is a module present within the DSP > processor sub-system, so can only be accessed when the sub-system is > clocked and the appropriate reset is released. > >>> > >>> OK so if it's specific to the DSP driver along the lines of sysc and > >>> syss registers. > >> > >> There will be those registers too within the MMU config register space, > >> even for DRA7xx MMUs. This is different, think of it like a register in > >> the Control module except that it is present within the DSP sub-system > >> instead of at the SoC level. > > > > And what is taking care of pm_runtime_get here to ensure the module > > is powered and clocked? > > pm_runtime_get_sync is indeed getting invoked, its just the current > patch doesn't include the code block that invokes it. The function that > invokes omap2_iommu_enable does so after a call to the > pm_runtime_get_sync() call. OK > > I think you are missing a layer here and it's the Linux kernel side > > device driver for DSP that initializes things. > > We already have separate drivers for MMUs (omap-iommu) and the processor > management (omap-rproc). The former manages all the low-level > programming sequences for the MMUs, while the latter manages the > low-level reset etc, and is a client user of the respective IOMMU > device. Both integrate into the respective frameworks. The IOMMU API > invocations are handled in the remoteproc core, with the OMAP remoteproc > driver publishing itself as having an MMU with the remoteproc core. The > IOMMU API invoke the appropriate iommu_ops. > > You can lookup the functions rproc_enable_iommu()/rproc_disable_iommu() > in the remoteproc core. The IOMMU enabling sequences happen within the > iommu_attach_device() API. The call flow is > iommu_attach_device()->omap_iommu_attach_dev()->omap_iommu_attach()-> > iommu_enable()-> >omap_device_deassert_hardreset, pm_runtime_get_sync, omap2_iommu_enable. OK. The thing to check here is that you have a separate device driver for each sysc/syss device registers. This is because each hardware module can be independently clocked and idled. Otherwise things will break at some point. And no "things are configured for autoidle" or "we're not doing PM is not a good excuse here" :) Can you please check that? If the remoteproc driver and iommu driver are tinkering with registers in separate hardware modules, we have a layering violation. My guess is that we have at least two hardware modules involved here, one for the iommu and one for the DSP device. > >>> Typically we handle these registers by mapping them to the PM runtime > >>> functions for the interconnect so we can reset and idle the hardware > >>> modules even if there is no driver, see for example > >>> omap54xx_mmu_dsp_hwmod. > >> > >> I haven't yet submitted the DRA7xx hwmods, but they will look almost > >> exactly like the OMAP5 ones. The reset and idle on these are in general > >> not effective at boot time since these are also controlled by a > >> hard-reset line, so that's left to the drivers to deal with it through > >> the omap_device_deassert_hardreset API. > > > > If the MMU configuration is one time init, it may make sense to add > > it to the hwmod reset function. However, if the Linux kernel side > > driver needs to configure things depending on the DSP firmware, it > > should be done in the kernel side device driver. > > The MMU configuration comes into picture whenever the remoteproc driver > is being booted and shut down, and also during suspend (no support for > this yet in mainline on OMAP rproc). Today, the hwmod > _enable/_idle/reset functions alone are not enough to power on the OMAP > remoteproc/iommus. We need sequencing calls to both > omap_device_assert/_deassert_hardreset (done through pdata-quirks) and > pm_runtime API to achieve this. Right and that's why I'm worried that we have multiple hardware modules involved :) > > We should use some Linux generic framework for configuring these > > bits to avoid nasty dependencies between various hardware modules > > on the SoC. > > > > What does DSP_SYS_MMU_CONFIG register do? It seems it's probably > > a regulator or a gate clock? If so, it should be set up as a > > regulator or a clock and then the omap-iommu driv
Re: [PATCH v3 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
Hi, On Sunday 26 July 2015 08:21 AM, chunfeng yun wrote: > hi, > On Wed, 2015-07-22 at 09:21 -0500, Felipe Balbi wrote: >> Hi, >> >> On Wed, Jul 22, 2015 at 10:05:43PM +0800, Chunfeng Yun wrote: >>> support usb3.0 phy of mt65xx SoCs >>> >>> Signed-off-by: Chunfeng Yun >> >> you missed Kishon here. >> > Thank you. >>> --- >>> drivers/phy/Kconfig | 9 + >>> drivers/phy/Makefile | 1 + >>> drivers/phy/phy-mt65xx-usb3.c | 426 >>> ++ >>> 3 files changed, 436 insertions(+) >>> create mode 100644 drivers/phy/phy-mt65xx-usb3.c >>> >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig >>> index c0e6ede..019cf8b 100644 >>> --- a/drivers/phy/Kconfig >>> +++ b/drivers/phy/Kconfig >>> @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA >>> help >>> Support for SATA PHY on Hisilicon hix5hd2 Soc. >>> >>> +config PHY_MT65XX_USB3 >>> + tristate "Mediatek USB3.0 PHY Driver" >>> + depends on ARCH_MEDIATEK && OF >>> + select GENERIC_PHY >>> + help >>> + Say 'Y' here to add support for Mediatek USB3.0 PHY driver >>> + for mt65xx SoCs. it supports two usb2.0 ports and >>> + one usb3.0 port. >>> + >>> config PHY_SUN4I_USB >>> tristate "Allwinner sunxi SoC USB PHY driver" >>> depends on ARCH_SUNXI && HAS_IOMEM && OF >>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile >>> index f344e1b..3ceff2a 100644 >>> --- a/drivers/phy/Makefile >>> +++ b/drivers/phy/Makefile >>> @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= >>> phy-ti-pipe3.o >>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o >>> obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o >>> obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o >>> +obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o >>> obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o >>> obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o >>> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o >>> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c >>> new file mode 100644 >>> index 000..5da4534 >>> --- /dev/null >>> +++ b/drivers/phy/phy-mt65xx-usb3.c >>> @@ -0,0 +1,426 @@ >>> +/* >>> + * Copyright (c) 2015 MediaTek Inc. >>> + * Author: Chunfeng.Yun >>> + * >>> + * This software is licensed under the terms of the GNU General Public >>> + * License version 2, as published by the Free Software Foundation, and >>> + * may be copied, distributed, and modified under those terms. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include Lot of these #include are not required. Add only those what are required by this driver. >>> +#include >>> + >>> +/* >>> + * for sifslv2 register >>> + * relative to USB3_SIF2_BASE base address >>> + */ >>> +#define SSUSB_SIFSLV_SPLLC (0x) >>> +#define SSUSB_SIFSLV_U2PHY_COM_BASE(0x0800) Looks like all this base address can come from dt. >>> +#define SSUSB_SIFSLV_U3PHYD_BASE (0x0900) >>> +#define SSUSB_USB30_PHYA_SIV_B_BASE(0x0b00) >>> +#define SSUSB_SIFSLV_U3PHYA_DA_BASE(0x0c00) >>> + >>> +/*port1 refs. +0x800(refer to port0)*/ >>> +#define U3P_PORT_INTERVAL (0x800) /*based on port0 */ >>> +#define U3P_PHY_DELTA(index) ((U3P_PORT_INTERVAL) * (index)) >>> + >>> +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) >>> +#define PA0_RG_U2PLL_FORCE_ON (0x1 << 15) >>> + >>> +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) >>> +#define PA2_RG_SIF_U2PLL_FORCE_EN (0x1 << 18) >>> + >>> +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) >>> +#define PA5_RG_U2_HSTX_SRCTRL (0x7 << 12) >>> +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) >>> +#define PA5_RG_U2_HS_100U_U3_EN(0x1 << 11) >>> + >>> +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) >>> +#define PA6_RG_U2_ISO_EN (0x1 << 31) >>> +#define PA6_RG_U2_BC11_SW_EN (0x1 << 23) >>> +#define PA6_RG_U2_OTG_VBUSCMP_EN (0x1 << 20) >>> + >>> +#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) >>> +#define P2C_RG_USB20_GPIO_CTL (0x1 << 9) >>> +#define P2C_USB20_GPIO_MODE(0x1 << 8) >>> +#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | >>> P2C_USB20_GPIO_MODE) >>> + >>> +#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) >>> +#define P2C_RG_SIF_U2PLL_FORCE_ON (0x1 << 24) >>> + >>> +#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) >>> +#define P2C_FORCE_UART_EN (0x1 << 26) >
Re: [RFCv2 3/3] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
On 07/28/2015 06:59 AM, Moritz Fischer wrote:
> Hi Michal,
>
> On Mon, Jul 27, 2015 at 12:12 AM, Michal Simek wrote:
>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>> This adds a reset controller driver to control the Xilinx Zynq
>>> SoC's various resets.
>>>
>>> Signed-off-by: Moritz Fischer
>>> ---
>>> drivers/reset/Makefile | 1 +
>>> drivers/reset/reset-zynq.c | 142
>>> +
>>> 2 files changed, 143 insertions(+)
>>> create mode 100644 drivers/reset/reset-zynq.c
>>>
>>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>>> index 157d421..3fe50e7 100644
>>> --- a/drivers/reset/Makefile
>>> +++ b/drivers/reset/Makefile
>>> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>>> obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
>>> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>>> obj-$(CONFIG_ARCH_STI) += sti/
>>> +obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
>>> diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
>>> new file mode 100644
>>> index 000..05e37f8
>>> --- /dev/null
>>> +++ b/drivers/reset/reset-zynq.c
>>> @@ -0,0 +1,142 @@
>>> +/*
>>> + * Copyright (c) 2015, National Instruments Corp.
>>> + *
>>> + * Xilinx Zynq Reset controller driver
>>> + *
>>> + * 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 of the License.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* Offsets into SLCR regmap */
>>> +#define SLCR_RST_CTRL_OFFSET 0x200 /* FPGA Software Reset Control */
>>> +
>>> +#define NBANKS 18
>>> +
>>> +struct zynq_reset_data {
>>> + struct regmap *slcr;
>>> + struct reset_controller_dev rcdev;
>>> +};
>>> +
>>> +#define to_zynq_reset_data(p)\
>>> + container_of((p), struct zynq_reset_data, rcdev)
>>> +
>>> +static int zynq_reset_assert(struct reset_controller_dev *rcdev,
>>> + unsigned long id)
>>> +{
>>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>>> +
>>> + int bank = id / BITS_PER_LONG;
>>> + int offset = id % BITS_PER_LONG;
>>> +
>>
>> Personally me I would also add debug message here to be simply enabled
>> for easier tracking.
> See below
>>
>>> + regmap_update_bits(priv->slcr,
>>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>>> +BIT(offset),
>>> +BIT(offset));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
>>> +unsigned long id)
>>> +{
>>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>>> +
>>> + int bank = id / BITS_PER_LONG;
>>> + int offset = id % BITS_PER_LONG;
>>> +
>>
>> debug message here too.
> is:
> pr_debug("%s: bank: %u offset %u\n", __func__, bank, offset);
> accetable? Otherwise I'd have to carry around a struct dev* to use dev_dbg()
It is fine for me.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
On 07/28/2015 07:03 AM, Moritz Fischer wrote: > Hi Michal, > > I agree we need to be careful with changing the bindings. > > On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote: >> Hi Moritz, >> >> On 07/25/2015 02:21 AM, Moritz Fischer wrote: >>> Signed-off-by: Moritz Fischer >>> --- >>> arch/arm/boot/dts/zynq-7000.dtsi| 43 - >> >> This patch is nice in general but every change in binding should be >> discussed separately. There is also necessary to wire them up in the >> driver to do action. That's why I think that will be the best just to >> add the code to slcr and keep others untouched. > > Ok, just to clarify: You'd suggest to just add the rstc as child node > to the slcr, > and leave the other nodes untouched? yes and then add it on case-by-case basis. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
On 07/28/2015 06:55 AM, Moritz Fischer wrote:
> Hi Michal,
>
> On Sun, Jul 26, 2015 at 10:09 PM, Michal Simek wrote:
>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>> Signed-off-by: Moritz Fischer
>>> ---
>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13
>>> +
>>> 1 file changed, 13 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> new file mode 100644
>>> index 000..ac4499e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>> @@ -0,0 +1,13 @@
>>> +Xilinx Zynq PL Reset Manager
>>
>> here
>>
>>> +
>>> +Required properties:
>>> +- compatible: "xlnx,zynq-reset-pl"
>>
>> Currently it is not just PL reset controller.
>>
>>> +- syscon <&slcr>;
>>
>>
>> missing : and please be more descriptive here.
>>
>>> +- #reset-cells: 1
>>> +
>>> +Example:
>>> + rstc: rstc@240 {
>>> + #reset-cells = <1>;
>>> + compatible = "xlnx,zynq-reset-pl";
>>
>> Compatible property should go first.
>>
>> I am missing that reg property
>>
>>> + syscon = <&slcr>;
>>> + };
>>>
>>
> Would something like this work:
>
> Xilinx Zynq Reset Manager
>
> The Zynq AP-SoC has several different resets.
>
> See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
>
> Required properties:
> - compatible: "xlnx,zynq-reset"
> - reg: SLCR offset and size taken via syscon <0x200 0x50>
> - syscon: <&slcr>
> This should be a phandle to the Zynq's SLCR register.
> - #reset-cells: Must be 1
>
> The Zynq Reset Manager needs to be a child node of the SLCR.
>
> Example:
> rstc: rstc@200 {
> compatible = "xlnx,zynq-reset";
> reg = <0x200 0x50>;
> #reset-cells = <1>;
> syscon = <&slcr>;
> };
Looks good to me.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey
On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > From: S Twiss
> >
> > Add device tree bindings for the DA9062 OnKey driver component
> >
> > Signed-off-by: Steve Twiss
> >
> > ---
> > Changes in V3:
> > - Child driver specifics separated out into separate document
> >in this case ../input/da9062-onkey.txt
> > Changes in V2:
> > - No change
> >
> > This patch applies against linux-next and next-20150708
> >
> >
> > .../devicetree/bindings/input/da9062-onkey.txt | 36
> > ++
> > Documentation/devicetree/bindings/mfd/da9062.txt | 3 ++
>
> I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> 9063, folded into the onkey patch and applied.
Argh, da9062 core is not in mainline yet... OK, below is the patch I
had; if Lee does not pick it up I'll re-apply it when da9062 core hits
mainline.
Thanks.
--
Dmitry
Input: add DA9062 OnKey capability to DA9063 OnKey driver
From: S Twiss
Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
using generic access tables for common register and bit mask definitions.
The following change will add generic register and bit mask support to the
DA9063 OnKey.
The following alterations have been made to the DA9063 OnKey:
- Addition of a da906x_chip_config structure to hold all
generic registers and bitmasks for this type of OnKey component.
- Addition of an struct of_device_id table for DA9063 and DA9062
defaults
- Refactoring functions to use struct da9063_onkey accesses to generic
registers/masks instead of using defines from registers.h
- Re-work of da9063_onkey_probe() to use of_match_node() and
dev_get_regmap() to provide initialisation of generic registers and
masks and access to regmap
Signed-off-by: Steve Twiss
Signed-off-by: Dmitry Torokhov
---
.../devicetree/bindings/input/da9062-onkey.txt | 32 +
drivers/input/misc/Kconfig |8 +
drivers/input/misc/da9063_onkey.c | 129
3 files changed, 140 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt
b/Documentation/devicetree/bindings/input/da9062-onkey.txt
new file mode 100644
index 000..ab0e048
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -0,0 +1,32 @@
+* Dialog DA9062/63 OnKey Module
+
+This module is part of the DA9062/DA9063. For more details about entire
+chips see Documentation/devicetree/bindings/mfd/da9062.txt and
+Documentation/devicetree/bindings/mfd/da9063.txt
+
+This module provides KEY_POWER, KEY_SLEEP and events.
+
+Required properties:
+
+ - compatible: should be one of:
+ dlg,da9062-onkey
+ dlg,da9063-onkey
+
+Optional properties:
+
+ - dlg,disable-key-power : Disable power-down using a long key-press. If this
+entry exists the OnKey driver will remove support for the KEY_POWER key
+press. If this entry does not exist then by default the key-press
+triggered power down is enabled and the OnKey will support both KEY_POWER
+and KEY_SLEEP.
+
+Example:
+
+ pmic0: da9062@58 {
+
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ dlg,disable-key-power;
+ };
+
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..d4b993d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -611,11 +611,11 @@ config INPUT_DA9055_ONKEY
will be called da9055_onkey.
config INPUT_DA9063_ONKEY
- tristate "Dialog DA9063 OnKey"
- depends on MFD_DA9063
+ tristate "Dialog DA9062/63 OnKey"
+ depends on MFD_DA9063 || MFD_DA9062
help
- Support the ONKEY of Dialog DA9063 Power Management IC as an
- input device reporting power button statue.
+ Support the ONKEY of Dialog DA9063 and DA9062 Power Management ICs
+ as an input device capable of reporting the power button status.
To compile this driver as a module, choose M here: the module
will be called da9063_onkey.
diff --git a/drivers/input/misc/da9063_onkey.c
b/drivers/input/misc/da9063_onkey.c
index f577585..8eb697d 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -1,5 +1,5 @@
/*
- * OnKey device driver for DA9063
+ * OnKey device driver for DA9063 and DA9062 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -24,36 +24,96 @@
#include
#include
#include
+#include
+#include
+
+struct da906x_chip_config {
+ /* REGS */
+ int onkey_status;
+ int onkey_pwr_signalling;
+ int onkey_fault_log;
+ int onkey_shutdown;
+ /* MASKS */
+ int onkey_nonkey_mask;
+
Re: [PATCH v4 7/7] arm64: dts: mt8173: Add subsystem clock controller device nodes
On Mon, 2015-07-27 at 03:21 -0700, Matthias Brugger wrote:
> On Monday, July 27, 2015 10:56:22 AM James Liao wrote:
> > Hi Daniel,
> >
> > On Fri, 2015-07-24 at 19:32 +0800, Daniel Kurtz wrote:
> > > > @@ -88,6 +88,13 @@
> > > >
> > > > #clock-cells = <0>;
> > > >
> > > > };
> > > >
> > > > + cpum_ck: dummy_clk {
> > >
> > > I'm not a big fan of this "dummy_clk".
> > > The 'name' part of the devicetree node is supposed to be generic.
> > > So, perhaps just oscillator@2, and move it down below clk32k:
> > > oscillator@1.
> >
> > > Otherwise:
> > cpum_ck is a test clock which only available in IC test. It's empty on
> > MT8173 evaluation or production boards. Should we name this kind of
> > empty clock as an oscillator? Or is there a better name for it?
> >
>
> So if it will never be part of any available boards, why do you want to add
> it?
infra_cpum is a clock gate, and its clock comes from an external clock.
In previous versions we named the external clock as "clk_null", but it's
not accepted. A specified name is preferred even it's not available on
some boards. So I named it as cpum_ck in this patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] clk: mediatek: Fix rate and dependency of MT8173 clocks
Hi,
On Mon, 2015-07-27 at 09:52 +0200, Heiko Stübner wrote:
> Am Montag, 27. Juli 2015, 14:19:41 schrieb Daniel Kurtz:
> > On Jul 27, 2015 12:52, "Sascha Hauer" wrote:
> > > On Fri, Jul 24, 2015 at 07:10:14PM +0800, Daniel Kurtz wrote:
> > > > > /* TOPCKGEN */
> > > > >
> > > > > #define CLK_TOP_CLKPH_MCK_O1
> > > > >
> > > > > -#define CLK_TOP_DPI2
> > > > >
> > > > > #define CLK_TOP_USB_SYSPLL_125M3
> > > >
> > > > I think we should renumber the rest of the CLK_TOP_*
> > >
> > > They shouldn't be renumbered at all as this makes all binary device
> > > trees out there useless. That may not be a big issue with the MT8173
> > > at the moment as there are hardly any binary device trees with the
> > > mainline device trees shipped, but still we should get used to not
> > > break existing device trees without need.
> >
> > As you mention, there are no devices shipped with mainline binary device
> > trees. So, let's just correct the numbering now while we still can do it
> > painlessly. It seems a bit unnecessary to preserve backwards compatibility
> > when we are still landing basic device support, like the clock tree.
>
> in general I'm with Sascha on this regarding breaking the dt, and I guess
> the empty number does not hurt this much. Another argument against
> renumbering would be that the clock is there, it's just not used in the
> code anymore, but the clock is acutally still there.
>
>
> But on the other hand, the clock hasn't been part of an official kernel
> release yet (not in 4.1), and if we want to follow protocol to the letter,
> the removal of the clock id itself is already breakage, because the
> binding-header is considered part of the dt and removing a constant
> could already cause breakage in some universe far far away :-)
>
> So you could try to convince the clock maintainers, that this might still
> be 4.2 material. Or do a smaller patch for 4.2 like the following, to at
> least follow the dt-protocol.
>
> Please also take a look at the mt8135 clock tree, to maybe fix this
> already too, before it becomes part of a release.
There is no non-existed clock in current MT8135 clock implementation. So
we just need to remove dpi_ck from MT8173 clocks.
I'll send a new patchset to remove dpi_ck in a small separated patch.
Best regards,
James
> --- 8< -
> From: Heiko Stuebner
> Date: Mon, 27 Jul 2015 09:41:56 +0200
> Subject: [PATCH] clk: mediatek: mt8173: remove unused dpi_ck clock
>
> The dpi_ck clock is not actually used and its source isn't 100% clear too.
> So remove it for the time being.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/clk/mediatek/clk-mt8173.c | 1 -
> include/dt-bindings/clock/mt8173-clk.h | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 8b6523d..80871e2 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -26,7 +26,6 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
>
> static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> };
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h
> index 4ad76ed..7230c38 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -18,7 +18,6 @@
> /* TOPCKGEN */
>
> #define CLK_TOP_CLKPH_MCK_O 1
> -#define CLK_TOP_DPI 2
> #define CLK_TOP_USB_SYSPLL_125M 3
> #define CLK_TOP_HDMITX_DIG_CTS 4
> #define CLK_TOP_ARMCA7PLL_754M 5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/7] clk: mediatek: Add fixed clocks support for Mediatek SoC.
Hi Daniel, On Fri, 2015-07-24 at 19:33 +0800, Daniel Kurtz wrote: > Hi James, > > On Fri, Jul 24, 2015 at 11:01 AM, James Liao > wrote: > > > > +void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks, int num, > > + struct clk_onecell_data *clk_data) > > > void __init mtk_clk_register_fixed_clks(... It will be added in next patch. > > -extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, > > +void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, > > Technically, this hunk is unrelated and should probably be in its own patch. It will be in a separated patch. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
On Mon, 2015-07-27 at 15:11 +0100, Will Deacon wrote:
> On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> > On 27/07/15 05:21, Yong Wu wrote:
> > > + } else {/* page or largepage */
> > > + if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > > + if (large) { /* special Bit */
> >
> > This definitely needs a better comment! What exactly are you doing here
> > and what is that quirk all about?
> > >>>
> > >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> > >>> pagetable.
> > >>
> > >> I'm still not really clear about what this is.
> > >
> > > There is some difference between the standard spec and MTK HW,
> > > Our hw don't implement some bits, like XN and AP.
> > > So I add a quirk for MTK special.
> >
> > When you say it doesn't implement these bits, do you mean that having
> > them set will lead to Bad Things happening in the hardware, or that it
> > will simply ignore them and not enforce any of the protections they
> > imply? The former case would definitely want clearly documenting
> > somewhere, whereas for the latter case I'm not sure it's even worth the
> > complication of having a quirk - if the value doesn't matter there seems
> > little point in doing a special dance just for the sake of semantic
> > correctness of the in-memory PTEs, in my opinion.
>
> Agreed. We should only use quirks if the current (architecturally
> compliant) code causes real issues with the hardware. Then the quirk can
> be used to either avoid the problematic routines or to take extra steps
> to make things work as the architecture intended.
>
> I've asked how this IOMMU differs from the architecture on a number of
> occasions, but I'm still yet to receive a response other than "it's special".
>
After check further with DE, Our pagetable is refer to ARM-v7's
short-descriptor which is a little different from ARM-v8. like bit0(PXN)
in section and supersection, I didn't read ARM-v7 spec before, so I add
a MTK quirk to disable PXN bit in section and supersection.(if the PXN
bit is wrote in ARM-v7 spec, HW will page fault.)
Then I write this code according to ARM-v8 spec defaultly, and add a
ARM-v7 quirk?
And there is a little different between ARM-v7 spec and MTK pagetable.
It's the XN(bit0) in small page. MTK don't implement XN bit.
The bit[1:0] in MTK's small page should be 2'b10, if it's 2'b11, HW will
page fault.
(MTK don't implement AP bits too, but HW don't use them, it is ok even
though AP bits is wrote)
In the end, I will add two quirk like this, is it OK?
//===
#define ARM_PGTABLE_QUIRK_SHORT_ARM_V7 BIT(2) /* for ARM-v7 while
default is the ARM-v8 spec */
#define ARM_PGTABLE_QUIRK_SHORT_MTK BIT(3) /* MTK special */
//===
In the ARM_V7 quirk, I only disable PXN bit in section and supersection,
In the MTK quirk, I only disbable XN in small page.
The other bits seems the same. I'm not sure I write clearly and It seems
we could not copy a image of mtk pagetable here..If any question, please
help tell me.
Thanks very much.
> Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
Hi Michal, I agree we need to be careful with changing the bindings. On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote: > Hi Moritz, > > On 07/25/2015 02:21 AM, Moritz Fischer wrote: >> Signed-off-by: Moritz Fischer >> --- >> arch/arm/boot/dts/zynq-7000.dtsi| 43 - > > This patch is nice in general but every change in binding should be > discussed separately. There is also necessary to wire them up in the > driver to do action. That's why I think that will be the best just to > add the code to slcr and keep others untouched. Ok, just to clarify: You'd suggest to just add the rstc as child node to the slcr, and leave the other nodes untouched? > > For example MACB/GEM is one example. Adding names to this node and > extending driver to work properly with reset means that all others MACB > users will be affected. Definitely this patch should be ACKed by Nicolas. > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform > > Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 3/3] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
Hi Michal,
On Mon, Jul 27, 2015 at 12:12 AM, Michal Simek wrote:
> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>> This adds a reset controller driver to control the Xilinx Zynq
>> SoC's various resets.
>>
>> Signed-off-by: Moritz Fischer
>> ---
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-zynq.c | 142
>> +
>> 2 files changed, 143 insertions(+)
>> create mode 100644 drivers/reset/reset-zynq.c
>>
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index 157d421..3fe50e7 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>> obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
>> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>> obj-$(CONFIG_ARCH_STI) += sti/
>> +obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
>> diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
>> new file mode 100644
>> index 000..05e37f8
>> --- /dev/null
>> +++ b/drivers/reset/reset-zynq.c
>> @@ -0,0 +1,142 @@
>> +/*
>> + * Copyright (c) 2015, National Instruments Corp.
>> + *
>> + * Xilinx Zynq Reset controller driver
>> + *
>> + * 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 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* Offsets into SLCR regmap */
>> +#define SLCR_RST_CTRL_OFFSET 0x200 /* FPGA Software Reset Control */
>> +
>> +#define NBANKS 18
>> +
>> +struct zynq_reset_data {
>> + struct regmap *slcr;
>> + struct reset_controller_dev rcdev;
>> +};
>> +
>> +#define to_zynq_reset_data(p)\
>> + container_of((p), struct zynq_reset_data, rcdev)
>> +
>> +static int zynq_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> +
>
> Personally me I would also add debug message here to be simply enabled
> for easier tracking.
See below
>
>> + regmap_update_bits(priv->slcr,
>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>> +BIT(offset),
>> +BIT(offset));
>> +
>> + return 0;
>> +}
>> +
>> +static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
>> +unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> +
>
> debug message here too.
is:
pr_debug("%s: bank: %u offset %u\n", __func__, bank, offset);
accetable? Otherwise I'd have to carry around a struct dev* to use dev_dbg()
>
>> + regmap_update_bits(priv->slcr,
>> +SLCR_RST_CTRL_OFFSET + (bank * 4),
>> +BIT(offset),
>> +~BIT(offset));
>> +
>> + return 0;
>> +}
>> +
>> +static int zynq_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
>> +
>> + int bank = id / BITS_PER_LONG;
>> + int offset = id % BITS_PER_LONG;
>> + u32 reg;
>> +
>> + regmap_read(priv->slcr, SLCR_RST_CTRL_OFFSET + (bank * 4), ®);
>
> debug message here too.
>
>> +
>> + return !(reg & BIT(offset));
>> +}
>> +
>> +static const struct reset_control_ops zynq_reset_ops = {
>
> Remove const here - there is sparse warning.
>
>> + .assert = zynq_reset_assert,
>> + .deassert = zynq_reset_deassert,
>> + .status = zynq_reset_status,
>> +};
>> +
>> +static int zynq_reset_probe(struct platform_device *pdev)
>> +{
>> + struct zynq_reset_data *priv;
>> +
>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> + platform_set_drvdata(pdev, priv);
>> +
>> + priv->slcr = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
>> + "syscon");
>> + if (IS_ERR(priv->slcr)) {
>> + dev_err(&pdev->dev, "unable to get zynq-slcr regmap");
>> + return PTR_ERR(priv->slcr);
>> + }
>> +
>> + priv->rcdev.owner = THIS_MODULE;
>> + priv->rcdev.nr_resets = NBANKS * BITS_PER_LONG;
>> + priv->rcdev.ops = &zynq_reset_ops;
>> + priv->rcdev.of_node = pdev->dev.of_node;
>> + reset_controller_register(&priv->rcdev);
>> +
>>
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Michal,
On Sun, Jul 26, 2015 at 10:09 PM, Michal Simek wrote:
> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> ---
>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
>> 1 file changed, 13 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> new file mode 100644
>> index 000..ac4499e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> @@ -0,0 +1,13 @@
>> +Xilinx Zynq PL Reset Manager
>
> here
>
>> +
>> +Required properties:
>> +- compatible: "xlnx,zynq-reset-pl"
>
> Currently it is not just PL reset controller.
>
>> +- syscon <&slcr>;
>
>
> missing : and please be more descriptive here.
>
>> +- #reset-cells: 1
>> +
>> +Example:
>> + rstc: rstc@240 {
>> + #reset-cells = <1>;
>> + compatible = "xlnx,zynq-reset-pl";
>
> Compatible property should go first.
>
> I am missing that reg property
>
>> + syscon = <&slcr>;
>> + };
>>
>
Would something like this work:
Xilinx Zynq Reset Manager
The Zynq AP-SoC has several different resets.
See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
Required properties:
- compatible: "xlnx,zynq-reset"
- reg: SLCR offset and size taken via syscon <0x200 0x50>
- syscon: <&slcr>
This should be a phandle to the Zynq's SLCR register.
- #reset-cells: Must be 1
The Zynq Reset Manager needs to be a child node of the SLCR.
Example:
rstc: rstc@200 {
compatible = "xlnx,zynq-reset";
reg = <0x200 0x50>;
#reset-cells = <1>;
syscon = <&slcr>;
};
> Thanks,
> Michal
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
>
>
Thanks for your feedback,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Sören,
thanks for your feedback.
On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
wrote:
> Hi Moritz,
>
> On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> ---
>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
>> 1 file changed, 13 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> new file mode 100644
>> index 000..ac4499e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> @@ -0,0 +1,13 @@
>> +Xilinx Zynq PL Reset Manager
>> +
>> +Required properties:
>> +- compatible: "xlnx,zynq-reset-pl"
>> +- syscon <&slcr>;
>> +- #reset-cells: 1
>> +
>> +Example:
>> + rstc: rstc@240 {
>> + #reset-cells = <1>;
>> + compatible = "xlnx,zynq-reset-pl";
>> + syscon = <&slcr>;
>> + };
>
> I think you also have to add the outputs and make them part of the
> binding. Otherwise you'd have to read the implementation to find
> out what device should be hooked up to which output of the reset-controller.
Is something like this what you had in mind? I had that prepared for
the next round of patches:
Reset outputs:
0 : soft reset
32 : ddr reset
64 : topsw reset
96 : dmac reset
128: usb0 reset
129: usb1 reset
160: gem0 reset
161: gem1 reset
164: gem0 rx reset
165: gem1 rx reset
166: gem0 ref reset
167: gem1 ref reset
192: sdio0 reset
193: sdio1 reset
196: sdio0 ref reset
197: sdio1 ref reset
224: spi0 reset
225: spi1 reset
226: spi0 ref reset
227: spi1 ref reset
256: can0 reset
257: can1 reset
258: can0 ref reset
259: can1 ref reset
288: i2c0 reset
289: i2c1 reset
320: uart0 reset
321: uart1 reset
322: uart0 ref reset
323: uart1 ref reset
352: gpio reset
384: lqspi reset
385: qspi ref reset
416: smc reset
417: smc ref reset
448: ocm reset
512: fpga0 out reset
513: fpga1 out reset
514: fpga2 out reset
515: fpga3 out reset
544: a9 reset 0
545: a9 reset 1
552: peri reset
> Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/7] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
Hi Daniel,
On Fri, 2015-07-24 at 19:28 +0800, Daniel Kurtz wrote:
> On Fri, Jul 24, 2015 at 11:02 AM, James Liao
> wrote:
> > +struct clk *mtk_clk_register_ref2usb_tx(const char *name,
> > + const char *parent_name, void __iomem *reg)
>
> struct clk * __init mtk_clk_register_ref2usb_tx(
It will be added in next patch.
> >
> > #include
> > #include
> > -#include
> > -#include
>
> nit: this looks like an unrelated change that can be in its own patch.
It will be in a separated patch.
> >
> > +typedef struct clk *(*mtk_clk_register_ex)(const char *, const char *,
> > + void __iomem *);
> > +
> > +struct mtk_clk_ex {
> > + int id;
> > + const char *name;
> > + const char *parent;
> > + u32 reg_ofs;
> > + mtk_clk_register_ex reg_clk_ex;
>
>
> This "mtk_clk_ex" abstraction seems unnecessarily complicated for a
> one-off USB clock.
> Just call mtk_clk_register_ref2usb_tx() directly from mtk_apmixedsys_init().
Use a table to associate related constants and names is more readable,
such as:
APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", ...
If we call mtk_clk_register_ref2usb_tx() directly, it will be:
clk = mtk_clk_register_ref2usb_tx("ref2usb_tx", ...);
clk_data-clks[CLK_APMIXED_REF2USB_TX] = clk;
Do you prefer the last one?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] devicetree: soc: Add Qualcomm SMD based RPM DT binding
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Moved from mfd
.../devicetree/bindings/soc/qcom,smd-rpm.txt | 117 +
1 file changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
new file mode 100644
index ..e27f5c4c54fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
@@ -0,0 +1,117 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,rpm-msm8974"
+
+- qcom,smd-channels:
+ Usage: required
+ Value type:
+ Definition: Shared Memory channel used for communication with the RPM
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Regulators
+
+Regulator nodes are identified by their compatible:
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,rpm-pm8841-regulators"
+ "qcom,rpm-pm8941-regulators"
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+ Usage: optional (pm8841 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_l1_l3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l4_l11-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l21-supply:
+- vin_5vs-supply:
+ Usage: optional (pm8941 only)
+ Value type:
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+The regulator node houses sub-nodes for each regulator within the device. Each
+sub-node is identified using the node's name, with valid values listed for each
+of the pmics below.
+
+pm8841:
+ s1, s2, s3, s4, s5, s6, s7, s8
+
+pm8941:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
+ lvs3, 5vs1, 5vs2
+
+The content of each sub-node is defined by the standard binding for regulators
-
+see regulator.txt.
+
+= EXAMPLE
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8974";
+ qcom,smd-channels = "rpm_requests";
+
+ pm8941-regulators {
+ compatible =
"qcom,rpm-pm8941-regulators";
+ vdd_l13_l20_l23_l24-supply =
<&pm8941_boost>;
+
+ pm8941_s3: s3 {
+ regulator-min-microvolt =
<180>;
+ regulator-max-microvolt =
<180>;
+ };
+
+ pm8941_boost: s4 {
+ regulator-min-microvolt =
<500>;
+ regulator-max-microvolt =
<500>;
+ };
+
+ pm8941_l20: l20 {
+ regulator-min-microvolt =
<295>;
+ regulator-max-microvolt =
<295>;
+ };
+ };
+ };
+ };
+ };
+
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] soc: qcom: Add device tree binding for Shared Memory Device
Add device tree binding documentation for the Qualcomm Shared Memory
Device, used for communication between the various CPUs in the Qualcomm
SoCs.
Signed-off-by: Bjorn Andersson
---
No changes since v2
.../devicetree/bindings/soc/qcom/qcom,smd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
new file mode 100644
index ..f65c76db9859
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
@@ -0,0 +1,79 @@
+Qualcomm Shared Memory Driver (SMD) binding
+
+This binding describes the Qualcomm Shared Memory Driver, a fifo based
+communication channel for sending data between the various subsystems in
+Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,smd"
+
+= EDGES
+
+Each subnode of the SMD node represents a remote subsystem or a remote
+processor of some sort - or in SMD language an "edge". The name of the edges
+are not important.
+The edge is described by the following properties:
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: should specify the IRQ used by the remote processor to
+ signal this processor about communication related updates
+
+- qcom,ipc:
+ Usage: required
+ Value type:
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the remote processor:
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,smd-edge:
+ Usage: required
+ Value type:
+ Definition: the identifier of the remote processor in the smd channel
+ allocation table
+
+= SMD DEVICES
+
+In turn, subnodes of the "edges" represent devices tied to SMD channels on that
+"edge". The names of the devices are not important. The properties of these
+nodes are defined by the individual bindings for the SMD devices - but must
+contain the following property:
+
+- qcom,smd-channels:
+ Usage: required
+ Value type:
+ Definition: a list of channels tied to this device, used for matching
+ the device to channels
+
+= EXAMPLE
+
+The following example represents a smd node, with one edge representing the
+"rpm" subsystem. For the "rpm" subsystem we have a device tied to the
+"rpm_request" channel.
+
+ apcs: syscon@f9011000 {
+ compatible = "syscon";
+ reg = <0xf9011000 0x1000>;
+ };
+
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8974";
+ qcom,smd-channels = "rpm_requests";
+
+ ...
+ };
+ };
+ };
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] Qualcomm Shared Memory & RPM drivers
The third iteration of the patches to add support for the regulators provided by the RPM on family B Qualcomm devices. This depends on the SMEM implementation that Andy already picked up. Changes since v2: - Made smd copy functions work on words for the word access channels - Corrected access of smem items from secure heap - Updated error handling path in RPM driver - Moved init of smd to postcore and rpm to arch - Minor nits from Georgi on the SMD code - Moved rpm driver from mfd to soc Bjorn Andersson (5): soc: qcom: Add device tree binding for Shared Memory Device soc: qcom: Add Shared Memory Driver devicetree: soc: Add Qualcomm SMD based RPM DT binding soc: qcom: Driver for the Qualcomm RPM over SMD regulator: Regulator driver for the Qualcomm RPM .../devicetree/bindings/soc/qcom,smd-rpm.txt | 117 ++ .../devicetree/bindings/soc/qcom/qcom,smd.txt | 79 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/qcom_smd-regulator.c | 349 ++ drivers/soc/qcom/Kconfig | 22 + drivers/soc/qcom/Makefile |2 + drivers/soc/qcom/smd-rpm.c | 244 drivers/soc/qcom/smd.c | 1319 include/linux/soc/qcom/smd-rpm.h | 35 + include/linux/soc/qcom/smd.h | 46 + 11 files changed, 2226 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt create mode 100644 drivers/regulator/qcom_smd-regulator.c create mode 100644 drivers/soc/qcom/smd-rpm.c create mode 100644 drivers/soc/qcom/smd.c create mode 100644 include/linux/soc/qcom/smd-rpm.h create mode 100644 include/linux/soc/qcom/smd.h -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: dts: vf500-colibri: Add device tree node for touchscreen support
On Thu, Jul 16, 2015 at 08:43:20PM +0530, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 4 +++
> arch/arm/boot/dts/vf500-colibri.dtsi| 46
> +
> 2 files changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c5efb57 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,7 @@
> model = "Toradex Colibri VF50 on Colibri Evaluation Board";
> compatible = "toradex,vf500-colibri_vf50-on-eval",
> "toradex,vf500-colibri_vf50", "fsl,vf500";
> };
> +
> +&touchctrl {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..7cbe341 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,50 @@
> memory {
> reg = <0x8000 0x800>;
> };
> +
> + touchctrl: vf50_touchctrl {
Minus rather than underscore should be used in node name. And node name
should be generic. "touchscreen" might be a good choice.
Shawn
> + compatible = "toradex,vf50-touchctrl";
> + io-channels = <&adc1 0>,<&adc0 0>,
> + <&adc0 1>,<&adc1 2>;
> + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> + pen-detect-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> + pen-pullup-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <&pinctrl_touchctrl_idle>;
> + pinctrl-1 = <&pinctrl_touchctrl_default>;
> + pinctrl-2 = <&pinctrl_touchctrl_gpios>;
> + status = "disabled";
> + };
> +};
> +
> +&iomuxc {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x206d
> + VF610_PAD_PTA19__GPIO_9 0x206d
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0 0x2060
> + VF610_PAD_PTA19__ADC0_SE1 0x2060
> + VF610_PAD_PTA16__ADC1_SE0 0x2060
> + VF610_PAD_PTB2__ADC1_SE20x2060
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
> };
> --
> 2.4.6
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: vfxxx: Add io-channel-cells property for ADC node
On Thu, Jul 16, 2015 at 08:43:19PM +0530, Sanchayan Maity wrote: > This commit adds io-channel-cells property to the ADC node. This > property is required in order for an IIO consumer driver to work. > Especially required for Colibri VF50, as the touchscreen driver > uses ADC channels with the ADC driver based on IIO framework. > > Signed-off-by: Sanchayan Maity Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Hi Moritz,
On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
> Signed-off-by: Moritz Fischer
> ---
> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> new file mode 100644
> index 000..ac4499e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> @@ -0,0 +1,13 @@
> +Xilinx Zynq PL Reset Manager
> +
> +Required properties:
> +- compatible: "xlnx,zynq-reset-pl"
> +- syscon <&slcr>;
> +- #reset-cells: 1
> +
> +Example:
> + rstc: rstc@240 {
> + #reset-cells = <1>;
> + compatible = "xlnx,zynq-reset-pl";
> + syscon = <&slcr>;
> + };
I think you also have to add the outputs and make them part of the
binding. Otherwise you'd have to read the implementation to find
out what device should be hooked up to which output of the reset-controller.
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
On 07/24/2015 12:47 AM, Martin Sperl wrote:
>
>> On 24.07.2015, at 06:09, Stephen Warren wrote:
>>
>> I think I'd expect the shared registers to be:
>>
>> bcm2835aux: misc@0x7e215000 {
>>compatible = "brcm,bcm2835-aux";
>>reg = <0x7e215000 0x08>;
>> };
>>
>> There are two 4-byte registers outside the UART/SPI blocks, and the
>> compatible value should reflect what the block is, not that Linux may
>> use a syscon driver to implement the driver for it.
>>
>> In the client, I'd expect a more semantic naming for the reference;
>> something like:
>>
>> brcm,aux = <&bcm2835aux 4>;
>>
>> brcm, since it's a custom/vendor-specific property. aux is the name of
>> the object that's referenced. Packing the phandle and data together into
>> a single property reduces the number of separate properties, and is a
>> typical thing to do in a client of a service in DT.
>
> So in the end you are saying we need a separate driver to get written
> (because of ‘compatible = "brcm,bcm2835-aux”;’)
It's fine if some existing driver matches that compatible value.
> That is unless you would allow:
> compatible = compatible = "brcm,bcm2835-aux”, “syscon”;
"syscon" definitely shouldn't be in a DT.
> If this is not acceptable, then where should such a driver go in the
> kernel tree?
>
> It would essentially implement the following:
> bcm2835aux_enable(dev, device-id);
> bcm2835aux_disable(dev, device-id);
>
> Which would just set/clean the bits in the register while holding a lock.
That sounds reasonable. I'd also expect a function that the client
drivers could call during probe() to look up the device (and implement
deferred probe) and another to release the reference during the client's
remove().
> As an alternative: maybe we could implement it as an IRQ driver
> and when the irq is requested for that device, then the HW-block gets
> enabled automatically (and disabled when released).
That seems a bit too implicit; there's no strict requirement that a
driver for e.g. the SPI block has to use an interrupt; it's merely
extremely likely.
> That way we may not need to have a separate driver that would enable
> the uart1, but it would be sufficient to configure it as follows:
Surely the IRQ driver would be a separate driver either way? The only
difference is whether it exposes custom APIs, or does things as a
side-effect of the existing IRQ API.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Cc'ing few people (whom I cc'd last time as well :)).
On 27-07-15, 16:20, Lee Jones wrote:
> These OPPs are used in ST's CPUFreq implementation.
>
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - None, new patch
>
> Documentation/devicetree/bindings/power/opp-st.txt | 76
> ++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
>
> diff --git a/Documentation/devicetree/bindings/power/opp-st.txt
> b/Documentation/devicetree/bindings/power/opp-st.txt
> new file mode 100644
> index 000..6eb2a91
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/opp-st.txt
> @@ -0,0 +1,76 @@
> +STMicroelectronics OPP (Operating Performance Points) Bindings
> +--
> +
> +Frequency Scaling only
> +--
> +
> +Located in CPU's node:
> +
> +- operating-points : [See: ./opp.txt]
> +
> +Example [safe]
> +--
> +
> +cpus {
> + cpu@0 {
> + /* kHz uV */
> + operating-points = <150 0
> + 120 0
> + 80 0
> + 50 0>;
> + };
> +};
> +
> +Dynamic Voltage and Frequency Scaling (DVFS)
> +
> +
> +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> +
> +- compatible : Should be "operating-points-v2-sti"
> +- opp{1..N} : Each 'oppX' subnode will contain the following
> properties:
Or should we mention:
- opp{1..N} : Each 'oppX' subnode shall contain below properties,
over what ./opp.txt defines:
?
> + - opp-hz: CPU frequency [Hz] for this OPP [See: ./opp.txt]
> + - st,avs: List of available voltages [uV] indexed by process
> code
> + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL]
> + - st,substrate : Substrate version this OPP is suitable for
> [0xFF means ALL]
> +- st,syscfg : Phandle to Major number register
> + First cell: offset to major number
> +- st,syscfg-eng : Phandle to Minor number and Pcode registers
> + First cell: offset to process code
> + Second cell: offset to minor number
> +
> +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not
> attempt to
> + artificially synthesise the opp{1..N} nodes or any of their
> descendants.
> + They are very platform specific and may damage the hardware if created
> + incorrectly.
> +
> +Example [unsafe]
> +
> +
> +cpus {
> + cpu@0 {
> + operating-points-v2 = <&cpu0_opp_list>;
> + };
> +};
> +
> +/* */
> +/* # WARNING: Do not attempt to copy/replicate this node, # */
> +/* # it is only to be supplied by the bootloader !!! # */
> +/* */
> +cpu0-opp-list {
> + compatible = "operating-points-v2-sti";
> + st,syscfg = <&syscfg [major_offset]>;
> + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>;
> +
> + opp0 {
> + opp-hz = <12>;
> + st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
> + st,substrate= <0xff>;
> + st,cuts = <0xff>;
> + };
> + opp1 {
> + opp-hz = <15>;
> + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
> + st,substrate= <0xff>;
> + st,cuts = <0x2>;
> + };
> +};
I don't see more problems here, unless we can move some of this to the
generic bindings.
@Rob/Stephen: Please respond before it is late :)
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
On 27-07-15, 16:20, Lee Jones wrote:
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - Using OPP-v2
> - Moved (and linked) a bunch of documentation to ../power/
>
> .../devicetree/bindings/cpufreq/cpufreq-st.txt | 40
> ++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> new file mode 100644
> index 000..79add9d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> @@ -0,0 +1,40 @@
> +Binding for ST's CPUFreq driver
> +===
> +
> +Frequency Scaling only
> +--
> +
> +Located in CPU's node:
> +
> +- operating-points : [See: ../power/opp.txt]
> +
> +Example [safe]
> +--
> +
> +cpus {
> + cpu@0 {
> + /* kHz uV */
> + operating-points = <150 0
> + 120 0
> + 80 0
> + 50 0>;
> + };
> +};
> +
> +Dynamic Voltage and Frequency Scaling (DVFS)
> +
> +
> +Located in CPU's node:
> +
> +- operating-points-v2-sti: [See ../power/opp-st.txt]
> +
> +Example [unsafe]
> +
> +
> +cpus {
> + cpu@0 {
> + operating-points-v2 = <[OPP list phandle]>;
> + };
> +};
> +
> +For an example of an OPP list, see ../power/opp-st.txt.
I don't think you need this file/patch at all.. It is almost blank and
doesn't define a binding. And so there is no need to specify this at
all. Just an OPP binding file is enough.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/7] clk: mediatek: Add subsystem clocks of MT8173
Hi Daniel,
On Fri, 2015-07-24 at 19:18 +0800, Daniel Kurtz wrote:
> On Fri, Jul 24, 2015 at 11:02 AM, James Liao
> wrote:
> > +static const struct mtk_gate_regs cg_regs_4_8_0 = {
>
> All of these regs tables can be __initconst.
It will be added in next patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
On Mon, Jul 27, 2015 at 06:42:40PM +0200, Stefan Agner wrote: > The eigth revision fixes some rough spots in the device trees. > > More information and the full test log of earlier patchset version > can be found in the cover letter of the last revision v6: > http://thread.gmane.org/gmane.linux.kernel/1979868 > > Changes since v7: > - vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node > and sort new nfc node behind the existing iomuxc node as well. > - vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes Now I'm happy with the dts part and waiting for mtd part to be accepted to actually apply them. Shawn > > Changes since v6: > - Rebased ontop of l2-mtd/master (v4.2-rc1 based) > - Removed HAVE_NAND_VF610_NFC and use depends on. This made > "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary > > Changes since v5: > - Removed fsl,mpc5125-nfc compatible string > - Removed readl/writel_relaxed > - Change interface of vf610_nfc_transfer_size to match other accessors > > Changes since v4: > - Rebased ontop of l2-mtd/master (v4.1-rc4 based) > - Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does > not support sub-page writes anyway (improves write performance) > - Support ONFI by enabling READID command with offset and parameter page > reads (CMD_PARAM) > - Change to dedicated read_page/write_page function, enables raw writes > - Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements > - Eliminated vf610_nfc_probe_dt in favor of common DT init code > - Use wait_for_completion_timeout > - Some style fixes (spaces, etc.) > > Changes since v3: > - Make the driver selectable when COMPILE_TEST is set > - Fix compile error due to superfluous ECC_STATUS configuration in initial > patch (without ECC correction ECC_STATUS does not need to be configured) > - Remove custom BBT pattern and switch to in-band BBT in the initial patch > - Include two bug fixes, for details see the corresponding U-Boot patches: > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 > > Changes since v2: > - Updated binding documentation > > Changes since v1: > - Nest nfc_config struct within the main nfc struct > - Use assigned clock binding to specify NFC clock > - Rebased ontop of MSCM IR patchset (driver parts have been merged) > - Split out arch Kconfig in a separate config > - Fix module license > - Updated MAINTAINERS > > Changes since RFC (Bill Pringlemeir): > - Renamed driver from fsl_nfc to vf610_nfc > - Use readl/writel for all register in accessor functions > - Optimized field accessor functions > - Implemented PM (suspend/resume) functions > - Implemented basic support for ECC strength/ECC step size from dt > - Improved performance of count_written_bits by using hweight32 > - Support ECC with 60-bytes to correct up to 32 bit errors > - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes > which uses up to 60 bytes on 64 byte OOB > - Removed custom (downstream) BBT pattern since BBT table won't be > compatible anyway (due to the change above) > > Stefan Agner (5): > mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others > mtd: nand: vf610_nfc: add hardware BCH-ECC support > mtd: nand: vf610_nfc: add device tree bindings > ARM: dts: vf610twr: add NAND flash controller peripherial > ARM: dts: vf-colibri: enable NAND flash controller > > .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++ > MAINTAINERS| 6 + > arch/arm/boot/dts/vf-colibri.dtsi | 32 + > arch/arm/boot/dts/vf610-twr.dts| 40 + > arch/arm/boot/dts/vfxxx.dtsi | 8 + > drivers/mtd/nand/Kconfig | 11 + > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/vf610_nfc.c | 839 > + > 8 files changed, 982 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt > create mode 100644 drivers/mtd/nand/vf610_nfc.c > > -- > 2.4.5 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/5] mtd: nand: vf610_nfc: add device tree bindings
On Mon, Jul 27, 2015 at 06:42:43PM +0200, Stefan Agner wrote:
> Signed-off-by: Bill Pringlemeir
> Signed-off-by: Stefan Agner
Acked-by: Shawn Guo
> ---
> .../devicetree/bindings/mtd/vf610-nfc.txt | 45
> ++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> new file mode 100644
> index 000..cae5f25
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> @@ -0,0 +1,45 @@
> +Freescale's NAND flash controller (NFC)
> +
> +This variant of the Freescale NAND flash controller (NFC) can be found on
> +Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
> +
> +Required properties:
> +- compatible: Should be set to "fsl,vf610-nfc"
> +- reg: address range of the NFC
> +- interrupts: interrupt of the NFC
> +- nand-bus-width: see nand.txt
> +- nand-ecc-mode: see nand.txt
> +- nand-on-flash-bbt: see nand.txt
> +- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
> +- assigned-clock-rates: The NAND bus timing is derived from this clock
> +rate and should not exceed maximum timing for any NAND memory chip
> +in a board stuffing. Typical NAND memory timings derived from this
> +clock are found in the SoC hardware reference manual. Furthermore,
> +there might be restrictions on maximum rates when using hardware ECC.
> +
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> + representing partitions.
> +
> +Required properties for hardware ECC:
> +- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
> +- nand-ecc-step-size: step size equals page size, currently only 2k pages are
> +supported
> +
> +Example:
> +
> + nfc: nand@400e {
> + compatible = "fsl,vf610-nfc";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x400e 0x4000>;
> + interrupts = ;
> + clocks = <&clks VF610_CLK_NFC>;
> + clock-names = "nfc";
> + assigned-clocks = <&clks VF610_CLK_NFC>;
> + assigned-clock-rates = <3300>;
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + nand-ecc-strength = <32>;
> + nand-ecc-step-size = <2048>;
> + nand-on-flash-bbt;
> + };
> --
> 2.4.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: Add SPI CS on exynos5250-snow
On 28.07.2015 06:24, Javier Martinez Canillas wrote:
> Hello Michal,
>
> The patch looks good to me, just one small comment below.
>
> On Mon, Jul 27, 2015 at 10:11 PM, Michal Suchanek wrote:
>> Although there is only one choice of chipselect it is necessary to
>> specify it. The driver cannot claim the gpio otherwise.
>>
>> Signed-off-by: Michal Suchanek
>>
>> --
>> v2
>> - don't move unrelated line
>> ---
>> arch/arm/boot/dts/exynos5250-snow.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index b7f4122..62be08a 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -688,6 +688,7 @@
>> status = "okay";
>> samsung,spi-src-clk = <0>;
>> num-cs = <1>;
>> + cs-gpios = <&gpa2 5 0>;
>
> NIT: this should be GPIO_ACTIVE_HIGH instead of 0 but maybe Kukjin or
> Krzysztof can fixup when applying it?
>
>> };
>>
>> &usbdrd_dwc3 {
>> --
>
> Acked-by: Javier Martinez Canillas
Yes, the GPIO_ACTIVE_HIGH would be better. Can you re-spin the patch
with this change and respective Acks? Including mine ack:
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: shmobile: Add JPU device nodes to Renesas R-Car SoCs.
On Fri, Jul 24, 2015 at 04:25:44PM +0300, Mikhail Ulyanov wrote: > This series of patches contains device tree nodes definitions for JPEG > codec peripheral found in the Renesas R-Car SoCs. > > This series of patches is against the renesas-devel-20150720-v4.2-rc3 > of https://kernel.googlesource.com/pub/scm/linux/kernel/git/horms/renesas > > The driver itself was accepted by Hans Verkuil > http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git > commit hash 761a0eee505f3a7051b187e67cd28c50b385d409 > > Mikhail Ulyanov (2): > ARM: shmobile: r8a7790: Add JPU device node. > ARM: shmobile: r8a7791: Add JPU device node. Thanks, I have queued up both patches. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 42/51] of/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource, so set IORESOUCE_MEM_64 for 64bit resource during of device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: Grant Likely Cc: Rob Herring Cc: devicetree@vger.kernel.org --- drivers/of/address.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 8bfda6a..073125f 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -128,9 +128,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr) flags |= IORESOURCE_IO; break; case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] iio: adc: hi8435: Holt HI-8435 threshold detector
Add Holt threshold detector driver for HI-8435 chip Signed-off-by: Vladimir Barinov --- Changes in version 2: - Added file sysfs-bus-iio-adc-hi8435 - Changed naming from "discrete ADC" to "threshold detector" - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup - Made *_show and *_store functions static - moved out from iio buffers to iio events - removed hi8436/hi8437 chips from the driver - moved from debounce_soft_delay/enable to debounce_interval via IIO_CHAN_INFO_DEBOUNCE_TIME - added name extention "comparator" - moved threshold/hysteresis setup via generic iio event sysfs - added software mask/unmask channel events - added programming sensor outputs while in test mode via IIO_CHAN_INFO_RAW - added channels .ext_info for programming sensing mode Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 | 76 +++ drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/hi8435.c | 659 + 4 files changed, 747 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 drivers/iio/adc/hi8435.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 new file mode 100644 index 000..2ff5bb3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 @@ -0,0 +1,76 @@ +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Read value is a voltage threshold measurement from channel Y. + Could be ether 0 if sensor voltage lower then low voltage + threshold or 1 if sensor votlage higher then high voltage + threshold. + Write value is a programmed sensor output while in self test + mode. Could be ether 0 or 1. The programmed value will be read + back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 1 + +What /sys/bus/iio/devices/iio:deviceX/test_enable +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Enable/disable the HI-8435 self test mode. + If enabled the in_voltageY_comparator_raw should be read back + accordingly to written value to in_voltageY_comparator_raw + +What /sys/bus/iio/devices/iio:deviceX/debounce_time +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Software debounce interval in millliseconds. If value is + set to 0 then debouncing is disabled + +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Program sensor type for threshold detector inputs. + Could be ether "GND-Open" or "Supply-Open" modes. Y is a + threshold detector input channel. Channels 0..7, 8..15, 16..23 + and 24..31 has common sensor types. + +What /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_either_en +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Mask/unmask channel Y events + +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_falling_value +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Cahnnel Y low voltage threshold. If sensor input voltage goes lower then + this value then the threshold falling event is pushed. + Depending on in_voltageY_comparator_sensing_mode the low voltage threshold + is separately set for "GND-Open" and "Supply-Open" modes. + Channels 0..31 has common low threshold values, but could have different + sensing_modes. + The low voltage threshold range is between 2..21V. + Hysteresis between low and high thresholds can not be lower then 2 and + can not be odd. + +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_thresh_rising_value +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Cahnnel Y high voltage threshold. If sensor input voltage goes higher then + this value then the threshold rising event is pushed. + Depending on in_voltageY_comparator_sensing_mode the high voltage threshold + is separately set for "GND-Open" and "Supply-Open" modes. + Channels 0..31 has common high threshold values, but could have different + sensing_modes. + The
[PATCH v2 2/5] dt: Add vendor prefix 'holt'
Add Holt Integrated Circuits, Inc. to the list of device tree vendor prefixes Signed-off-by: Vladimir Barinov --- Changes in version 2: - none 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 d444757..bc64cc9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -99,6 +99,7 @@ himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hitHitachi Ltd. hitex Hitex Development Tools +holt Holt Integrated Circuits, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] iio: trigger: Add periodic polling to SYSFS trigger
Add periodic polling functionality to SYSFS trigger
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- initially added
.../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11
drivers/iio/trigger/iio-trig-sysfs.c | 58 ++
2 files changed, 69 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..49caff2 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What: /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact: linux-...@vger.kernel.org
+Description:
+ This file is provided by the iio-trig-sysfs stand-alone trigger
+ driver. Writing this file with positive value (in milliseconds)
+ will start peroidic event triggereing of the driver, associated
+ with this trigger. Writing this file with 0 will stop perioding
+ triggering.
+ X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+ struct delayed_work poll_work;
+ unsigned int poll_interval; /* msec */
int id;
struct list_head l;
};
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
}
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+ unsigned long delay;
+
+ delay = msecs_to_jiffies(trig->poll_interval);
+ if (delay >= HZ)
+ delay = round_jiffies_relative(delay);
+
+ queue_delayed_work(system_freezable_wq, &trig->poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+ struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+ poll_work.work);
+
+ irq_work_queue(&trig->work);
+ iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+ return sprintf(buf, "%d\n", sysfs_trig->poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+ unsigned int interval;
+ int err;
+
+ err = kstrtouint(buf, 0, &interval);
+ if (err)
+ return err;
+
+ sysfs_trig->poll_interval = interval;
+
+ cancel_delayed_work_sync(&sysfs_trig->poll_work);
+ if (sysfs_trig->poll_interval > 0)
+ iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+ return count;
+}
+
static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+ iio_sysfs_trigger_set_poll);
static struct attribute *iio_sysfs_trigger_attrs[] = {
&dev_attr_trigger_now.attr,
+ &dev_attr_trigger_poll.attr,
NULL,
};
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t->trig, t);
init_irq_work(&t->work, iio_sysfs_trigger_work);
+ INIT_DELAYED_WORK(&t->poll_work, iio_sysfs_trigger_poll_work);
ret = iio_trigger_register(t->trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
+ cancel_delayed_work_sync(&t->poll_work);
+
iio_trigger_unregister(t->trig);
iio_trigger_free(t->trig);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] dt: Document Holt HI-8435 bindings
These bindings can be used to register Holt HI-8435 threshold detector
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
.../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+ compatible = "holt,hi8435";
+ reg = <0>;
+
+ holt,reset-gpios = <&gpio6 1 0>;
+
+ holt,debounce-interval = <100>;
+
+ spi-max-frequency = <100>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] iio: Support triggered events
Support triggered events.
This is useful for chips that has no it's own interrupt sources.
It allows to use generic/standalone iio triggeres for those drivers.
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- initially added
drivers/iio/Kconfig| 6 +++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-core.c| 4 +-
drivers/iio/industrialio-trigger.c | 12 +-
drivers/iio/industrialio-triggered-event.c | 67 ++
include/linux/iio/iio.h| 1 +
include/linux/iio/triggered_event.h| 11 +
7 files changed, 98 insertions(+), 4 deletions(-)
create mode 100644 drivers/iio/industrialio-triggered-event.c
create mode 100644 include/linux/iio/triggered_event.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_TRIGGERED_EVENT
+ tristate
+ select IIO_TRIGGER
+ help
+ Provides helper functions for setting up triggered events.
+
source "drivers/iio/accel/Kconfig"
source "drivers/iio/adc/Kconfig"
source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev
*indio_dev)
static void iio_dev_release(struct device *device)
{
struct iio_dev *indio_dev = dev_to_iio_dev(device);
- if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+ if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
- if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+ if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/drivers/iio/industrialio-trigger.c
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device
*dev,
indio_dev->trig = trig;
- if (oldtrig)
+ if (oldtrig) {
+ if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+ iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc);
iio_trigger_put(oldtrig);
- if (indio_dev->trig)
+ }
+ if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+ if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+ iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+ }
return len;
}
diff --git a/drivers/iio/industrialio-triggered-event.c
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..c434ce7
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,67 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh: Function which will be used as pollfunc bottom half
+ * @pollfunc_th: Function which will be used as pollfunc top half
+ *
+ * This function combines some common tasks which will normally be performed
+ * when setting up a triggered event. It will allocate the pollfunc and
+ * set mode to use it for triggered event.
+ *
+ * Before ca
[PATCH v2 0/5] iio: adc: hi8435: Add Holt HI-8435 threshold detector
Hello, This adds the folowing: - Holt threshold detector driver for HI-8435 chip - Add Holt vendor prefix - Document HI-8435 DT bindings - Add periodic polling functionality to SYSFS trigger - Support triggered events PDF file can be found here: http://www.holtic.com/products/3081-hi-8435.aspx Vladimir Barinov (3): [1/5] iio: adc: hi8435: Holt HI-8435 threshold detector [2/5] dt: Add vendor prefix 'holt' [3/5] dt: Document Holt HI-8435 bindings [4/5] iio: trigger: Add periodic polling to SYSFS trigger [5/5] iio: Support triggered events --- This patchset is against the 'kernel/git/torvalds/linux.git' repo. Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435| 76 ++ Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs | 11 Documentation/devicetree/bindings/iio/adc/hi8435.txt | 25 Documentation/devicetree/bindings/vendor-prefixes.txt |1 drivers/iio/Kconfig |6 drivers/iio/Makefile |1 drivers/iio/adc/Kconfig | 11 drivers/iio/adc/Makefile |1 drivers/iio/adc/hi8435.c | 659 ++ drivers/iio/industrialio-core.c |4 drivers/iio/industrialio-trigger.c| 12 drivers/iio/industrialio-triggered-event.c| 67 + drivers/iio/trigger/iio-trig-sysfs.c | 58 + include/linux/iio/iio.h |1 include/linux/iio/triggered_event.h | 11 15 files changed, 940 insertions(+), 4 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 drivers/iio/adc/hi8435.c create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt create mode 100644 drivers/iio/industrialio-triggered-event.c create mode 100644 include/linux/iio/triggered_event.h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey
On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote: > From: S Twiss > > Add device tree bindings for the DA9062 OnKey driver component > > Signed-off-by: Steve Twiss > > --- > Changes in V3: > - Child driver specifics separated out into separate document >in this case ../input/da9062-onkey.txt > Changes in V2: > - No change > > This patch applies against linux-next and next-20150708 > > > .../devicetree/bindings/input/da9062-onkey.txt | 36 > ++ > Documentation/devicetree/bindings/mfd/da9062.txt | 3 ++ I dropped bits for mfd/da9062.txt, changed to mention both 9062 and 9063, folded into the onkey patch and applied. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: shmobile: r8a7794: add PFC DT support
Define the generic R8A7794 part of the PFC device node.
Based on original patch by Hisashi Nakamura .
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20150727-v4.2-rc4' tag of Simon Horman's
'renesas.git' repo.
Changes in version 2:
- refreshed the patch.
arch/arm/boot/dts/r8a7794.dtsi |6 ++
1 file changed, 6 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -108,6 +108,12 @@
clocks = <&mstp4_clks R8A7794_CLK_IRQC>;
};
+ pfc: pin-controller@e606 {
+ compatible = "renesas,pfc-r8a7794";
+ reg = <0 0xe606 0 0x11c>;
+ #gpio-range-cells = <3>;
+ };
+
dmac0: dma-controller@e670 {
compatible = "renesas,rcar-dmac";
reg = <0 0xe670 0 0x2>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] input: touchscreen: add imx6ul_tsc driver support
Hi Haibo,
On Mon, Jul 27, 2015 at 07:26:43PM +0800, Haibo Chen wrote:
> Freescale i.MX6UL contains a internal touchscreen controller,
> this patch add a driver to support this controller.
>
> Signed-off-by: Haibo Chen
> ---
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/imx6ul_tsc.c | 510
> +
> 3 files changed, 523 insertions(+)
> create mode 100644 drivers/input/touchscreen/imx6ul_tsc.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 5b272ba..32c300d 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -479,6 +479,18 @@ config TOUCHSCREEN_MTOUCH
> To compile this driver as a module, choose M here: the
> module will be called mtouch.
>
> +config TOUCHSCREEN_IMX6UL_TSC
> + tristate "Freescale i.MX6UL touchscreen controller"
> + depends on OF
> + help
> + Say Y here if you have a Freescale i.MX6UL, and want to
> + use the internal touchscreen controller.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + moduel will be called imx6ul_tsc.
> +
> config TOUCHSCREEN_INEXIO
> tristate "iNexio serial touchscreens"
> select SERIO
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index c85aae2..9379b32 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)+= egalax_ts.o
> obj-$(CONFIG_TOUCHSCREEN_FUJITSU)+= fujitsu_ts.o
> obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
> obj-$(CONFIG_TOUCHSCREEN_ILI210X)+= ili210x.o
> +obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
> obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
> obj-$(CONFIG_TOUCHSCREEN_IPROC) += bcm_iproc_tsc.o
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> b/drivers/input/touchscreen/imx6ul_tsc.c
> new file mode 100644
> index 000..5a5a368
> --- /dev/null
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -0,0 +1,510 @@
> +/*
> + * Freescale i.MX6UL touchscreen controller driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* ADC configuration registers field define */
> +#define ADC_AIEN (0x1 << 7)
> +#define ADC_CONV_DISABLE 0x1F
> +#define ADC_CAL (0x1 << 7)
> +#define ADC_CALF 0x2
> +#define ADC_12BIT_MODE (0x2 << 2)
> +#define ADC_IPG_CLK 0x00
> +#define ADC_CLK_DIV_8(0x03 << 5)
> +#define ADC_SHORT_SAMPLE_MODE(0x0 << 4)
> +#define ADC_HARDWARE_TRIGGER (0x1 << 13)
> +#define SELECT_CHANNEL_4 0x04
> +#define SELECT_CHANNEL_1 0x01
> +#define DISABLE_CONVERSION_INT (0x0 << 7)
> +
> +/* ADC registers */
> +#define REG_ADC_HC0 0x00
> +#define REG_ADC_HC1 0x04
> +#define REG_ADC_HC2 0x08
> +#define REG_ADC_HC3 0x0C
> +#define REG_ADC_HC4 0x10
> +#define REG_ADC_HS 0x14
> +#define REG_ADC_R0 0x18
> +#define REG_ADC_CFG 0x2C
> +#define REG_ADC_GC 0x30
> +#define REG_ADC_GS 0x34
> +
> +#define ADC_TIMEOUT msecs_to_jiffies(100)
> +
> +/* TSC registers */
> +#define REG_TSC_BASIC_SETING 0x00
> +#define REG_TSC_PRE_CHARGE_TIME 0x10
> +#define REG_TSC_FLOW_CONTROL 0x20
> +#define REG_TSC_MEASURE_VALUE0x30
> +#define REG_TSC_INT_EN 0x40
> +#define REG_TSC_INT_SIG_EN 0x50
> +#define REG_TSC_INT_STATUS 0x60
> +#define REG_TSC_DEBUG_MODE 0x70
> +#define REG_TSC_DEBUG_MODE2 0x80
> +
> +/* TSC configuration registers field define */
> +#define DETECT_4_WIRE_MODE (0x0 << 4)
> +#define AUTO_MEASURE 0x1
> +#define MEASURE_SIGNAL 0x1
> +#define DETECT_SIGNAL(0x1 << 4)
> +#define VALID_SIGNAL (0x1 << 8)
> +#define MEASURE_INT_EN 0x1
> +#define MEASURE_SIG_EN 0x1
> +#define VALID_SIG_EN (0x1 << 8)
> +#define DE_GLITCH_2 (0x2 << 29)
> +#define START_SENSE (0x1 << 12)
> +#define TSC_DISABLE (0x1 << 16)
> +#define DETECT_MODE 0x2
> +
> +struct imx6ul_tsc {
> + struct device *dev;
> + struct input_dev *input;
> + void __iomem *tsc_regs;
> + void __iomem *adc_regs;
> + struct clk *tsc_clk;
> + struct
RE: [PATCH v2] dts: ls1021a: Add dts nodes for eTSEC0, eTSEC1 and eTSEC2
> -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: Monday, July 27, 2015 5:28 PM > To: Manoil Claudiu-B08782 > Cc: devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; shawn@linaro.org; Wang Huan-B18965 > Subject: Re: [PATCH v2] dts: ls1021a: Add dts nodes for eTSEC0, eTSEC1 and > eTSEC2 > [...] > > > > .../devicetree/bindings/net/fsl-tsec-phy.txt | 6 +- > > Bindings doc should be a separate patch reviewed by device tree > maintainers. > > > arch/arm/boot/dts/ls1021a-qds.dts | 20 + > > arch/arm/boot/dts/ls1021a-twr.dts | 20 + > > arch/arm/boot/dts/ls1021a.dtsi | 92 > ++ > > Please separate soc level dts changes from board level changes. > Ok, will break this in 3 patches (soc, boards, bindings), trimmed down as much as possible, with remaining findings addressed. Thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: Add SPI CS on exynos5250-snow
Hello Michal,
The patch looks good to me, just one small comment below.
On Mon, Jul 27, 2015 at 10:11 PM, Michal Suchanek wrote:
> Although there is only one choice of chipselect it is necessary to
> specify it. The driver cannot claim the gpio otherwise.
>
> Signed-off-by: Michal Suchanek
>
> --
> v2
> - don't move unrelated line
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index b7f4122..62be08a 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -688,6 +688,7 @@
> status = "okay";
> samsung,spi-src-clk = <0>;
> num-cs = <1>;
> + cs-gpios = <&gpa2 5 0>;
NIT: this should be GPIO_ACTIVE_HIGH instead of 0 but maybe Kukjin or
Krzysztof can fixup when applying it?
> };
>
> &usbdrd_dwc3 {
> --
Acked-by: Javier Martinez Canillas
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] input: touchscreen: pixcir_i2c_ts: Add support for optional wakeup interrupt
On Mon, Jul 27, 2015 at 04:49:22PM +0530, Vignesh R wrote:
>
>
> On 07/27/2015 04:19 PM, Roger Quadros wrote:
> > Hi,
> >
> > On 23/07/15 17:54, Vignesh R wrote:
> >> On am437x-gp-evm, pixcir touchscreen can wake the system from low power
> >> state by generating wake-up interrupt via pinctrl and IO daisy chain.
> >> Add support for optional wakeup interrupt source by regsitering to
> >> automated wake IRQ framework introduced by commit 4990d4fe327b ("PM /
> >> Wakeirq: Add automated device wake IRQ handling").
> >> This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
> >> support for optional wake-up")
> >>
> >> Signed-off-by: Vignesh R
> >> ---
> >>
> >> v3:
> >> * handle error code returned by of_irq_get_byname()
> >>
> >> v2:
> >> * use of_irq_get_byname()
> >> * remove enable/disable_wake_irq()
> >>
> >> drivers/input/touchscreen/pixcir_i2c_ts.c | 22 ++
> >> include/linux/input/pixcir_ts.h | 1 +
> >> 2 files changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
> >> b/drivers/input/touchscreen/pixcir_i2c_ts.c
> >> index 8f3e243a62bf..3a4ab358bf52 100644
> >> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
> >> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
> >> @@ -29,6 +29,8 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +#include
> >>
> >> #define PIXCIR_MAX_SLOTS 5 /* Max fingers supported by driver */
> >>
> >> @@ -364,8 +366,6 @@ static int __maybe_unused pixcir_i2c_ts_suspend(struct
> >> device *dev)
> >>goto unlock;
> >>}
> >>}
> >> -
> >> - enable_irq_wake(client->irq);
> >>} else if (input->users) {
> >>ret = pixcir_stop(ts);
> >>}
> >> @@ -386,8 +386,6 @@ static int __maybe_unused pixcir_i2c_ts_resume(struct
> >> device *dev)
> >>mutex_lock(&input->mutex);
> >>
> >>if (device_may_wakeup(&client->dev)) {
> >> - disable_irq_wake(client->irq);
> >> -
> >>if (!input->users) {
> >>ret = pixcir_stop(ts);
> >>if (ret) {
> >> @@ -445,6 +443,13 @@ static struct pixcir_ts_platform_data
> >> *pixcir_parse_dt(struct device *dev)
> >>dev_dbg(dev, "%s: x %d, y %d, gpio %d\n", __func__,
> >>pdata->x_max + 1, pdata->y_max + 1, pdata->gpio_attb);
> >>
> >> + pdata->wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> >> + if (pdata->wakeirq < 0 && pdata->wakeirq != -ENODATA &&
> >> + pdata->wakeirq != -EINVAL) {
> >> + dev_err(dev, "Failed to get wakeirq\n");
> >> + return ERR_PTR(pdata->wakeirq);
> >> + }
> >> +
> >>return pdata;
> >> }
> >> #else
> >> @@ -564,11 +569,20 @@ static int pixcir_i2c_ts_probe(struct i2c_client
> >> *client,
> >>i2c_set_clientdata(client, tsdata);
> >>device_init_wakeup(&client->dev, 1);
> >>
> >> + /* Register wakeirq */
> >> + error = (pdata->wakeirq > 0) ?
> >> + dev_pm_set_dedicated_wake_irq(dev, pdata->wakeirq) :
> >> + dev_pm_set_wake_irq(dev, client->irq);
> >
> > Can 0 be a valid wakeirq or client->irq?
> > If yes then this logic is broken.
> >
>
> AFAIK, IRQ 0 is always assigned to system timer interrupt (cannot find
> reliable source to quote).
>
> > I would set wakeirq to -EINVAL or something if it is not available
> > during probe and check for that condition.
> >
>
> Not sure, if I understand you correctly
> pdata->wakeirq will have -ENODATA or -EINVAL(as returned by
> of_irq_get_byname()), if wakeirq is not available. Do you want me to
> check for these two conditions specifically rather than
> (pdata->wakeirq > 0) ?
0 is not really valid general IRQ number; I2C for example sets
client->irq to 0 when there is no IRQ.
BTW, what do you think about my patch pushing this into i2c core? Could
you try and see if it works for you?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 6/7] ARM: dts: apq8064: Add DT support for GSBI6 and for UART pin mux
On Mon, Jul 27, 2015 at 02:52:10PM +0100, Srinivas Kandagatla wrote: > From: Pramod Gurav > > This change adds DT support for GSBI6 and muxes the gpio pins > as UART lines. Also defines a alias for serial port on these lines. > > Signed-off-by: Pramod Gurav > [Srinivas Kandagatla]: fix pinctrl location and rename alias correctly > Signed-off-by: Srinivas Kandagatla > --- Applied. Thanks. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 7/7] ARM: dts: apq8064: fix missing gsbi cell-index
On Mon, Jul 27, 2015 at 02:52:19PM +0100, Srinivas Kandagatla wrote: > Without this i2c instance for missing cell-index nodes would fail, fix > it by adding correct cell-index. > > Signed-off-by: Srinivas Kandagatla > --- Applied. Thanks. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 5/7] ARM: dts: apq8064: add pm8921 mpp support
On Mon, Jul 27, 2015 at 02:52:02PM +0100, Srinivas Kandagatla wrote: > This patch adds pmic pm8921 mpp gpio controller node. > > Signed-off-by: Srinivas Kandagatla > --- Applied. Thanks! -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3 2/5] mtd: nand: add NVIDIA Tegra NAND Flash controller driver
On Mon, Jul 27, 2015 at 09:19:57PM +0200, Lucas Stach wrote: > Am Dienstag, den 21.07.2015, 14:27 -0700 schrieb Brian Norris: > I've checked this again and unfortunately the DEC_STATUS_ERR_COUNT seems > to be completely bogus. It is certainly only set when there are > bitflips, but it doesn't represent a valid value. :( HW sucks. > I have another register that seems to accurately reflect the maximum > number of bitflips in any of the 512b ECC blocks, so I'm able to return > the correct amount of bitflips to the upper level. > The downside is that the hardware already does the calculation of max > bitflips, so I'm unable to count bitflips correctly for the stats. All I > can do is to return a pessimistic value that assumes that all 512b > blocks had the returned number of bitflips. Could this be a problem? As things currently stand: no, I don't think so. The ecc_stats are actually mostly just that -- statistics. Some pieces of the codebase use the fact they increased as a sign, but they don't care about the actual number. The max_bitflips calculation, however, is very important so that MTD can determine whether we've reached the reliability threshold. So I guess you have some flexibility in how to report this, but I think two main options are sane: 1. leave as-is; you can only guarantee that max_bitflips occurred in total, so only increment ecc_stats.corrected by max_bitflips 2. change to ecc_stats.corrected += max_bitflips * chip->ecc.steps; This is the maximum that might have occured on this page read. IOW, option 1 is optimistic and option 2 is pessimistic. Either way, this probably deserves a comment in the code. Regards, Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/7] ARM: dts: apq8064: Add pm8921 mfd and its gpio node
On Mon, Jul 27, 2015 at 02:51:52PM +0100, Srinivas Kandagatla wrote: > This patch adds pmic gpio node to the device tree, this node is > necessary for devices like wlan to control reset gpio. > > Signed-off-by: Srinivas Kandagatla > --- Applied. thanks! -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 3/7] ARM: dts: qs600: Add real regulators to sdcc
On Mon, Jul 27, 2015 at 02:50:20PM +0100, Srinivas Kandagatla wrote:
> /* WLAN */
> sdcc4: sdcc@121c {
> status = "okay";
> + vmmc-supply = <&v3p3_fixed>;
> + vqmmc-supply = <&v3p3_fixed>;
> + mmc-pwrseq = <&sdcc4_pwrseq>;
Where is sdcc4_pwrseq defined?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/7] ARM: dts: ifc6410: add real regulators for sdcc nodes.
On Mon, Jul 27, 2015 at 02:50:12PM +0100, Srinivas Kandagatla wrote:
> sdcc3: sdcc@1218 {
> status = "okay";
> + vmmc-supply = <&pm8921_l6>;
> pinctrl-names = "default";
> pinctrl-0 = <&card_detect>;
> cd-gpios= <&tlmm_pinmux 26
> GPIO_ACTIVE_LOW>;
> @@ -187,6 +200,8 @@
> /* WLAN */
> sdcc4: sdcc@121c {
> status = "okay";
> + vmmc-supply = <&ext_3p3v>;
Where is ext_3p3v defined?
> + vqmmc-supply = <&pm8921_lvs1>;
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] irqchip: bcm2836: Use a CPU notifier enable IPIs.
Signed-off-by: Eric Anholt
---
Florian: Thanks! That looks like what we need to squash for Thomas's
feedback. It feels a bit silly to me to avoid enabling IPIs on
not-yet-booted CPUs, despite the fact that Linux itself is what
generates IPIs. However, I've tested it on the 2836 series and it
does work.
drivers/irqchip/irq-bcm2836.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 87340b0..0bb0552 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -14,6 +14,7 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
@@ -195,6 +196,25 @@ static void bcm2836_arm_irqchip_send_ipi(const struct
cpumask *mask,
writel(1 << ipi, mailbox0_base + 16 * cpu);
}
}
+
+/* Unmasks the IPI on the CPU wen it's first brought online. */
+static int bcm2836_arm_irqchip_cpu_notify(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ unsigned int cpu = (unsigned long)hcpu;
+ unsigned int int_reg = LOCAL_MAILBOX_INT_CONTROL0;
+ unsigned int mailbox = 0;
+
+ if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
+ bcm2836_arm_irqchip_unmask_per_cpu_irq(int_reg, mailbox, cpu);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block bcm2836_arm_irqchip_cpu_notifier = {
+ .notifier_call = bcm2836_arm_irqchip_cpu_notify,
+ .priority = 100,
+};
#endif
static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
@@ -205,13 +225,12 @@ static void
bcm2836_arm_irqchip_smp_init(void)
{
#ifdef CONFIG_SMP
- int i;
+ /* Unmask IPIs to the boot CPU. */
+ bcm2836_arm_irqchip_cpu_notify(&bcm2836_arm_irqchip_cpu_notifier,
+ CPU_STARTING,
+ (void *)smp_processor_id());
+ register_cpu_notifier(&bcm2836_arm_irqchip_cpu_notifier);
- /* unmask IPIs */
- for_each_possible_cpu(i) {
- bcm2836_arm_irqchip_unmask_per_cpu_irq(
- LOCAL_MAILBOX_INT_CONTROL0, 0, i);
- }
set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
#endif
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of: fix platform_no_drv_owner.cocci warnings
drivers/of/unittest.c:982:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu
---
unittest.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -979,7 +979,6 @@ static struct platform_driver unittest_d
.remove = unittest_remove,
.driver = {
.name = "unittest",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(unittest_match),
},
};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3 2/5] mtd: nand: add NVIDIA Tegra NAND Flash controller driver
Am Dienstag, den 21.07.2015, 14:27 -0700 schrieb Brian Norris:
[...]
>
> > + return 0;
> > + }
> > +
> > + if (value & DEC_STATUS_ERR_COUNT_MASK) {
> > + value = (value & DEC_STATUS_ERR_COUNT_MASK) >>
> > + DEC_STATUS_ERR_COUNT_SHIFT;
>
> What does this ERR_COUNT represent? The total bitflips seen in this
> page? The max seen per ECC region? Or something else?
>
> > + mtd->ecc_stats.corrected += value;
>
> I ask because this ^^^ should be accounting the total bitflips for the
> page, if possible...
>
> > + return value;
>
> ...and this ^^^ should be returning the max bitflips seen in a single
> correction region (see the mtd_read() API). There is a subtle
> difference.
>
I've checked this again and unfortunately the DEC_STATUS_ERR_COUNT seems
to be completely bogus. It is certainly only set when there are
bitflips, but it doesn't represent a valid value.
I have another register that seems to accurately reflect the maximum
number of bitflips in any of the 512b ECC blocks, so I'm able to return
the correct amount of bitflips to the upper level.
The downside is that the hardware already does the calculation of max
bitflips, so I'm unable to count bitflips correctly for the stats. All I
can do is to return a pessimistic value that assumes that all 512b
blocks had the returned number of bitflips. Could this be a problem?
Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] reset: socfpga: Update reset-socfpga to read the altr,modrst-offset property
From: Dinh Nguyen
In order for the Arria10 to be able to re-use the reset driver for SoCFPGA
Cyclone5/Arria5, we need to read the 'altr,modrst-offset' property from the
device tree entry. The 'altr,modrst-offset' property is the first register
into the reset manager that is used for bringing peripherals out of reset.
Signed-off-by: Dinh Nguyen
---
drivers/reset/reset-socfpga.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 0a8def3..9074d41 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -24,11 +24,11 @@
#include
#define NR_BANKS 4
-#define OFFSET_MODRST 0x10
struct socfpga_reset_data {
spinlock_t lock;
void __iomem*membase;
+ u32 modrst_offset;
struct reset_controller_dev rcdev;
};
@@ -45,8 +45,8 @@ static int socfpga_reset_assert(struct reset_controller_dev
*rcdev,
spin_lock_irqsave(&data->lock, flags);
- reg = readl(data->membase + OFFSET_MODRST + (bank * NR_BANKS));
- writel(reg | BIT(offset), data->membase + OFFSET_MODRST +
+ reg = readl(data->membase + data->modrst_offset + (bank * NR_BANKS));
+ writel(reg | BIT(offset), data->membase + data->modrst_offset +
(bank * NR_BANKS));
spin_unlock_irqrestore(&data->lock, flags);
@@ -67,8 +67,8 @@ static int socfpga_reset_deassert(struct reset_controller_dev
*rcdev,
spin_lock_irqsave(&data->lock, flags);
- reg = readl(data->membase + OFFSET_MODRST + (bank * NR_BANKS));
- writel(reg & ~BIT(offset), data->membase + OFFSET_MODRST +
+ reg = readl(data->membase + data->modrst_offset + (bank * NR_BANKS));
+ writel(reg & ~BIT(offset), data->membase + data->modrst_offset +
(bank * NR_BANKS));
spin_unlock_irqrestore(&data->lock, flags);
@@ -85,7 +85,7 @@ static int socfpga_reset_status(struct reset_controller_dev
*rcdev,
int offset = id % BITS_PER_LONG;
u32 reg;
- reg = readl(data->membase + OFFSET_MODRST + (bank * NR_BANKS));
+ reg = readl(data->membase + data->modrst_offset + (bank * NR_BANKS));
return !(reg & BIT(offset));
}
@@ -100,6 +100,8 @@ static int socfpga_reset_probe(struct platform_device *pdev)
{
struct socfpga_reset_data *data;
struct resource *res;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
/*
* The binding was mainlined without the required property.
@@ -120,6 +122,11 @@ static int socfpga_reset_probe(struct platform_device
*pdev)
if (IS_ERR(data->membase))
return PTR_ERR(data->membase);
+ if (of_property_read_u32(np, "altr,modrst-offset",
&data->modrst_offset)) {
+ dev_err(dev, "no altr,modrst-offset specified in device
tree\n");
+ return -ENODEV;
+ }
+
spin_lock_init(&data->lock);
data->rcdev.owner = THIS_MODULE;
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3 2/5] mtd: nand: add NVIDIA Tegra NAND Flash controller driver
Hi Brian,
a bit of investigation later I have some coherent answers to your
requests. :)
Am Mittwoch, den 22.07.2015, 16:10 -0700 schrieb Brian Norris:
> Hi,
>
> On Wed, Jul 22, 2015 at 10:42:40PM +0200, Lucas Stach wrote:
> > Am Dienstag, den 21.07.2015, 14:27 -0700 schrieb Brian Norris:
> > > On Sun, May 10, 2015 at 08:29:59PM +0200, Lucas Stach wrote:
> > > > --- /dev/null
> > > > +++ b/drivers/mtd/nand/tegra_nand.c
> > > > @@ -0,0 +1,801 @@
> ...
> > > > +static int tegra_nand_read_page(struct mtd_info *mtd, struct nand_chip
> > > > *chip,
> > > > + uint8_t *buf, int oob_required, int
> > > > page)
> > > > +{
> ...
> > > > + value = readl(nand->regs + DEC_STATUS);
> > > > +
> > > > + if (value & DEC_STATUS_A_ECC_FAIL) {
> > > > + /*
> > > > +* The ECC isn't smart enough to figure out if a page is
> > > > +* completely erased and flags an error in this case.
> > > > So we
> > > > +* check the read data here to figure out if it's a
> > > > legitimate
> > > > +* error or a false positive.
> > > > +*/
> > > > + int i;
> > > > + u32 *data = (u32 *)buf;
> > > > + for (i = 0; i < mtd->writesize / 4; i++) {
> > > > + if (data[i] != 0x) {
> > > > + mtd->ecc_stats.failed++;
> > > > + return -EBADMSG;
> > > > + }
> > > > + }
> > >
> > > Hmm, what about OOB? It's possible to actually write 0xff to the entire
> > > page. This hunk means that such a data pattern would then be
> > > unprotected. You should probably check that *both* the main and OOB data
> > > are all 0xff; if there are non-0xff bytes, then that (probably, see the
> > > following) means someone intentionally wrote all 0xff to the page. [1]
> > >
> >
> > This check is only executed if the ECC engine flagged a non-correctable
> > error. If someone wrote all 0xff to the page there will be a proper ECC
> > checksum calculated and we won't get into this path. So to get this
> > check to wrongly paper over a legitimate error someone would need to
> > write almost all 0xff with a few bits 0, which then flip to a 1
> > afterwards, which is highly unlikely as far as I understand flash
> > technology.
>
> On second thought, the case I mentioned is not a problem for you
> currently. You'll just have more problems once you start seeing bitflips
> in erased pages.
>
> And I agree, the latter case you mention is probably pretty unlikely,
> though I'm not really an EE expert to tell you cannot see such a 0->1
> "stuck bit".
>
> But anyway, why don't you check the spare area too? It turns the
> "unlikely" problem into a non-issue.
>
If I'm using the HWECC/DMA functions I have no way to check the OOB ECC
area. The controller just skips over it and only transfers user
available OOB data into the buffer. So checking the OOB is unfortunately
not easily done.
> At the same time, I see that you don't support raw page reads/writes. Is
> it impossible? Or is it just an oversight?
>
It's possible, but I've skipped it for now, as this would increase the
amount of testing I have to do to validate each round of those patches
even more and I don't see much benefit right now. So this remains a
TODO.
[...]
> > > > + unsigned long rate = clk_get_rate(nand->clk) / 100;
>
> ^^ conversion to MHz? Why? (comment) How about DIV_ROUND_UP, so you
> don't overestimate the clock period (and thus underestimate the number
> of clock periods needed)?
>
> > > > + unsigned long period = 100 / rate;
>
> And period is... in picoseconds? It took me a minute to figure that out
> for sure, so IMO it deserves a comment.
>
> > > > + const struct nand_sdr_timings *timings;
> > > > + u32 val, reg = 0;
> > > > +
> > > > + timings = onfi_async_timing_mode_to_sdr_timings(mode);
> > > > +
> > > > + val = max3(timings->tAR_min, timings->tRR_min,
> > > > + timings->tRC_min) / period;
>
> DIV_ROUND_UP()? You don't want to lop off a partial timing cycle, right?
> Simliar comments apply throughout. Or please correct me if I'm wrong.
>
I agree with the reasoning here and made those changes for v4.
> > > > + if (val > 2)
> > > > + val -= 3;
> > > > + reg |= TIMING_TCR_TAR_TRR(val);
> > > > +
> > > > + val = max(max(timings->tCS_min, timings->tCH_min),
> > > > + max(timings->tALS_min, timings->tALH_min)) / period;
> > > > + if (val > 1)
> > > > + val -= 2;
> > > > + reg |= TIMING_TCS(val);
> > > > +
> > > > + val = (max(timings->tRP_min, timings->tREA_max) + 6000) /
> > > > period;
> > > > + reg |= (TIMING_TRP(val) | TIMING_TRP_RESP(val));
> > > > +
> > > > + reg |= TIMING_TWB(timings->tWB_max / period);
> > > > + reg |= TIMING_TWHR(timi
Re: [PATCH v1 0/7] APQ8064 dt patches.
On Mon, Jul 27, 2015 at 02:49:05PM +0100, Srinivas Kandagatla wrote: > Hi Andy, > > Here are some DT patches which are fixes + pmic gpio/mpp nodes for APQ8064. > I tested these patches on APQ8064 based IFC6410 board. These patches are > on top of your qcom/dt branch. > > I got few more DT patches which depend on the pmic gpio and mpp dt-bindings > header file, > this header file is already available in the linux-next, Should I send those > patches too? > Or wait till it appears on 4.3-rc1? Send em. I can at least add them to my next branch. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: socfpga: dts: add "altr,modrst-offset" property
From: Dinh Nguyen
The "altr,modrst-offset" property represents the offset into the reset manager
that is the first register to be used by the driver to bring peripherals out
of reset.
Signed-off-by: Dinh Nguyen
---
Documentation/devicetree/bindings/reset/socfpga-reset.txt | 2 ++
arch/arm/boot/dts/socfpga.dtsi| 1 +
arch/arm/boot/dts/socfpga_arria10.dtsi| 1 +
3 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/reset/socfpga-reset.txt
b/Documentation/devicetree/bindings/reset/socfpga-reset.txt
index 32c1c8b..98c9f56 100644
--- a/Documentation/devicetree/bindings/reset/socfpga-reset.txt
+++ b/Documentation/devicetree/bindings/reset/socfpga-reset.txt
@@ -3,6 +3,7 @@ Altera SOCFPGA Reset Manager
Required properties:
- compatible : "altr,rst-mgr"
- reg : Should contain 1 register ranges(address and length)
+- altr,modrst-offset : Should contain the offset of the first modrst register.
- #reset-cells: 1
Example:
@@ -10,4 +11,5 @@ Example:
#reset-cells = <1>;
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
+ altr,modrst-offset = <0x10>;
};
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 86e0fb6..0bda96a 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -783,6 +783,7 @@
#reset-cells = <1>;
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
+ altr,modrst-offset = <0x10>;
};
usbphy0: usbphy@0 {
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index a252905..22e7d82 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -593,6 +593,7 @@
#reset-cells = <1>;
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x100>;
+ altr,modrst-offset = <0x20>;
};
scu: snoop-control-unit@c000 {
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: socfpga: dts: Add resets for EMACs on Arria10
From: Dinh Nguyen
Add the reset property for the EMAC controllers on Arria10.
Signed-off-by: Dinh Nguyen
---
arch/arm/boot/dts/socfpga_arria10.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 22e7d82..2340fcb 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -16,6 +16,7 @@
#include "skeleton.dtsi"
#include
+#include
/ {
#address-cells = <1>;
@@ -414,6 +415,8 @@
rx-fifo-depth = <16384>;
clocks = <&l4_mp_clk>;
clock-names = "stmmaceth";
+ resets = <&rst EMAC0_RESET>;
+ reset-names = "stmmaceth";
status = "disabled";
};
@@ -431,6 +434,8 @@
rx-fifo-depth = <16384>;
clocks = <&l4_mp_clk>;
clock-names = "stmmaceth";
+ resets = <&rst EMAC1_RESET>;
+ reset-names = "stmmaceth";
status = "disabled";
};
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] dt-bindings: Add reset manager offsets for Arria10
From: Dinh Nguyen The reset manager for is pretty similar to the one for SoCFPGA cyclone5/arria5 except for a few offsets. This patch adds those offsets. Signed-off-by: Dinh Nguyen --- include/dt-bindings/reset/altr,rst-mgr-a10.h | 110 +++ 1 file changed, 110 insertions(+) create mode 100644 include/dt-bindings/reset/altr,rst-mgr-a10.h diff --git a/include/dt-bindings/reset/altr,rst-mgr-a10.h b/include/dt-bindings/reset/altr,rst-mgr-a10.h new file mode 100644 index 000..acb0bbf --- /dev/null +++ b/include/dt-bindings/reset/altr,rst-mgr-a10.h @@ -0,0 +1,110 @@ +/* + * Copyright (c) 2014, Steffen Trumtrar + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_RESET_ALTR_RST_MGR_A10_H +#define _DT_BINDINGS_RESET_ALTR_RST_MGR_A10_H + +/* MPUMODRST */ +#define CPU0_RESET 0 +#define CPU1_RESET 1 +#define WDS_RESET 2 +#define SCUPER_RESET 3 + +/* PER0MODRST */ +#define EMAC0_RESET32 +#define EMAC1_RESET33 +#define EMAC2_RESET34 +#define USB0_RESET 35 +#define USB1_RESET 36 +#define NAND_RESET 37 +#define QSPI_RESET 38 +#define SDMMC_RESET39 +#define EMAC0_OCP_RESET40 +#define EMAC1_OCP_RESET41 +#define EMAC2_OCP_RESET42 +#define USB0_OCP_RESET 43 +#define USB1_OCP_RESET 44 +#define NAND_OCP_RESET 45 +#define QSPI_OCP_RESET 46 +#define SDMMC_OCP_RESET47 +#define DMA_RESET 48 +#define SPIM0_RESET49 +#define SPIM1_RESET50 +#define SPIS0_RESET51 +#define SPIS1_RESET52 +#define DMA_OCP_RESET 53 +#define EMAC_PTP_RESET 54 +/* 55 is empty*/ +#define DMAIF0_RESET 56 +#define DMAIF1_RESET 57 +#define DMAIF2_RESET 58 +#define DMAIF3_RESET 59 +#define DMAIF4_RESET 60 +#define DMAIF5_RESET 61 +#define DMAIF6_RESET 62 +#define DMAIF7_RESET 63 + +/* PER1MODRST */ +#define L4WD0_RESET64 +#define L4WD1_RESET65 +#define L4SYSTIMER0_RESET 66 +#define L4SYSTIMER1_RESET 67 +#define SPTIMER0_RESET 68 +#define SPTIMER1_RESET 69 +/* 70-71 is reserved */ +#define I2C0_RESET 72 +#define I2C1_RESET 73 +#define I2C2_RESET 74 +#define I2C3_RESET 75 +#define I2C4_RESET 76 +/* 77-79 is reserved */ +#define UART0_RESET80 +#define UART1_RESET81 +/* 82-87 is reserved */ +#define GPIO0_RESET88 +#define GPIO1_RESET89 +#define GPIO2_RESET90 + +/* BRGMODRST */ +#define HPS2FPGA_RESET 96 +#define LWHPS2FPGA_RESET 97 +#define FPGA2HPS_RESET 98 +#define F2SSDRAM0_RESET99 +#define F2SSDRAM1_RESET100 +#define F2SSDRAM2_RESET101 +#define DDRSCH_RESET 102 + +/* SYSMODRST*/ +#define ROM_RESET 128 +#define OCRAM_RESET129 +/* 130 is reserved */ +#define FPGAMGR_RESET 131 +#define S2F_RESET 132 +#define SYSDBG_RESET 133 +#define OCRAM_OCP_RESET134 + +/* COLDMODRST */ +#define CLKMGRCOLD_RESET 160 +/* 161-162 is reserved */ +#define S2FCOLD_RESET 163 +#define TIMESTAMPCOLD_RESET164 +#define TAPCOLD_RESET 165 +#define HMCCOLD_RESET 166 +#define IOMGRCOLD_RESET167 + +/* NRSTMODRST */ +#define NRSTPINOE_RESET192 + +/* DBGMODRST */ +#define DBG_RESET 224 +#endif -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] reset: socfpga: Add reset driver support for Arria10 platform
From: Dinh Nguyen Hi, This patch series adds reset driver support for the SoCFPGA Arria10 SOC. The reset manager on the Arria10 is very similar to the one on Cyclone5/Arria5, thus I think it's best to try to re-use the same reset driver. The biggest difference between the reset manager on Arria10 and Cyclone is the addition of security features. Since the driver does not support these security features, it winds down to just a driver that will release IPs from reset. The other difference between Arria10 and Cyclone5 are register offsets, and register bits for different IPs. For the register offset, the main register offset is the very first register that is needed by the driver for releasing IPs from reset. To handle this difference, I've introduced a new DTS property, "altr,modrst-offset", that will represent this register. The register bits for all the resets are in a new file: include/dt-bindings/reset/altr,rst-mgr-a10.h Thanks, Dinh Nguyen (4): dt-bindings: Add reset manager offsets for Arria10 ARM: socfpga: dts: add "altr,modrst-offset" property reset: socfpga: Update reset-socfpga to read the altr,modrst-offset property ARM: socfpga: dts: Add resets for EMACs on Arria10 .../devicetree/bindings/reset/socfpga-reset.txt| 2 + arch/arm/boot/dts/socfpga.dtsi | 1 + arch/arm/boot/dts/socfpga_arria10.dtsi | 6 ++ drivers/reset/reset-socfpga.c | 19 ++-- include/dt-bindings/reset/altr,rst-mgr-a10.h | 110 + 5 files changed, 132 insertions(+), 6 deletions(-) create mode 100644 include/dt-bindings/reset/altr,rst-mgr-a10.h -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irq-bcm2836: Move SMP boot to the irqchip code.
On 27/07/15 11:42, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
> ---
>
> Thomas: The problem with delaying IPI unmasking until secondary boot
> is that it means we need the secondary boot process to integrate with
> the irqchip code, which seems unusual given the dearth of includes I
> could find between arch/arm/mach-* SMP boot code and drivers/irqchip/
> to get function prototypes. However, since the irqchip is most of
> this register space already, it might make sense to just have the SMP
> boot live in drivers/irqchip/. Here's a patch that would do that,
> that could be squashed into my change.
I do not think this patch is going to work, there are CPU notifiers that
allows you to listen for events (CPU_ONLINE, CPU_DEAD...) as to when
(re)configuration of an interrupt controller can become necessary in
other areas of the kernel.
drivers/irqchip/irq-gic*.c contains code that deals with this for instance.
>
> drivers/irqchip/irq-bcm2836.c | 57
> +--
> 1 file changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> index 87340b0..5f2a40e 100644
> --- a/drivers/irqchip/irq-bcm2836.c
> +++ b/drivers/irqchip/irq-bcm2836.c
> @@ -49,14 +49,16 @@
> /* Same status bits as above, but for FIQ. */
> #define LOCAL_FIQ_PENDING0 0x070
> /*
> - * Mailbox0 write-to-set bits. There are 16 mailboxes, 4 per CPU, and
> + * Mailbox write-to-set bits. There are 16 mailboxes, 4 per CPU, and
> * these bits are organized by mailbox number and then CPU number. We
> * use mailbox 0 for IPIs. The mailbox's interrupt is raised while
> * any bit is set.
> */
> #define LOCAL_MAILBOX0_SET0 0x080
> +#define LOCAL_MAILBOX3_SET0 0x08c
> /* Mailbox0 write-to-clear bits. */
> #define LOCAL_MAILBOX0_CLR0 0x0c0
> +#define LOCAL_MAILBOX3_CLR0 0x0cc
>
> #define LOCAL_IRQ_CNTPSIRQ 0
> #define LOCAL_IRQ_CNTPNSIRQ 1
> @@ -195,6 +197,46 @@ static void bcm2836_arm_irqchip_send_ipi(const struct
> cpumask *mask,
> writel(1 << ipi, mailbox0_base + 16 * cpu);
> }
> }
> +
> +/* Requests boot of a secondary CPU.
> + *
> + * The Raspberry Pi firmware has already started up the CPU and set it
> + * spinning in a loop in low memory waiting for a value in mailbox 3
> + * indicating what OS code it should jump to.
> + */
> +int __init bcm2836_smp_boot_secondary(unsigned int cpu, struct task_struct
> *idle)
> +{
> + int timeout = 20;
> + void __iomem *mailbox3_set_base = intc.base + LOCAL_MAILBOX3_SET0;
> + void __iomem *mailbox3_clr_base = intc.base + LOCAL_MAILBOX3_CLR0;
> + unsigned long secondary_startup_phys =
> + (unsigned long) virt_to_phys((void *)secondary_startup);
> +
> + /* Unmask IPIs to the target cpu. */
> + bcm2836_arm_irqchip_unmask_per_cpu_irq(LOCAL_MAILBOX_INT_CONTROL0, 0,
> +cpu);
> +
> + dsb();
> +
> + writel(secondary_startup_phys, mailbox3_set_base + 16 * cpu);
> +
> + while (true) {
> + int val = readl(mailbox3_clr_base + 16 * cpu);
> +
> + if (val == 0)
> + return 0;
> + if (timeout-- == 0)
> + return -ETIMEDOUT;
> + cpu_relax();
> + }
> +
> + return 0;
> +}
> +
> +static struct smp_operations bcm2836_smp_ops __initdata = {
> + .smp_boot_secondary = bcm2836_smp_boot_secondary,
> +};
> +
> #endif
>
> static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
> @@ -205,14 +247,15 @@ static void
> bcm2836_arm_irqchip_smp_init(void)
> {
> #ifdef CONFIG_SMP
> - int i;
> + /* Unmask IPIs to the boot CPU. Other CPUs will be unmasked as
> + * they're brought up.
> + */
> + bcm2836_arm_irqchip_unmask_per_cpu_irq(LOCAL_MAILBOX_INT_CONTROL0, 0,
> +smp_processor_id());
>
> - /* unmask IPIs */
> - for_each_possible_cpu(i) {
> - bcm2836_arm_irqchip_unmask_per_cpu_irq(
> - LOCAL_MAILBOX_INT_CONTROL0, 0, i);
> - }
> set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
> +
> + smp_set_ops(&bcm2836_smp_ops);
> #endif
> }
>
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] irq-bcm2836: Move SMP boot to the irqchip code.
Signed-off-by: Eric Anholt
---
Thomas: The problem with delaying IPI unmasking until secondary boot
is that it means we need the secondary boot process to integrate with
the irqchip code, which seems unusual given the dearth of includes I
could find between arch/arm/mach-* SMP boot code and drivers/irqchip/
to get function prototypes. However, since the irqchip is most of
this register space already, it might make sense to just have the SMP
boot live in drivers/irqchip/. Here's a patch that would do that,
that could be squashed into my change.
drivers/irqchip/irq-bcm2836.c | 57 +--
1 file changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 87340b0..5f2a40e 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -49,14 +49,16 @@
/* Same status bits as above, but for FIQ. */
#define LOCAL_FIQ_PENDING0 0x070
/*
- * Mailbox0 write-to-set bits. There are 16 mailboxes, 4 per CPU, and
+ * Mailbox write-to-set bits. There are 16 mailboxes, 4 per CPU, and
* these bits are organized by mailbox number and then CPU number. We
* use mailbox 0 for IPIs. The mailbox's interrupt is raised while
* any bit is set.
*/
#define LOCAL_MAILBOX0_SET00x080
+#define LOCAL_MAILBOX3_SET00x08c
/* Mailbox0 write-to-clear bits. */
#define LOCAL_MAILBOX0_CLR00x0c0
+#define LOCAL_MAILBOX3_CLR00x0cc
#define LOCAL_IRQ_CNTPSIRQ 0
#define LOCAL_IRQ_CNTPNSIRQ1
@@ -195,6 +197,46 @@ static void bcm2836_arm_irqchip_send_ipi(const struct
cpumask *mask,
writel(1 << ipi, mailbox0_base + 16 * cpu);
}
}
+
+/* Requests boot of a secondary CPU.
+ *
+ * The Raspberry Pi firmware has already started up the CPU and set it
+ * spinning in a loop in low memory waiting for a value in mailbox 3
+ * indicating what OS code it should jump to.
+ */
+int __init bcm2836_smp_boot_secondary(unsigned int cpu, struct task_struct
*idle)
+{
+ int timeout = 20;
+ void __iomem *mailbox3_set_base = intc.base + LOCAL_MAILBOX3_SET0;
+ void __iomem *mailbox3_clr_base = intc.base + LOCAL_MAILBOX3_CLR0;
+ unsigned long secondary_startup_phys =
+ (unsigned long) virt_to_phys((void *)secondary_startup);
+
+ /* Unmask IPIs to the target cpu. */
+ bcm2836_arm_irqchip_unmask_per_cpu_irq(LOCAL_MAILBOX_INT_CONTROL0, 0,
+ cpu);
+
+ dsb();
+
+ writel(secondary_startup_phys, mailbox3_set_base + 16 * cpu);
+
+ while (true) {
+ int val = readl(mailbox3_clr_base + 16 * cpu);
+
+ if (val == 0)
+ return 0;
+ if (timeout-- == 0)
+ return -ETIMEDOUT;
+ cpu_relax();
+ }
+
+ return 0;
+}
+
+static struct smp_operations bcm2836_smp_ops __initdata = {
+ .smp_boot_secondary = bcm2836_smp_boot_secondary,
+};
+
#endif
static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
@@ -205,14 +247,15 @@ static void
bcm2836_arm_irqchip_smp_init(void)
{
#ifdef CONFIG_SMP
- int i;
+ /* Unmask IPIs to the boot CPU. Other CPUs will be unmasked as
+* they're brought up.
+*/
+ bcm2836_arm_irqchip_unmask_per_cpu_irq(LOCAL_MAILBOX_INT_CONTROL0, 0,
+ smp_processor_id());
- /* unmask IPIs */
- for_each_possible_cpu(i) {
- bcm2836_arm_irqchip_unmask_per_cpu_irq(
- LOCAL_MAILBOX_INT_CONTROL0, 0, i);
- }
set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
+
+ smp_set_ops(&bcm2836_smp_ops);
#endif
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] iio: mma8452: add devicetree property to allow all pin wirings
On Mon, Jul 27, 2015 at 03:37:48PM +0100, Martin Kepplinger wrote: > Am 2015-07-27 um 16:23 schrieb Mark Rutland: > > On Mon, Jul 27, 2015 at 03:08:15PM +0100, Martin Kepplinger wrote: > >> For the devices supported by the mma8452 driver, two interrupt pins are > >> available to route the interrupt signals to. By default INT1 is assumed. > >> > >> This adds a bitmask DT property for users to configure interrupt sources > >> for INT2, if that is the wired interrupt pin for them. > > > > This sounds like configureation rather than a HW property. Why does this > > need to be in the DT? > > It's a hardware property of the board that uses the device. There might > be boards that connect just one of them at random, which is the reason > for this DT property. There also might be exotic users who will want > to use both pins to route different interrupt sources to (not yet > supported, but no problem with such a bitmask). Ok, so I'm somewhat confused as to what the hardware looks like and what this means. Could you elaborate on how INT1 and INT2 are used? It looks like they're used as output pins, and so interrupt-names would seem appropriate for describing the combination which is wired up. w.r.t. configuring the choice of output(s), that sounds like a runtime decision rather than something which needs to be configured statically. > >> This is important for everyone to be able to use this driver, no matter > >> how their chip is wired. At the moment, only 0xff for using INT2 for all > >> available interrupt sources is supported. See the devicetree documentation > >> file for more details. > >> > >> Since this doesn't change the default behaviour, it doesn't break anything > >> for existing users. > >> > >> Signed-off-by: Martin Kepplinger > >> Signed-off-by: Christoph Muellner > >> > >> --- > >> .../devicetree/bindings/iio/accel/mma8452.txt| 4 > >> drivers/iio/accel/mma8452.c | 20 > >> +--- > >> 2 files changed, 17 insertions(+), 7 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt > >> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt > >> index 8d98e05..738a430 100644 > >> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt > >> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt > >> @@ -10,6 +10,9 @@ Optional properties: > >> > >>- interrupt-parent: should be the phandle for the interrupt controller > >>- interrupts: interrupt mapping for GPIO IRQ > >> + - use_int2: bitmask to choose interrupt sources assumed to be wired to > >> +interrupt pin INT2 instead of INT1. Only 0xff (INT2 for every > >> interrupt > >> +source) is supported at the moment. > > > > s/_/-/ in property names, please. > > ok. If I don't do a version 6 really soon, I'll reply with this patch > corrected here. > > > > > We generally avoid bitmasks in properties, and we also usually exepct a > > full cell even if data is smaller. The fact that you expect /bits/ 8 > > must be documented here if that's truly necessary. > > It's not truly necessary. It's just a nice fit. There is one 8 bit > (device memory) register that basically could (in the future) be > exposed through this DT property. > > For now it's just 0xff or nothing. We only don't want to create an > interface that could restrict us from implementing more in the future > without breaking anything. It sounds like you wouldn't need this (at least for now) if you were to use interrupt-names to describe whether INT1 and/or INT2 were wired up. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
The eigth revision fixes some rough spots in the device trees. More information and the full test log of earlier patchset version can be found in the cover letter of the last revision v6: http://thread.gmane.org/gmane.linux.kernel/1979868 Changes since v7: - vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node and sort new nfc node behind the existing iomuxc node as well. - vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes Changes since v6: - Rebased ontop of l2-mtd/master (v4.2-rc1 based) - Removed HAVE_NAND_VF610_NFC and use depends on. This made "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary Changes since v5: - Removed fsl,mpc5125-nfc compatible string - Removed readl/writel_relaxed - Change interface of vf610_nfc_transfer_size to match other accessors Changes since v4: - Rebased ontop of l2-mtd/master (v4.1-rc4 based) - Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does not support sub-page writes anyway (improves write performance) - Support ONFI by enabling READID command with offset and parameter page reads (CMD_PARAM) - Change to dedicated read_page/write_page function, enables raw writes - Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements - Eliminated vf610_nfc_probe_dt in favor of common DT init code - Use wait_for_completion_timeout - Some style fixes (spaces, etc.) Changes since v3: - Make the driver selectable when COMPILE_TEST is set - Fix compile error due to superfluous ECC_STATUS configuration in initial patch (without ECC correction ECC_STATUS does not need to be configured) - Remove custom BBT pattern and switch to in-band BBT in the initial patch - Include two bug fixes, for details see the corresponding U-Boot patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 Changes since v2: - Updated binding documentation Changes since v1: - Nest nfc_config struct within the main nfc struct - Use assigned clock binding to specify NFC clock - Rebased ontop of MSCM IR patchset (driver parts have been merged) - Split out arch Kconfig in a separate config - Fix module license - Updated MAINTAINERS Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes which uses up to 60 bytes on 64 byte OOB - Removed custom (downstream) BBT pattern since BBT table won't be compatible anyway (due to the change above) Stefan Agner (5): mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others mtd: nand: vf610_nfc: add hardware BCH-ECC support mtd: nand: vf610_nfc: add device tree bindings ARM: dts: vf610twr: add NAND flash controller peripherial ARM: dts: vf-colibri: enable NAND flash controller .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++ MAINTAINERS| 6 + arch/arm/boot/dts/vf-colibri.dtsi | 32 + arch/arm/boot/dts/vf610-twr.dts| 40 + arch/arm/boot/dts/vfxxx.dtsi | 8 + drivers/mtd/nand/Kconfig | 11 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c | 839 + 8 files changed, 982 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/Kconfig | 6 +-
drivers/mtd/nand/vf610_nfc.c | 201 ++-
2 files changed, 204 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
Enables support for NAND Flash Controller on some Freescale
processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 0da500e..4d795a5 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
* - Untested on MPC5125 and M54418.
* - DMA not used.
* - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
*/
#include
@@ -72,6 +74,8 @@
/* NFC ECC mode define */
#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
/*** Register Mask and bit definitions */
@@ -104,6 +108,8 @@
#define STATUS_BYTE1_MASK 0x00FF
/* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK 0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
#define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
#define CONFIG_DMA_REQ_BIT (1<<20)
#define CONFIG_ECC_MODE_MASK 0x000E
@@ -122,6 +128,21 @@
#define CMD_DONE_CLEAR_BIT (1<<18)
#define IDLE_CLEAR_BIT (1<<17)
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR ((PAGE_2K + 256 - 8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT 0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -136,10 +157,40 @@ struct vf610_nfc {
#define ALT_BUF_STAT 2
#define ALT_BUF_ONFI 3
struct clk *clk;
+ bool use_hw_ecc;
+ u32 ecc_mode;
};
#define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+ .eccbytes = 60,
+ .eccpos = { 4, 5, 6, 7, 8, 9, 10, 11,
+ 12, 13, 14, 15, 16, 17, 18, 19,
+ 20, 21, 22, 23, 24, 25, 26, 27,
+ 28, 29, 30, 31, 32, 33, 34, 35,
+ 36, 37, 38, 39, 40, 41, 42, 43,
+ 44, 45, 46, 47, 48, 49, 50, 51,
+ 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63 },
+ .oobfree = {
+ {.offset = 2,
+.length = 2} }
+};
+
static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
{
return readl(nfc->regs + reg);
@@ -281,6 +332,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc,
int column, int page)
ROW_ADDR_SHIFT, page);
}
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+ vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+ CONFIG_ECC_MODE_MASK,
+ CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
{
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -299,13 +357,20 @@ static void vf610_nfc_command(struct
[PATCH v8 5/5] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..ab2e74b 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = <&pinctrl_i2c0>;
};
+&nfc {
+ assigned-clocks = <&clks VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <2048>;
+ nand-ecc-strength = <32>;
+ nand-on-flash-bbt;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ status = "okay";
+};
+
&pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +169,25 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
This driver supports Freescale NFC (NAND flash controller) found on Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has been tested on 8-bit and 16-bit NAND interface and supports ONFI parameter page reading. Limitations: - DMA and pipelining not used - Pages larger than 2k are not supported - No hardware ECC The driver has only been tested on Vybrid SoC VF610 and VF500. Some paths have been hand-optimized and evaluated by measurements made using mtd_speedtest.ko on a 100MB MTD partition. Colibri VF50 eb write % eb read % page write % page read % rel/opt 5175 115374560 11039 opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10 none5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58 Colibri VF61 eb write % eb read % page write % page read % rel/opt 5766 130965459 12846 opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34 none5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86 rel = using readl_relaxed/writel_relaxed in optimized paths opt = hand-optimized by combining multiple accesses into one read/write The measurements have not been statistically verfied, hence use them with care. The author came to the conclusion that using the relaxed variants of readl/writel are not worth the additional code. Signed-off-by: Bill Pringlemeir Signed-off-by: Stefan Agner --- MAINTAINERS | 6 + drivers/mtd/nand/Kconfig | 9 + drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 640 +++ 4 files changed, 656 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/MAINTAINERS b/MAINTAINERS index 9567329..59975c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10835,6 +10835,12 @@ S: Maintained F: Documentation/fb/uvesafb.txt F: drivers/video/fbdev/uvesafb.* +VF610 NAND DRIVER +M: Stefan Agner +L: linux-...@lists.infradead.org +S: Supported +F: drivers/mtd/nand/vf610_nfc.c + VFAT/FAT/MSDOS FILESYSTEM M: OGAWA Hirofumi S: Maintained diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b2806a..8550b14 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC This enables the driver for the NAND flash controller on the MPC5121 SoC. +config MTD_NAND_VF610_NFC + tristate "Support for Freescale NFC for VF610/MPC5125" + depends on (SOC_VF610 || COMPILE_TEST) + help + Enables support for NAND Flash Controller on some Freescale + processors like the VF610, MPC5125, MCF54418 or Kinetis K70. + The driver supports a maximum 2k page size. The driver + currently does not support hardware ECC. + config MTD_NAND_MXC tristate "MXC NAND support" depends on ARCH_MXC diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..a490af8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..0da500e --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,640 @@ +/* + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Jason ported to M54418TWR and MVFA5 (VF610). + * Authors: Stefan Agner + * Bill Pringlemeir + * Shaohui Xie + * Jason Jin + * + * Based on original driver mpc5121_nfc.c. + * + * This 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; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDRV_NAME"vf610_nfc" + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC
[PATCH v8 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf610-twr.dts | 40
arch/arm/boot/dts/vfxxx.dtsi| 8
2 files changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..2a278a2 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,19 @@
};
};
+&nfc {
+ assigned-clocks = <&clks VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <2048>;
+ nand-ecc-strength = <24>;
+ nand-on-flash-bbt;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ status = "okay";
+};
+
&pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = "disabled";
};
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ reg = <0x400e 0x4000>;
+ interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_NFC>;
+ clock-names = "nfc";
+ status = "disabled";
+ };
};
};
};
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/5] mtd: nand: vf610_nfc: add device tree bindings
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc"
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400e 0x4000>;
+ interrupts = ;
+ clocks = <&clks VF610_CLK_NFC>;
+ clock-names = "nfc";
+ assigned-clocks = <&clks VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] ARM: tegra124: pmu support
On Sat, Jul 18, 2015 at 6:54 AM, Kyle Huey wrote:
> On Fri, Jul 17, 2015 at 4:59 PM, Thierry Reding
> wrote:
>> On Mon, Jul 13, 2015 at 10:35:45AM -0700, Kyle Huey wrote:
>>> This patch modifies the device tree for tegra124 based devices to enable
>>> the Cortex A15 PMU. The interrupt numbers are taken from NVIDIA TRM
>>> DP-06905-001_v03p. This patch was tested on a Jetson TK1.
>>>
>>> Updated for proper ordering and to add interrupt-affinity values.
>>>
>>> Signed-off-by: Kyle Huey
>>> ---
>>> arch/arm/boot/dts/tegra124.dtsi | 17 +
>>> 1 file changed, 13 insertions(+), 4 deletions(-)
>>
>> Is there any way to test this? What are the effects of adding this?
>
> Yes. This enables the ARM PMU driver for the Cortex A15, which allows
> one to use hardware performance counters via the perf_event_open API.
> For a simple test program, see
> https://github.com/khuey/perf-counter-test/. Without this patch, the
> perf_event_open syscall will fail. With this patch, the program will
> print out the performance counter value for each iteration of the
> loop. (IIRC on the A15 the branch counter was removed, so you may want
> to replace 0xD with 0x8 which counts instructions executed if you want
> to see a non-zero number there). You also will see a message about
> the PMU in the kernel log at startup after applying this patch.
>
> I have also tested this extensively (including the interrupt features
> of the PMU) on a more complex program.
>
>> Does it enable using perf for profiling?
>
> I have not tested it, but I believe you can use perf without this
> patch if you do not use features that require hardware performance
> counter support. This patch would enable those features.
>
>>> diff --git a/arch/arm/boot/dts/tegra124.dtsi
>>> b/arch/arm/boot/dts/tegra124.dtsi
>>> index 13cc7ca..de07d7e 100644
>>> --- a/arch/arm/boot/dts/tegra124.dtsi
>>> +++ b/arch/arm/boot/dts/tegra124.dtsi
>>> @@ -918,31 +918,40 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> - cpu@0 {
>>> + A15_0: cpu@0 {
>>> device_type = "cpu";
>>> compatible = "arm,cortex-a15";
>>> reg = <0>;
>>> };
>>>
>>> - cpu@1 {
>>> + A15_1: cpu@1 {
>>> device_type = "cpu";
>>> compatible = "arm,cortex-a15";
>>> reg = <1>;
>>> };
>>>
>>> - cpu@2 {
>>> + A15_2: cpu@2 {
>>> device_type = "cpu";
>>> compatible = "arm,cortex-a15";
>>> reg = <2>;
>>> };
>>>
>>> - cpu@3 {
>>> + A15_3: cpu@3 {
>>> device_type = "cpu";
>>> compatible = "arm,cortex-a15";
>>> reg = <3>;
>>> };
>>> };
>>>
>>> + pmu {
>>> + compatible = "arm,cortex-a15-pmu";
>>> + interrupts = ,
>>> + ,
>>> + ,
>>> + ;
>>> + interrupt-affinity = <&A15_0>, <&A15_1>, <&A15_2>, <&A15_3>;
>>
>> These labels look somewhat artificial to me, perhaps we could do
>> something like the following instead?
>>
>> interrupt-affinity = <&{/cpus/cpu@0}>, ...;
>>
>> That's slightly more obvious and avoids the need to "invent" labels for
>> the CPUs.
>>
>> No need to respin, I can fix that up when applying if nobody objects to
>> using the alternative notation.
>>
>> Thierry
>
> I have no objections. I was not aware that the device tree syntax
> supported that. FWIW I cargo-culted my way to victory from
> vexpress-v2p-ca9.dts here.
>
> - Kyle
Anything else I can do to help move this along?
- Kyle
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver
On 27/07/15 16:31, Russell King - ARM Linux wrote:
On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote:
On 16/07/15 10:04, Yong Wu wrote:
This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).
Signed-off-by: Yong Wu
[...]
+static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
+{
+ struct mtk_iommu_domain *domain = cookie;
+ unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
+
+ dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
+size, DMA_TO_DEVICE);
Nit: this looks like it may as well be dma_map_single.
It would probably be worth following it with a matching unmap too, just to
avoid any possible leakage bugs (especially if this M4U ever appears in a
SoC supporting RAM above the 32-bit boundary).
Why not do the job properly? Take a look at how I implemented the
streaming DMA API on Tegra SMMU (patch set recently sent out earlier
today).
There's no need for hacks like dma_map_page() (and discarding it's
return value) or dma_map_page() followed by dma_unmap_page().
Indeed, as it happens I do have a branch where I prototyped that for the
long-descriptor io-pgtable-arm code a while ago; this discussion has
prompted me to dig it up again. Stay tuned, folks...
Robin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver
On Mon, Jul 27, 2015 at 05:24:31AM +0100, Yong Wu wrote:
> On Fri, 2015-07-24 at 17:55 +0100, Will Deacon wrote:
> > On Fri, Jul 24, 2015 at 06:43:13AM +0100, Yong Wu wrote:
> > > On Tue, 2015-07-21 at 15:59 +0100, Will Deacon wrote:
> > > > On Thu, Jul 16, 2015 at 10:04:34AM +0100, Yong Wu wrote:
> > > > > +static void mtk_iommu_tlb_flush_all(void *cookie)
> > > > > +{
> > > > > + struct mtk_iommu_domain *domain = cookie;
> > > > > + void __iomem *base;
> > > > > +
> > > > > + base = domain->data->base;
> > > > > + writel(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> > > > > + writel(F_ALL_INVLD, base + REG_MMU_INVALIDATE);
> > > >
> > > > This needs to be synchronous, so you probably want to call
> > > > mtk_iommu_tlb_sync at the end.
> > >
> > > From our spec, we have to wait until HW done after tlb flush range.
> > > But it don't need wait after tlb flush all.
> > > so It isn't necessary to add mtk_iommu_tlb_sync in tlb_flush_all here.
> >
> > Okey doke, but I'm surprised you don't need a subsequent DSB or read-back.
> > What if the writel is buffered on the way to the IOMMU?
>
> Then I change to this:
> //==
> writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> writel_relaxed(F_ALL_INVLD, base + REG_MMU_INVALIDATE);
> dsb(ishst);
> //===
> dsb or mb(). which one is better here?
I think you should use mb();
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver
On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote:
> On 16/07/15 10:04, Yong Wu wrote:
> >This patch adds support for mediatek m4u (MultiMedia Memory Management
> >Unit).
> >
> >Signed-off-by: Yong Wu
> [...]
> >+static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> >+{
> >+ struct mtk_iommu_domain *domain = cookie;
> >+ unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
> >+
> >+ dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
> >+size, DMA_TO_DEVICE);
>
> Nit: this looks like it may as well be dma_map_single.
>
> It would probably be worth following it with a matching unmap too, just to
> avoid any possible leakage bugs (especially if this M4U ever appears in a
> SoC supporting RAM above the 32-bit boundary).
Why not do the job properly? Take a look at how I implemented the
streaming DMA API on Tegra SMMU (patch set recently sent out earlier
today).
There's no need for hacks like dma_map_page() (and discarding it's
return value) or dma_map_page() followed by dma_unmap_page().
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones
---
Changelog:
- Using OPP-v2
- Moved (and linked) a bunch of documentation to ../power/
.../devicetree/bindings/cpufreq/cpufreq-st.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
new file mode 100644
index 000..79add9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
@@ -0,0 +1,40 @@
+Binding for ST's CPUFreq driver
+===
+
+Frequency Scaling only
+--
+
+Located in CPU's node:
+
+- operating-points : [See: ../power/opp.txt]
+
+Example [safe]
+--
+
+cpus {
+ cpu@0 {
+/* kHz uV */
+ operating-points = <150 0
+ 120 0
+ 80 0
+ 50 0>;
+ };
+};
+
+Dynamic Voltage and Frequency Scaling (DVFS)
+
+
+Located in CPU's node:
+
+- operating-points-v2-sti : [See ../power/opp-st.txt]
+
+Example [unsafe]
+
+
+cpus {
+ cpu@0 {
+ operating-points-v2 = <[OPP list phandle]>;
+ };
+};
+
+For an example of an OPP list, see ../power/opp-st.txt.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones
---
Changelog:
- None, new patch
Documentation/devicetree/bindings/power/opp-st.txt | 76 ++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
diff --git a/Documentation/devicetree/bindings/power/opp-st.txt
b/Documentation/devicetree/bindings/power/opp-st.txt
new file mode 100644
index 000..6eb2a91
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/opp-st.txt
@@ -0,0 +1,76 @@
+STMicroelectronics OPP (Operating Performance Points) Bindings
+--
+
+Frequency Scaling only
+--
+
+Located in CPU's node:
+
+- operating-points : [See: ./opp.txt]
+
+Example [safe]
+--
+
+cpus {
+ cpu@0 {
+/* kHz uV */
+ operating-points = <150 0
+ 120 0
+ 80 0
+ 50 0>;
+ };
+};
+
+Dynamic Voltage and Frequency Scaling (DVFS)
+
+
+Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
+
+- compatible : Should be "operating-points-v2-sti"
+- opp{1..N}: Each 'oppX' subnode will contain the following
properties:
+ - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt]
+ - st,avs : List of available voltages [uV] indexed by process
code
+ - st,cuts : Cut version this OPP is suitable for [0xFF means ALL]
+ - st,substrate: Substrate version this OPP is suitable for
[0xFF means ALL]
+- st,syscfg: Phandle to Major number register
+ First cell: offset to major number
+- st,syscfg-eng: Phandle to Minor number and Pcode registers
+ First cell: offset to process code
+ Second cell: offset to minor number
+
+WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not
attempt to
+artificially synthesise the opp{1..N} nodes or any of their
descendants.
+They are very platform specific and may damage the hardware if created
+incorrectly.
+
+Example [unsafe]
+
+
+cpus {
+ cpu@0 {
+ operating-points-v2 = <&cpu0_opp_list>;
+ };
+};
+
+/* */
+/* # WARNING: Do not attempt to copy/replicate this node, # */
+/* # it is only to be supplied by the bootloader !!! # */
+/* */
+cpu0-opp-list {
+ compatible = "operating-points-v2-sti";
+ st,syscfg = <&syscfg [major_offset]>;
+ st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>;
+
+ opp0 {
+ opp-hz = <12>;
+ st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
+ st,substrate= <0xff>;
+ st,cuts = <0xff>;
+ };
+ opp1 {
+ opp-hz = <15>;
+ st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
+ st,substrate= <0xff>;
+ st,cuts = <0x2>;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5] PCI: Store PCIe bus address in struct of_pci_range
> -Original Message-
> From: Gabriele Paoloni
> Sent: Monday, July 27, 2015 11:45 AM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v5] PCI: Store PCIe bus address in struct of_pci_range
>
> From: gabriele paoloni
>
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
>
> In order to solve this problem commit f4c55c5a3 "PCI: designware:
> Program ATU with untranslated address" added code to read the PCIe
> controller start address directly from the DT ranges.
>
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
>
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
>
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
>
> the patch is based on 4.2-rc1
>
> Signed-off-by: Gabriele Paoloni
> Acked-by: Liviu Dudai
Fixed Liviu's surname in v6, sorry I messed up amending the commit
> Acked-by: Rob Herring
> ---
> drivers/of/address.c | 2 ++
> drivers/of/of_pci.c| 4
> include/linux/of_address.h | 1 +
> 3 files changed, 7 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
>
> if (!range)
> return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> range->pci_addr = of_read_number(parser->range + 1, ns);
> range->cpu_addr = of_translate_address(parser->node,
> parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
> range->size = of_read_number(parser->range + parser->pna + na,
> ns);
>
> parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>
> pr_debug("Parsing ranges property...\n");
> for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
> /* Read next ranges element */
> if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
> snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> }
>
> pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
> }
>
> return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
> u32 pci_space;
> u64 pci_addr;
> u64 cpu_addr;
> + u64 bus_addr;
> u64 size;
> u32 flags;
> };
> --
> 1.9.1
N�Р骒r��yb�X�肚�v�^�)藓{.n�+���z��z谵z)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ��&�)摺�a囤�� �G���h��j:+v���w��佶
[PATCH v6] PCI: Store PCIe bus address in struct of_pci_range
From: gabriele paoloni
This patch is needed port PCIe designware to new DT parsing API
As discussed in
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.
In order to solve this problem commit f4c55c5a3 "PCI: designware:
Program ATU with untranslated address" added code to read the PCIe
controller start address directly from the DT ranges.
In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.
In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"
This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address
the patch is based on 4.2-rc1
Signed-off-by: Gabriele Paoloni
Acked-by: Liviu Dudau
Acked-by: Rob Herring
---
drivers/of/address.c | 2 ++
drivers/of/of_pci.c| 4
include/linux/of_address.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
of_pci_range_parser *parser,
struct of_pci_range *range)
{
const int na = 3, ns = 2;
+ const int p_ns = of_n_size_cells(parser->node);
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+ range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..fe57030 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+ struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
}
pci_add_resource_offset(resources, res, res->start -
range.pci_addr);
+ entry = list_last_entry(resources, struct resource_entry, node);
+ /* we are using __res for storing the PCI controller address */
+ entry->__res.start = range.bus_addr;
}
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+ u64 bus_addr;
u64 size;
u32 flags;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/8] iio: mma8452: add devicetree binding document
As we support more chips now, add a binding document and remove it from
i2c trivial-devices.txt list.
The binding document is further extended in a later patch of this series.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
builds a nice list of supported compatible strings.
thanks!
.../devicetree/bindings/i2c/trivial-devices.txt| 1 -
.../devicetree/bindings/iio/accel/mma8452.txt | 24 ++
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 00f8652..094238a 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -54,7 +54,6 @@ epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mc13892MC13892: Power Management Integrated Circuit (PMIC) for
i.MX35/51
fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
Accelerometer
-fsl,mma8452MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
with Two-Wire Interface
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
new file mode 100644
index 000..57feb16
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -0,0 +1,24 @@
+Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
+
+Required properties:
+
+ - compatible: should contain one of
+* "fsl,mma8653"
+* "fsl,mma8652"
+* "fsl,mma8453"
+* "fsl,mma8452"
+ - reg: the I2C address of the chip
+
+Optional properties:
+
+ - interrupt-parent: should be the phandle for the interrupt controller
+ - interrupts: interrupt mapping for GPIO IRQ
+
+Example:
+
+ mma8653fc@1d {
+ compatible = "fsl,mma8653";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 0>;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 8/8] iio: mma8452: add devicetree property to allow all pin wirings
For the devices supported by the mma8452 driver, two interrupt pins are
available to route the interrupt signals to. By default INT1 is assumed.
This adds a bitmask DT property for users to configure interrupt sources
for INT2, if that is the wired interrupt pin for them.
This is important for everyone to be able to use this driver, no matter
how their chip is wired. At the moment, only 0xff for using INT2 for all
available interrupt sources is supported. See the devicetree documentation
file for more details.
Since this doesn't change the default behaviour, it doesn't break anything
for existing users.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
PATCH v2 of the series' 5th version. DT cleanup and a little clearer
documentation.
.../devicetree/bindings/iio/accel/mma8452.txt| 3 +++
drivers/iio/accel/mma8452.c | 20 +---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 57feb16..32f137e 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -13,6 +13,8 @@ Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: interrupt mapping for GPIO IRQ
+ - use-int2: To use interrupt pin INT2 instead of INT1 (default), use
+"/bits/ 8 <0xff>" here. More options might be available in the future.
Example:
@@ -21,4 +23,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+ use-int2 = /bits/ 8 <0xff>;
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 918ab59..ab40fa9 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1028,8 +1028,9 @@ static int mma8452_probe(struct i2c_client *client,
{
struct mma8452_data *data;
struct iio_dev *indio_dev;
- int ret;
const struct of_device_id *match;
+ int ret;
+ u8 int2;
match = of_match_device(mma8452_dt_ids, &client->dev);
if (!match) {
@@ -1104,12 +1105,17 @@ static int mma8452_probe(struct i2c_client *client,
int enabled_interrupts = MMA8452_INT_TRANS |
MMA8452_INT_FF_MT;
- /* Assume wired to INT1 pin */
- ret = i2c_smbus_write_byte_data(client,
- MMA8452_CTRL_REG5,
- supported_interrupts);
- if (ret < 0)
- return ret;
+ of_property_read_u8(client->dev.of_node, "use-int2", &int2);
+ if (int2 == 0xff) {
+ dev_dbg(&client->dev, "use interrupt line INT2\n");
+ } else {
+ dev_dbg(&client->dev, "use interrupt line INT1\n");
+ ret = i2c_smbus_write_byte_data(client,
+ MMA8452_CTRL_REG5,
+ supported_interrupts);
+ if (ret < 0)
+ return ret;
+ }
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] iio: mma8452: add devicetree property to allow all pin wirings
Am 2015-07-27 um 16:23 schrieb Mark Rutland:
> On Mon, Jul 27, 2015 at 03:08:15PM +0100, Martin Kepplinger wrote:
>> For the devices supported by the mma8452 driver, two interrupt pins are
>> available to route the interrupt signals to. By default INT1 is assumed.
>>
>> This adds a bitmask DT property for users to configure interrupt sources
>> for INT2, if that is the wired interrupt pin for them.
>
> This sounds like configureation rather than a HW property. Why does this
> need to be in the DT?
It's a hardware property of the board that uses the device. There might
be boards that connect just one of them at random, which is the reason
for this DT property. There also might be exotic users who will want
to use both pins to route different interrupt sources to (not yet
supported, but no problem with such a bitmask).
>
>> This is important for everyone to be able to use this driver, no matter
>> how their chip is wired. At the moment, only 0xff for using INT2 for all
>> available interrupt sources is supported. See the devicetree documentation
>> file for more details.
>>
>> Since this doesn't change the default behaviour, it doesn't break anything
>> for existing users.
>>
>> Signed-off-by: Martin Kepplinger
>> Signed-off-by: Christoph Muellner
>> ---
>> .../devicetree/bindings/iio/accel/mma8452.txt| 4
>> drivers/iio/accel/mma8452.c | 20
>> +---
>> 2 files changed, 17 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> index 8d98e05..738a430 100644
>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> @@ -10,6 +10,9 @@ Optional properties:
>>
>>- interrupt-parent: should be the phandle for the interrupt controller
>>- interrupts: interrupt mapping for GPIO IRQ
>> + - use_int2: bitmask to choose interrupt sources assumed to be wired to
>> +interrupt pin INT2 instead of INT1. Only 0xff (INT2 for every interrupt
>> +source) is supported at the moment.
>
> s/_/-/ in property names, please.
ok. If I don't do a version 6 really soon, I'll reply with this patch
corrected here.
>
> We generally avoid bitmasks in properties, and we also usually exepct a
> full cell even if data is smaller. The fact that you expect /bits/ 8
> must be documented here if that's truly necessary.
It's not truly necessary. It's just a nice fit. There is one 8 bit
(device memory) register that basically could (in the future) be
exposed through this DT property.
For now it's just 0xff or nothing. We only don't want to create an
interface that could restrict us from implementing more in the future
without breaking anything.
>
> Thanks,
> Mark
>
>>
>> Example:
>>
>> @@ -18,4 +21,5 @@ Example:
>> reg = <0x1d>;
>> interrupt-parent = <&gpio1>;
>> interrupts = <5 0>;
>> +use_int2 = /bits/ 8 <0xff>;
>> };
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 918ab59..a03836b1 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -1028,8 +1028,9 @@ static int mma8452_probe(struct i2c_client *client,
>> {
>> struct mma8452_data *data;
>> struct iio_dev *indio_dev;
>> -int ret;
>> const struct of_device_id *match;
>> +int ret;
>> +u8 int2;
>>
>> match = of_match_device(mma8452_dt_ids, &client->dev);
>> if (!match) {
>> @@ -1104,12 +1105,17 @@ static int mma8452_probe(struct i2c_client *client,
>> int enabled_interrupts = MMA8452_INT_TRANS |
>> MMA8452_INT_FF_MT;
>>
>> -/* Assume wired to INT1 pin */
>> -ret = i2c_smbus_write_byte_data(client,
>> -MMA8452_CTRL_REG5,
>> -supported_interrupts);
>> -if (ret < 0)
>> -return ret;
>> +of_property_read_u8(client->dev.of_node, "use_int2", &int2);
>> +if (int2 == 0xff) {
>> +dev_dbg(&client->dev, "use interrupt line INT2\n");
>> +} else {
>> +dev_dbg(&client->dev, "use interrupt line INT1\n");
>> +ret = i2c_smbus_write_byte_data(client,
>> +MMA8452_CTRL_REG5,
>> +supported_interrupts);
>> +if (ret < 0)
>> +return ret;
>> +}
>>
>> ret = i2c_smbus_write_byte_data(client,
>> MMA8452_CTRL_REG4,
>> --
>> 2.1.4
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
> phyCORE-AM335x is a SoM (System on Module) containing
> a AM335x SOC. The module can be connected to different
> carrier boards.
>
> Some hardware parts are configurable on the phyCORE-AM335x.
> So they are disabled on default in this som dtsi file.
> They will be enabled in the board dts files, when populated.
>
> * RAM up to 1GiB
> * PMIC
> * NAND flash up to 1GiB
> * Eth PHY on SOM: 1x RMII
> * SPI NOR flash 8MiB (optional)
> * i2c RTC (optional)
> * i2c EEPROM 4kiB (optional)
>
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
> ++
> 1 file changed, 368 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
>
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> new file mode 100644
> index 000..4d28fc3
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -0,0 +1,368 @@
> +/*
> + * Copyright (C) 2015 Phytec Messtechnik GmbH
> + * Author: Teresa Remmet
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "Phytec AM335x phyCORE";
> + compatible = "phytec,am335x-phycore-som", "ti,am33xx";
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like "ti,am33xx" that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like "phytec,am3352-phycore-som" or whatever is the base family part
on these SOMs.
-Matt
> +
> + aliases {
> + rtc0 = &i2c_rtc;
> + rtc1 = &rtc;
> + };
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <&vdd1_reg>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +
> + vbat: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + };
> +};
> +
> +/* Crypto Module */
> +&aes {
> + status = "okay";
> +};
> +
> +&sham {
> + status = "okay";
> +};
> +
> +/* Ethernet */
> +&am33xx_pinmux {
> + ethernet0_pins: pinmux_ethernet0 {
> + pinctrl-single,pins = <
> + 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_crs.rmii1_crs_dv */
> + 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxerr.rmii1_rxerr */
> + 0x114 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txen.rmii1_txen */
> + 0x124 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd1.rmii1_txd1 */
> + 0x128 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd0.rmii1_txd0 */
> + 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd1.rmii1_rxd1 */
> + 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd0.rmii1_rxd0 */
> + 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
> rmii1_refclk.rmii1_refclk */
> + >;
> + };
> +
> + mdio_pins: pinmux_mdio {
> + pinctrl-single,pins = <
> + /* MDIO */
> + 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
> /* mdio_data.mdio_data */
> + 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
> /* mdio_clk.mdio_clk */
> + >;
> + };
> +};
> +
> +&cpsw_emac0 {
> + phy_id = <&davinci_mdio>, <0>;
> + phy-mode = "rmii";
> + dual_emac_res_vlan = <1>;
> +};
> +
> +&davinci_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins>;
> + status = "okay";
> +};
> +
> +&mac {
> + slaves = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet0_pins>;
> + status = "okay";
> +};
> +
> +&phy_sel {
> + rmii-clock-ext;
> +};
> +
> +/* I2C Busses */
> +&am33xx_pinmux {
> + i2c0_pins: pinmux_i2c0 {
> + pinctrl-single,pins = <
> + 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
> + 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
> + >;
> + };
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + clock-frequency = <40>;
> + status = "okay";
> +
> + tps: pmic@2d {
> + reg = <0x2d>;
> + };
> +
> + i2c_eeprom: eeprom@52 {
> + compatible = "atmel,24c32";
> + pagesize = <32>;
> + reg = <0x52>;
> + status = "disabled";
> + };
> +
> + i2c_rtc: rtc@68 {
> + compatible = "rv4162";
> + reg = <0x68>;
> + status = "disabled";
> + };
> +};
> +
> +/* NAND
Re: [PATCH 8/8] iio: mma8452: add devicetree property to allow all pin wirings
On Mon, Jul 27, 2015 at 03:08:15PM +0100, Martin Kepplinger wrote:
> For the devices supported by the mma8452 driver, two interrupt pins are
> available to route the interrupt signals to. By default INT1 is assumed.
>
> This adds a bitmask DT property for users to configure interrupt sources
> for INT2, if that is the wired interrupt pin for them.
This sounds like configureation rather than a HW property. Why does this
need to be in the DT?
> This is important for everyone to be able to use this driver, no matter
> how their chip is wired. At the moment, only 0xff for using INT2 for all
> available interrupt sources is supported. See the devicetree documentation
> file for more details.
>
> Since this doesn't change the default behaviour, it doesn't break anything
> for existing users.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
> ---
> .../devicetree/bindings/iio/accel/mma8452.txt| 4
> drivers/iio/accel/mma8452.c | 20
> +---
> 2 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> index 8d98e05..738a430 100644
> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -10,6 +10,9 @@ Optional properties:
>
>- interrupt-parent: should be the phandle for the interrupt controller
>- interrupts: interrupt mapping for GPIO IRQ
> + - use_int2: bitmask to choose interrupt sources assumed to be wired to
> +interrupt pin INT2 instead of INT1. Only 0xff (INT2 for every interrupt
> +source) is supported at the moment.
s/_/-/ in property names, please.
We generally avoid bitmasks in properties, and we also usually exepct a
full cell even if data is smaller. The fact that you expect /bits/ 8
must be documented here if that's truly necessary.
Thanks,
Mark
>
> Example:
>
> @@ -18,4 +21,5 @@ Example:
> reg = <0x1d>;
> interrupt-parent = <&gpio1>;
> interrupts = <5 0>;
> + use_int2 = /bits/ 8 <0xff>;
> };
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 918ab59..a03836b1 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1028,8 +1028,9 @@ static int mma8452_probe(struct i2c_client *client,
> {
> struct mma8452_data *data;
> struct iio_dev *indio_dev;
> - int ret;
> const struct of_device_id *match;
> + int ret;
> + u8 int2;
>
> match = of_match_device(mma8452_dt_ids, &client->dev);
> if (!match) {
> @@ -1104,12 +1105,17 @@ static int mma8452_probe(struct i2c_client *client,
> int enabled_interrupts = MMA8452_INT_TRANS |
>MMA8452_INT_FF_MT;
>
> - /* Assume wired to INT1 pin */
> - ret = i2c_smbus_write_byte_data(client,
> - MMA8452_CTRL_REG5,
> - supported_interrupts);
> - if (ret < 0)
> - return ret;
> + of_property_read_u8(client->dev.of_node, "use_int2", &int2);
> + if (int2 == 0xff) {
> + dev_dbg(&client->dev, "use interrupt line INT2\n");
> + } else {
> + dev_dbg(&client->dev, "use interrupt line INT1\n");
> + ret = i2c_smbus_write_byte_data(client,
> + MMA8452_CTRL_REG5,
> + supported_interrupts);
> + if (ret < 0)
> + return ret;
> + }
>
> ret = i2c_smbus_write_byte_data(client,
> MMA8452_CTRL_REG4,
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] dts: ls1021a: Add dts nodes for eTSEC0, eTSEC1 and eTSEC2
On Tue, Jul 14, 2015 at 06:46:17PM +0300, Claudiu Manoil wrote:
> This patch adds generic dts nodes for eTSEC0, eTSEC1 and eTSEC2.
>
> Signed-off-by: Alison Wang
SoBs should be put together.
>
> Enable support for the second interrupt group register block
> and the corresponding Rx/Tx/Err interrupt sources, for each
> eTSEC node. DT binding documentation updates.
>
> Signed-off-by: Claudiu Manoil
Please use "ARM: dts: ls1021a: ..." as subject prefix.
> ---
> v2:
> - register block size is 0x1000 (4kB memory page), not 0x8000;
> - reg property has 2 "address" and resp. 2 "size" cells;
> - remove optional/ obsoleted properties;
> - use register block address as queue-group id for consistency;
> - binding documentation updates for missing vendor properties;
>
>
> .../devicetree/bindings/net/fsl-tsec-phy.txt | 6 +-
Bindings doc should be a separate patch reviewed by device tree
maintainers.
> arch/arm/boot/dts/ls1021a-qds.dts | 20 +
> arch/arm/boot/dts/ls1021a-twr.dts | 20 +
> arch/arm/boot/dts/ls1021a.dtsi | 92
> ++
Please separate soc level dts changes from board level changes.
> 4 files changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> index 1e97532..b3291c7 100644
> --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> @@ -45,7 +45,7 @@ Properties:
>
>- device_type : Should be "network"
>- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
> - - compatible : Should be "gianfar"
> + - compatible : "gianfar", "fsl-etsec2"
You meant "fsl,etsec2", which is what I see from dts changes?
>- reg : Offset and length of the register set for the device
>- interrupts : For FEC devices, the first interrupt is the device's
> interrupt. For TSEC and eTSEC devices, the first interrupt is
> @@ -57,6 +57,10 @@ Properties:
> "rgmii-id", as all other connection types are detected by hardware.
>- fsl,magic-packet : If present, indicates that the hardware supports
> waking up via magic packet.
> + - fsl,wake-on-filer: Indicates that the device can wake up the system
> +by generating a filer interrupt. Depending on the wake-on-lan mode
> +set for this device, the filer interrupt can be triggered by certain
> +user-defined ethernet packets (usually ARP or L2 unicast packets).
>- bd-stash : If present, indicates that the hardware supports stashing
> buffer descriptors in the L2.
>- rx-stash-len : Denotes the number of bytes of a received buffer to stash
> diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
> b/arch/arm/boot/dts/ls1021a-qds.dts
> index 9c5e16b..f16a061 100644
> --- a/arch/arm/boot/dts/ls1021a-qds.dts
> +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> @@ -75,6 +75,26 @@
> };
> };
>
> +&enet0 {
> + tbi-handle = <&tbi0>;
tbi-handle is undocumented.
> + phy-handle = <&sgmii_phy1c>;
> + phy-connection-type = "sgmii";
> + status = "okay";
> +};
> +
> +&enet1 {
> + tbi-handle = <&tbi0>;
> + phy-handle = <&sgmii_phy1d>;
> + phy-connection-type = "sgmii";
> + status = "okay";
> +};
> +
> +&enet2 {
> + phy-handle = <&rgmii_phy3>;
> + phy-connection-type = "rgmii-id";
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index a2c591e..4b61766 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -73,6 +73,26 @@
> };
> };
>
> +&enet0 {
> + tbi-handle = <&tbi1>;
> + phy-handle = <&sgmii_phy2>;
> + phy-connection-type = "sgmii";
> + status = "okay";
> +};
> +
> +&enet1 {
> + tbi-handle = <&tbi1>;
> + phy-handle = <&sgmii_phy0>;
> + phy-connection-type = "sgmii";
> + status = "okay";
> +};
> +
> +&enet2 {
> + phy-handle = <&rgmii_phy1>;
> + phy-connection-type = "rgmii-id";
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c70bb27..cc48d56 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -59,6 +59,9 @@
> serial3 = &lpuart3;
> serial4 = &lpuart4;
> serial5 = &lpuart5;
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> sysclk = &sysclk;
> };
>
> @@ -391,6 +394,95 @@
> reg = <0x0 0x2d24000 0x0 0x4000>;
> };
>
> + enet0: ethernet@2d1 {
> + compatible = "fsl,etsec2";
> + device_type = "network";
> + #address-cells = <2>;
> +
Re: [PATCH 5/8] iio: mma8452: add devicetree binding document
On Mon, Jul 27, 2015 at 03:08:12PM +0100, Martin Kepplinger wrote:
> As we support more chips now, add a binding document and remove it from
> i2c trivial-devices.txt list.
>
> The binding document is further extended in a later patch of this series.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
> ---
> .../devicetree/bindings/i2c/trivial-devices.txt | 1 -
> .../devicetree/bindings/iio/accel/mma8452.txt | 21
> +
> 2 files changed, 21 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index 00f8652..094238a 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -54,7 +54,6 @@ epson,rx8581I2C-BUS INTERFACE REAL TIME
> CLOCK MODULE
> fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
> fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for
> i.MX35/51
> fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
> Accelerometer
> -fsl,mma8452 MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
> fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
> fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
> gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
> with Two-Wire Interface
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> new file mode 100644
> index 000..8d98e05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -0,0 +1,21 @@
> +Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
> +
> +Required properties:
> +
> + - compatible: should be "fsl,mma8653", "fsl,mma8652", "fsl,mma8453" or
> +"fsl,mma8452" respectively.
This would be easier to read/search (and easier to extend in future) if
formatted as a list, e.g.
- compatible: should contain one of:
* "fsl,mma8653"
* "fsl,mma8652"
* "fsl,mma8453"
* "fsl,mma8452"
Mark.
> + - reg: the I2C address of the chip
> +
> +Optional properties:
> +
> + - interrupt-parent: should be the phandle for the interrupt controller
> + - interrupts: interrupt mapping for GPIO IRQ
> +
> +Example:
> +
> + mma8653fc@1d {
> + compatible = "fsl,mma8653";
> + reg = <0x1d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 0>;
> + };
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] iio: mma8452: add support for MMA8652FC and MMA8653FC accelerometers
MMA8652FC and MMA8653FC don't provide the transient interrupt source, so
the motion interrupt source is used by providing a new iio_chan_spec
definition, so that other supported devices are not affected by this.
Datasheets for the newly supported devices are available at Freescale's
website:
http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8652FC.pdf
http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8653FC.pdf
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
drivers/iio/accel/Kconfig | 2 +-
drivers/iio/accel/mma8452.c | 98 +
2 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index dc80dc9..fdb59e0 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -93,7 +93,7 @@ config MMA8452
select IIO_TRIGGERED_BUFFER
help
Say yes here to build support for the following Freescale 3-axis
- accelerometers: MMA8452Q, MMA8453Q.
+ accelerometers: MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC.
To compile this driver as a module, choose M here: the module
will be called mma8452.
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index d51ce63..5a8c738 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -3,6 +3,8 @@
*
* MMA8452Q
* MMA8453Q
+ * MMA8652FC
+ * MMA8653FC
*
* Copyright 2014 Peter Meerwald
*
@@ -87,6 +89,8 @@
#define MMA8452_DEVICE_ID 0x2a
#define MMA8453_DEVICE_ID 0x3a
+#define MMA8652_DEVICE_ID 0x4a
+#define MMA8653_DEVICE_ID 0x5a
struct mma8452_data {
struct i2c_client *client;
@@ -766,6 +770,26 @@ static struct attribute_group
mma8452_event_attribute_group = {
.num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
}
+#define MMA8652_CHANNEL(axis, idx, bits) { \
+ .type = IIO_ACCEL, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_##axis, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_CALIBBIAS), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .scan_index = idx, \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = (bits), \
+ .storagebits = 16, \
+ .shift = 16 - (bits), \
+ .endianness = IIO_BE, \
+ }, \
+ .event_spec = mma8452_motion_event, \
+ .num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
+}
+
static const struct iio_chan_spec mma8452_channels[] = {
MMA8452_CHANNEL(X, 0, 12),
MMA8452_CHANNEL(Y, 1, 12),
@@ -780,9 +804,25 @@ static const struct iio_chan_spec mma8453_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(3),
};
+static const struct iio_chan_spec mma8652_channels[] = {
+ MMA8652_CHANNEL(X, 0, 12),
+ MMA8652_CHANNEL(Y, 1, 12),
+ MMA8652_CHANNEL(Z, 2, 12),
+ IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
+static const struct iio_chan_spec mma8653_channels[] = {
+ MMA8652_CHANNEL(X, 0, 10),
+ MMA8652_CHANNEL(Y, 1, 10),
+ MMA8652_CHANNEL(Z, 2, 10),
+ IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
enum {
mma8452,
mma8453,
+ mma8652,
+ mma8653,
};
static const struct mma_chip_info mma_chip_info_table[] = {
@@ -825,6 +865,38 @@ static const struct mma_chip_info mma_chip_info_table[] = {
.ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
.ev_count = MMA8452_TRANSIENT_COUNT,
},
+ [mma8652] = {
+ .chip_id = MMA8652_DEVICE_ID,
+ .channels = mma8652_channels,
+ .num_channels = ARRAY_SIZE(mma8652_channels),
+ .mma_scales = { {0, 9577}, {0, 19154}, {0, 38307} },
+ .ev_cfg = MMA8452_FF_MT_CFG,
+ .ev_cfg_ele = MMA8452_FF_MT_CFG_ELE,
+ .ev_cfg_chan_shift = 3,
+ .ev_src = MMA8452_FF_MT_SRC,
+ .ev_src_xe = MMA8452_FF_MT_SRC_XHE,
+ .ev_src_ye = MMA8452_FF_MT_SRC_YHE,
+ .ev_src_ze = MMA8452_FF_MT_SRC_ZHE,
+ .ev_ths = MMA8452_FF_MT_THS,
+ .ev_ths_mask = MMA8452_FF_MT_THS_MASK,
+ .ev_count = MMA8452_FF_MT_COUNT,
+ },
+ [mma8653] = {
+ .chip_id = MMA8653_DEVICE_ID,
+ .channels = mma8653_channels,
+ .num_channels = ARRAY_SIZE(mma8653_channels),
+ .mma_scales = { {0, 38307}, {0, 76614}, {0, 153228} },
+ .ev_cfg = MMA8452_FF_MT_CFG,
+ .ev_cfg_ele = MMA8452_FF_MT_CFG_ELE,
+ .ev_cfg_chan_shift = 3,
+ .ev_src = MMA8452_FF_MT_SRC,
+ .ev_src_xe = MMA8452_FF_MT_SRC_XHE,
+ .ev_src_ye = MMA8452_FF_MT_SRC_YHE,
+ .ev_src_ze = MMA8452_FF_MT_SRC_ZHE,
+ .ev_ths = MMA8452_FF_MT_THS,
+
[PATCH 3/8] iio: mma8452: add freefall / motion interrupt source
This adds the freefall / motion interrupt source definitions to the driver.
It is used in this series' next patch, for chips that don't support the
transient interrupt source.
The iio event type is IIO_EV_TYPE_MAG since the threshold for comparison
is no signed value. An interrupt occurs on positive and negative values
when the magnitude crosses the threshold value.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
drivers/iio/accel/mma8452.c | 45 -
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 57b12eb..d51ce63 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -37,9 +37,18 @@
#define MMA8452_DATA_CFG 0x0e
#define MMA8452_HP_FILTER_CUTOFF 0x0f
#define MMA8452_HP_FILTER_CUTOFF_SEL_MASK (BIT(0) | BIT(1))
+#define MMA8452_FF_MT_CFG 0x15
+#define MMA8452_FF_MT_CFG_OAE BIT(6)
+#define MMA8452_FF_MT_CFG_ELE BIT(7)
+#define MMA8452_FF_MT_SRC 0x16
+#define MMA8452_FF_MT_SRC_XHE BIT(1)
+#define MMA8452_FF_MT_SRC_YHE BIT(3)
+#define MMA8452_FF_MT_SRC_ZHE BIT(5)
+#define MMA8452_FF_MT_THS 0x17
+#define MMA8452_FF_MT_THS_MASK 0x7f
+#define MMA8452_FF_MT_COUNT 0x18
#define MMA8452_TRANSIENT_CFG 0x1d
#define MMA8452_TRANSIENT_CFG_ELE BIT(4)
-#define MMA8452_TRANSIENT_CFG_CHAN(chan) BIT(chan + 1)
#define MMA8452_TRANSIENT_CFG_HPF_BYP BIT(0)
#define MMA8452_TRANSIENT_SRC 0x1e
#define MMA8452_TRANSIENT_SRC_XTRANSE BIT(1)
@@ -73,6 +82,7 @@
#define MMA8452_DATA_CFG_HPF_MASK BIT(4)
#define MMA8452_INT_DRDY BIT(0)
+#define MMA8452_INT_FF_MT BIT(2)
#define MMA8452_INT_TRANS BIT(5)
#define MMA8452_DEVICE_ID 0x2a
@@ -590,7 +600,8 @@ static int mma8452_write_event_config(struct iio_dev
*indio_dev,
else
val &= ~BIT(chan->scan_index + chip->ev_cfg_chan_shift);
- val |= MMA8452_TRANSIENT_CFG_ELE;
+ val |= chip->ev_cfg_ele;
+ val |= MMA8452_FF_MT_CFG_OAE;
return mma8452_change_config(data, chip->ev_cfg, val);
}
@@ -631,6 +642,7 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
{
struct iio_dev *indio_dev = p;
struct mma8452_data *data = iio_priv(indio_dev);
+ const struct mma_chip_info *chip = data->chip_info;
int ret = IRQ_NONE;
int src;
@@ -643,7 +655,10 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
ret = IRQ_HANDLED;
}
- if (src & MMA8452_INT_TRANS) {
+ if ((src & MMA8452_INT_TRANS &&
+chip->ev_src == MMA8452_TRANSIENT_SRC) ||
+ (src & MMA8452_INT_FF_MT &&
+chip->ev_src == MMA8452_FF_MT_SRC)) {
mma8452_transient_interrupt(indio_dev);
ret = IRQ_HANDLED;
}
@@ -704,6 +719,16 @@ static const struct iio_event_spec
mma8452_transient_event[] = {
},
};
+static const struct iio_event_spec mma8452_motion_event[] = {
+ {
+ .type = IIO_EV_TYPE_MAG,
+ .dir = IIO_EV_DIR_RISING,
+ .mask_separate = BIT(IIO_EV_INFO_ENABLE),
+ .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
+ BIT(IIO_EV_INFO_PERIOD)
+ },
+};
+
/*
* Threshold is configured in fixed 8G/127 steps regardless of
* currently selected scale for measurement.
@@ -987,13 +1012,15 @@ static int mma8452_probe(struct i2c_client *client,
if (client->irq) {
/*
-* Although we enable the transient interrupt source once and
-* for all here the transient event detection itself is not
-* enabled until userspace asks for it by
-* mma8452_write_event_config()
+* Although we enable the interrupt sources once and for
+* all here the event detection itself is not enabled until
+* userspace asks for it by mma8452_write_event_config()
*/
- int supported_interrupts = MMA8452_INT_DRDY | MMA8452_INT_TRANS;
- int enabled_interrupts = MMA8452_INT_TRANS;
+ int supported_interrupts = MMA8452_INT_DRDY |
+ MMA8452_INT_TRANS |
+ MMA8452_INT_FF_MT;
+ int enabled_interrupts = MMA8452_INT_TRANS |
+MMA8452_INT_FF_MT;
/* Assume wired to INT1 pin */
ret = i2c_smbus_write_byte_data(client,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: imx6ul-14x14-evk.dts: add tsc support
On Mon, Jul 27, 2015 at 07:26:47PM +0800, Haibo Chen wrote:
> Add touch screen surpport for i.MX6UL-EVK board.
>
> Signed-off-by: Haibo Chen
> ---
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> index 61b41ee..323d32d 100644
> --- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> +++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> @@ -44,6 +44,15 @@
> soc-supply = <®_soc>;
> };
>
> +&tsc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tsc>;
> + status = "okay";
We generally have "status" at the bottom of the property list.
Shawn
> + xnur-gpio = <&gpio1 3 0>;
> + measure_delay_time = <0x>;
> + pre_charge_time = <0xfff>;
> +};
> +
> &uart1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart1>;
> @@ -212,6 +221,15 @@
> >;
> };
>
> + pinctrl_tsc: tscgrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO01__GPIO1_IO010xb0
> + MX6UL_PAD_GPIO1_IO02__GPIO1_IO020xb0
> + MX6UL_PAD_GPIO1_IO03__GPIO1_IO030xb0
> + MX6UL_PAD_GPIO1_IO04__GPIO1_IO040xb0
> + >;
> + };
> +
> pinctrl_uart1: uart1grp {
> fsl,pins = <
> MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] iio: mma8452: add copyright notice comment
Signed-off-by: Martin Kepplinger Signed-off-by: Christoph Muellner --- drivers/iio/accel/mma8452.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c index 5a8c738..dc66815 100644 --- a/drivers/iio/accel/mma8452.c +++ b/drivers/iio/accel/mma8452.c @@ -6,6 +6,7 @@ * MMA8652FC * MMA8653FC * + * Copyright 2015 Martin Kepplinger * Copyright 2014 Peter Meerwald * * This file is subject to the terms and conditions of version 2 of -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] iio: mma8452: add devicetree binding document
As we support more chips now, add a binding document and remove it from
i2c trivial-devices.txt list.
The binding document is further extended in a later patch of this series.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
.../devicetree/bindings/i2c/trivial-devices.txt | 1 -
.../devicetree/bindings/iio/accel/mma8452.txt | 21 +
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 00f8652..094238a 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -54,7 +54,6 @@ epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mc13892MC13892: Power Management Integrated Circuit (PMIC) for
i.MX35/51
fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
Accelerometer
-fsl,mma8452MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
with Two-Wire Interface
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
new file mode 100644
index 000..8d98e05
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -0,0 +1,21 @@
+Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
+
+Required properties:
+
+ - compatible: should be "fsl,mma8653", "fsl,mma8652", "fsl,mma8453" or
+"fsl,mma8452" respectively.
+ - reg: the I2C address of the chip
+
+Optional properties:
+
+ - interrupt-parent: should be the phandle for the interrupt controller
+ - interrupts: interrupt mapping for GPIO IRQ
+
+Example:
+
+ mma8653fc@1d {
+ compatible = "fsl,mma8653";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 0>;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] dt-binding: document the binding for mxc rtc
On Sun, Jul 26, 2015 at 11:37:51PM +0200, Philippe Reynes wrote:
> This adds documentation of device tree bindings for the
> mxc rtc.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
DT maintainers,
Any comments on the bindings? Otherwise, I will queue the whole patch
series on IMX tree for 4.3.
Shawn
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Philippe Reynes
> ---
> Documentation/devicetree/bindings/rtc/rtc-mxc.txt | 26
> +
> 1 files changed, 26 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.txt
> b/Documentation/devicetree/bindings/rtc/rtc-mxc.txt
> new file mode 100644
> index 000..49aa550
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc.txt
> @@ -0,0 +1,26 @@
> +* Real Time Clock of the i.MX SoCs
> +
> +RTC controller for the i.MX SoCs
> +
> +Required properties:
> +- compatible: Should be "fsl,imx1-rtc" or "fsl,imx21-rtc".
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: IRQ line for the RTC.
> +- clocks: should contain two entries:
> + * one for the input reference
> + * one for the the SoC RTC
> +- clock-names: should contain:
> + * "ref" for the input reference clock
> + * "ipg" for the SoC RTC clock
> +
> +Example:
> +
> +rtc@10007000 {
> + compatible = "fsl,imx21-rtc";
> + reg = <0x10007000 0x1000>;
> + interrupts = <22>;
> + clocks = <&clks IMX27_CLK_CKIL>,
> + <&clks IMX27_CLK_RTC_IPG_GATE>;
> + clock-names = "ref", "ipg";
> +};
> --
> 1.7.4.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
On Mon, Jul 27, 2015 at 03:05:38PM +0100, Robin Murphy wrote:
> On 27/07/15 05:21, Yong Wu wrote:
> > + } else {/* page or largepage */
> > + if (quirk & IO_PGTABLE_QUIRK_SHORT_MTK) {
> > + if (large) { /* special Bit */
>
> This definitely needs a better comment! What exactly are you doing here
> and what is that quirk all about?
> >>>
> >>> I use this quirk is for MTK Special Bit as we don't have the XN bit in
> >>> pagetable.
> >>
> >> I'm still not really clear about what this is.
> >
> > There is some difference between the standard spec and MTK HW,
> > Our hw don't implement some bits, like XN and AP.
> > So I add a quirk for MTK special.
>
> When you say it doesn't implement these bits, do you mean that having
> them set will lead to Bad Things happening in the hardware, or that it
> will simply ignore them and not enforce any of the protections they
> imply? The former case would definitely want clearly documenting
> somewhere, whereas for the latter case I'm not sure it's even worth the
> complication of having a quirk - if the value doesn't matter there seems
> little point in doing a special dance just for the sake of semantic
> correctness of the in-memory PTEs, in my opinion.
Agreed. We should only use quirks if the current (architecturally
compliant) code causes real issues with the hardware. Then the quirk can
be used to either avoid the problematic routines or to take extra steps
to make things work as the architecture intended.
I've asked how this IOMMU differs from the architecture on a number of
occasions, but I'm still yet to receive a response other than "it's special".
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] iio: mma8452: leave sysfs namings to the iio core
This doesn't actually change anything since the core names the sysfs folder
for the iio event attributes "events" anyways. It only leaves the job to the
core.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
drivers/iio/accel/mma8452.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index dc66815..918ab59 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -747,7 +747,6 @@ static struct attribute *mma8452_event_attributes[] = {
static struct attribute_group mma8452_event_attribute_group = {
.attrs = mma8452_event_attributes,
- .name = "events",
};
#define MMA8452_CHANNEL(axis, idx, bits) { \
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v5 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:05PM +0530, Vaibhav Hiremath wrote:
> With addition of PXA910 family of devices, the TWSI module supports
> new feature which allows us to adjust SCLK. i2c-pxa driver takes input
> configuration in nsec and converts it to respective bit-fields,
>
> - i2c-sclk-low-time-ns : SCLK low time (tlow)
>This property is used along with mode selection.
> - i2c-sclk-high-time-ns : SCLK high time (thigh)
> - i2c-start-hold-time-ns : Used in case of high speed mode for start bit
>hold/setup wait counter.
> - i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
>hold/setup wait counter.
> - i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
>standard and fast mode.
Again, these should have a mrvl prefix..very specific to this PXA
controller.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 9657db5..bb4df60 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -23,12 +23,25 @@ Optional properties :
> - i2c-disable-after-xfer : If set, driver will disable I2C module
> after msg xfer and enable it again before xfer.
>
> + (Applicable to PXA910 family):
> +
> + - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
> + speed mode.
> + This property is used along with mode selection. Driver uses this property
> + to set low/high time for standard and fast speed mode, as HW counter
> + bit-field is same for both.
> + - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
> + mode only.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> reg = <0xd4011000 0x1000>;
> interrupts = <7>;
> mrvl,i2c-fast-mode;
> +
> + i2c-sclk-low-time-ns = <988>;
> + i2c-sclk-high-time-ns = <988>;
> };
>
> twsi2: i2c@d4025000 {
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] iio: mma8452: add support for MMA8453Q accelerometer chip
This adds support for the 10 bit version if Freescale's accelerometers
of this series. The datasheet is available at Freescale's website:
http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8453Q.pdf
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
drivers/iio/accel/Kconfig | 6 +++---
drivers/iio/accel/mma8452.c | 38 +++---
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 00e7bcb..dc80dc9 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -87,13 +87,13 @@ config KXSD9
will be called kxsd9.
config MMA8452
- tristate "Freescale MMA8452Q Accelerometer Driver"
+ tristate "Freescale MMA8452Q and similar Accelerometers Driver"
depends on I2C
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- Say yes here to build support for the Freescale MMA8452Q 3-axis
- accelerometer.
+ Say yes here to build support for the following Freescale 3-axis
+ accelerometers: MMA8452Q, MMA8453Q.
To compile this driver as a module, choose M here: the module
will be called mma8452.
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 8965517..57b12eb 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1,5 +1,8 @@
/*
- * mma8452.c - Support for Freescale MMA8452Q 3-axis 12-bit accelerometer
+ * mma8452.c - Support for following Freescale 3-axis accelerometers:
+ *
+ * MMA8452Q
+ * MMA8453Q
*
* Copyright 2014 Peter Meerwald
*
@@ -26,7 +29,7 @@
#include
#define MMA8452_STATUS 0x00
-#define MMA8452_OUT_X 0x01 /* MSB first, 12-bit */
+#define MMA8452_OUT_X 0x01 /* MSB first, 10 or 12-bit */
#define MMA8452_OUT_Y 0x03
#define MMA8452_OUT_Z 0x05
#define MMA8452_INT_SRC 0x0c
@@ -73,6 +76,7 @@
#define MMA8452_INT_TRANS BIT(5)
#define MMA8452_DEVICE_ID 0x2a
+#define MMA8453_DEVICE_ID 0x3a
struct mma8452_data {
struct i2c_client *client;
@@ -744,8 +748,16 @@ static const struct iio_chan_spec mma8452_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(3),
};
+static const struct iio_chan_spec mma8453_channels[] = {
+ MMA8452_CHANNEL(X, 0, 10),
+ MMA8452_CHANNEL(Y, 1, 10),
+ MMA8452_CHANNEL(Z, 2, 10),
+ IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
enum {
mma8452,
+ mma8453,
};
static const struct mma_chip_info mma_chip_info_table[] = {
@@ -772,7 +784,24 @@ static const struct mma_chip_info mma_chip_info_table[] = {
.ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
.ev_count = MMA8452_TRANSIENT_COUNT,
},
+ [mma8453] = {
+ .chip_id = MMA8453_DEVICE_ID,
+ .channels = mma8453_channels,
+ .num_channels = ARRAY_SIZE(mma8453_channels),
+ .mma_scales = { {0, 38307}, {0, 76614}, {0, 153228} },
+ .ev_cfg = MMA8452_TRANSIENT_CFG,
+ .ev_cfg_ele = MMA8452_TRANSIENT_CFG_ELE,
+ .ev_cfg_chan_shift = 1,
+ .ev_src = MMA8452_TRANSIENT_SRC,
+ .ev_src_xe = MMA8452_TRANSIENT_SRC_XTRANSE,
+ .ev_src_ye = MMA8452_TRANSIENT_SRC_YTRANSE,
+ .ev_src_ze = MMA8452_TRANSIENT_SRC_ZTRANSE,
+ .ev_ths = MMA8452_TRANSIENT_THS,
+ .ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
+ .ev_count = MMA8452_TRANSIENT_COUNT,
+ },
};
+
static struct attribute *mma8452_attributes[] = {
&iio_dev_attr_sampling_frequency_available.dev_attr.attr,
&iio_dev_attr_in_accel_scale_available.dev_attr.attr,
@@ -891,6 +920,7 @@ static int mma8452_reset(struct i2c_client *client)
static const struct of_device_id mma8452_dt_ids[] = {
{ .compatible = "fsl,mma8452", .data = &mma_chip_info_table[mma8452] },
+ { .compatible = "fsl,mma8453", .data = &mma_chip_info_table[mma8453] },
{ }
};
@@ -905,7 +935,8 @@ static int mma8452_probe(struct i2c_client *client,
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
return ret;
- if (ret != MMA8452_DEVICE_ID)
+
+ if (ret != MMA8452_DEVICE_ID && ret != MMA8453_DEVICE_ID)
return -ENODEV;
match = of_match_device(mma8452_dt_ids, &client->dev);
@@ -1052,6 +1083,7 @@ static SIMPLE_DEV_PM_OPS(mma8452_pm_ops, mma8452_suspend,
mma8452_resume);
static const struct i2c_device_id mma8452_id[] = {
{ "mma8452", mma8452 },
+ { "mma8453", mma8453 },
{ }
};
MODULE_DEVICE_TABLE(i2c, mma8452_id);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] iio: mma8452: refactor for seperating chip specific data
This adds a struct mma_chip_info to hold data that will remain specific to
the chip in use. It is provided during probe() and linked in
struct of_device_id.
Also this suggests that the driver is called "mma8452" and now handles the
MMA8452Q device, but is not limited to it.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
drivers/iio/accel/mma8452.c | 185
1 file changed, 136 insertions(+), 49 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 13ea1ea..8965517 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define MMA8452_STATUS 0x00
#define MMA8452_OUT_X 0x01 /* MSB first, 12-bit */
@@ -78,6 +79,52 @@ struct mma8452_data {
struct mutex lock;
u8 ctrl_reg1;
u8 data_cfg;
+ const struct mma_chip_info *chip_info;
+};
+
+/**
+ * struct mma_chip_info - chip specific data for Freescale's accelerometers
+ * @chip_id: WHO_AM_I register's value
+ * @channels: struct iio_chan_spec matching the device's
+ * capabilities
+ * @num_channels: number of channels
+ * @mma_scales:scale factors for converting register
values
+ * to m/s^2; 3 modes: 2g, 4g, 8g; 2 integers
+ * per mode: m/s^2 and micro m/s^2
+ * @ev_cfg:event config register address
+ * @ev_cfg_ele:latch bit in event config register
+ * @ev_cfg_chan_shift: number of the bit to enable events in X
+ * direction; in event config register
+ * @ev_src:event source register address
+ * @ev_src_xe: bit in event source register that indicates
+ * an event in X direction
+ * @ev_src_ye: bit in event source register that indicates
+ * an event in Y direction
+ * @ev_src_ze: bit in event source register that indicates
+ * an event in Z direction
+ * @ev_ths:event threshold register address
+ * @ev_ths_mask: mask for the threshold value
+ * @ev_count: event count (period) register address
+ *
+ * Since not all chips supported by the driver support comparing high pass
+ * filtered data for events (interrupts), different interrupt sources are
+ * used for different chips and the relevant registers are included here.
+ */
+struct mma_chip_info {
+ u8 chip_id;
+ const struct iio_chan_spec *channels;
+ int num_channels;
+ const int mma_scales[3][2];
+ u8 ev_cfg;
+ u8 ev_cfg_ele;
+ u8 ev_cfg_chan_shift;
+ u8 ev_src;
+ u8 ev_src_xe;
+ u8 ev_src_ye;
+ u8 ev_src_ze;
+ u8 ev_ths;
+ u8 ev_ths_mask;
+ u8 ev_count;
};
static int mma8452_drdy(struct mma8452_data *data)
@@ -143,16 +190,6 @@ static const int mma8452_samp_freq[8][2] = {
{6, 25}, {1, 56}
};
-/*
- * Hardware has fullscale of -2G, -4G, -8G corresponding to raw value -2048
- * The userspace interface uses m/s^2 and we declare micro units
- * So scale factor is given by:
- * g * N * 100 / 2048 for N = 2, 4, 8 and g=9.80665
- */
-static const int mma8452_scales[3][2] = {
- {0, 9577}, {0, 19154}, {0, 38307}
-};
-
/* Datasheet table 35 (step time vs sample frequency) */
static const int mma8452_transient_time_step_us[8] = {
1250,
@@ -187,8 +224,11 @@ static ssize_t mma8452_show_samp_freq_avail(struct device
*dev,
static ssize_t mma8452_show_scale_avail(struct device *dev,
struct device_attribute *attr, char *buf)
{
- return mma8452_show_int_plus_micros(buf, mma8452_scales,
- ARRAY_SIZE(mma8452_scales));
+ struct mma8452_data *data = iio_priv(i2c_get_clientdata(
+to_i2c_client(dev)));
+
+ return mma8452_show_int_plus_micros(buf, data->chip_info->mma_scales,
+ ARRAY_SIZE(data->chip_info->mma_scales));
}
static ssize_t mma8452_show_hp_cutoff_avail(struct device *dev,
@@ -219,8 +259,8 @@ static int mma8452_get_samp_freq_index(struct mma8452_data
*data,
static int mma8452_get_scale_index(struct mma8452_data *data,
int val, int val2)
{
- return mma8452_get_int_plus_micros_index(mma8452_scales,
- ARRAY_SIZE(mma8452_scales), val, val2);
+ return mma8452_get_int_plus_micros_index(data->chip_info->mma_scales,
+ ARRAY_SIZE(data->chip_info->mma_scales), val, val2);
}
static int mma8452_get_hp_filter_index(struct mma8452_data *data,
@@ -229,7 +269,7 @@ static int mma8452_get_hp_filter_index(struct mma8452_data
*data,
int i = mma8452_get_odr_index(data);
[PATCH 8/8] iio: mma8452: add devicetree property to allow all pin wirings
For the devices supported by the mma8452 driver, two interrupt pins are
available to route the interrupt signals to. By default INT1 is assumed.
This adds a bitmask DT property for users to configure interrupt sources
for INT2, if that is the wired interrupt pin for them.
This is important for everyone to be able to use this driver, no matter
how their chip is wired. At the moment, only 0xff for using INT2 for all
available interrupt sources is supported. See the devicetree documentation
file for more details.
Since this doesn't change the default behaviour, it doesn't break anything
for existing users.
Signed-off-by: Martin Kepplinger
Signed-off-by: Christoph Muellner
---
.../devicetree/bindings/iio/accel/mma8452.txt| 4
drivers/iio/accel/mma8452.c | 20 +---
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 8d98e05..738a430 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -10,6 +10,9 @@ Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: interrupt mapping for GPIO IRQ
+ - use_int2: bitmask to choose interrupt sources assumed to be wired to
+interrupt pin INT2 instead of INT1. Only 0xff (INT2 for every interrupt
+source) is supported at the moment.
Example:
@@ -18,4 +21,5 @@ Example:
reg = <0x1d>;
interrupt-parent = <&gpio1>;
interrupts = <5 0>;
+ use_int2 = /bits/ 8 <0xff>;
};
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 918ab59..a03836b1 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1028,8 +1028,9 @@ static int mma8452_probe(struct i2c_client *client,
{
struct mma8452_data *data;
struct iio_dev *indio_dev;
- int ret;
const struct of_device_id *match;
+ int ret;
+ u8 int2;
match = of_match_device(mma8452_dt_ids, &client->dev);
if (!match) {
@@ -1104,12 +1105,17 @@ static int mma8452_probe(struct i2c_client *client,
int enabled_interrupts = MMA8452_INT_TRANS |
MMA8452_INT_FF_MT;
- /* Assume wired to INT1 pin */
- ret = i2c_smbus_write_byte_data(client,
- MMA8452_CTRL_REG5,
- supported_interrupts);
- if (ret < 0)
- return ret;
+ of_property_read_u8(client->dev.of_node, "use_int2", &int2);
+ if (int2 == 0xff) {
+ dev_dbg(&client->dev, "use interrupt line INT2\n");
+ } else {
+ dev_dbg(&client->dev, "use interrupt line INT1\n");
+ ret = i2c_smbus_write_byte_data(client,
+ MMA8452_CTRL_REG5,
+ supported_interrupts);
+ if (ret < 0)
+ return ret;
+ }
ret = i2c_smbus_write_byte_data(client,
MMA8452_CTRL_REG4,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote:
> Driver will now supports enable/disable across msg xfer, which user
> can control it by new DT property -
>
> i2c-disable-after-xfer : If set, driver will disable I2C module after msg
> xfer and enable it back before xfer.
If this is a new property specific to this Marvell part, it needs
the vendor prefix as in mrvl,i2c-disable-after-xfer
Or, it couldn't hurt to start an i2c.txt for generic i2c bindings
and store it there as this and others later in this series would
reasonably apply to other controllers.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 12b78ac..9657db5 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -18,6 +18,11 @@ Recommended properties :
> status register of i2c controller instead.
> - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
>
> +Optional properties :
> +
> + - i2c-disable-after-xfer : If set, driver will disable I2C module
> + after msg xfer and enable it again before xfer.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/8] iio: mma8452: improve driver and support more chips
Before I go away for holidays, this is version 5 of the mma8452 driver improvements. This version removes the unnessasary DRIVER_NAME define and improves the DT property "use_int2" to be extendible for any future additions to the driver. This is based on today's -next. These changes add support for motion interrupts and 3 more accelerometer chips, two of which use them because they don't support the until now included transient interrupt sources: MMA8453Q, MMA8652FC and MMA8653FC; datasheets are in the commit messages. The driver and module name remains the same, seperating it from the device names it now supports. On top of this, there are minor documentation additions, and more notably, it allows to use the driver, no matter how the interrupt pins are wired on your board. Please review and test if you can. For MMA8452Q, nothing should have changed. revision history v5 DRIVER_NAME define removed; more flexible DT property v4 cleanup; one bugfix patch removed from series; DT people added v3 adds one patch to allow all possible pin wirings; adds more email recipients v2 splits the work into a series of smaller pieces v1 initial post -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
