RE: [PATCH V4 2/7] qup: i2c: factor out common code for reuse
Hi Ivan,
Thnaks for all the reviews.
> -Original Message-
> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
> ow...@vger.kernel.org] On Behalf Of Ivan T. Ivanov
> Sent: Monday, July 20, 2015 1:55 PM
> To: Sricharan R
> Cc: devicetree@vger.kernel.org; linux-arm-...@vger.kernel.org;
> ga...@codeaurora.org; linux-ker...@vger.kernel.org; linux-
> i...@vger.kernel.org; agr...@codeaurora.org; dmaeng...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH V4 2/7] qup: i2c: factor out common code for reuse
>
>
> Hi Sricharan,
>
> On Thu, 2015-07-09 at 08:55 +0530, Sricharan R wrote:
> >
>
> > static int qup_i2c_read_one(struct qup_i2c_dev *qup, struct i2c_msg
> > *msg) {
> > - unsigned long left;
> > - int ret;
> > + int ret = 0;
> >
> > - qup->msg = msg;
> > - qup->pos = 0;
> > + /*
> > + * The QUP block will issue a NACK and STOP on the bus when
> reaching
> > + * the end of the read, the length of the read is specified
> > as one
> byte
> > + * which limits the possible read to 256 (QUP_READ_LIMIT)
> > bytes.
> > + */
> > + if (msg->len > QUP_READ_LIMIT) {
> > + dev_err(qup->dev, "HW not capable of reads over %d bytes\n",
> > + QUP_READ_LIMIT);
> > + return -EINVAL;
> > + }
> >
>
> This should be removed. Please see qup_i2c_quirks.
>
Ok get it, will remove this.
Regards,
Sricharan
--
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 0/5] PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05
Very sorry for sending this cover repeatedly :( Please ignore this one. Zhou On 2015/7/21 14:42, Zhou Wang wrote: > This patchset adds PCIe host support for Hisilicon Soc Hip05. The PCIe hosts > use PCIe IP core from Synopsys, So this driver is base on designware PCIe > driver. > > Hip05 is an ARMv8 architecture Soc. It should be able to use ARM64 PCIe API in > designeware PCIe driver. So this patch also adds ARM64 support for designware > pcie. > > This patchset is based on v4.2-rc1 and Gabriele's patch about of_pci_range > fix[1]. > > Change from v3: > - Change 1/5 to what Gabriele suggested. > - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series. > > Change from v2: > - Move struct pci_dev *dev and struct pci_sys_data *sys in > pcibios_align_resource in 1/5. > - Add Gabriele's codes in 2/5 which delete unnecessary information parse and > use of_pci_get_host_bridge_resources for both ARM32 and ARM64. > - Add maintainer patch 5/5. > > Change from RFC v1: > - Add 1/4 patch by Arnd which removes align_resource callback in ARM > pcibios_align_resource. > - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h. > - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape, > spear13xx. > - Remove unnecessary parentheses of some macros in pcie-hisi. > - Use macro to replace some magic values. > - Merge two loops together and add some comments about it in context_config > function in pcie-hisi. > - Modify some value of items in pcie node example in binding document. > > Change from RFC: > - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci, > merge related operations into dw_pcie_host_init. > > Link of v3: > - http://www.spinics.net/lists/linux-pci/msg42539.html > Link of v2: > - http://www.spinics.net/lists/linux-pci/msg41844.html > Link of RFC v1: > - http://www.spinics.net/lists/linux-pci/msg41305.html > Link of RFC: > - http://www.spinics.net/lists/linux-pci/msg40434.html > > [1] https://patchwork.ozlabs.org/patch/495018/ > > Zhou Wang (5): > ARM/PCI: remove align_resource in pci_sys_data > PCI: designware: Add ARM64 support > PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05 > Documentation: DT: Add Hisilicon PCIe host binding > MAINTAINERS: Add pcie-hisi maintainer > > .../devicetree/bindings/pci/hisilicon-pcie.txt | 46 > MAINTAINERS| 7 + > arch/arm/include/asm/mach/pci.h| 5 - > arch/arm/kernel/bios32.c | 12 +- > drivers/pci/host/Kconfig | 5 + > drivers/pci/host/Makefile | 1 + > 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-hisi.c | 257 > + > drivers/pci/host/pcie-spear13xx.c | 2 +- > 16 files changed, 410 insertions(+), 163 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt > create mode 100644 drivers/pci/host/pcie-hisi.c > -- 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/5] ARM/PCI: remove align_resource in pci_sys_data
This patch is needed in order to unify the PCIe designware framework for ARM and
ARM64 architectures. In the PCIe designware unification process we are calling
pci_create_root_bus() passing a "sysdata" parameter that is the same for both
ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this will
cause a problem with the function pcibios_align_resource(); in fact this will
cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had passed a
"struct pcie_port*" pointer.
This patch solves the issue by removing "align_resource" from "pci_sys_data"
struct and defining a static global function pointer in "bios32.c"
Signed-off-by: Gabriele Paoloni
Signed-off-by: Zhou Wang
---
arch/arm/include/asm/mach/pci.h | 5 -
arch/arm/kernel/bios32.c| 12
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 28b9bb3..8a4e4de 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -58,11 +58,6 @@ struct pci_sys_data {
/* IRQ mapping
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
/* Resource alignement requirements
*/
- resource_size_t (*align_resource)(struct pci_dev *dev,
- const struct resource *res,
- resource_size_t start,
- resource_size_t size,
- resource_size_t align);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index fc1..4cdc64d 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -17,6 +17,11 @@
#include
static int debug_pci;
+static resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align) = NULL;
#ifdef CONFIG_PCI_MSI
struct msi_controller *pcibios_msi_controller(struct pci_dev *dev)
@@ -468,7 +473,7 @@ static void pcibios_init_hw(struct device *parent, struct
hw_pci *hw,
sys->busnr = busnr;
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
- sys->align_resource = hw->align_resource;
+ align_resource = hw->align_resource;
INIT_LIST_HEAD(&sys->resources);
if (hw->private_data)
@@ -589,7 +594,6 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
resource_size_t size, resource_size_t align)
{
struct pci_dev *dev = data;
- struct pci_sys_data *sys = dev->sysdata;
resource_size_t start = res->start;
if (res->flags & IORESOURCE_IO && start & 0x300)
@@ -597,8 +601,8 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
start = (start + align - 1) & ~(align - 1);
- if (sys->align_resource)
- return sys->align_resource(dev, res, start, size, align);
+ if (align_resource)
+ return align_resource(dev, res, start, size, align);
return start;
}
--
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 3/5] PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05
This patch adds PCIe host support for Hisilicon Soc Hip05.
Signed-off-by: Zhou Wang
---
drivers/pci/host/Kconfig | 5 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pcie-hisi.c | 257 +++
3 files changed, 263 insertions(+)
create mode 100644 drivers/pci/host/pcie-hisi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c132bdd..37f2075 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,9 @@ config PCIE_IPROC_BCMA
Say Y here if you want to use the Broadcom iProc PCIe controller
through the BCMA bus interface
+config PCI_HISI
+ depends on OF && ARM64
+ bool "Hisilicon Soc HIP05 PCIe controller"
+ select PCIE_DW
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..ea1dbf2 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
new file mode 100644
index 000..9f2fac1
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.c
@@ -0,0 +1,257 @@
+/*
+ * PCIe host controller driver for Hisilicon Hip05 SoCs
+ *
+ * Copyright (C) 2015 Hisilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang
+ * Dacai Zhu
+ *
+ * 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 "pcie-designware.h"
+
+#define PCIE_SUBCTRL_MODE_REG 0x2800
+#define PCIE_SUBCTRL_SYS_STATE4_REG 0x6818
+#define PCIE_SLV_DBI_MODE 0x0
+#define PCIE_SLV_SYSCTRL_MODE 0x1
+#define PCIE_SLV_CONTENT_MODE 0x2
+#define PCIE_SLV_MSI_ASID 0x10
+#define PCIE_LTSSM_LINKUP_STATE 0x11
+#define PCIE_LTSSM_STATE_MASK 0x3F
+#define PCIE_MSI_ASID_ENABLE(0x1 << 12)
+#define PCIE_MSI_ASID_VALUE (0x1 << 16)
+#define PCIE_MSI_TRANS_ENABLE (0x1 << 12)
+#define PCIE_MSI_TRANS_REG 0x1c8
+#define PCIE_MSI_LOW_ADDRESS0x1b4
+#define PCIE_MSI_HIGH_ADDRESS 0x1c4
+#define PCIE_MSI_ADDRESS_VAL0xb7010040
+
+#define to_hisi_pcie(x)container_of(x, struct hisi_pcie, pp)
+
+struct hisi_pcie {
+ void __iomem *subctrl_base;
+ void __iomem *reg_base;
+ struct msi_controller *msi;
+ u32 port_id;
+ struct pcie_port pp;
+};
+
+static inline void hisi_pcie_subctrl_writel(struct hisi_pcie *pcie,
+ u32 val, u32 reg)
+{
+ writel(val, pcie->subctrl_base + reg);
+}
+
+static inline u32 hisi_pcie_subctrl_readl(struct hisi_pcie *pcie, u32 reg)
+{
+ return readl(pcie->subctrl_base + reg);
+}
+
+static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
+ u32 val, u32 reg)
+{
+ writel(val, pcie->reg_base + reg);
+}
+
+static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
+{
+ return readl(pcie->reg_base + reg);
+}
+
+/*
+ * Change mode to indicate the same reg_base to base of PCIe host configure
+ * registers, base of RC configure space or base of vmid/asid context table
+ */
+static void hisi_pcie_change_apb_mode(struct hisi_pcie *pcie, u32 mode)
+{
+ u32 val;
+ u32 bit_mask;
+ u32 bit_shift;
+ u32 port_id = pcie->port_id;
+ u32 reg = PCIE_SUBCTRL_MODE_REG + 0x100 * port_id;
+
+ if ((port_id == 1) || (port_id == 2)) {
+ bit_mask = 0xc;
+ bit_shift = 0x2;
+ } else {
+ bit_mask = 0x6;
+ bit_shift = 0x1;
+ }
+
+ val = hisi_pcie_subctrl_readl(pcie, reg);
+ val = (val & (~bit_mask)) | (mode << bit_shift);
+ hisi_pcie_subctrl_writel(pcie, val, reg);
+}
+
+/* Configure vmid/asid table in PCIe host */
+static void hisi_pcie_config_context(struct hisi_pcie *pcie)
+{
+ int i;
+
+ hisi_pcie_change_apb_mode(pcie, PCIE_SLV_CONTENT_MODE);
+
+ /*
+* init vmid and asid tables for all PCIes device as 0
+* vmid table: 0 ~ 0x3ff, asid table: 0x400 ~ 0x7ff
+*/
+ for (i = 0; i < 0x800; i++)
+ hisi_pcie_apb_writel(pcie, 0x0, i * 4);
+
+ hisi_pcie_change_apb_mode(pcie, PCIE_SLV_SYSCTRL_MODE);
+
+ hisi_pcie_apb_writel(pci
[PATCH v4 2/5] PCI: designware: Add ARM64 support
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.
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 @@
#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
- BUG_ON(!sys->private_data);
-
- return sys->private_data;
-}
+static struct pci_ops dw_pcie_ops;
int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
{
@@ -255,7 +247,7 @@ static void dw
[PATCH v4 4/5] Documentation: DT: Add Hisilicon PCIe host binding
This patch adds related DTS binding document for Hisilicon PCIe host driver.
Signed-off-by: Zhou Wang
---
.../devicetree/bindings/pci/hisilicon-pcie.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
new file mode 100644
index 000..6c9b827
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -0,0 +1,46 @@
+Hisilicon PCIe host bridge DT description
+
+Hisilicon PCIe host controller is based on Designware PCI core.
+It shares common functions with PCIe Designware core driver and inherits
+common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties:
+- compatible: Should contain "hisilicon,hip05-pcie".
+- reg: Should contain rc_dbi, subctrl, config registers location and length.
+- reg-names: Must include the following entries:
+ "rc_dbi": controller configuration registers;
+ "subctrl": whole PCIe hosts configuration registers;
+ "config": PCIe configuration space registers.
+- msi-parent: Should be its_pcie which is an its receiving MSI interrupts.
+- port-id: Should be 0, 1, 2 or 3.
+
+Optional properties:
+- status: Either "ok" or "disabled".
+- dma-coherent: Present if dma operations are coherent.
+
+Example:
+ pcie@0xb008 {
+ compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
+ reg = <0 0xb008 0 0x1>, <0 0xb000 0 0x1>,
+ <0x220 0x 0 0x2000>;
+ reg-names = "rc_dbi", "subctrl", "config";
+ bus-range = <0 15>;
+ msi-parent = <&its_pcie>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ ranges = <0x8200 0 0x 0x220 0x 0
0x1000>;
+ num-lanes = <8>;
+ port-id = <1>;
+ #interrupts-cells = <1>;
+ interrupts-map-mask = <0xf800 0 0 7>;
+ interrupts-map = <0x0 0 0 1 &mbigen_pcie 1 10
+ 0x0 0 0 2 &mbigen_pcie 2 11
+ 0x0 0 0 3 &mbigen_pcie 3 12
+ 0x0 0 0 4 &mbigen_pcie 4 13>;
+ status = "ok";
+ };
--
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 5/5] MAINTAINERS: Add pcie-hisi maintainer
Signed-off-by: Zhou Wang --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..7cd8e47 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7854,6 +7854,13 @@ S: Maintained F: Documentation/devicetree/bindings/pci/xgene-pci-msi.txt F: drivers/pci/host/pci-xgene-msi.c +PCIE DRIVER FOR HISILICON +M: Zhou Wang +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt +F: drivers/pci/host/pcie-hisi.c + PCMCIA SUBSYSTEM P: Linux PCMCIA Team L: linux-pcm...@lists.infradead.org -- 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 0/5] PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05
This patchset adds PCIe host support for Hisilicon Soc Hip05. The PCIe hosts use PCIe IP core from Synopsys, So this driver is base on designware PCIe driver. Hip05 is an ARMv8 architecture Soc. It should be able to use ARM64 PCIe API in designeware PCIe driver. So this patch also adds ARM64 support for designware pcie. This patchset is based on v4.2-rc1 and Gabriele's patch about of_pci_range fix[1]. Change from v3: - Change 1/5 to what Gabriele suggested. - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series. Change from v2: - Move struct pci_dev *dev and struct pci_sys_data *sys in pcibios_align_resource in 1/5. - Add Gabriele's codes in 2/5 which delete unnecessary information parse and use of_pci_get_host_bridge_resources for both ARM32 and ARM64. - Add maintainer patch 5/5. Change from RFC v1: - Add 1/4 patch by Arnd which removes align_resource callback in ARM pcibios_align_resource. - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h. - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape, spear13xx. - Remove unnecessary parentheses of some macros in pcie-hisi. - Use macro to replace some magic values. - Merge two loops together and add some comments about it in context_config function in pcie-hisi. - Modify some value of items in pcie node example in binding document. Change from RFC: - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci, merge related operations into dw_pcie_host_init. Link of v3: - http://www.spinics.net/lists/linux-pci/msg42539.html Link of v2: - http://www.spinics.net/lists/linux-pci/msg41844.html Link of RFC v1: - http://www.spinics.net/lists/linux-pci/msg41305.html Link of RFC: - http://www.spinics.net/lists/linux-pci/msg40434.html [1] https://patchwork.ozlabs.org/patch/495018/ Zhou Wang (5): ARM/PCI: remove align_resource in pci_sys_data PCI: designware: Add ARM64 support PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05 Documentation: DT: Add Hisilicon PCIe host binding MAINTAINERS: Add pcie-hisi maintainer .../devicetree/bindings/pci/hisilicon-pcie.txt | 46 MAINTAINERS| 7 + arch/arm/include/asm/mach/pci.h| 5 - arch/arm/kernel/bios32.c | 12 +- drivers/pci/host/Kconfig | 5 + drivers/pci/host/Makefile | 1 + 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-hisi.c | 257 + drivers/pci/host/pcie-spear13xx.c | 2 +- 16 files changed, 410 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt create mode 100644 drivers/pci/host/pcie-hisi.c -- 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 0/5] PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05
This patchset adds PCIe host support for Hisilicon Soc Hip05. The PCIe hosts use PCIe IP core from Synopsys, So this driver is base on designware PCIe driver. Hip05 is an ARMv8 architecture Soc. It should be able to use ARM64 PCIe API in designeware PCIe driver. So this patch also adds ARM64 support for designware pcie. This patchset is based on v4.2-rc1 and Gabriele's patch about of_pci_range fix[1]. Change from v3: - Change 1/5 to what Gabriele suggested. - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series. Change from v2: - Move struct pci_dev *dev and struct pci_sys_data *sys in pcibios_align_resource in 1/5. - Add Gabriele's codes in 2/5 which delete unnecessary information parse and use of_pci_get_host_bridge_resources for both ARM32 and ARM64. - Add maintainer patch 5/5. Change from RFC v1: - Add 1/4 patch by Arnd which removes align_resource callback in ARM pcibios_align_resource. - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h. - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape, spear13xx. - Remove unnecessary parentheses of some macros in pcie-hisi. - Use macro to replace some magic values. - Merge two loops together and add some comments about it in context_config function in pcie-hisi. - Modify some value of items in pcie node example in binding document. Change from RFC: - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci, merge related operations into dw_pcie_host_init. Link of v3: - http://www.spinics.net/lists/linux-pci/msg42539.html Link of v2: - http://www.spinics.net/lists/linux-pci/msg41844.html Link of RFC v1: - http://www.spinics.net/lists/linux-pci/msg41305.html Link of RFC: - http://www.spinics.net/lists/linux-pci/msg40434.html [1] https://patchwork.ozlabs.org/patch/495018/ Zhou Wang (5): ARM/PCI: remove align_resource in pci_sys_data PCI: designware: Add ARM64 support PCI: hisi: Add PCIe host support for Hisilicon Soc Hip05 Documentation: DT: Add Hisilicon PCIe host binding MAINTAINERS: Add pcie-hisi maintainer .../devicetree/bindings/pci/hisilicon-pcie.txt | 46 MAINTAINERS| 7 + arch/arm/include/asm/mach/pci.h| 5 - arch/arm/kernel/bios32.c | 12 +- drivers/pci/host/Kconfig | 5 + drivers/pci/host/Makefile | 1 + 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-hisi.c | 257 + drivers/pci/host/pcie-spear13xx.c | 2 +- 16 files changed, 410 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt create mode 100644 drivers/pci/host/pcie-hisi.c -- 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 v3 4/4] dt: paz00: define nvec as child of i2c bus
On 21.07.2015 1:19, Stephen Warren wrote:
On 07/20/2015 02:35 PM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
+nvec: nvec@45 {
+compatible = "nvidia,nvec-slave";
+reg = <0x45>;
I think you need to or in I2C_OWN_SLAVE_ADDRESS from
here?
Sorry, I mentioned it in letter 0 only.
I will rework nvec driver and device tree according to i2c core slave
implementation later. v3 of this patchset is for fixing tegra i2c driver
only.
--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On Sun, Jul 19, 2015 at 09:01:34PM +0200, Michal Suchanek wrote: > Hello, > > On 15 July 2015 at 17:59, Brian Norris wrote: > > Hi Michal, > > > > On Wed, Jul 15, 2015 at 01:52:27PM +0200, Marek Vasut wrote: > >> The problem is, if you add a new DT binding, you'd have to support it > >> forever, no matter how bad idea that binding turned out to be. > > > > Agreed, and a solid NAK to this patch. I could have sworn I gave such a > > response when this was originally being discussed a month ago. > > > > AFAICT, you have one of two general approaches available to you: > > > > 1. Fix up the SPI driver so that it knows how to break large SPI > > transfers up into smaller segments that its constituent hardware (DMA > > controllers, fast clocks, etc.) can handle. > > > > 2. Utilize/create a parameter within the SPI subsystem to communicate > > that the SPI master has a limited max transfer size (notably: NOT a > > per-device DT property, but a SPI API property), and modify SPI device > > drivers (like m25p80) to honor it. Mark Brown seemed open to this, and I > > thought he suggested it somewhere. > > It is not known what exactly is limited here. > > It seems that the pl330 fails but it is not possible to transfer that > much data over the spi bus in one go without the help of the pl330. > > With either approach the limit depends on the SPI transfer settings > which are known the the SPI driver. The pl330 driver is oblivious to > these because it just transfers data from one port to another port and > has no idea that the port is wired to SPI in the SoC. > > On the other hand, AFAICT the SPI driver only allocates a DMA channel > which it receives through DT binding and is oblivious to the fact the > DMA channel lives on a pl330. It could probably determine that the > channel is indeed driven by a pl330. I don't think it's a great idea > to add device-specific handling to a generic dmaengine driver or a > dmaengine-spiecific handling to a SPI driver. > > It's technically possible to pass SPI transfer parameters to the > dmaengine driver prior to transfer and the dmaengine could impose some > limitation based on those parameters. However, generalising this to > drivers other than SPI might be problematic. Should this interface > also handle i2c parameters, VE parameters, audio parameters, ethernet > parameters, etc? Or alternatively we could publish the limitations of the channel using capabilities so SPI knows I have a dmaengine channel and it can transfer max N length transfers so would be able to break rather than guessing it or coding in DT. Yes it may come from DT but that should be dmaengine driver rather than client driver :) This can be done by dma_get_slave_caps(chan, &caps) And we add max_length as one more parameter to existing set Also all this could be handled in generic SPI-dmaengine layer so that individual drivers don't have to code it in Let me know if this idea is okay, I can push the dmaengine bits... Thanks -- ~Vinod -- 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/5] ARM/PCI: remove align_resource callback in pcibios_align_resource
On 2015/7/17 18:02, Gabriele Paoloni wrote:
> The following patch is maybe a better solution
>
> Gab
>
Hi Gab,
Many thanks for your patch, I think this patch is cleaner than 1/4 in v2
patchset.
I will merge this one in my new series.
Thanks，
Zhou
> ---
> This patch is needed in order to unify the PCIe designware
> framework for ARM and ARM64 architectures.
> In the PCIe designware unification process we are calling
> pci_create_root_bus() passing a "sysdata" parameter
> that is the same for both ARM and ARM64 and is of type
> "struct pcie_port*". In the ARM case this will cause
> a problem with the function pcibios_align_resource();
> in fact this will cast "dev->sysdata" to "struct pci_sys_data*",
> whereas designware had passed a "struct pcie_port*" pointer.
>
> This patch solves the issue by removing "align_resource" from
> "pci_sys_data" struct and defining a static global function pointer
> in "bios32.c"
>
> Signed-off-by: Gabriele Paoloni
> ---
> arch/arm/include/asm/mach/pci.h | 5 -
> arch/arm/kernel/bios32.c| 12
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 28b9bb3..8a4e4de 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -58,11 +58,6 @@ struct pci_sys_data {
> /* IRQ mapping
> */
> int (*map_irq)(const struct pci_dev *, u8, u8);
> /* Resource alignement requirements
> */
> - resource_size_t (*align_resource)(struct pci_dev *dev,
> - const struct resource *res,
> - resource_size_t start,
> - resource_size_t size,
> - resource_size_t align);
> void*private_data; /* platform controller private data
> */
> };
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index fc1..4cdc64d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -17,6 +17,11 @@
> #include
>
> static int debug_pci;
> +static resource_size_t (*align_resource)(struct pci_dev *dev,
> + const struct resource *res,
> + resource_size_t start,
> + resource_size_t size,
> + resource_size_t align) = NULL;
>
> #ifdef CONFIG_PCI_MSI
> struct msi_controller *pcibios_msi_controller(struct pci_dev *dev)
> @@ -468,7 +473,7 @@ static void pcibios_init_hw(struct device *parent, struct
> hw_pci *hw,
> sys->busnr = busnr;
> sys->swizzle = hw->swizzle;
> sys->map_irq = hw->map_irq;
> - sys->align_resource = hw->align_resource;
> + align_resource = hw->align_resource;
> INIT_LIST_HEAD(&sys->resources);
>
> if (hw->private_data)
> @@ -589,7 +594,6 @@ resource_size_t pcibios_align_resource(void *data, const
> struct resource *res,
> resource_size_t size, resource_size_t align)
> {
> struct pci_dev *dev = data;
> - struct pci_sys_data *sys = dev->sysdata;
> resource_size_t start = res->start;
>
> if (res->flags & IORESOURCE_IO && start & 0x300)
> @@ -597,8 +601,8 @@ resource_size_t pcibios_align_resource(void *data, const
> struct resource *res,
>
> start = (start + align - 1) & ~(align - 1);
>
> - if (sys->align_resource)
> - return sys->align_resource(dev, res, start, size, align);
> + if (align_resource)
> + return align_resource(dev, res, start, size, align);
>
> return start;
> }
>
--
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] input: cyapa: add of match device support and description document
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 2015?7?21? 8:15
> To: Dudley Du
> Cc: mark.rutl...@arm.com; robh...@kernel.org; rydb...@euromail.se;
> ble...@google.com; jmmah...@gmail.com; devicetree@vger.kernel.org;
> linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v1 6/7] input: cyapa: add of match device support and
> description document
>
> On Mon, Jun 15, 2015 at 05:01:36PM +0800, Dudley Du wrote:
> > Add of_match_device mechanism support for Cypress trackpad device, and
> > add the sample description document of adding the trackpad device node in
> > device tree.
> > TEST=test on Chromebook.
> >
> > Signed-off-by: Dudley Du
> > ---
> > .../devicetree/bindings/input/cypress,cyapa.txt| 44
> ++
> > .../devicetree/bindings/vendor-prefixes.txt| 1 +
> > drivers/input/mouse/cyapa.c| 10 +
> > 3 files changed, 55 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/input/cypress,cyapa.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> > new file mode 100644
> > index 000..9be2b44
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> > @@ -0,0 +1,44 @@
> > +Cypress I2C Touchpad
> > +
> > +Required properties:
> > +- compatible: must be "cypress,cyapa".
> > +- reg: I2C address of the chip.
> > +- interrupt-parent: a phandle for the interrupt controller (see interrupt
> > + binding[0]).
> > +- interrupts: interrupt to which the chip is connected (see interrupt
> > + binding[0]).
> > +
> > +Optional properties:
> > +- wakeup-source: touchpad can be used as a wakeup source.
> > +- pinctrl-names: should be "default" (see pinctrl binding [1]).
> > +- pinctrl-0: a phandle pointing to the pin settings for the device (see
> > + pinctrl binding [1]).
> > +- vcc-supply: a phandle for the regulator supplying 3.3V power.
>
> I do not see it being used in the driver?
Thanks, I will add the vcc-supply code in the cyapa_probe routine.
And resubmit this patch.
>
> > +
> > +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> > +[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> > +
> > +Example:
> > +&i2c0 {
> > +/* ... */
> > +
> > +/* Cypress Gen3 touchpad */
> > +touchpad@67 {
> > +compatible = "cypress,cyapa";
> > +reg = <0x24>;
> > +interrupt-parent = <&gpio>;
> > +interrupts = <2 IRQ_TYPE_EDGE_FALLING>;/* GPIO 2 */
> > +wakeup-source;
> > +};
> > +
> > +/* Cypress Gen5 and later touchpad */
> > +touchpad@24 {
> > +compatible = "cypress,cyapa";
> > +reg = <0x24>;
> > +interrupt-parent = <&gpio>;
> > +interrupts = <2 IRQ_TYPE_EDGE_FALLING>;/* GPIO 2 */
> > +wakeup-source;
> > +};
> > +
> > +/* ... */
> > +};
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index ee2ce7b..e43d532 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -54,6 +54,7 @@ cortinaCortina Systems, Inc.
> > cosmicCosmic Circuits
> > crystalfontzCrystalfontz America, Inc.
> > cubietechCubietech, Ltd.
> > +cypressCypress Semiconductor Corporation
> > dallasMaxim Integrated Products (formerly Dallas Semiconductor)
> > davicomDAVICOM Semiconductor, Inc.
> > deltaDelta Electronics, Inc.
> > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> > index 4e69594..7b6d6d4 100644
> > --- a/drivers/input/mouse/cyapa.c
> > +++ b/drivers/input/mouse/cyapa.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "cyapa.h"
> >
> >
> > @@ -1562,12 +1563,21 @@ static const struct acpi_device_id cyapa_acpi_id[] =
> {
> > MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
> > #endif
> >
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cyapa_of_match[] = {
> > +{ .compatible = "cypress,cyapa" },
> > +{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, cyapa_of_match);
> > +#endif
> > +
> > static struct i2c_driver cyapa_driver = {
> > .driver = {
> > .name = "cyapa",
> > .owner = THIS_MODULE,
> > .pm = &cyapa_pm_ops,
> > .acpi_match_table = ACPI_PTR(cyapa_acpi_id),
> > +.of_match_table = of_match_ptr(cyapa_of_match),
> > },
> >
> > .probe = cyapa_probe,
> > --
> > 1.9.1
> >
> >
> > ---
> > This message and any attachments may contain Cypress (or its
> > subsidiaries) confidential information. If it has been received
> > in error, please advise the sender and immediately delete this
> > message.
> > ---
> >
>
> --
> Dmitry
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error,
[PATCH 3/3] MAINTAINERS: V4L2: PLATFORM: Add entry for Renesas JPEG Processing Unit driver
Update RENESAS JPU driver maintainer in MAINTAINERS file. Signed-off-by: Mikhail Ulyanov --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b65b22b..da57ec1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5381,6 +5381,12 @@ S: Maintained F: fs/jbd2/ F: include/linux/jbd2.h +JPU V4L2 MEM2MEM DRIVER FOR RENESAS +M: Mikhail Ulyanov +L: linux-me...@vger.kernel.org +S: Maintained +F: drivers/media/platform/rcar_jpu.c + JSM Neo PCI based serial card M: Thadeu Lima de Souza Cascardo L: linux-ser...@vger.kernel.org -- 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 v3 2/3] devicetree: bindings: Document Renesas R-Car JPEG Processing Unit
Add Renesas R-Car JPEG processing unit driver device tree bindings
documentation.
Signed-off-by: Mikhail Ulyanov
---
Changes since v2:
- remove generic "renesas,jpu-gen2" descriptor
Changes since v1:
- Fix typos
.../devicetree/bindings/media/renesas,jpu.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,jpu.txt
diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.txt
b/Documentation/devicetree/bindings/media/renesas,jpu.txt
new file mode 100644
index 000..0cb9420
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,jpu.txt
@@ -0,0 +1,24 @@
+* Renesas JPEG Processing Unit
+
+The JPEG processing unit (JPU) incorporates the JPEG codec with an encoding
+and decoding function conforming to the JPEG baseline process, so that the JPU
+can encode image data and decode JPEG data quickly.
+
+Required properties:
+ - compatible: should containg one of the following:
+ - "renesas,jpu-r8a7790" for R-Car H2
+ - "renesas,jpu-r8a7791" for R-Car M2-W
+ - "renesas,jpu-r8a7792" for R-Car V2H
+ - "renesas,jpu-r8a7793" for R-Car M2-N
+
+ - reg: Base address and length of the registers block for the JPU.
+ - interrupts: JPU interrupt specifier.
+ - clocks: A phandle + clock-specifier pair for the JPU functional clock.
+
+Example: R8A7790 (R-Car H2) JPU node
+ jpeg-codec@fe98 {
+ compatible = "renesas,jpu-r8a7790";
+ reg = <0 0xfe98 0 0x10300>;
+ interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp1_clks R8A7790_CLK_JPU>;
+ };
--
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 v5 1/3] V4L2: platform: Add Renesas R-Car JPEG codec driver
Here's the driver for the Renesas R-Car JPEG processing unit. The driver is implemented within the V4L2 framework as a memory-to-memory device. It presents two video nodes to userspace, one for the encoding part, and one for the decoding part. It was found that the only working mode for encoding is no markers output, so we generate markers with software. In the current version of driver we also use software JPEG header parsing because with hardware parsing performance is lower than desired. >From a userspace point of view the process is typical (S_FMT, REQBUF, optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination queues. STREAMON can return -EINVAL in case of mismatch of output and capture queues format. Also during decoding driver can return buffers if queued buffer with JPEG image contains image with inappropriate subsampling (e.g. 4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag. During encoding the available formats are: V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and V4L2_PIX_FMT_JPEG for destination. During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16 for destination. Performance of current version: 1280x800 NV12 image encoding/decoding decoding ~122 FPS encoding ~191 FPS Signed-off-by: Mikhail Ulyanov --- Changes since v4: - ARCH dependency added to Kconfig - module name fix in Kconfig - add v4l2_buf.sequence number filling - add v4l2_buf.field copy from source to destination buffer - only valid flags in destination buffer - fix bpl type in __jpu_try_fmt() - remove V4L2_MEMORY_USERPTR support as almost useless and buggy - fix jpu->curr setup in irq handler Changes since v3: - driver file renamed to rcar_jpu.c - semiplanar formats NV12 and NV16 support - new callbacks streamon, job_abort and stop_streaming - extra processing error information printout irq handler - fill in JPEG header for encoded buffer in buf_finish - wrapped reading/writing to registers - vb2_set_plane_payload only for necessary buffer in buf_prepare - multiple buffers now supported - removed format setup with parsed info; rely only on users info - JPEG header parser redesigned - video_device structs embedded - video_device_alloc/release removed - "name" filed in format description removed - remove g_selection - start_streaming removed Changes since v2: - Kconfig entry reordered - unnecessary clk_disable_unprepare(jpu->clk) removed - ref_count fixed in jpu_resume - enable DMABUF in src_vq->io_modes - remove jpu_s_priority jpu_g_priority - jpu_g_selection fixed - timeout in jpu_reset added and hardware reset reworked - remove unused macros - JPEG header parsing now is software because of performance issues based on s5p-jpeg code - JPEG header generation redesigned: JPEG header(s) pre-generated and memcpy'ed on encoding we only fill the necessary fields more "transparent" header format description - S_FMT, G_FMT and TRY_FMT hooks redesigned partially inspired by VSP1 driver code - some code was reformatted - image formats handling redesigned - multi-planar V4L2 API now in use - now passes v4l2-compliance tool check Cnanges since v1: - s/g_fmt function simplified - default format for queues added - dumb vidioc functions added to be in compliance with standard api: jpu_s_priority, jpu_g_priority - standard v4l2_ctrl_subscribe_event and v4l2_event_unsubscribe now in use by the same reason drivers/media/platform/Kconfig| 12 + drivers/media/platform/Makefile |1 + drivers/media/platform/rcar_jpu.c | 1783 + 3 files changed, 1796 insertions(+) create mode 100644 drivers/media/platform/rcar_jpu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 765bffb..7a64077 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -220,6 +220,18 @@ config VIDEO_SH_VEU Support for the Video Engine Unit (VEU) on SuperH and SH-Mobile SoCs. +config VIDEO_RENESAS_JPU + tristate "Renesas JPEG Processing Unit" + depends on VIDEO_DEV && VIDEO_V4L2 + depends on ARCH_SHMOBILE || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + ---help--- + This is a V4L2 driver for the Renesas JPEG Processing Unit. + + To compile this driver as a module, choose M here: the module + will be called rcar_jpu. + config VIDEO_RENESAS_VSP1 tristate "Renesas VSP1 Video Processing Engine" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA dif
[PATCH 0/3] R-Car JPEG Processing Unit
This series of patches contains a driver for the JPEG codec integrated peripheral found in the Renesas R-Car SoCs and associated DT documentation. This series of patches is against the 'master' branch of linuxtv.org/media_tree.git v4l2-compliance -s Driver Info: Driver name : rcar_jpu Card type : rcar_jpu encoder Bus info : platform:fe98.jpu Driver version: 4.2.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 2 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: warn: v4l2-test-buffers.cpp(542): VIDIOC_CREATE_BUFS not supported warn: v4l2-test-buffers.cpp(542): VIDIOC_CREATE_BUFS not supported test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK (Not Supported) Test input 0: Streaming ioctls: test read/write: OK (Not Supported) test MMAP: OK test USERPTR: OK (Not Supported) test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 45, Failed: 0, Warnings: 2 Mikhail Ulyanov (3): V4L2: platform: Add Renesas R-Car JPEG codec driver. devicetree: bindings: Document Renesas JPEG Processing Unit MAINTAINERS: V4L2: PLATFORM: Add entry for Renesas JPEG Processing Unit driver .../devicetree/bindings/media/renesas,jpu.txt | 24 + MAINTAINERS|6 + drivers/media/platform/Kconfig | 12 + drivers/media/platform/Makefile|1 + drivers/media/platform/rcar_jpu.c | 1783 5 files changed, 1826 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/renesas,jpu.txt create mode 100644 drivers/media/platform/rcar_jpu.c -- 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 v1 3/7] input: cyapa: add proximity function support for gen5 and gen6 modules
Dmitry,
Yes, It cannot report the distance per-contact.
Thanks for the update.
Thanks,
Dudley
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 2015?7?21? 8:07
> To: Dudley Du
> Cc: mark.rutl...@arm.com; robh...@kernel.org; rydb...@euromail.se;
> ble...@google.com; jmmah...@gmail.com; devicetree@vger.kernel.org;
> linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v1 3/7] input: cyapa: add proximity function support for
> gen5
> and gen6 modules
>
> Hi Dudley,
>
> On Mon, Jun 15, 2015 at 05:01:33PM +0800, Dudley Du wrote:
> >
> > +static void cyapa_pip_report_proximity(struct cyapa *cyapa,
> > +const struct cyapa_pip_report_data *report_data)
> > +{
> > +struct input_dev *input = cyapa->input;
> > +u8 distance = report_data->report_head[PIP_PROXIMITY_DISTANCE_OFFSET]
> &
> > +PIP_PROXIMITY_DISTANCE_MASK;
> > +
> > +input_report_abs(input, ABS_MT_DISTANCE, distance);
> > +input_sync(input);
>
> It looks like the distance reported by the hardware is not per-contact
> (i.e. it can not tell that we had 2 fingers on surface and the 2nd one
> was lifted and is now hovering over the surface), so we should be using
> ABS_DISTANCE, not ABS_MT_DISTANCE.
>
> I can adjust it here, no need to resend.
>
> Thanks.
>
> --
> Dmitry
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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] ARM: OMAP2+: omap3-pandora: add backlight support
Add backlight support via pdata-quirks as it's driver lacks DT support.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/mach-omap2/pdata-quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 821171c..3c97aa49 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -268,6 +268,16 @@ static void __init omap3_tao3530_legacy_init(void)
{
hsmmc2_internal_input_clk();
}
+
+static struct platform_device pandora_backlight = {
+ .name = "pandora-backlight",
+ .id = -1,
+};
+
+static void __init omap3_pandora_legacy_init(void)
+{
+ platform_device_register(&pandora_backlight);
+}
#endif /* CONFIG_ARCH_OMAP3 */
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
@@ -381,6 +391,8 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
{ "ti,am3517-evm", am3517_evm_legacy_init, },
{ "technexion,omap3-tao3530", omap3_tao3530_legacy_init, },
+ { "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
+ { "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
#endif
#ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
--
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 2/4] ARM: dts: omap3-pandora: add support for usb host and 32k buffer
This adds missing bits for EHCI HS USB host support and 32k clock
buffer control for the wg7210 bt+wifi module.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 36 +
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index f6363bc..6e82c4a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -199,6 +199,38 @@
gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>; /* GPIO_108 */
};
};
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>; /* GPIO_16 */
+ vcc-supply = <&vaux2>;
+ };
+
+ /* HS USB Host VBUS supply
+* disabling this regulator causes current leakage, and LCD flicker
+* on earlier (CC) board revisions, so keep it always on */
+ usb_host_5v: fixed-regulator-usb_host_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_host_5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = <&gpio6 4 0>;/* GPIO_164 */
+ };
+
+ /* wg7210 (wifi+bt module) 32k clock buffer */
+ wg7210_32k: fixed-regulator-wg7210_32k {
+ compatible = "regulator-fixed";
+ regulator-name = "wg7210_32k";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&twl_gpio 13 GPIO_ACTIVE_HIGH>;
+ };
};
&omap3_pmx_core {
@@ -501,6 +533,10 @@
port2-mode = "ehci-phy";
};
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
+
&gpmc {
ranges = <0 0 0x3000 0x100>; /* CS0: 16MB for NAND */
--
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 4/4] ARM: OMAP2+: omap3-pandora: add wifi support
Add wl1251 support via pdata-quirks as it's driver lacks DT
support. MMC3 is marked disabled in DT so that MMC3 instance of
hsmmc driver is probed using platform data with special card init
callback.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 5 ++
arch/arm/mach-omap2/pdata-quirks.c | 101
2 files changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 6e82c4a..f2084e6 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -514,6 +514,11 @@
/*wp-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;*//* GPIO_127 */
};
+/* mmc3 is probed using pdata-quirks to pass wl1251 card data */
+&mmc3 {
+ status = "disabled";
+};
+
/* bluetooth*/
&uart1 {
};
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3c97aa49..95f6724 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,6 +14,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
#include
@@ -25,6 +30,7 @@
#include "omap_device.h"
#include "omap-secure.h"
#include "soc.h"
+#include "hsmmc.h"
struct pdata_init {
const char *compatible;
@@ -269,14 +275,109 @@ static void __init omap3_tao3530_legacy_init(void)
hsmmc2_internal_input_clk();
}
+/* omap3pandora legacy devices */
+#define PANDORA_WIFI_IRQ_GPIO 21
+#define PANDORA_WIFI_NRESET_GPIO 23
+
static struct platform_device pandora_backlight = {
.name = "pandora-backlight",
.id = -1,
};
+static struct regulator_consumer_supply pandora_vmmc3_supply[] = {
+ REGULATOR_SUPPLY("vmmc", "omap_hsmmc.2"),
+};
+
+static struct regulator_init_data pandora_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(pandora_vmmc3_supply),
+ .consumer_supplies = pandora_vmmc3_supply,
+};
+
+static struct fixed_voltage_config pandora_vwlan = {
+ .supply_name= "vwlan",
+ .microvolts = 180, /* 1.8V */
+ .gpio = PANDORA_WIFI_NRESET_GPIO,
+ .startup_delay = 5, /* 50ms */
+ .enable_high= 1,
+ .init_data = &pandora_vmmc3,
+};
+
+static struct platform_device pandora_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &pandora_vwlan,
+ },
+};
+
+static void pandora_wl1251_init_card(struct mmc_card *card)
+{
+ /*
+* We have TI wl1251 attached to MMC3. Pass this information to
+* SDIO core because it can't be probed by normal methods.
+*/
+ if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
+ card->quirks |= MMC_QUIRK_NONSTD_SDIO;
+ card->cccr.wide_bus = 1;
+ card->cis.vendor = 0x104c;
+ card->cis.device = 0x9066;
+ card->cis.blksize = 512;
+ card->cis.max_dtr = 2400;
+ card->ocr = 0x80;
+ }
+}
+
+static struct omap2_hsmmc_info pandora_mmc3[] = {
+ {
+ .mmc= 3,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .init_card = pandora_wl1251_init_card,
+ },
+ {} /* Terminator */
+};
+
+static void __init pandora_wl1251_init(void)
+{
+ struct wl1251_platform_data pandora_wl1251_pdata;
+ int ret;
+
+ memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
+
+ pandora_wl1251_pdata.power_gpio = -1;
+
+ ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, "wl1251 irq");
+ if (ret < 0)
+ goto fail;
+
+ pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
+ if (pandora_wl1251_pdata.irq < 0)
+ goto fail_irq;
+
+ pandora_wl1251_pdata.use_eeprom = true;
+ ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
+ if (ret < 0)
+ goto fail_irq;
+
+ return;
+
+fail_irq:
+ gpio_free(PANDORA_WIFI_IRQ_GPIO);
+fail:
+ pr_err("wl1251 board initialisation failed\n");
+}
+
static void __init omap3_pandora_legacy_init(void)
{
platform_device_register(&pandora_backlight);
+ platform_device_register(&pandora_vwlan_device);
+ omap_hsmmc_init(pandora_mmc3);
+ omap_hsmmc_late_init(pandora_mmc3);
+ pandora_wl1251_init();
}
#endif /* CONFIG_ARCH_OMAP3 */
--
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 ma
[PATCH 1/4] ARM: dts: omap3-pandora: miscellaneous corrections
- add pandora specific compatible name
- fix mmc2 card detect polarity
- fix mmc1 and mmc2 write protect polarity
- disable write protect pins because of production issue and add an
explanation why they are disabled
- fix NAND partition name to reflect the correct address
Signed-off-by: Grazvydas Ignotas
---
arch/arm/boot/dts/omap3-pandora-1ghz.dts| 2 +-
arch/arm/boot/dts/omap3-pandora-600mhz.dts | 2 +-
arch/arm/boot/dts/omap3-pandora-common.dtsi | 13 +
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
index 9619a28..25498f7 100644
--- a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
@@ -19,7 +19,7 @@
/ {
model = "Pandora Handheld Console 1GHz";
- compatible = "ti,omap36xx", "ti,omap3";
+ compatible = "openpandora,omap3-pandora-1ghz", "ti,omap36xx",
"ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-pandora-600mhz.dts
b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
index fb803a7..8775897 100644
--- a/arch/arm/boot/dts/omap3-pandora-600mhz.dts
+++ b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
@@ -19,7 +19,7 @@
/ {
model = "Pandora Handheld Console";
- compatible = "ti,omap3";
+ compatible = "openpandora,omap3-pandora-600mhz", "ti,omap3430",
"ti,omap3";
};
&omap3_pmx_core2 {
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 782ab1f..f6363bc 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -459,13 +459,18 @@
power = <50>;
};
+/*
+ * Many pandora boards have been produced with defective write-protect switches
+ * on either slot, so it was decided not to use this feature. If you know
+ * your board has good switches, feel free to uncomment wp-gpios below.
+ */
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <&vmmc1>;
bus-width = <4>;
cd-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>; /* GPIO_126 */
+ /*wp-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;*//* GPIO_126 */
};
&mmc2 {
@@ -473,8 +478,8 @@
pinctrl-0 = <&mmc2_pins>;
vmmc-supply = <&vmmc2>;
bus-width = <4>;
- cd-gpios = <&twl_gpio 1 GPIO_ACTIVE_HIGH>;
- wp-gpios = <&gpio4 31 GPIO_ACTIVE_LOW>; /* GPIO_127 */
+ cd-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ /*wp-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;*//* GPIO_127 */
};
/* bluetooth*/
@@ -545,7 +550,7 @@
reg = <0x28 0xa0>;
};
- filesystem@68 {
+ filesystem@c8 {
label = "rootfs";
reg = <0xc8 0>; /* 0 = MTDPART_SIZ_FULL */
};
--
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 net v5 1/4] net: dsa: bcm_sf2: Do not override speed settings
The SF2 driver currently overrides speed settings for its port
configured using a fixed PHY, this is both unnecessary and incorrect,
because we keep feedback to the hardware parameters that we read from
the PHY device, which in the case of a fixed PHY cannot possibly change
speed.
This is a required change to allow the fixed PHY code to allow
registering a PHY with a link configured as DOWN by default and avoid
some sort of circular dependency where we require the link_update
callback to run to program the hardware, and we then utilize the fixed
PHY parameters to program the hardware with the same settings.
Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/bcm_sf2.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 972982f8bea7..3297604f8216 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -890,15 +890,11 @@ static void bcm_sf2_sw_fixed_link_update(struct
dsa_switch *ds, int port,
struct fixed_phy_status *status)
{
struct bcm_sf2_priv *priv = ds_to_priv(ds);
- u32 duplex, pause, speed;
+ u32 duplex, pause;
u32 reg;
duplex = core_readl(priv, CORE_DUPSTS);
pause = core_readl(priv, CORE_PAUSESTS);
- speed = core_readl(priv, CORE_SPDSTS);
-
- speed >>= (port * SPDSTS_SHIFT);
- speed &= SPDSTS_MASK;
status->link = 0;
@@ -933,18 +929,6 @@ static void bcm_sf2_sw_fixed_link_update(struct dsa_switch
*ds, int port,
reg &= ~LINK_STS;
core_writel(priv, reg, CORE_STS_OVERRIDE_GMIIP_PORT(port));
- switch (speed) {
- case SPDSTS_10:
- status->speed = SPEED_10;
- break;
- case SPDSTS_100:
- status->speed = SPEED_100;
- break;
- case SPDSTS_1000:
- status->speed = SPEED_1000;
- break;
- }
-
if ((pause & (1 << port)) &&
(pause & (1 << (port + PAUSESTS_TX_PAUSE_SHIFT {
status->asym_pause = 1;
--
2.1.0
--
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 net v5 2/4] net: phy: fixed_phy: handle link-down case
From: Stas Sergeev
fixed_phy_register() currently hardcodes the fixed PHY link to 1, and
expects to find a "speed" parameter to provide correct information
towards the fixed PHY consumer.
In a subsequent change, where we allow "managed" (e.g: (RS)GMII in-band
status auto-negotiation) fixed PHYs, none of these parameters can be
provided since they will be auto-negotiated, hence, we just provide a
zero-initialized fixed_phy_status to fixed_phy_register() which makes it
fail when we call fixed_phy_update_regs() since status.speed = 0 which
makes us hit the "default" label and error out.
Without this change, we would also see potentially inconsistent
speed/duplex parameters for fixed PHYs when the link is DOWN.
CC: net...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Stas Sergeev
[florian: add more background to why this is correct and desirable]
Signed-off-by: Florian Fainelli
---
drivers/net/phy/fixed_phy.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 1960b46add65..479b93f9581c 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -52,6 +52,10 @@ static int fixed_phy_update_regs(struct fixed_phy *fp)
u16 lpagb = 0;
u16 lpa = 0;
+ if (!fp->status.link)
+ goto done;
+ bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
+
if (fp->status.duplex) {
bmcr |= BMCR_FULLDPLX;
@@ -96,15 +100,13 @@ static int fixed_phy_update_regs(struct fixed_phy *fp)
}
}
- if (fp->status.link)
- bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
-
if (fp->status.pause)
lpa |= LPA_PAUSE_CAP;
if (fp->status.asym_pause)
lpa |= LPA_PAUSE_ASYM;
+done:
fp->regs[MII_PHYSID1] = 0;
fp->regs[MII_PHYSID2] = 0;
--
2.1.0
--
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 net v5 3/4] of_mdio: add new DT property 'managed' to specify the PHY management type
From: Stas Sergeev
Currently the PHY management type is selected by the MAC driver arbitrary.
The decision is based on the presence of the "fixed-link" node and on a
will of the driver's authors.
This caused a regression recently, when mvneta driver suddenly started
to use the in-band status for auto-negotiation on fixed links.
It appears the auto-negotiation may not work when expected by the MAC driver.
Sebastien Rannou explains:
<< Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
inband status) is connected to the switch through QSGMII, and in this context
we are on the media side of the PHY. >>
https://lkml.org/lkml/2015/7/10/206
This patch introduces the new string property 'managed' that allows
the user to set the management type explicitly.
The supported values are:
"auto" - default. Uses either MDIO or nothing, depending on the presence
of the fixed-link node
"in-band-status" - use in-band status
Signed-off-by: Stas Sergeev
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Florian Fainelli
CC: Grant Likely
CC: devicetree@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: net...@vger.kernel.org
---
Documentation/devicetree/bindings/net/ethernet.txt | 4
drivers/of/of_mdio.c | 19 +--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ethernet.txt
b/Documentation/devicetree/bindings/net/ethernet.txt
index 41b3f3f864e8..5d88f37480b6 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -25,7 +25,11 @@ The following properties are common to the Ethernet
controllers:
flow control thresholds.
- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
is used for components that can have configurable fifo sizes.
+- managed: string, specifies the PHY management type. Supported values are:
+ "auto", "in-band-status". "auto" is the default, it usess MDIO for
+ management if fixed-link is not specified.
Child nodes of the Ethernet controller are typically the individual PHY devices
connected via the MDIO bus (sometimes the MDIO bus controller is separate).
They are described in the phy.txt file in this same directory.
+For non-MDIO PHY management see fixed-link.txt.
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index fdc60db60829..7c8c23cc6896 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -266,7 +266,8 @@ EXPORT_SYMBOL(of_phy_attach);
bool of_phy_is_fixed_link(struct device_node *np)
{
struct device_node *dn;
- int len;
+ int len, err;
+ const char *managed;
/* New binding */
dn = of_get_child_by_name(np, "fixed-link");
@@ -275,6 +276,10 @@ bool of_phy_is_fixed_link(struct device_node *np)
return true;
}
+ err = of_property_read_string(np, "managed", &managed);
+ if (err == 0 && strcmp(managed, "auto") != 0)
+ return true;
+
/* Old binding */
if (of_get_property(np, "fixed-link", &len) &&
len == (5 * sizeof(__be32)))
@@ -289,8 +294,18 @@ int of_phy_register_fixed_link(struct device_node *np)
struct fixed_phy_status status = {};
struct device_node *fixed_link_node;
const __be32 *fixed_link_prop;
- int len;
+ int len, err;
struct phy_device *phy;
+ const char *managed;
+
+ err = of_property_read_string(np, "managed", &managed);
+ if (err == 0) {
+ if (strcmp(managed, "in-band-status") == 0) {
+ /* status is zeroed, namely its .link member */
+ phy = fixed_phy_register(PHY_POLL, &status, np);
+ return IS_ERR(phy) ? PTR_ERR(phy) : 0;
+ }
+ }
/* New binding */
fixed_link_node = of_get_child_by_name(np, "fixed-link");
--
2.1.0
--
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 net v5 4/4] mvneta: use inband status only when explicitly enabled
From: Stas Sergeev
The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state
signaling") implemented the link parameters auto-negotiation unconditionally.
Unfortunately it appears that some HW that implements SGMII protocol,
doesn't generate the inband status, so it is not possible to auto-negotiate
anything with such HW.
This patch enables the auto-negotiation only if explicitly requested with
the 'managed' DT property.
This patch fixes the following regression:
https://lkml.org/lkml/2015/7/8/865
Signed-off-by: Stas Sergeev
CC: Thomas Petazzoni
CC: net...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mvneta.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 370e20ed224c..e4fb172d91a6 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3029,8 +3029,8 @@ static int mvneta_probe(struct platform_device *pdev)
const char *dt_mac_addr;
char hw_mac_addr[ETH_ALEN];
const char *mac_from;
+ const char *managed;
int phy_mode;
- int fixed_phy = 0;
int err;
/* Our multiqueue support is not complete, so for now, only
@@ -3064,7 +3064,6 @@ static int mvneta_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "cannot register fixed PHY\n");
goto err_free_irq;
}
- fixed_phy = 1;
/* In the case of a fixed PHY, the DT node associated
* to the PHY is the Ethernet MAC DT node.
@@ -3088,8 +3087,10 @@ static int mvneta_probe(struct platform_device *pdev)
pp = netdev_priv(dev);
pp->phy_node = phy_node;
pp->phy_interface = phy_mode;
- pp->use_inband_status = (phy_mode == PHY_INTERFACE_MODE_SGMII) &&
- fixed_phy;
+
+ err = of_property_read_string(dn, "managed", &managed);
+ pp->use_inband_status = (err == 0 &&
+strcmp(managed, "in-band-status") == 0);
pp->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(pp->clk)) {
--
2.1.0
--
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 net v5 0/4] net: enable inband link state negotiation only when explicitly requested
Hi all, Changes in v5: - removed an invalid use of the link_update callback in the SF2 driver was appeared after merging "net: phy: fixed_phy: handle link-down case" - reworded the commit message for patch 2 to make it clear what it fixes and why this is required Initial cover letter from Stas: Hello. Currently the link status auto-negotiation is enabled for any SGMII link with fixed-link DT binding. The regression was reported: https://lkml.org/lkml/2015/7/8/865 Apparently not all HW that implements SGMII protocol, generates the inband status for the auto-negotiation to work. More details here: https://lkml.org/lkml/2015/7/10/206 The following patches reverts to the old behavior by default, which is to not enable the auto-negotiation for fixed-link. The new DT property is added that allows to explicitly request the auto-negotiation. Florian Fainelli (1): net: dsa: bcm_sf2: Do not override speed settings Stas Sergeev (3): net: phy: fixed_phy: handle link-down case of_mdio: add new DT property 'managed' to specify the PHY management type mvneta: use inband status only when explicitly enabled Documentation/devicetree/bindings/net/ethernet.txt | 4 drivers/net/dsa/bcm_sf2.c | 18 +- drivers/net/ethernet/marvell/mvneta.c | 9 + drivers/net/phy/fixed_phy.c| 8 +--- drivers/of/of_mdio.c | 19 +-- 5 files changed, 32 insertions(+), 26 deletions(-) -- 2.1.0 -- 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] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
On 2015. 7. 21., at AM 6:11, Jacek Anaszewski
wrote:
>> On 20.07.2015 16:15, Jingoo Han wrote:
>>> On Thursday, July 16, 2015 5:01 PM, Jacek Anaszewski wrote:
On 07/15/2015 10:02 PM, Bjorn Andersson wrote:
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
drivers/leds/Kconfig | 8 ---
drivers/leds/Makefile | 1 -
drivers/video/backlight/Kconfig | 8 +++
drivers/video/backlight/Makefile | 1 +
.../backlight/pm8941-wled.c} | 59
++
6 files changed, 36 insertions(+), 46 deletions(-)
rename drivers/{leds/leds-pm8941-wled.c =>
video/backlight/pm8941-wled.c} (90%)
>>>
>>> Acked-by: Jacek Anaszewski
>>
>> If you are not an author of this driver or a maintainer affected by this
>> patch,
>> Just 'Reviewed-by' looks good.
>
> I am a LED subsystem maintainer.
OK, I see.
I didn't notice that you were added as the maintainer 2 months ago.
Best regards,
Jingoo Han--
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] input: cyapa: add CYAP0002 Gen6 device for ACPI configuration
On Mon, Jun 15, 2015 at 05:01:37PM +0800, Dudley Du wrote:
> Add CYTP0002 name for Gen6 device for ACPI configuration
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
Applied, thank you.
> ---
> drivers/input/mouse/cyapa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index 7b6d6d4..7f674aa 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -1558,6 +1558,7 @@ MODULE_DEVICE_TABLE(i2c, cyapa_id_table);
> static const struct acpi_device_id cyapa_acpi_id[] = {
> { "CYAP", 0 }, /* Gen3 trackpad with 0x67 I2C address. */
> { "CYAP0001", 0 }, /* Gen5 trackpad with 0x24 I2C address. */
> + { "CYAP0002", 0 }, /* Gen6 trackpad with 0x24 I2C address. */
> { }
> };
> MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
> --
> 1.9.1
>
>
> ---
> This message and any attachments may contain Cypress (or its
> subsidiaries) confidential information. If it has been received
> in error, please advise the sender and immediately delete this
> message.
> ---
>
--
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] input: cyapa: add of match device support and description document
On Mon, Jun 15, 2015 at 05:01:36PM +0800, Dudley Du wrote:
> Add of_match_device mechanism support for Cypress trackpad device, and
> add the sample description document of adding the trackpad device node in
> device tree.
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
> ---
> .../devicetree/bindings/input/cypress,cyapa.txt| 44
> ++
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> drivers/input/mouse/cyapa.c| 10 +
> 3 files changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt
>
> diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> new file mode 100644
> index 000..9be2b44
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
> @@ -0,0 +1,44 @@
> +Cypress I2C Touchpad
> +
> +Required properties:
> +- compatible: must be "cypress,cyapa".
> +- reg: I2C address of the chip.
> +- interrupt-parent: a phandle for the interrupt controller (see interrupt
> + binding[0]).
> +- interrupts: interrupt to which the chip is connected (see interrupt
> + binding[0]).
> +
> +Optional properties:
> +- wakeup-source: touchpad can be used as a wakeup source.
> +- pinctrl-names: should be "default" (see pinctrl binding [1]).
> +- pinctrl-0: a phandle pointing to the pin settings for the device (see
> + pinctrl binding [1]).
> +- vcc-supply: a phandle for the regulator supplying 3.3V power.
I do not see it being used in the driver?
> +
> +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + &i2c0 {
> + /* ... */
> +
> + /* Cypress Gen3 touchpad */
> + touchpad@67 {
> + compatible = "cypress,cyapa";
> + reg = <0x24>;
> + interrupt-parent = <&gpio>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
> + wakeup-source;
> + };
> +
> + /* Cypress Gen5 and later touchpad */
> + touchpad@24 {
> + compatible = "cypress,cyapa";
> + reg = <0x24>;
> + interrupt-parent = <&gpio>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
> + wakeup-source;
> + };
> +
> + /* ... */
> + };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ee2ce7b..e43d532 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -54,6 +54,7 @@ cortina Cortina Systems, Inc.
> cosmic Cosmic Circuits
> crystalfontz Crystalfontz America, Inc.
> cubietechCubietech, Ltd.
> +cypress Cypress Semiconductor Corporation
> dallas Maxim Integrated Products (formerly Dallas Semiconductor)
> davicom DAVICOM Semiconductor, Inc.
> deltaDelta Electronics, Inc.
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index 4e69594..7b6d6d4 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include "cyapa.h"
>
>
> @@ -1562,12 +1563,21 @@ static const struct acpi_device_id cyapa_acpi_id[] = {
> MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id cyapa_of_match[] = {
> + { .compatible = "cypress,cyapa" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, cyapa_of_match);
> +#endif
> +
> static struct i2c_driver cyapa_driver = {
> .driver = {
> .name = "cyapa",
> .owner = THIS_MODULE,
> .pm = &cyapa_pm_ops,
> .acpi_match_table = ACPI_PTR(cyapa_acpi_id),
> + .of_match_table = of_match_ptr(cyapa_of_match),
> },
>
> .probe = cyapa_probe,
> --
> 1.9.1
>
>
> ---
> This message and any attachments may contain Cypress (or its
> subsidiaries) confidential information. If it has been received
> in error, please advise the sender and immediately delete this
> message.
> ---
>
--
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 4/7] input: cyapa: fully support runtime suspend power management
On Mon, Jun 15, 2015 at 05:01:34PM +0800, Dudley Du wrote:
> Fix the the runtime suspend power management not working issue when system
> starts up and before user touches the trackpad device.
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
Applied, thank you.
> ---
> drivers/input/mouse/cyapa.c | 79
> +++-
> drivers/input/mouse/cyapa.h | 2 +-
> drivers/input/mouse/cyapa_gen3.c | 4 +-
> drivers/input/mouse/cyapa_gen5.c | 21 +++
> drivers/input/mouse/cyapa_gen6.c | 4 +-
> 5 files changed, 72 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index d2a24fc..9288948 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -371,7 +371,7 @@ static int cyapa_detect(struct cyapa *cyapa)
> static int cyapa_open(struct input_dev *input)
> {
> struct cyapa *cyapa = input_get_drvdata(input);
> - struct i2c_client *client = cyapa->client;
> + struct device *dev = &cyapa->client->dev;
> int error;
>
> error = mutex_lock_interruptible(&cyapa->state_sync_lock);
> @@ -385,10 +385,9 @@ static int cyapa_open(struct input_dev *input)
>* when in operational mode.
>*/
> error = cyapa->ops->set_power_mode(cyapa,
> - PWR_MODE_FULL_ACTIVE, 0);
> + PWR_MODE_FULL_ACTIVE, 0, false);
> if (error) {
> - dev_warn(&client->dev,
> - "set active power failed: %d\n", error);
> + dev_warn(dev, "set active power failed: %d\n", error);
> goto out;
> }
> } else {
> @@ -399,11 +398,15 @@ static int cyapa_open(struct input_dev *input)
> }
> }
>
> - enable_irq(client->irq);
> - if (!pm_runtime_enabled(&client->dev)) {
> - pm_runtime_set_active(&client->dev);
> - pm_runtime_enable(&client->dev);
> + enable_irq(cyapa->client->irq);
> + if (!pm_runtime_enabled(dev)) {
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> }
> +
> + pm_runtime_get_sync(dev);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_sync_autosuspend(dev);
> out:
> mutex_unlock(&cyapa->state_sync_lock);
> return error;
> @@ -412,17 +415,17 @@ out:
> static void cyapa_close(struct input_dev *input)
> {
> struct cyapa *cyapa = input_get_drvdata(input);
> - struct i2c_client *client = cyapa->client;
> + struct device *dev = &cyapa->client->dev;
>
> mutex_lock(&cyapa->state_sync_lock);
>
> - disable_irq(client->irq);
> - if (pm_runtime_enabled(&client->dev))
> - pm_runtime_disable(&client->dev);
> - pm_runtime_set_suspended(&client->dev);
> + disable_irq(cyapa->client->irq);
> + if (pm_runtime_enabled(dev))
> + pm_runtime_disable(dev);
> + pm_runtime_set_suspended(dev);
>
> if (cyapa->operational)
> - cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
> + cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0, false);
>
> mutex_unlock(&cyapa->state_sync_lock);
> }
> @@ -533,7 +536,7 @@ static void cyapa_enable_irq_for_cmd(struct cyapa *cyapa)
>*/
> if (!input || cyapa->operational)
> cyapa->ops->set_power_mode(cyapa,
> - PWR_MODE_FULL_ACTIVE, 0);
> + PWR_MODE_FULL_ACTIVE, 0, false);
> /* Gen3 always using polling mode for command. */
> if (cyapa->gen >= CYAPA_GEN5)
> enable_irq(cyapa->client->irq);
> @@ -548,7 +551,8 @@ static void cyapa_disable_irq_for_cmd(struct cyapa *cyapa)
> if (cyapa->gen >= CYAPA_GEN5)
> disable_irq(cyapa->client->irq);
> if (!input || cyapa->operational)
> - cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
> + cyapa->ops->set_power_mode(cyapa,
> +PWR_MODE_OFF, 0, false);
> }
> }
>
> @@ -615,7 +619,7 @@ static int cyapa_initialize(struct cyapa *cyapa)
>
> /* Power down the device until we need it. */
> if (cyapa->operational)
> - cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
> + cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0, false);
>
> return 0;
> }
> @@ -631,7 +635,8 @@ static int cyapa_reinitialize(struct cyapa *cyapa)
>
> /* Avoid command failures when TP was in OFF state. */
> if (cyapa->operational)
> - cyapa->ops->set_power_mode(cyapa, PWR_MODE_FULL_ACTIVE, 0);
> + cyapa->ops->set_power_mode(cyapa,
> +PWR_MODE_FULL_ACTIVE, 0, false);
>
> error = cyapa_detect(cyapa
Re: [PATCH v1 3/7] input: cyapa: add proximity function support for gen5 and gen6 modules
Hi Dudley,
On Mon, Jun 15, 2015 at 05:01:33PM +0800, Dudley Du wrote:
>
> +static void cyapa_pip_report_proximity(struct cyapa *cyapa,
> + const struct cyapa_pip_report_data *report_data)
> +{
> + struct input_dev *input = cyapa->input;
> + u8 distance = report_data->report_head[PIP_PROXIMITY_DISTANCE_OFFSET] &
> + PIP_PROXIMITY_DISTANCE_MASK;
> +
> + input_report_abs(input, ABS_MT_DISTANCE, distance);
> + input_sync(input);
It looks like the distance reported by the hardware is not per-contact
(i.e. it can not tell that we had 2 fingers on surface and the 2nd one
was lifted and is now hovering over the surface), so we should be using
ABS_DISTANCE, not ABS_MT_DISTANCE.
I can adjust it here, no need to resend.
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 2/7] input: cyapa: add gen6 device module support in driver
On Mon, Jun 15, 2015 at 05:01:32PM +0800, Dudley Du wrote:
> Based on the cyapa core, add the gen6 trackpad device's basic functions
> supported, so gen6 trackpad device can work with kernel input system.
> And also based on the state parse interface, the cyapa driver can
> automatically determine the attached is gen3, gen5 or gen6 protocol
> trackpad device, then set the correct protocol to work with the attached
> trackpad device.
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
Applied, thank you.
> ---
> drivers/input/mouse/Makefile | 2 +-
> drivers/input/mouse/cyapa.c | 22 ++
> drivers/input/mouse/cyapa.h | 15 +
> drivers/input/mouse/cyapa_gen5.c | 69 +++-
> drivers/input/mouse/cyapa_gen6.c | 727
> +++
> 5 files changed, 831 insertions(+), 4 deletions(-)
> create mode 100644 drivers/input/mouse/cyapa_gen6.c
>
> diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
> index 793300b..ee6a6e9 100644
> --- a/drivers/input/mouse/Makefile
> +++ b/drivers/input/mouse/Makefile
> @@ -24,7 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
> obj-$(CONFIG_MOUSE_SYNAPTICS_USB)+= synaptics_usb.o
> obj-$(CONFIG_MOUSE_VSXXXAA) += vsxxxaa.o
>
> -cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o
> +cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o cyapa_gen6.o
> psmouse-objs := psmouse-base.o synaptics.o focaltech.o
>
> psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index 4f0d76e..dbb53eb 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -41,6 +41,9 @@ static int cyapa_reinitialize(struct cyapa *cyapa);
>
> bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
> {
> + if (cyapa->gen == CYAPA_GEN6 && cyapa->state == CYAPA_STATE_GEN6_BL)
> + return true;
> +
> if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_BL)
> return true;
>
> @@ -49,6 +52,9 @@ bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
>
> bool cyapa_is_pip_app_mode(struct cyapa *cyapa)
> {
> + if (cyapa->gen == CYAPA_GEN6 && cyapa->state == CYAPA_STATE_GEN6_APP)
> + return true;
> +
> if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
> return true;
>
> @@ -204,6 +210,15 @@ static int cyapa_get_state(struct cyapa *cyapa)
> if (!error)
> goto out_detected;
> }
> + if (cyapa->gen == CYAPA_GEN_UNKNOWN ||
> + cyapa->gen == CYAPA_GEN6 ||
> + cyapa->gen == CYAPA_GEN5) {
> + error = cyapa_pip_state_parse(cyapa,
> + status, BL_STATUS_SIZE);
> + if (!error)
> + goto out_detected;
> + }
> + /* For old Gen5 trackpads detecting. */
> if ((cyapa->gen == CYAPA_GEN_UNKNOWN ||
> cyapa->gen == CYAPA_GEN5) &&
> !smbus && even_addr) {
> @@ -300,6 +315,9 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
> return error;
>
> switch (cyapa->gen) {
> + case CYAPA_GEN6:
> + cyapa->ops = &cyapa_gen6_ops;
> + break;
> case CYAPA_GEN5:
> cyapa->ops = &cyapa_gen5_ops;
> break;
> @@ -579,6 +597,8 @@ static int cyapa_initialize(struct cyapa *cyapa)
> error = cyapa_gen3_ops.initialize(cyapa);
> if (!error)
> error = cyapa_gen5_ops.initialize(cyapa);
> + if (!error)
> + error = cyapa_gen6_ops.initialize(cyapa);
> if (error)
> return error;
>
> @@ -1136,9 +1156,11 @@ static char *cyapa_state_to_string(struct cyapa *cyapa)
> case CYAPA_STATE_BL_ACTIVE:
> return "bootloader active";
> case CYAPA_STATE_GEN5_BL:
> + case CYAPA_STATE_GEN6_BL:
> return "bootloader";
> case CYAPA_STATE_OP:
> case CYAPA_STATE_GEN5_APP:
> + case CYAPA_STATE_GEN6_APP:
> return "operational"; /* Normal valid state. */
> default:
> return "invalid mode";
> diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
> index d019d1d..3a211c0 100644
> --- a/drivers/input/mouse/cyapa.h
> +++ b/drivers/input/mouse/cyapa.h
> @@ -19,6 +19,7 @@
> #define CYAPA_GEN_UNKNOWN 0x00 /* unknown protocol. */
> #define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */
> #define CYAPA_GEN5 0x05 /* support TrueTouch GEN5 trackpad device. */
> +#define CYAPA_GEN6 0x06 /* support TrueTouch GEN6 trackpad device. */
>
> #define CYAPA_NAME "Cypress APA Trackpad (cyapa)"
>
> @@ -198,6 +199,9 @@
> #define PIP_BL_APP_INFO_RESP_LENGTH 30
> #define PIP_BL_GET_INFO_RESP_LENGTH 19
>
>
Re: [PATCH v1 1/7] input: cyapa: change strings of gen5 to pip in the name when they are shared
On Mon, Jun 15, 2015 at 05:01:31PM +0800, Dudley Du wrote:
> Change strings 'gen5' to 'pip' for all macros, variables and functions when
> they are shared in gen5 and gen6 modules. The change of these strings is
> aimed to keep name definition much more clear and readable.
> Also the spelling errors are fix in this patch.
> TEST=test on Chromebook.
>
> Signed-off-by: Dudley Du
Applied, thank you.
> ---
> drivers/input/mouse/cyapa.c | 34 +-
> drivers/input/mouse/cyapa.h | 136 -
> drivers/input/mouse/cyapa_gen3.c |4 +-
> drivers/input/mouse/cyapa_gen5.c | 1103
> ++
> 4 files changed, 673 insertions(+), 604 deletions(-)
>
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index efe1484..4f0d76e 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -6,7 +6,7 @@
> * Daniel Kurtz
> * Benson Leung
> *
> - * Copyright (C) 2011-2014 Cypress Semiconductor, Inc.
> + * Copyright (C) 2011-2015 Cypress Semiconductor, Inc.
> * Copyright (C) 2011-2012 Google, Inc.
> *
> * This file is subject to the terms and conditions of the GNU General Public
> @@ -39,11 +39,27 @@ const char product_id[] = "CYTRA";
>
> static int cyapa_reinitialize(struct cyapa *cyapa);
>
> -static inline bool cyapa_is_bootloader_mode(struct cyapa *cyapa)
> +bool cyapa_is_pip_bl_mode(struct cyapa *cyapa)
> {
> if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_BL)
> return true;
>
> + return false;
> +}
> +
> +bool cyapa_is_pip_app_mode(struct cyapa *cyapa)
> +{
> + if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
> + return true;
> +
> + return false;
> +}
> +
> +static inline bool cyapa_is_bootloader_mode(struct cyapa *cyapa)
> +{
> + if (cyapa_is_pip_bl_mode(cyapa))
> + return true;
> +
> if (cyapa->gen == CYAPA_GEN3 &&
> cyapa->state >= CYAPA_STATE_BL_BUSY &&
> cyapa->state <= CYAPA_STATE_BL_ACTIVE)
> @@ -54,7 +70,7 @@ static inline bool cyapa_is_bootloader_mode(struct cyapa
> *cyapa)
>
> static inline bool cyapa_is_operational_mode(struct cyapa *cyapa)
> {
> - if (cyapa->gen == CYAPA_GEN5 && cyapa->state == CYAPA_STATE_GEN5_APP)
> + if (cyapa_is_pip_app_mode(cyapa))
> return true;
>
> if (cyapa->gen == CYAPA_GEN3 && cyapa->state == CYAPA_STATE_OP)
> @@ -306,7 +322,7 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
>
> /*
> * Returns 0 on device detected, negative errno on no device detected.
> - * And when the device is detected and opertaional, it will be reset to
> + * And when the device is detected and operational, it will be reset to
> * full power active mode automatically.
> */
> static int cyapa_detect(struct cyapa *cyapa)
> @@ -629,15 +645,15 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
> if (device_may_wakeup(dev))
> pm_wakeup_event(dev, 0);
>
> - /* Interrupt event maybe cuased by host command to trackpad device. */
> + /* Interrupt event maybe caused by host command to trackpad device. */
> if (cyapa->ops->irq_cmd_handler(cyapa)) {
> /*
>* Interrupt event maybe from trackpad device input reporting.
>*/
> if (!cyapa->input) {
> /*
> - * Still in probling or in firware image
> - * udpating or reading.
> + * Still in probing or in firmware image
> + * updating or reading.
>*/
> cyapa->ops->sort_empty_output_data(cyapa,
> NULL, NULL, NULL);
> @@ -1051,12 +1067,12 @@ static ssize_t cyapa_update_fw_store(struct device
> *dev,
> dev_dbg(dev, "firmware update successfully done.\n");
>
> /*
> - * Redetect trackpad device states because firmware update process
> + * Re-detect trackpad device states because firmware update process
>* will reset trackpad device into bootloader mode.
>*/
> ret = cyapa_reinitialize(cyapa);
> if (ret) {
> - dev_err(dev, "failed to redetect after updated: %d\n", ret);
> + dev_err(dev, "failed to re-detect after updated: %d\n", ret);
> error = error ? error : ret;
> }
>
> diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
> index adc9ed5..d019d1d 100644
> --- a/drivers/input/mouse/cyapa.h
> +++ b/drivers/input/mouse/cyapa.h
> @@ -3,7 +3,7 @@
> *
> * Author: Dudley Du
> *
> - * Copyright (C) 2014 Cypress Semiconductor, Inc.
> + * Copyright (C) 2014-2015 Cypress Semiconductor, Inc.
> *
> * This file is subject to the terms and conditions of the GNU General Public
> * License. See the file COPYING in the main directory of this archive for
> @@ -25,7 +25,7 @@
> /*
[PATCH] firmware: qcom: scm: Convert to platform driver
This patch creates a platform driver for the SCM so that we can adequately
manage resources. This removes clients having to carry the necessary
clocks to use the SCM resources.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/firmware/qcom,scm.txt | 25
drivers/firmware/qcom_scm.c| 138 +++-
2 files changed, 159 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
new file mode 100644
index 000..debcd32
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -0,0 +1,25 @@
+QCOM Secure Channel Manager (SCM)
+
+Qualcomm processors include an interface to communicate to the secure firmware.
+This interface allows for clients to request different types of actions. These
+can include CPU power up/down, HDCP requests, loading of firmware, and other
+assorted actions.
+
+Required properties:
+- compatible: must contain "qcom,scm"
+- clocks: Should contain the core, iface, and bus clocks.
+- clock-names: Must contain "core" for the core clock, "iface" for the
interface
+ clock and "bus" for the bus clock.
+
+Example:
+
+ firmware {
+ compatible = "simple-bus";
+
+ scm {
+ compatible = "qcom,scm";
+ clocks = <&gcc GCC_CE1_CLK> , <&gcc GCC_CE1_AXI_CLK>,
<&gcc GCC_CE1_AHB_CLK>;
+ clock-names = "core", "bus", "iface";
+ };
+ };
+
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 45c008d..5dd0514 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -15,14 +15,57 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
*/
-
+#include
+#include
+#include
#include
#include
#include
#include
+#include
+#include
#include "qcom_scm.h"
+struct qcom_scm {
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *bus_clk;
+};
+
+static struct qcom_scm *__scm;
+
+static int qcom_scm_clk_enable(void)
+{
+ int ret;
+
+ ret = clk_prepare_enable(__scm->core_clk);
+ if (ret)
+ goto bail;
+ ret = clk_prepare_enable(__scm->iface_clk);
+ if (ret)
+ goto disable_core;
+ ret = clk_prepare_enable(__scm->bus_clk);
+ if (ret)
+ goto disable_iface;
+
+ return 0;
+
+disable_iface:
+ clk_disable_unprepare(__scm->iface_clk);
+disable_core:
+ clk_disable_unprepare(__scm->core_clk);
+bail:
+ return ret;
+}
+
+static void qcom_scm_clk_disable(void)
+{
+ clk_disable_unprepare(__scm->core_clk);
+ clk_disable_unprepare(__scm->iface_clk);
+ clk_disable_unprepare(__scm->bus_clk);
+}
+
/**
* qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
* @entry: Entry point function for the cpus
@@ -72,11 +115,17 @@ EXPORT_SYMBOL(qcom_scm_cpu_power_down);
*/
bool qcom_scm_hdcp_available(void)
{
- int ret;
+ int ret = qcom_scm_clk_enable();
+
+ if (ret)
+ goto clk_err;
ret = __qcom_scm_is_call_available(QCOM_SCM_SVC_HDCP,
- QCOM_SCM_CMD_HDCP);
+ QCOM_SCM_CMD_HDCP);
+
+ qcom_scm_clk_disable();
+clk_err:
return (ret > 0) ? true : false;
}
EXPORT_SYMBOL(qcom_scm_hdcp_available);
@@ -91,6 +140,87 @@ EXPORT_SYMBOL(qcom_scm_hdcp_available);
*/
int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
{
- return __qcom_scm_hdcp_req(req, req_cnt, resp);
+ int ret = qcom_scm_clk_enable();
+
+ if (ret)
+ return ret;
+
+ ret = __qcom_scm_hdcp_req(req, req_cnt, resp);
+ qcom_scm_clk_disable();
+ return ret;
}
EXPORT_SYMBOL(qcom_scm_hdcp_req);
+
+/**
+ * qcom_scm_is_available() - Checks if SCM is available
+ */
+bool qcom_scm_is_available(void)
+{
+ return !!__scm;
+}
+EXPORT_SYMBOL(qcom_scm_is_available);
+
+static int qcom_scm_remove(struct platform_device *pdev)
+{
+ __scm = NULL;
+
+ return 0;
+}
+
+static int qcom_scm_probe(struct platform_device *pdev)
+{
+ struct qcom_scm *scm;
+ int ret;
+
+ scm = devm_kzalloc(&pdev->dev, sizeof(*scm), GFP_KERNEL);
+ if (!scm)
+ return -ENOMEM;
+
+ scm->core_clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(scm->core_clk)) {
+ if (PTR_ERR(scm->core_clk) != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "failed to acquire core clk\n");
+ return PTR_ERR(scm->core_clk);
+ }
+
+ scm->iface_clk = devm_clk_get(&pdev->dev, "iface");
+ if (IS_ERR(scm->iface_clk)) {
+ if (PTR_ERR(scm->iface_clk) != -EPROBE_DEFER)
+ dev_err(&pdev->de
Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus
On 07/20/2015 02:35 PM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
+ nvec: nvec@45 {
+ compatible = "nvidia,nvec-slave";
+ reg = <0x45>;
I think you need to or in I2C_OWN_SLAVE_ADDRESS from
here?
--
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/4] staging/nvec: reimplement on top of tegra i2c driver
On 07/20/2015 02:35 PM, Andrey Danin wrote: Remove i2c controller related code and use tegra i2c driver in slave mode. Update nvec documentation. diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt I would expect this patch to add a new binding file nvidia,nvec-slave.txt so that the filename continues to match the compatible value it documents. This patch introduces a new binding for the NVEC slave as opposed to modifying the existing binding. +- compatible : should be "nvidia,nvec-slave". +- reg: the i2c address of the slave controller I think "the I2C address to respond to" would be clearer? You might also mention that this needs to include flags from . -- 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 RFC V1 2/3] rtc: da9063: Add DA9062 RTC capability to DA9063 RTC driver
On 20/07/2015 at 17:57:50 +, Opensource [Steve Twiss] wrote :
> On 18 July 2015 00:45, Alexandre Belloni wrote:
> > On 09/07/2015 at 08:45:53 +0100, S Twiss wrote :
> > > - Addition of a re-try when reading the RTC inside da9063_rtc_read_time()
> >
> > Can you separate that change in another patch as it is a change in the
> > behaviour of the driver? And maybe give a word or two on why this is
> > needed.
>
> Sure.
>
> I will separate this into a new patch and add it at a later date. It is a
> recommendation
> to have this in for both DA9062/3 now, although I have not seen this happen
> during
> my testing -- it should be added.
> Something similar happened with the RTC previously -- everything tested fine
> with earlier kernels until the RTC core functions were improved and I picked
> up a
> synchronisation problem with my testing:
>
> http://lxr.free-electrons.com/source/drivers/rtc/rtc-da9063.c#L129
>
> [...]
>
> > > diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c
> > > index 7ffc570..e94fb6d 100644
> > > --- a/drivers/rtc/rtc-da9063.c
> > > +++ b/drivers/rtc/rtc-da9063.c
> > > @@ -1,127 +1,274 @@
> > > -/* rtc-da9063.c - Real time clock device driver for DA9063
> > > - * Copyright (C) 2013-14 Dialog Semiconductor Ltd.
> > > +/*
> > > + * Real time clock device driver for DA9063/DA9062
> > > + * Copyright (C) 2013-15 Dialog Semiconductor Ltd.
> > > *
> > > - * This library is free software; you can redistribute it and/or
> > > - * modify it under the terms of the GNU Library General Public
> > > - * License as published by the Free Software Foundation; either
> > > - * version 2 of the License, or (at your option) any later version.
> > > + * 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; either version 2
> > > + * of the License, or (at your option) any later version.
> > > *
> > > - * This library is distributed in the hope that it will be useful,
> > > + * 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
> > > - * Library General Public License for more details.
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > */
> > >
> >
> > Please also list that license change in the commit log. It should also
> > probably be separated in another patch.
> >
>
> I can add this to a different patch and change it at a later date.
> It is to fix a minor wording problem with the GPL header so it matches the
> correct
> MODULE_LICENSE(""); macro.
>
> https://lkml.org/lkml/2015/4/18/19
>
> The info at the top of the file needs to remove the LGPL worded text where
> appropriate:
> words such as "Library" from the line "GNU Library General Public License";
> and replace
> the word "library" with "program" in several places
>
Yeah, I understood the change, it can go in as soon as you send the
patch.
>
> > > + return -ENXIO;
> > > +
> > > + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
> > > + if (!rtc)
> > > + return -ENOMEM;
> > > +
> > > + if (strncmp(match->name, "dlg,da9063-rtc", 14) == 0) {
> >
> > You must not do that.
> > You should add a new compatible and change the of_compatible string of
> > the mfd_cell in drivers/mfd/da9063-core.c onc you know the variant.
>
> I can check for a binary comparison against the address of the
> static const struct of_device_id da9063_compatible_reg_id_table[] = {}
> entry for DA9063.
You also must not compare pointers that way. You can use
of_device_is_compatible().
> The DA9063 driver already associates "dlg,da9063-rtc" with both BB and AD
> register maps. I think that altering the string at this point would break
> backwards
> compatibility in the device tree for the DA9063.
I'm not fond of the backward compatibility exactly for that kind of
issue. The proper way to handle it is to have tow different compatible
strings because obviously, the BB and AD variants are not compatible.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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/4] i2c: tegra: implement slave mode
Initialization code is based on NVEC driver.
There is a HW bug in AP20 that was also mentioned in kernel sources
for Toshiba AC100.
Signed-off-by: Andrey Danin
---
Changes for v3:
- handle 10-bit clients properly
Changes for v2:
- remove hack from tegra_i2c_clock_disable
- replace slave status helper functions with local variables
- add constant for default delay count value
- add 10-bit address support
- remove read_slave_start_delay init as zero
- don't reset controller during slave registration
- slave isr returns int instead of bool
- make status related variables in slave u32 instead of unsigned int
- enable i2c slave in Kconfig
- rebase on top of new i2c slave framework
- delay workaround was added from nvec
Signed-off-by: Andrey Danin
---
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-tegra.c | 119 +
2 files changed, 120 insertions(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0b798ae..3c02041 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -888,6 +888,7 @@ config I2C_SUN6I_P2WI
config I2C_TEGRA
tristate "NVIDIA Tegra internal I2C controller"
depends on ARCH_TEGRA
+ select I2C_SLAVE
help
If you say yes to this option, support will be included for the
I2C controller embedded in NVIDIA Tegra SOCs
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 78a3668..f6ecd28 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -42,8 +42,17 @@
#define I2C_SL_CNFG0x020
#define I2C_SL_CNFG_NACK (1<<1)
#define I2C_SL_CNFG_NEWSL (1<<2)
+#define I2C_SL_RCVD0x024
+#define I2C_SL_STATUS 0x028
+#define I2C_SL_ST_IRQ (1<<3)
+#define I2C_SL_ST_END_TRANS(1<<4)
+#define I2C_SL_ST_RCVD (1<<2)
+#define I2C_SL_ST_RNW (1<<1)
#define I2C_SL_ADDR1 0x02c
#define I2C_SL_ADDR2 0x030
+#define I2C_SL_ADDR2_TEN_BIT_MODE 1
+#define I2C_SL_DELAY_COUNT 0x03c
+#define I2C_SL_DELAY_COUNT_DEFAULT 0x1E
#define I2C_TX_FIFO0x050
#define I2C_RX_FIFO0x054
#define I2C_PACKET_TRANSFER_STATUS 0x058
@@ -125,6 +134,8 @@ enum msg_end_type {
* @clk_divisor_std_fast_mode: Clock divisor in standard/fast mode. It is
* applicable if there is no fast clock source i.e. single clock
* source.
+ * @slave_read_start_delay: Workaround for AP20 I2C Slave Controller bug. Delay
+ * before writing data byte into register I2C_SL_RCVD.
*/
struct tegra_i2c_hw_feature {
@@ -133,6 +144,7 @@ struct tegra_i2c_hw_feature {
bool has_single_clk_source;
int clk_divisor_hs_mode;
int clk_divisor_std_fast_mode;
+ int slave_read_start_delay;
};
/**
@@ -173,6 +185,7 @@ struct tegra_i2c_dev {
int msg_read;
u32 bus_clk_rate;
bool is_suspended;
+ struct i2c_client *slave;
};
static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val, unsigned long
reg)
@@ -461,12 +474,78 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
return err;
}
+static void tegra_i2c_slave_write(struct tegra_i2c_dev *i2c_dev, u32 val)
+{
+ i2c_writel(i2c_dev, val, I2C_SL_RCVD);
+
+ /*
+* TODO: A correct fix needs to be found for this.
+*
+* We experience less incomplete messages with this delay than without
+* it, but we don't know why. Help is appreciated.
+*/
+ udelay(100);
+}
+
+static int tegra_i2c_slave_isr(int irq, struct tegra_i2c_dev *i2c_dev)
+{
+ u32 status;
+ u8 value;
+ u8 dummy;
+ u32 is_slave_irq, is_read, is_trans_start, is_trans_end;
+
+ if (!i2c_dev->slave || !i2c_dev->slave->slave_cb)
+ return -EINVAL;
+
+ status = i2c_readl(i2c_dev, I2C_SL_STATUS);
+
+ is_slave_irq = (status & I2C_SL_ST_IRQ);
+ is_read = (status & I2C_SL_ST_RNW);
+ is_trans_start = (status & I2C_SL_ST_RCVD);
+ is_trans_end = (status & I2C_SL_ST_END_TRANS);
+
+ if (!is_slave_irq)
+ return -EINVAL;
+
+ /* master sent stop */
+ if (is_trans_end) {
+ i2c_slave_event(i2c_dev->slave, I2C_SLAVE_STOP, &dummy);
+ if (!is_trans_start)
+ return 0;
+ }
+
+ if (is_read) {
+ /* i2c master reads data from us */
+ i2c_slave_event(i2c_dev->slave,
+ is_trans_start ? I2C_SLAVE_READ_REQUESTED
+ : I2C_SLAVE_READ_PROCESSED,
+ &value);
+
Re: [PATCH v8 6/9] nvmem: qfprom: Add Qualcomm QFPROM support.
On 07/20/2015 07:44 AM, Srinivas Kandagatla wrote: This patch adds QFPROM support driver which is used by other drivers like thermal sensor and cpufreq. On MSM parts there are some efuses (called qfprom) these fuses store things like calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would read out this data for configuring the driver. Signed-off-by: Srinivas Kandagatla One comment below, otherwise Reviewed-by: Stephen Boyd diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c new file mode 100644 index 000..ba5e2b4 --- /dev/null +++ b/drivers/nvmem/qfprom.c @@ -0,0 +1,86 @@ +/* + * Copyright (C) 2015 Srinivas Kandagatla + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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 This include is used? -- Qualcomm Innovation Center, Inc. is a member of 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] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
On 20.07.2015 16:15, Jingoo Han wrote:
On Thursday, July 16, 2015 5:01 PM, Jacek Anaszewski wrote:
On 07/15/2015 10:02 PM, Bjorn Andersson wrote:
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
drivers/leds/Kconfig | 8 ---
drivers/leds/Makefile | 1 -
drivers/video/backlight/Kconfig| 8 +++
drivers/video/backlight/Makefile | 1 +
.../backlight/pm8941-wled.c} | 59
++
6 files changed, 36 insertions(+), 46 deletions(-)
rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c}
(90%)
Acked-by: Jacek Anaszewski
If you are not an author of this driver or a maintainer affected by this patch,
Just 'Reviewed-by' looks good.
I am a LED subsystem maintainer.
--
Best Regards,
Jacek Anaszewski
--
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 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
On 07/20/2015 07:43 AM, Srinivas Kandagatla wrote:
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
new file mode 100644
index 000..bde5528
--- /dev/null
+++ b/drivers/nvmem/core.c
@@ -0,0 +1,384 @@
+
+static int nvmem_add_cells(struct nvmem_device *nvmem,
+ const struct nvmem_config *cfg)
+{
+ struct nvmem_cell **cells;
+ const struct nvmem_cell_info *info = cfg->cells;
+ int i, rval;
+
+ cells = kzalloc(sizeof(*cells) * cfg->ncells, GFP_KERNEL);
kcalloc?
+ if (!cells)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->ncells; i++) {
+ cells[i] = kzalloc(sizeof(**cells), GFP_KERNEL);
+ if (!cells[i]) {
+ rval = -ENOMEM;
+ goto err;
+ }
+
+ rval = nvmem_cell_info_to_nvmem_cell(nvmem, &info[i], cells[i]);
+ if (IS_ERR_VALUE(rval)) {
+ kfree(cells[i]);
+ goto err;
+ }
+
+ nvmem_cell_add(cells[i]);
+ }
+
+ nvmem->ncells = cfg->ncells;
+ /* remove tmp array */
+ kfree(cells);
+
+ return 0;
+err:
+ while (--i)
+ nvmem_cell_drop(cells[i]);
+
+ return rval;
+}
+
+/**
+ * nvmem_register() - Register a nvmem device for given nvmem_config.
+ * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
+ *
+ * @config: nvmem device configuration with which nvmem device is created.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer to nvmem_device
+ * on success.
+ */
+
Why the newline?
+struct nvmem_device *nvmem_register(const struct nvmem_config *config)
+{
+ struct nvmem_device *nvmem;
+ struct device_node *np;
+ struct regmap *rm;
+ int rval;
+
+ if (!config->dev)
+ return ERR_PTR(-EINVAL);
+
+ rm = dev_get_regmap(config->dev, NULL);
+ if (!rm) {
+ dev_err(config->dev, "Regmap not found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
+ if (!nvmem)
+ return ERR_PTR(-ENOMEM);
+
+ nvmem->id = ida_simple_get(&nvmem_ida, 0, 0, GFP_KERNEL);
+ if (nvmem->id < 0) {
+ kfree(nvmem);
+ return ERR_PTR(nvmem->id);
Oops, we already freed nvmem.
+ }
+
+ nvmem->regmap = rm;
+ nvmem->owner = config->owner;
+ nvmem->stride = regmap_get_reg_stride(rm);
+ nvmem->word_size = regmap_get_val_bytes(rm);
+ nvmem->size = regmap_get_max_register(rm) + nvmem->stride;
+ nvmem->dev.type = &nvmem_provider_type;
+ nvmem->dev.bus = &nvmem_bus_type;
+ nvmem->dev.parent = config->dev;
+ np = config->dev->of_node;
+ nvmem->dev.of_node = np;
+ dev_set_name(&nvmem->dev, "%s%d",
+config->name ? : "nvmem", config->id);
+
+ nvmem->read_only = np ? of_property_read_bool(np, "read-only") : 0;
of_property_read_bool(NULL, ..) "does the right thing" and returns false
already.
+
+ nvmem->read_only |= config->read_only;
+
+ device_initialize(&nvmem->dev);
+
+ dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name);
+
+ rval = device_add(&nvmem->dev);
+ if (rval) {
+ ida_simple_remove(&nvmem_ida, nvmem->id);
+ kfree(nvmem);
+ return ERR_PTR(rval);
+ }
+
+ if (device_create_bin_file(&nvmem->dev,
+ nvmem->read_only ? &bin_attr_ro_nvmem :
+ &bin_attr_rw_nvmem))
+ dev_warn(&nvmem->dev, "Failed to create sysfs binary file\n");
Why can't we have device_add() add the binary file attribute too?
+
+ if (config->cells)
+ nvmem_add_cells(nvmem, config);
+
+ return nvmem;
+}
+EXPORT_SYMBOL_GPL(nvmem_register);
+
+/**
+ * nvmem_unregister() - Unregister previously registered nvmem device
+ *
+ * @nvmem: Pointer to previously registered nvmem device.
+ *
+ * Return: Will be an negative on error or a zero on success.
+ */
+int nvmem_unregister(struct nvmem_device *nvmem)
+{
+ mutex_lock(&nvmem_mutex);
+ if (nvmem->users) {
+ mutex_unlock(&nvmem_mutex);
+ return -EBUSY;
+ }
+ mutex_unlock(&nvmem_mutex);
This lock doesn't seem to be doing anything in this patch? Perhaps it
should be added in the second patch where consumers start making it useful?
--
Qualcomm Innovation Center, Inc. is a member of 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 RFC V1 3/3] devicetree: da9062: Add device tree bindings for DA9062 RTC
Hi, On 20/07/2015 at 17:08:00 +, Opensource [Steve Twiss] wrote : > If I miss out the compatible line for the RTC in the DTSI for DA9062, or is I > alter it > so it does not match the string specified in the DA9063 RTC driver, the > DA9063 RTC > driver will not be probed for the DA9062 compatibility. > The RTC compatible = "dlg,da9062-rtc" is essential in this case. > You are right. Disregard my comment. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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/4] arm: tegra: implement NVEC driver using tegra i2c.
This version (v3) is for pushing tegra i2c driver to i2c tree. NVEC driver will be reworked later to use i2c core slave framework. NVEC driver contains code to manage tegra i2c controller in slave mode. I2C slave support was implemented in linux kernel. The goal of this patch serie is to implement I2C slave mode in tegra drived and rework NVEC driver to use it. Patches are based on i2c for-next. Changes for v3: - rebase on top of i2c for-next tree - fix 10-bit address condition in tegra i2c driver Changes for v2: - rebased on top of new i2c slave framework. - old code is removed in separate patch - documentation patch is integrated to main nvec patch Thanks in advance *** BLURB HERE *** Andrey Danin (4): i2c: tegra: implement slave mode staging/nvec: reimplement on top of tegra i2c driver staging/nvec: remove old code dt: paz00: define nvec as child of i2c bus .../devicetree/bindings/nvec/nvidia,nvec.txt | 21 +- arch/arm/boot/dts/tegra20-paz00.dts| 22 +- drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-tegra.c | 119 ++ drivers/staging/nvec/nvec.c| 411 +++-- drivers/staging/nvec/nvec.h| 10 - 6 files changed, 269 insertions(+), 315 deletions(-) -- 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 v3 3/4] staging/nvec: remove old code
Signed-off-by: Andrey Danin
---
No changes for v3
No changes for v2
Signed-off-by: Andrey Danin
---
drivers/staging/nvec/nvec.c | 211
1 file changed, 211 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 7da3dfe..fc0ee5c 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -516,23 +516,6 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
schedule_work(&nvec->rx_work);
}
-#if 0
-/**
- * nvec_invalid_flags - Send an error message about invalid flags and jump
- * @nvec: The nvec device
- * @status: The status flags
- * @reset: Whether we shall jump to state 0.
- */
-static void nvec_invalid_flags(struct nvec_chip *nvec, unsigned int status,
- bool reset)
-{
- dev_err(nvec->dev, "unexpected status flags 0x%02x during state %i\n",
- status, nvec->state);
- if (reset)
- nvec->state = 0;
-}
-#endif /* FIXME: remove old code */
-
/**
* nvec_tx_set - Set the message to transfer (nvec->tx)
* @nvec: A &struct nvec_chip
@@ -562,200 +545,6 @@ static void nvec_tx_set(struct nvec_chip *nvec)
(uint)nvec->tx->size, nvec->tx->data[1]);
}
-
-#if 0
-/**
- * nvec_interrupt - Interrupt handler
- * @irq: The IRQ
- * @dev: The nvec device
- *
- * Interrupt handler that fills our RX buffers and empties our TX
- * buffers. This uses a finite state machine with ridiculous amounts
- * of error checking, in order to be fairly reliable.
- */
-static irqreturn_t nvec_interrupt(int irq, void *dev)
-{
- unsigned long status;
- unsigned int received = 0;
- unsigned char to_send = 0xff;
- const unsigned long irq_mask = I2C_SL_IRQ | END_TRANS | RCVD | RNW;
- struct nvec_chip *nvec = dev;
- unsigned int state = nvec->state;
-
- status = readl(nvec->base + I2C_SL_STATUS);
-
- /* Filter out some errors */
- if ((status & irq_mask) == 0 && (status & ~irq_mask) != 0) {
- dev_err(nvec->dev, "unexpected irq mask %lx\n", status);
- return IRQ_HANDLED;
- }
- if ((status & I2C_SL_IRQ) == 0) {
- dev_err(nvec->dev, "Spurious IRQ\n");
- return IRQ_HANDLED;
- }
-
- /* The EC did not request a read, so it send us something, read it */
- if ((status & RNW) == 0) {
- received = readl(nvec->base + I2C_SL_RCVD);
- if (status & RCVD)
- writel(0, nvec->base + I2C_SL_RCVD);
- }
-
- if (status == (I2C_SL_IRQ | RCVD))
- nvec->state = 0;
-
- switch (nvec->state) {
- case 0: /* Verify that its a transfer start, the rest later */
- if (status != (I2C_SL_IRQ | RCVD))
- nvec_invalid_flags(nvec, status, false);
- break;
- case 1: /* command byte */
- if (status != I2C_SL_IRQ) {
- nvec_invalid_flags(nvec, status, true);
- } else {
- nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
- /* Should not happen in a normal world */
- if (unlikely(nvec->rx == NULL)) {
- nvec->state = 0;
- break;
- }
- nvec->rx->data[0] = received;
- nvec->rx->pos = 1;
- nvec->state = 2;
- }
- break;
- case 2: /* first byte after command */
- if (status == (I2C_SL_IRQ | RNW | RCVD)) {
- udelay(33);
- if (nvec->rx->data[0] != 0x01) {
- dev_err(nvec->dev,
- "Read without prior read command\n");
- nvec->state = 0;
- break;
- }
- nvec_msg_free(nvec, nvec->rx);
- nvec->state = 3;
- nvec_tx_set(nvec);
- BUG_ON(nvec->tx->size < 1);
- to_send = nvec->tx->data[0];
- nvec->tx->pos = 1;
- } else if (status == (I2C_SL_IRQ)) {
- BUG_ON(nvec->rx == NULL);
- nvec->rx->data[1] = received;
- nvec->rx->pos = 2;
- nvec->state = 4;
- } else {
- nvec_invalid_flags(nvec, status, true);
- }
- break;
- case 3: /* EC does a block read, we transmit data */
- if (status & END_TRANS) {
- nvec_tx_completed(nvec);
- } else if ((status & RNW) == 0 || (status & RCVD)) {
- nvec_invalid_flags(nvec, status, true);
- } else i
[PATCH v3 2/4] staging/nvec: reimplement on top of tegra i2c driver
Remove i2c controller related code and use tegra i2c driver in slave mode.
Update nvec documentation.
Signed-off-by: Andrey Danin
---
Changes for v3:
- resolve conflict: 'nvec != NULL' changed to '!nvec'
Changes for v2:
- remove extra new line
- keep old functions to simplify review
- move nvec_state enum to nvec.c
- use nvec-slave instead of nvec in dts to keep ABI compatibility
- rebased on top of new i2c slave framework
- delay workaround moved to tegra-i2c
- documentation patch is integrated in this commit
- reverted a log message to minimize changes
Signed-off-by: Andrey Danin
---
.../devicetree/bindings/nvec/nvidia,nvec.txt | 21 +-
drivers/staging/nvec/nvec.c| 258 +
drivers/staging/nvec/nvec.h| 10 -
3 files changed, 169 insertions(+), 120 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
index 5ae601e..aba34095 100644
--- a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
+++ b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
@@ -1,21 +1,6 @@
NVIDIA compliant embedded controller
Required properties:
-- compatible : should be "nvidia,nvec".
-- reg : the iomem of the i2c slave controller
-- interrupts : the interrupt line of the i2c slave controller
-- clock-frequency : the frequency of the i2c bus
-- gpios : the gpio used for ec request
-- slave-addr: the i2c address of the slave controller
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- Tegra20/Tegra30:
- - div-clk
- - fast-clk
- Tegra114:
- - div-clk
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2c
+- compatible : should be "nvidia,nvec-slave".
+- reg: the i2c address of the slave controller
+- request-gpios : the gpio used for ec request
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 164634d..7da3dfe 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -25,8 +25,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#include
@@ -39,25 +39,19 @@
#include "nvec.h"
-#define I2C_CNFG 0x00
-#define I2C_CNFG_PACKET_MODE_EN(1<<10)
-#define I2C_CNFG_NEW_MASTER_SFM(1<<11)
-#define I2C_CNFG_DEBOUNCE_CNT_SHIFT12
-
-#define I2C_SL_CNFG0x20
-#define I2C_SL_NEWSL (1<<2)
-#define I2C_SL_NACK(1<<1)
-#define I2C_SL_RESP(1<<0)
-#define I2C_SL_IRQ (1<<3)
-#define END_TRANS (1<<4)
-#define RCVD (1<<2)
-#define RNW(1<<1)
-
-#define I2C_SL_RCVD0x24
-#define I2C_SL_STATUS 0x28
-#define I2C_SL_ADDR1 0x2c
-#define I2C_SL_ADDR2 0x30
-#define I2C_SL_DELAY_COUNT 0x3c
+
+#define I2C_SL_ST_END_TRANS(1<<4)
+#define I2C_SL_ST_IRQ (1<<3)
+#define I2C_SL_ST_RCVD (1<<2)
+#define I2C_SL_ST_RNW (1<<1)
+
+
+enum nvec_state {
+ ST_NONE,
+ ST_RX,
+ ST_TX,
+ ST_TRANS_START,
+};
/**
* enum nvec_msg_category - Message categories for nvec_msg_alloc()
@@ -479,7 +473,7 @@ static void nvec_tx_completed(struct nvec_chip *nvec)
nvec->tx->pos = 0;
nvec_gpio_set_value(nvec, 0);
} else {
- nvec->state = 0;
+ nvec->state = ST_NONE;
}
}
@@ -497,7 +491,7 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
(uint) nvec->rx->pos);
nvec_msg_free(nvec, nvec->rx);
- nvec->state = 0;
+ nvec->state = ST_NONE;
/* Battery quirk - Often incomplete, and likes to crash */
if (nvec->rx->data[0] == NVEC_BAT)
@@ -514,7 +508,7 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
spin_unlock(&nvec->rx_lock);
- nvec->state = 0;
+ nvec->state = ST_NONE;
if (!nvec_msg_is_event(nvec->rx))
complete(&nvec->ec_transfer);
@@ -522,6 +516,7 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
schedule_work(&nvec->rx_work);
}
+#if 0
/**
* nvec_invalid_flags - Send an error message about invalid flags and jump
* @nvec: The nvec device
@@ -536,6 +531,7 @@ static void nvec_invalid_flags(struct nvec_chip *nvec,
unsigned int status,
if (reset)
nvec->state = 0;
}
+#endif /* FIXME: remove old code */
/**
* nvec_tx_set - Set the message to transfer (nvec->tx)
@@ -566,6 +562,8 @@ static void nvec_tx_set(struct nvec_chip *nvec)
(uint)nvec->tx->size, nvec->tx->data[1]);
}
+
+#if 0
Re: [PATCH] ARM: dts: omap5-uevm: Add Palmas power button support
On 07/20/2015 04:07 PM, Aparna Balasubramanian wrote:
> Palmas on OMAP5uevm has support for power button, so enable it.
>
> Signed-off-by: Aparna Balasubramanian
> ---
>
> Based on kernel tag 4.2.0-rc1 and test result log is at
> http://pastebin.ubuntu.com/11910178/
>
> arch/arm/boot/dts/omap5-uevm.dts |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts
> b/arch/arm/boot/dts/omap5-uevm.dts
> index 275618f..3cc8f35 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -510,6 +510,13 @@
> };
> };
> };
> +
> + palmas_power_button: palmas_power_button {
> + compatible = "ti,palmas-pwrbutton";
> + interrupt-parent = <&palmas>;
> + interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
> + wakeup-source;
> + };
> };
>
> twl6040: twl@4b {
>
Tested (with evtest) and verified on v4.2-rc3
Acked-by: Nishanth Menon
--
Regards,
Nishanth Menon
--
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: dts: sun4i: Add Iteaduino Plus A10
Iteaduino Plus A10 is a breakout board + Itead Core A10. It features 1GB RAM,
has most of the A10 pins on a .1" header, 2 USB ports, 1 OTG USB port,
Ethernet, HDMI, SATA, Speaker/Microphone 3.5mm jacks and an SD card slot.
Signed-off-by: Josef Gajdusek
---
It does not look like there are any other breakout boards for Core A10/A20
modules.
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun4i-a10-itead-iteaduino-plus.dts| 202 +
2 files changed, 203 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index adb1826..564d5a8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -529,6 +529,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-hackberry.dtb \
sun4i-a10-hyundai-a7hd.dtb \
sun4i-a10-inet97fv2.dtb \
+ sun4i-a10-itead-iteaduino-plus.dts \
sun4i-a10-jesurun-q5.dtb \
sun4i-a10-marsboard.dtb \
sun4i-a10-mini-xplus.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
new file mode 100644
index 000..985e155
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
@@ -0,0 +1,202 @@
+/*
+ * Copyright 2015 Josef Gajdusek
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Iteaduino Plus A10";
+ compatible = "itead,iteaduino-plus-a10", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&ahci {
+ target-supply = <®_ahci_5v>;
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_pins_a>;
+ phy = <&phy1>;
+ status = "okay";
+};
+
+&emac_sram {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&ir0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_rx_pins_a>;
+ status = "okay";
+};
+
+&mdio {
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+
[PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
Signed-off-by: Andrey Danin
---
No changes for v3:
Changes for v2:
- swap reg and request-gpios properties
- use nvec-slave instead of nvec to keep ABI compatibility
- place doc in separate patch
Signed-off-by: Andrey Danin
---
arch/arm/boot/dts/tegra20-paz00.dts | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index ed7e100..cd5e6ef 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -288,20 +288,16 @@
clock-frequency = <10>;
};
- nvec@7000c500 {
- compatible = "nvidia,nvec";
- reg = <0x7000c500 0x100>;
- interrupts = ;
- #address-cells = <1>;
- #size-cells = <0>;
+ i2c@7000c500 {
+ status = "okay";
clock-frequency = <8>;
- request-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
- slave-addr = <138>;
- clocks = <&tegra_car TEGRA20_CLK_I2C3>,
-<&tegra_car TEGRA20_CLK_PLL_P_OUT3>;
- clock-names = "div-clk", "fast-clk";
- resets = <&tegra_car 67>;
- reset-names = "i2c";
+
+ nvec: nvec@45 {
+ compatible = "nvidia,nvec-slave";
+ reg = <0x45>;
+ request-gpios = <&gpio TEGRA_GPIO(V, 2)
+ GPIO_ACTIVE_HIGH>;
+ };
};
i2c@7000d000 {
--
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] ARM: dts: omap5-uevm: Add Palmas power button support
Palmas on OMAP5uevm has support for power button, so enable it.
Signed-off-by: Aparna Balasubramanian
---
Based on kernel tag 4.2.0-rc1 and test result log is at
http://pastebin.ubuntu.com/11910178/
arch/arm/boot/dts/omap5-uevm.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 275618f..3cc8f35 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -510,6 +510,13 @@
};
};
};
+
+ palmas_power_button: palmas_power_button {
+ compatible = "ti,palmas-pwrbutton";
+ interrupt-parent = <&palmas>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ };
};
twl6040: twl@4b {
--
1.7.9.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 00/11] i2c: pxa: Fixes, cleanup and support for pxa910 family
Vaibhav Hiremath writes: > On Monday 20 July 2015 12:39 PM, Vaibhav Hiremath wrote: >> >> >> On Monday 20 July 2015 12:36 PM, Vaibhav Hiremath wrote: >>> >>> >>> On Saturday 18 July 2015 01:19 AM, Robert Jarzmik wrote: Vaibhav Hiremath writes: >> So, I applied patches 1-6 to for-next to make some progress. >> >> The others need more thought because of the bindings which shall be >> discussed replying to the patches in question. >> >> Thanks for the updated work with lots of proper references. >> > > OK, Thanks and no issues. > > Lets discuss more on the bindings. I made a simple try on my reference platform with the whole patchset. It oopses on a NULL dereference. The stack is in [1]. I think it boils down to : - i2c_pxa_do_sclk_adj() - reg_ilcr = readl(_ILCR(i2c)); I also think the faulty patch is : - i2c: pxa: Add ILCR (tLow & tHigh) configuration support My case, an I2C master case, I'd like you to find the issue and fix it. >>> >>> Which is this reference platform? >>> Can you share few details - >>> >>> - reference Platform? Mitac Mio A701, pxa270. >>> - DT file if you could None, ran in platform_data mode. >>> - Boot log (if you could) You already found the issue, no need for that anymore. >>> I am using pxa1928 based platform, and I do not see any issues. >> Having said that, >> I see issues in the patch for non PXA910 platform, where >> i2c_pxa_do_sclk_adj() will be called unconditionally and obviously >> reg_ilcr and reg_wcr are not set. Yep. >> I will fix this and send the patch. > > This should fix the issue - Most probably yes. > If you are ok, I will re-spin the patch and submit. Yes, I'm ok, let's try the next iteration. Cheers. -- Robert -- 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 4/7] Documentation: mtd: add a DT property to set the latency code of Spansion memory
On Monday, July 20, 2015 at 11:23:39 AM, Cyrille Pitchen wrote: > Hi Marek, Hi! > Le 16/07/2015 19:44, Marek Vasut a écrit : > > On Thursday, July 16, 2015 at 05:27:51 PM, Cyrille Pitchen wrote: > > > > Hi! > > > >> Both the SPI controller and the NOR flash memory need to agree on the > >> number of dummy cycles to use for Fast Read commands. For Spansion > >> memories, this number of dummy cycles is not given directly but through > >> a so called "latency code". > >> The latency code can be found into the memory datasheet and depends on > >> the SPI clock frequency, the Fast Read op code and the Single/Dual Data > >> Rate mode. > > > > Shouldn't you be able to derive the latency code from the above > > information, which you already know then ? > > Yes I agree with you; this could have been done adding static tables inside > the driver instead of creating a new DT property dedicated to Spansion > memories. OK, I see now. The latency code can not be calculed from "SPI clock frequency, the Fast Read op code and the Single/Dual Data Rate mode" easily, you need to index into some table to obtain some ad-hoc value. Got it. Sorry for the noise! > When I wrote this patch, I had a close look at the s25fl512s datasheet but > only overviewed few datasheets for other Spansion QSPI flash memories. So > I don't know whether a single latency code table could be shared among all > Spansion memories or many tables should be added to support different > memory models. > > That's why I've chosen to add a dedicated DT property to support Spansion > memories as it avoids to add tables to guess the proper latency code to be > used. I thought it would be more flexible. > > Maybe I will remove the support of Spansion QSPI memories from this series > for now. Their support can still be implemented later. > > Anyway, thanks for your review :) Let's wait for more comments :) Best regards, Marek Vasut -- 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/2] iio: light: opt3001: Add device tree binding documentation
Hi Jon, On 07/19/2015 08:17 AM, Jonathan Cameron wrote: > On 05/07/15 15:09, Jonathan Cameron wrote: >> On 02/07/15 23:27, Andreas Dannenberg wrote: >>> Signed-off-by: Andreas Dannenberg >> Utterly standard binding so unless someone shouts, I'll pick this >> up with the driver. > Applied to the togreg branch of iio.git - initially pushed > out as testing for the autobuilders to play with it. Thanks. Found it on the 'testing' branch, pulled the entire branch, and successfully re-ran all my HW tests without any findings. Regards, Andreas -- Andreas Dannenberg Texas Instruments Inc. -- 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 v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter
On Fri, May 08, 2015 at 10:41:12AM +0200, Jean-Francois Moine wrote:
> +
> + if (!priv->is_hdmi_sink
> + || !encoder->crtc)
> + return NULL;
That's weird indentation.
> + list_for_each_entry(connector, &drm->mode_config.connector_list, head) {
> + if (connector->encoder == encoder)
> + return connector->eld;
> + }
What guarantees that connector->eld stays valid after it's returned?
> +struct tda998x_ops_s {
> + u8 *(*get_eld)(struct device *dev);
Why _ops_s - what does the _s mean? If it's sound perhaps it makes
sense to spell it out so people aren't guessing.
> +int tda9998x_codec_register(struct device *dev,
> + struct tda998x_audio_s *tda998x_audio_i,
> + struct tda998x_ops_s *tda998x_ops);
> +void tda9998x_codec_unregister(struct device *dev);
I'd expect these to be internal to the DRM driver.
> +config SND_SOC_TDA998X
> + def_tristate y
> + select SND_PCM_ELD
> + depends on DRM_I2C_NXP_TDA998X
> +
def_tristate y? Why?
> +/* functions in tda998x_drv */
> +static struct tda998x_ops_s *tda998x_ops;
I'd expect this to be stored in the driver data rather than a static
global, what if a system has two HDMI outputs?
> +static int tda998x_codec_startup(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + u8 *eld;
> +
> + eld = tda998x_ops->get_eld(dai->dev);
> + if (!eld)
> + return -ENODEV;
> + return snd_pcm_hw_constraint_eld(runtime, eld);
> +}
Do we really need a device specific mechanism for fishing the ELD out of
the graphics code? I'd have expected this to be more generic.
> +/* ask the HDMI transmitter to activate the audio input port */
> +static int tda998x_codec_hw_params(struct snd_pcm_substream *substream,
> +struct snd_pcm_hw_params *params,
> +struct snd_soc_dai *dai)
> +{
> + return tda998x_ops->set_audio_input(dai->dev, dai->id,
> + params_rate(params));
> +}
The set_audio_input() function doesn't appear to have anything that
checks if the device is busy before enabling things, what happens if the
user tries to switch between I2S and S/PDIF? It looks like only one DAI
can be active at once.
> + for (i = 0, p_dai = dais; i < ndais ; i++, p_dai++) {
> + memcpy(p_dai, &tda998x_dai_i2s, sizeof(*p_dai));
> + p_dai->id = i;
> + if (tda998x_audio->port_types[i] == AFMT_SPDIF) {
> + p_dai->name = "spdif-hifi";
> + p_dai->playback.stream_name = "HDMI SPDIF Playback";
> + p_dai->playback.channels_max = 2;
> + p_dai->playback.rate_min = 22050;
> + }
> + }
It would be a bit clearer if the template were just a template and this
copying initialised both I2S and S/PDIF specific settings.
> + return snd_soc_register_codec(dev,
> + &tda998x_codec_drv,
> + dais, ndais);
> +}
> +EXPORT_SYMBOL(tda9998x_codec_register);
ASoC is all EXPORT_SYMBOL_GPL, you shouldn't reexport functionality with
plain EXPORT_SYMBOL.
signature.asc
Description: Digital signature
RE: [PATCH RFC V1 2/3] rtc: da9063: Add DA9062 RTC capability to DA9063 RTC driver
On 18 July 2015 00:45, Alexandre Belloni wrote:
> On 09/07/2015 at 08:45:53 +0100, S Twiss wrote :
> > From: S Twiss
> >
> > Add DA9062 RTC support into the existing DA9063 RTC 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 RTC. The changes are slightly complicated by requiring support for
> > three register sets: DA9063-AD, DA9063-BB and DA9062-AA.
> >
> > The following alterations have been made to the DA9063 RTC:
[...]
> > - Addition of a re-try when reading the RTC inside da9063_rtc_read_time()
>
> Can you separate that change in another patch as it is a change in the
> behaviour of the driver? And maybe give a word or two on why this is
> needed.
Sure.
I will separate this into a new patch and add it at a later date. It is a
recommendation
to have this in for both DA9062/3 now, although I have not seen this happen
during
my testing -- it should be added.
Something similar happened with the RTC previously -- everything tested fine
with earlier kernels until the RTC core functions were improved and I picked up
a
synchronisation problem with my testing:
http://lxr.free-electrons.com/source/drivers/rtc/rtc-da9063.c#L129
[...]
> > Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
> > Kconfig total: 0 errors, 15 warnings, 1600 lines checked
> > rtc-da9063.c total: 0 errors, 0 warnings, 531 lines checked
>
> This is not true, there is a warning:
> WARNING: DT compatible string "dlg,da9062-rtc" appears un-documented
> -- check /home/alex/M/linux/Documentation/devicetree/bindings/
> #275: FILE: drivers/rtc/rtc-da9063.c:171:
> + { .compatible = "dlg,da9062-rtc", .data = &da9062_aa_regs },
>
> patch 3/3 should come before 2/3 if you want to avoid that.
I will re-order the patches accordingly.
[...]
> > diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c
> > index 7ffc570..e94fb6d 100644
> > --- a/drivers/rtc/rtc-da9063.c
> > +++ b/drivers/rtc/rtc-da9063.c
> > @@ -1,127 +1,274 @@
> > -/* rtc-da9063.c - Real time clock device driver for DA9063
> > - * Copyright (C) 2013-14 Dialog Semiconductor Ltd.
> > +/*
> > + * Real time clock device driver for DA9063/DA9062
> > + * Copyright (C) 2013-15 Dialog Semiconductor Ltd.
> > *
> > - * This library is free software; you can redistribute it and/or
> > - * modify it under the terms of the GNU Library General Public
> > - * License as published by the Free Software Foundation; either
> > - * version 2 of the License, or (at your option) any later version.
> > + * 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; either version 2
> > + * of the License, or (at your option) any later version.
> > *
> > - * This library is distributed in the hope that it will be useful,
> > + * 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
> > - * Library General Public License for more details.
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > */
> >
>
> Please also list that license change in the commit log. It should also
> probably be separated in another patch.
>
I can add this to a different patch and change it at a later date.
It is to fix a minor wording problem with the GPL header so it matches the
correct
MODULE_LICENSE(""); macro.
https://lkml.org/lkml/2015/4/18/19
The info at the top of the file needs to remove the LGPL worded text where
appropriate:
words such as "Library" from the line "GNU Library General Public License"; and
replace
the word "library" with "program" in several places
> [...]
>
> > static int da9063_rtc_probe(struct platform_device *pdev)
> > {
> > - struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
> > - struct da9063_rtc *rtc;
> > + struct da9063_compatible_rtc *rtc;
> > + const struct da9063_compatible_rtc_regmap *config;
> > + const struct of_device_id *match;
> > int irq_alarm;
> > u8 data[RTC_DATA_LEN];
> > int ret;
> >
> > - ret = regmap_update_bits(da9063->regmap, DA9063_REG_CONTROL_E,
> > -DA9063_RTC_EN, DA9063_RTC_EN);
> > + match = of_match_node(da9063_compatible_reg_id_table,
> > + pdev->dev.of_node);
> > + if (!match)
>
> This will never happen if you are only probed from DT and this is waht
> you expect now.
Yes, I will change this.
> > + return -ENXIO;
> > +
> > + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
> > + if (!rtc)
> > + return -ENOMEM;
> > +
> > + if (strncmp(match->name, "dlg,da9063-rtc", 14
Re: [PATCH] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
On Mon 20 Jul 07:22 PDT 2015, Jingoo Han wrote:
> On Thursday, July 16, 2015 5:02 AM, Bjorn Andersson wrote:
> >
> > The Qualcomm PM8941 WLED block is used for backlight and should therefor
> > be in the backlight framework and not in the LED framework. This moves
> > the driver and adapts to the backlight api instead.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> > .../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
> > drivers/leds/Kconfig | 8 ---
> > drivers/leds/Makefile | 1 -
> > drivers/video/backlight/Kconfig| 8 +++
> > drivers/video/backlight/Makefile | 1 +
> > .../backlight/pm8941-wled.c} | 59
> > ++
> > 6 files changed, 36 insertions(+), 46 deletions(-)
> > rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c}
> > (90%)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> > b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> > index a85a964d61f5..424f8444a6cd 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> > +++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
>
> Please move this txt file to 'backlight' directory.
>
Of course
[..]
> > diff --git a/drivers/video/backlight/Kconfig
> > b/drivers/video/backlight/Kconfig
> > index 0505b796d743..6c67c5430933 100644
> > --- a/drivers/video/backlight/Kconfig
> > +++ b/drivers/video/backlight/Kconfig
> > @@ -299,6 +299,14 @@ config BACKLIGHT_TOSA
> > If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> > for its backlight
> >
> > +config BACKLIGHT_PM8941_WLED
> > + tristate "Qualcomm PM8941 WLED Driver"
> > + depends on LEDS_CLASS
>
> LEDS_CLASS?
> Please check your patch carefully.
>
Sorry about that.
> One more thing,
> Did you test this patch with the board?
> If not, I will not accept this patch, unless other people send 'Tested-by'.
I've tested the driver on the Sony Xperia Z3 and it visually behaves as
expected.
I'll send you an updated patch shortly.
Thank you,
Bjorn
--
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 RFC V1 3/3] devicetree: da9062: Add device tree bindings for DA9062 RTC
On 18 July 2015 00:48, Alexandre Belloni wrote:
> On 09/07/2015 at 08:45:54 +0100, S Twiss wrote :
> > From: S Twiss
> >
> > Add device tree bindings for the DA9062 RTC driver component
> >
> > Signed-off-by: Steve Twiss
[...]
> > +- rtc : This node defines settings required for the Real-Time Clock
> > associated
> > + with the DA9062. There are currently no entries in this binding, however
> > + compatible = "dlg,da9062-rtc" should be added if a node is created.
[...]
> > @@ -55,6 +60,10 @@ Example:
> > interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > interrupt-controller;
> >
> > + rtc {
> > + compatible = "dlg,da9062-rtc";
> > + };
> > +
>
> Are those subnodes even parsed? As the parent node is not compatible
> with "simple-bus" or "simple-mfd", I guess not. You driver is probed
> from the mfd_cells in da9063-core.c
Hi Alexandre,
If I miss out the compatible line for the RTC in the DTSI for DA9062, or is I
alter it
so it does not match the string specified in the DA9063 RTC driver, the DA9063
RTC
driver will not be probed for the DA9062 compatibility.
The RTC compatible = "dlg,da9062-rtc" is essential in this case.
[...]
Regards,
Stephen
--
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/2] power: reset: at91: add sama5d3 reset function
Hi, On Mon, Jul 20, 2015 at 05:32:05PM +0800, Josh Wu wrote: > This patch introduces a new compatible string: "atmel,sama5d3-rstc" and > new reset function for sama5d3 and later chips. > > As in sama5d3 or later chips, we don't have to shutdown the DDR > controller before reset. Shutdown the DDR controller before reset is a > workaround to avoid DDR signal driving the bus, but since sama5d3 and > later chips there is no such a conflict. > > So in this patch: >1. the sama5d3 reset function only need to write the rstc register > and return. >2. we can remove the code related with sama5d3 DDR controller as > we don't use it at all. > > Signed-off-by: Josh Wu > Acked-by: Nicolas Ferre queued. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v4 2/2] mfd: flexcom: add a driver for Atmel Flexible Serial Communication Unit
Hi all, based on my previous mail, do someone have any idea on how to add support to the Flexcom in the kernel ? We would like to manage the Flexcom separately so we avoid patching 3 existing drivers. Indeed, their associated devices have no need to know whether they're wrapped or not by a Flexcom: the Flexcom itself has no functional impact on the serial controllers it contains. Also, hiding the additional layer of the Flexcom from the USART, SPI and I2C drivers would ease their maintenance: it keeps the design of each IP independent from the others so it would be more easy to add support to future features. Best Regards, Cyrille Le 25/06/2015 12:11, Cyrille Pitchen a écrit : > Hi lee, > > Le 24/06/2015 16:24, Lee Jones a écrit : >> On Mon, 22 Jun 2015, Cyrille Pitchen wrote: >> >>> This driver supports the new Atmel Flexcom. The Flexcom is a wrapper which >>> integrates one SPI controller, one I2C controller and one USART. Only one >>> function can be enabled at a time. This driver selects the function once >>> for all, when the Flexcom is probed, according to the value of the new >>> "atmel,flexcom-mode" device tree property. >>> >>> This driver has chosen to present the Flexcom to the system as a MFD so >>> the implementation is seamless for the existing Atmel SPI, I2C and USART >>> drivers. >> >> No need for this driver. >> >> Just create your 3 platform drivers and get them to read the mode at >> probe time. If the mode isn't the one pertaining to itself return >> -ENODEV and the Device Driver API will attempt the probe the next >> device. Ensure all of the devices have the same compatible string >> i.e. atmel,sama5d2-flexcom. >> > > The main idea of this patch was to hide the Flexcom overlay from the 3 serial > drivers. The Flexcom is a kind of muxer which selects one of the 3 IPs: it > doesn't change the internal of the IPs. For instance, on sama5d2x SoCs, > some SPI controlers are still standalone whereas others are wrapped by a > Flexcom but all these SPI controllers share the same IP version. > > Also, the Flexcom has its own I/O range. Especially, the Flexcom Mode Register > which selects the active peripheral is outside the I/O ranges of the SPI, I2C > or USART IPs. > > The active peripheral must be selected first then its driver can access its > I/O > registers but registers of the other inactive peripherals are still > unavailable > and would be read as zero since their peripherals are still disabled. > That's why the very first version of the driver presented the Flexcom as a > clock because most peripherals can't be used before enabling their clock. > However the Flexcom is not an actual clock so I was told that it would be > better to introduce the Flexcom as an MFD. > > The idea is to separate the serial controller drivers and the Flexcom driver > the same way as a clock driver and a pin controller driver are separated from > the driver of a peripheral which uses them. > > > Best Regards, > > Cyrille > > ___ > 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 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
On Fri, 2015-07-10 at 08:42 +0200, Sascha Hauer wrote: > On Wed, Jul 08, 2015 at 05:41:05PM +0800, Chunfeng Yun wrote: > > Signed-off-by: Chunfeng Yun > > --- > > drivers/usb/phy/Kconfig | 10 + > > drivers/usb/phy/Makefile | 1 + > > drivers/usb/phy/phy-mt65xx-usb3.c | 856 > > ++ > > 3 files changed, 867 insertions(+) > > create mode 100644 drivers/usb/phy/phy-mt65xx-usb3.c > > > > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig > > index 869c0cfcad..66ded00 100644 > > --- a/drivers/usb/phy/Kconfig > > +++ b/drivers/usb/phy/Kconfig > > @@ -152,6 +152,16 @@ config USB_MSM_OTG > > This driver is not supported on boards like trout which > > has an external PHY. > > > > +config USB_MT65XX_USB3_PHY > > + tristate "Mediatek USB3.0 PHY controller Driver" > > + depends on ARCH_MEDIATEK || COMPILE_TEST > > + select USB_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. > > + To compile this driver as a module, choose M here > > + > > config USB_MV_OTG > > tristate "Marvell USB OTG support" > > depends on USB_EHCI_MV && USB_MV_UDC && PM > > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile > > index e36ab1d..414ef57 100644 > > --- a/drivers/usb/phy/Makefile > > +++ b/drivers/usb/phy/Makefile > > @@ -20,6 +20,7 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += > > phy-tegra-usb.o > > obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o > > obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o > > obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o > > +obj-$(CONFIG_USB_MT65XX_USB3_PHY) += phy-mt65xx-usb3.o > > obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o > > obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o > > obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o > > diff --git a/drivers/usb/phy/phy-mt65xx-usb3.c > > b/drivers/usb/phy/phy-mt65xx-usb3.c > > new file mode 100644 > > index 000..38ee6f3 > > --- /dev/null > > +++ b/drivers/usb/phy/phy-mt65xx-usb3.c > > @@ -0,0 +1,856 @@ > > +/* > > + * 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 > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* > > + * relative to MAC base address > > + */ > > +#define SSUSB_USB3_MAC_CSR_BASE(0x1400) > > +#define SSUSB_USB3_SYS_CSR_BASE(0x1400) > > +#define SSUSB_USB2_CSR_BASE(0x2400) > > Please drop the unnecessary braces. > ok > > + > > +/* > > + * for sifslv1 register > > + * relative to USB3_SIF_BASE base address > > + */ > > +#define SSUSB_SIFSLV_IPPC_BASE (0x700) > > + > > +/* > > + * for sifslv2 register > > + * relative to USB3_SIF_BASE base address > > + */ > > +#define SSUSB_SIFSLV_U2PHY_COM_BASE(0x10800) > > +#define SSUSB_SIFSLV_U3PHYD_BASE (0x10900) > > +#define SSUSB_SIFSLV_U2FREQ_BASE (0x10f00) > > +#define SSUSB_USB30_PHYA_SIV_B_BASE(0x10b00) > > +#define SSUSB_SIFSLV_U3PHYA_DA_BASE(0x10c00) > > +#define SSUSB_SIFSLV_SPLLC (0x1) > > + > > +/*port1 refs. +0x800(refer to port0)*/ > > +#define U3P_PORT_OFFSET (0x800)/*based on port0 */ > > +#define U3P_PHY_BASE(index) ((U3P_PORT_OFFSET) * (index)) > > According to my datasheet port(idx) base is at: > > sif_base + 0x800 + 0x100 * idx > > Am I missing something here? Maybe, ssusb_sifslv_u2_phy_com_T28_Xp etc(X = 1,2,3,4) and their interval is 0x800 > > + > > +#define U3P_IP_PW_CTRL0(SSUSB_SIFSLV_IPPC_BASE + 0x) > > +#define CTRL0_IP_SW_RST(0x1 << 0) > > + > > +#define U3P_IP_PW_CTRL1(SSUSB_SIFSLV_IPPC_BASE + 0x0004) > > +#define CTRL1_IP_HOST_PDN (0x1 << 0) > > + > > +#define U3P_IP_PW_CTRL2(SSUSB_SIFSLV_IPPC_BASE + 0x0008) > > +#define CTRL2_IP_DEV_PDN (0x1 << 0) > > + > > +#define U3P_IP_PW_STS1 (SSUSB_SIFSLV_IPPC_BASE + 0x0010) > > +#define STS1_IP_SLEEP_STS (0x1 << 30) > > +#define STS1_U3_MAC_RST(0x1 << 16) > > +#define STS1_SYS125_RST(0x1 << 10) > > +#define STS1_REF_RST (0x1 << 8) > > +#define STS1_SYSPLL_STABLE (0x1 << 0) > > + > > +#define U3P_I
Re: [linux-sunxi] Re: [PATCH v2] mmc: sunxi: Don't start commands while the card is busy
Hi, On 20-07-15 10:00, Maxime Ripard wrote: Hi, On Fri, Jul 10, 2015 at 05:14:44PM +0200, Hans de Goede wrote: Some sdio wifi modules have not been working reliable with the sunxi-mmc host code. This turns out to be caused by it starting new commands while the card signals that it is still busy processing a previous command. This commit fixes this, thereby fixing the wifi reliability issues on the Cubietruck and other sunxi boards using sdio wifi. Reported-by: Eugene K Suggested-by: Eugene K Cc: Eugene K You should use the "real" name here, and not some shortening. I don't know the real name, and AFAIK this is really only important for S-o-b lines. Eugene, care to share your full name with us? Regards, Hans -- 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 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
On Mon, Jul 20, 2015 at 10:51 PM, Yingjoe Chen
wrote:
>
> Hi Daniel, Chunfeng,
>
>
> On Mon, 2015-07-20 at 22:39 +0800, chunfeng yun wrote:
>> Hi,
>>
>> On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
> <...>
>> > > +
>> > > + usb_p1_vbus: fixedregulator@0 {
>> >
>> > Why @0 ?
>> It is the first fixed regulator, so set it to 0 as a index.
>> I will remove it later
>
> Since this name should be unique, I think we should use gpio number as
> address for fixedregulator in case we need other fixedregulators. So
> this could be:
>
> usb_p1_vbus: fixedregulator@130 {
>
> Also, we should sort according to the address(gpio number) for these
> nodes. Does this make sense?
Yes - that makes some sense.
But, a quick check of other "fixedregulator@" nodes in
arch/arm/boot/dts/ shows that mostly they use @0 , @1.
So, I think the original patch is probably fine.
Sorry for the noise,
-Dan
>
> Joe.C
>
>> >
>> > > + compatible = "regulator-fixed";
>> > > + regulator-name = "usb_vbus";
>> > > + regulator-min-microvolt = <500>;
>> > > + regulator-max-microvolt = <500>;
>> > > + gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
>> > > + enable-active-high;
>> > > + };
>
>
--
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/1] ARM: cpuidle: heterogeneous systems extension
This patch is a v3 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/337794.html v2 -> v3: - Added config option to enable multiple drivers explicitly - Added config option to select the maximum number of supported drivers - Dropped RFC status - Rebased against 4.2-rc2 v1 -> v2: - Rebased against 4.0 - Removed DT affinity probe interface - Improved and optimized idle states comparison and cpumask creation - Merged DT idle states vetting code in the ARM CPUidle driver This patch aims at enabling the generic CPUidle driver on ARM systems with heterogeneous idle states. In the CPUidle context the kernel considers cpus equal (and group them together through a CPUidle driver) if they share the same set of idle states. Since the idle states represent the differentiation point when it comes to creating CPUidle drivers (their states and related cpu logical mask), the idle states can be used as a means to create logical masks of cpus for which the CPUidle driver applies. This series introduces a config option to enable multiple drivers support for the ARM generic CPUidle driver and related code that creates cpumasks of cpus sharing same idle states at run-time. The maximum number of supported generic idle drivers can be configured through a Kconfig entry. The code carrying out idle states comparison is completely generic and borrowed from OF unit tests; it overrides the OF API entirely though to carry out properties (ie phandles list) comparison in the fastest possible way. If deemed worthwhile it can be moved to generic OF layer. Tested through several dts idle states permutations on Juno board with CPUidle and related idle states enabled. Cc: Howard Chen Cc: Rob Herring Cc: Kevin Hilman Cc: Sudeep Holla Cc: Lina Iyer Cc: Daniel Kurtz Cc: Daniel Lezcano Cc: Grant Likely Cc: Mathieu Poirier Cc: Mark Rutland Lorenzo Pieralisi (1): drivers: cpuidle: cpuidle-arm: heterogeneous systems extension drivers/cpuidle/Kconfig.arm | 25 + drivers/cpuidle/cpuidle-arm.c | 236 -- 2 files changed, 230 insertions(+), 31 deletions(-) -- 2.2.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 1/1] drivers: cpuidle: cpuidle-arm: heterogeneous systems extension
Some ARM systems (eg big.LITTLE ones) can be composed of CPUs having
different hardware power management configurations and in the context
of CPUidle, different idle states. The generic ARM CPUidle driver
treats all possible CPUs as equal and initializes a common idle driver
through DT idle states for all possible CPUs.
Current driver cannot manage systems where CPUs are heterogeneous
and therefore can have different idle states.
This patch augments the generic ARM CPUidle driver, by adding code and
related config option that at boot allows to initialize CPUidle drivers
by going through the cpu_possible_mask and through DT parsing detects
the cpus sharing the same idle states, thus creating the CPUidle drivers
cpumasks.
The drivers are then initialized through the DT idle states interface,
that parses and initializes the DT idle states for the cpus set in the
drivers cpumasks.
When the newly introduced
ARM_CPUIDLE_MULTIPLE_DRIVERS
config option is selected, this patch instantiates a static array of idle
drivers (configurable through Kconfig), some of which can turn out to be
unused (eg platforms with a set of idle states smaller than the number of
static CPUidle drivers - a CPUidle driver is a set of idle states), and
selects the config option CPU_IDLE_MULTIPLE_DRIVERS by default; this can
cause a little memory overhead, but at the same time allows supporting most
of the current and future ARM platforms through a single generic CPUidle
driver.
Signed-off-by: Lorenzo Pieralisi
Cc: Howard Chen
Cc: Rob Herring
Cc: Kevin Hilman
Cc: Sudeep Holla
Cc: Lina Iyer
Cc: Daniel Kurtz
Cc: Daniel Lezcano
Cc: Grant Likely
Cc: Mathieu Poirier
Cc: Mark Rutland
---
drivers/cpuidle/Kconfig.arm | 25 +
drivers/cpuidle/cpuidle-arm.c | 236 --
2 files changed, 230 insertions(+), 31 deletions(-)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 21340e0..45d78ce 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -11,6 +11,31 @@ config ARM_CPUIDLE
initialized by calling the CPU operations init idle hook
provided by architecture code.
+config ARM_CPUIDLE_MULTIPLE_DRIVERS
+bool "Support multiple Generic ARM/ARM64 CPU idle Drivers"
+ depends on ARM_CPUIDLE && SMP
+ select CPU_IDLE_MULTIPLE_DRIVERS
+ help
+ Select this option to enable initialization of multiple
+ ARM generic CPUidle drivers to support systems having
+ heterogeneous idle states. The sets of idle states are
+ created through probing of firmware idle states and
+ CPUidle drivers corresponding to the idle states sets
+ are initialized through the DT idle states API.
+ Each CPUidle driver manages CPUidle runtime behaviour for
+ a set of logical cpus sharing the same idle states.
+
+config ARM_CPUIDLE_MAX_NR_DRIVERS
+ int "Maximum number of generic ARM CPUidle drivers to support (2 - 4)"
+ depends on ARM_CPUIDLE_MULTIPLE_DRIVERS
+ range 2 4
+ default "2"
+ help
+ Systems with heterogeneous CPUs can require multiple idle
+ drivers to be instantiated according to the sets of idle states
+ provided by the platform firmware. This option defines
+ the maximum number of generic ARM cpuidle drivers supported.
+
config ARM_BIG_LITTLE_CPUIDLE
bool "Support for ARM big.LITTLE processors"
depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 545069d..bd34ec03 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -58,43 +59,15 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
return ret ? -1 : idx;
}
-static struct cpuidle_driver arm_idle_driver = {
- .name = "arm_idle",
- .owner = THIS_MODULE,
- /*
-* State at index 0 is standby wfi and considered standard
-* on all ARM platforms. If in some platforms simple wfi
-* can't be used as "state 0", DT bindings must be implemented
-* to work around this issue and allow installing a special
-* handler for idle state index 0.
-*/
- .states[0] = {
- .enter = arm_enter_idle_state,
- .exit_latency = 1,
- .target_residency = 1,
- .power_usage= UINT_MAX,
- .name = "WFI",
- .desc = "ARM WFI",
- }
-};
-
static const struct of_device_id arm_idle_state_match[] __initconst = {
{ .compatible = "arm,idle-state",
.data = arm_enter_idle_state },
{ },
};
-/*
- * arm_idle_init
- *
- * Registers the arm specific cpuidle driver with the cpuidle
- * framework. It relies
Re: [PATCH v2 4/5] xhci: mediatek: support MTK xHCI host controller
On Mon, 2015-07-13 at 16:52 +0200, John Crispin wrote:
> Hi
>
> there is a cross dependency between the modules. xhci-mtk.ko requires
> xhci.ko to be loaded. however this will look for xhci_mtk_add_ep_quirk()
> which is part of xhci-mtk. the modules will build but are not run time
> loadable.
>
> John
>
I seperate the quirk functions called by xhci_hcd.ko from xhci-mtk.c
into another C file to fix up the issue.
Thanks
> On 08/07/2015 11:41, Chunfeng Yun wrote:
> > MTK xhci host controller defines some extra SW scheduling
> > parameters for HW to minimize the scheduling effort for
> > synchronous and interrupt endpoints. The parameters are
> > put into reseved DWs of slot context and endpoint context
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/host/Kconfig | 9 +
> > drivers/usb/host/Makefile| 1 +
> > drivers/usb/host/xhci-mtk.c | 814
> > +++
> > drivers/usb/host/xhci-mtk.h | 108 ++
> > drivers/usb/host/xhci-ring.c | 35 +-
> > drivers/usb/host/xhci.c | 19 +-
> > drivers/usb/host/xhci.h | 1 +
> > 7 files changed, 980 insertions(+), 7 deletions(-)
> > create mode 100644 drivers/usb/host/xhci-mtk.c
> > create mode 100644 drivers/usb/host/xhci-mtk.h
> >
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index 8afc3c1..2202c68 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -34,6 +34,15 @@ config USB_XHCI_PCI
> > config USB_XHCI_PLATFORM
> > tristate
> >
> > +config USB_XHCI_MTK
> > + tristate "xHCI support for Mediatek MT65xx"
> > + select USB_XHCI_PLATFORM
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + ---help---
> > + Say 'Y' to enable the support for the xHCI host controller
> > + found in Mediatek MT65xx SoCs.
> > + If unsure, say N.
> > +
> > config USB_XHCI_MVEBU
> > tristate "xHCI support for Marvell Armada 375/38x"
> > select USB_XHCI_PLATFORM
> > diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> > index 754efaa..90c6eb2 100644
> > --- a/drivers/usb/host/Makefile
> > +++ b/drivers/usb/host/Makefile
> > @@ -30,6 +30,7 @@ endif
> >
> > obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
> > obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
> > +obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
> >
> > obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
> > obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > new file mode 100644
> > index 000..45f0606
> > --- /dev/null
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -0,0 +1,814 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author:
> > + * Zhigang.Wei
> > + * 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 "xhci.h"
> > +#include "xhci-mtk.h"
> > +
> > +
> > +#define SS_BW_BOUNDARY 51000
> > +/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
> > +#define HS_BW_BOUNDARY 6144
> > +/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
> > +#define FS_PAYLOAD_MAX 188
> > +
> > +/* mtk scheduler bitmasks */
> > +#define EP_BPKTS(p)((p) & 0x3f)
> > +#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
> > +#define EP_BBM(p) ((p) << 11)
> > +#define EP_BOFFSET(p) ((p) & 0x3fff)
> > +#define EP_BREPEAT(p) (((p) & 0x7fff) << 16)
> > +
> > +
> > +struct xhci_hcd_mtk {
> > + struct device *dev;
> > + struct usb_hcd *hcd;
> > + struct mu3h_sch_bw_info *sch_array;
> > + struct regulator *vusb33;
> > + struct regulator *vbus;
> > + struct clk *sys_mac;/* sys and mac clock */
> > +};
> > +
> > +
> > +static int is_fs_or_ls(enum usb_device_speed speed)
> > +{
> > + return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
> > +}
> > +
> > +static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
> > + struct usb_host_endpoint *ep)
> > +{
> > + int bw_index;
> > + int port_id;
> > + struct xhci_virt_device *virt_dev;
> > +
> > + virt_dev = xhci->devs[udev->slot_id];
> > + port_id = virt_dev->real_port;
> > +
> > + if (udev->speed == USB_SPEED_SUPER) {
> > + if (usb_endpoint_dir_out(&ep->desc))
> > + bw_index = (port_id - 1) * 2;
> > + else
> > + bw_index = (port_id - 1) *
Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
Hi Daniel, Chunfeng,
On Mon, 2015-07-20 at 22:39 +0800, chunfeng yun wrote:
> Hi,
>
> On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
<...>
> > > +
> > > + usb_p1_vbus: fixedregulator@0 {
> >
> > Why @0 ?
> It is the first fixed regulator, so set it to 0 as a index.
> I will remove it later
Since this name should be unique, I think we should use gpio number as
address for fixedregulator in case we need other fixedregulators. So
this could be:
usb_p1_vbus: fixedregulator@130 {
Also, we should sort according to the address(gpio number) for these
nodes. Does this make sense?
Joe.C
> >
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "usb_vbus";
> > > + regulator-min-microvolt = <500>;
> > > + regulator-max-microvolt = <500>;
> > > + gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
--
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: [RFC PATCH 0/2] thermal: Add generic devfreq cooling device
Hi Chanwoo,
Chanwoo Choi writes:
> Hi Punit,
>
> On 07/17/2015 07:53 PM, Punit Agrawal wrote:
>> Hi Chanwoo,
>>
>> Chanwoo Choi writes:
>>
>>> This patchset introduce the generic devfreq cooling device for generic
>>> thermal
>>> framework. The devfreq devices are used ad cooling device to reduce the
>>> overheating temperature. This patch is based on
>>> drivers/thermal/cpu_cooling.c.
>>> The devfreq cooling device can change the ragne of the frequency table of
>>> devfreq device according to cooling level in device tree file.
>>>
>>
>> Have you had a look at the devfreq cooling patches from Javi[0][1]? How
>> is the current patchset different?
>
> I didn't see Javi's patchset before. Thanks for your information.
>
> I reviewed ths Javi's patchset. Both Javi's patchset and my patchset
> has same concept except for applying the power allocator thermal governor
> as you below comment.
>
> But, there are some difference.
>
> First,
> I don't add new devfreq API (devfreq_set_max() / devfreq_set_min()).
> The my patchset used existing update_devfreq() to update the
> maximum frequency of devfreq device.
>
Ok.
> Second,
> In my patchset, the devfreq cooling device will be operated
> as existing cpu cooling device. If sensor measure the overheating
> temperature, devfreq cooling device will limit the maximum frequency
> of devfreq device.
Javi's patchset behaves exactly as you describe here.
> As below example, the devicetree file includes
> the overheating temperature information of each trip-point.
> - Javi's patchset used the static power value calculated by
> devfreq_cooling_gen_power_table() instead of temperature.
>
You've got this wrong.
The power table is used to model device power consumption which allows
the device to be used with the power_allocator governor. Refer to the
power_allocator documentation[2] to understand how it is used.
This doesn't change the behaviour when used with other governors.
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/thermal/power_allocator.txt?id=refs/tags/v4.2-rc3
> Third,
> Javi's patchset used the same string of type when calling
> the thermal_of_cooling_device_register()
> - Javi's patchset used always the same "devfreq" string.
> - My patchset used the different "thermal-devfreq-%d" string
> according to each devfreq cooling device.
>
Except for this difference (which needs to be fixed), the current
patchset is a subset of the functionality proposed in [1].
With the merging of the power_allocator governor in v4.2, it makes sense
for the devfreq cooling device to also include support for it -
especially when the functionality is already under discussion on the
list.
As such, it would be great if you could provide feedback on that thread.
Thanks,
Punit
> In my patchset, devfreq cooling device uses the same method
> to determine the throttling situation as existing cpu cooling
> device. It is just my opinion.
>
>>
>> At first glance, it seems that you are not implementing the extensions
>> that allow devfreq cooling devices to be used with power_allocator
>> thermal governor that got merged in v4.2-rc1.
>>
>> Thanks,
>> Punit
>>
>> [0] http://article.gmane.org/gmane.linux.power-management.general/61936
>> [1] http://article.gmane.org/gmane.linux.power-management.general/62417
>
> Thanks,
> Chanwoo Choi
>
>>
>>
>>> To verify the devfreq cooling device driver, I testd it with following
>>> platform:
>>>
>>> For example,
>>> - The Mali GPU of Exynos5433 SoC uses the devfreq framework to support the
>>> DVFS
>>> feature and Exynos5433 contains the G3D (GPU) thermal sensor. Following
>>> example
>>> explain the correlation between mali dt node and thermal sensor/zone.
>>> : thermal sensor : G3D sensor of Samsung Exynos5433 [1][2]
>>> : devfreq cooling device : Mali GPU [3]
>>>
>>> According to the temperature of g3d thermal sensor inclued in Exynos5433,
>>> devfreq cooling device can change the maximum frequency of Mali GPU.
>>>
>>> 1. In Exynos5433-based board dts file, Mali GPU dt node uses the devfreq
>>> framework to suppot the DVFS feature. Following dt node includes the
>>> both 'cooling-cells' and 'operating-points' which means the supported
>>> frequency entries:
>>>
>>> mali: mali@14AC {
>>> compatible = "arm,mali-midgard";
>>> reg = <0x14AC 0x5000>;
>>> interrupts = <0 282 0>, <0 283 0>, <0 281 0>;
>>> interrupt-names = "JOB", "MMU", "GPU";
>>> clocks = <&cmu_g3d CLK_ACLK_G3D>;
>>> clock-names = "clk_mali";
>>> power-domains = <&pd_g3d>;
>>> status = "disabled";
>>>
>>> #cooling-cells = <2>;
>>>
>>> operating-points = <
>>> 70 115
>>> 60 115
>>> 55 1125000
>>> 50 1075000
>>> 42 1025000
>>> 35 1025000
>>>
[PATCH v8 3/9] nvmem: Add nvmem_device based consumer apis.
This patch adds read/write apis which are based on nvmem_device. It is
common that the drivers like omap cape manager or qcom cpr driver to
access bytes directly at particular offset in the eeprom and not from
nvmem cell info in DT. These driver would need to get access to the nvmem
directly, which is what these new APIS provide.
These wrapper apis would help such users to avoid code duplication in
there drivers and also avoid them reading a big eeprom blob and parsing
it internally in there driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/nvmem/core.c | 258 +
include/linux/nvmem-consumer.h | 73
2 files changed, 331 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index de14c36..ac03119 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -419,6 +419,148 @@ static void __nvmem_device_put(struct nvmem_device *nvmem)
mutex_unlock(&nvmem_mutex);
}
+static int nvmem_match(struct device *dev, void *data)
+{
+ return !strcmp(dev_name(dev), data);
+}
+
+static struct nvmem_device *nvmem_find(const char *name)
+{
+ struct device *d;
+
+ d = bus_find_device(&nvmem_bus_type, NULL, (void *)name, nvmem_match);
+
+ if (!d)
+ return NULL;
+
+ return to_nvmem_device(d);
+}
+
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * of_nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev node: Device tree node that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *of_nvmem_device_get(struct device_node *np, const char
*id)
+{
+
+ struct device_node *nvmem_np;
+ int index;
+
+ index = of_property_match_string(np, "nvmem-names", id);
+
+ nvmem_np = of_parse_phandle(np, "nvmem", index);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+
+ return __nvmem_device_get(nvmem_np, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(of_nvmem_device_get);
+#endif
+
+/**
+ * nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev : Device that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *dev_name)
+{
+ if (dev->of_node) { /* try dt first */
+ struct nvmem_device *nvmem;
+
+ nvmem = of_nvmem_device_get(dev->of_node, dev_name);
+
+ if (!IS_ERR(nvmem) || PTR_ERR(nvmem) == -EPROBE_DEFER)
+ return nvmem;
+
+ }
+
+ return nvmem_find(dev_name);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_get);
+
+static int devm_nvmem_device_match(struct device *dev, void *res, void *data)
+{
+ struct nvmem_device **nvmem = res;
+
+ if (WARN_ON(!nvmem || !*nvmem))
+ return 0;
+
+ return *nvmem == data;
+}
+
+static void devm_nvmem_device_release(struct device *dev, void *res)
+{
+ nvmem_device_put(*(struct nvmem_device **)res);
+}
+
+/**
+ * devm_nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device allocated by devm_nvmem_cell_get(),
+ * that needs to be released.
+ */
+void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem)
+{
+ int ret;
+
+ ret = devres_release(dev, devm_nvmem_device_release,
+devm_nvmem_device_match, nvmem);
+
+ WARN_ON(ret);
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_put);
+
+/**
+ * nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device that needs to be released.
+ */
+void nvmem_device_put(struct nvmem_device *nvmem)
+{
+ __nvmem_device_put(nvmem);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_put);
+
+/**
+ * devm_nvmem_device_get() - Get nvmem cell of device form a given id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem name in nvmems property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_cell
+ * on success. The nvmem_cell will be freed by the automatically once the
+ * device is freed.
+ */
+struct nvmem_device *devm_nvmem_device_get(struct device *dev, const char *id)
+{
+ struct nvmem_device **ptr, *nvmem;
+
+ ptr = devres_alloc(devm_nvmem_device_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ nvmem = nvmem_device_get(dev, id);
+ if (!IS_ERR(nvmem)) {
+ *ptr = nvmem;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return nvmem;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_get);
+
static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
{
struct nvmem_cell *cell = NULL;
@@ -780,6 +922,122 @@ int nvmem_cell_write(struct nvmem
[PATCH v8 2/9] nvmem: Add a simple NVMEM framework for consumers
This patch adds just consumers part of the framework just to enable easy
review.
Up until now, nvmem drivers were stored in drivers/misc, where they all
had to duplicate pretty much the same code to register a sysfs file,
allow in-kernel users to access the content of the devices they were
driving, etc.
This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data they
require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from
the nvmems.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla
---
drivers/nvmem/core.c | 415 +
include/linux/nvmem-consumer.h | 61 ++
2 files changed, 476 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index bde5528..de14c36 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -365,6 +365,421 @@ int nvmem_unregister(struct nvmem_device *nvmem)
}
EXPORT_SYMBOL_GPL(nvmem_unregister);
+static struct nvmem_device *__nvmem_device_get(struct device_node *np,
+ struct nvmem_cell **cellp,
+ const char *cell_id)
+{
+ struct nvmem_device *nvmem = NULL;
+
+ mutex_lock(&nvmem_mutex);
+
+ if (np) {
+ nvmem = of_nvmem_find(np);
+ if (!nvmem) {
+ mutex_unlock(&nvmem_mutex);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+ } else {
+ struct nvmem_cell *cell = nvmem_find_cell(cell_id);
+
+ if (cell) {
+ nvmem = cell->nvmem;
+ *cellp = cell;
+ }
+
+ if (!nvmem) {
+ mutex_unlock(&nvmem_mutex);
+ return ERR_PTR(-ENOENT);
+ }
+ }
+
+ nvmem->users++;
+ mutex_unlock(&nvmem_mutex);
+
+ if (!try_module_get(nvmem->owner)) {
+ dev_err(&nvmem->dev,
+ "could not increase module refcount for cell %s\n",
+ nvmem->name);
+
+ mutex_lock(&nvmem_mutex);
+ nvmem->users--;
+ mutex_unlock(&nvmem_mutex);
+
+ return ERR_PTR(-EINVAL);
+ }
+
+ return nvmem;
+}
+
+static void __nvmem_device_put(struct nvmem_device *nvmem)
+{
+ module_put(nvmem->owner);
+ mutex_lock(&nvmem_mutex);
+ nvmem->users--;
+ mutex_unlock(&nvmem_mutex);
+}
+
+static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
+{
+ struct nvmem_cell *cell = NULL;
+ struct nvmem_device *nvmem;
+
+ nvmem = __nvmem_device_get(NULL, &cell, cell_id);
+ if (IS_ERR(nvmem))
+ return ERR_CAST(nvmem);
+
+ return cell;
+}
+
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell. The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+ const char *name)
+{
+ struct device_node *cell_np, *nvmem_np;
+ struct nvmem_cell *cell;
+ struct nvmem_device *nvmem;
+ const __be32 *addr;
+ int rval, len, index;
+
+ index = of_property_match_string(np, "nvmem-cell-names", name);
+
+ cell_np = of_parse_phandle(np, "nvmem-cells", index);
+ if (!cell_np)
+ return ERR_PTR(-EINVAL);
+
+ nvmem_np = of_get_next_parent(cell_np);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+
+ nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
+ if (IS_ERR(nvmem))
+ return ERR_CAST(nvmem);
+
+ addr = of_get_property(cell_np, "reg", &len);
+ if (!addr || (len < 2 * sizeof(int))) {
+ dev_err(&nvmem->dev, "nvmem: invalid reg on %s\n",
+ cell_np->full_name);
+ rval = -EINVAL;
+ goto err_mem;
+ }
+
+ cell = kzalloc(sizeof(*cell), GFP_KERNEL);
+ if (!cell) {
+ rval = -ENOMEM;
+ goto err_mem;
+ }
+
+ cell->nvmem = nvmem;
+ cell->offset = be32_to_cpup(addr++);
+ cell->bytes = be32_to_cpup(addr);
+ cell->name = cell_np->name;
+
+ addr = of_get_prop
Re: [PATCH V4 5/7] i2c: qup: Add bam dma capabilities
Hi Sricharan,
On Thu, 2015-07-09 at 08:55 +0530, Sricharan R wrote:
> QUP cores can be attached to a BAM module, which acts as a dma engine for the
> QUP core. When DMA with BAM is enabled, the BAM consumer pipe transmitted data
> is written to the output FIFO and the BAM producer pipe received data is read
> from the input FIFO.
>
> With BAM capabilities, qup-i2c core can transfer more than 256 bytes, without
> a
> 'stop' which is not possible otherwise.
>
> Signed-off-by: Sricharan R
> ---
> drivers/i2c/busses/i2c-qup.c | 431
> +--
> 1 file changed, 415 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index c0757d9..810b021 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -24,6 +24,11 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
Keep includes sorted alphabetically.
> +#define MX_TX_RX_LEN SZ_64K
> +#define MX_BLOCKS (MX_TX_RX_LEN / QUP_READ_LIMIT)
> +
> +/* Max timeout in ms for 32k bytes */
> +#define TOUT_MAX 300
> +
> struct qup_i2c_block {
> int count;
> int pos;
> @@ -125,6 +143,23 @@ struct qup_i2c_block {
> int config_run;
> };
>
> +struct qup_i2c_tag {
> + u8 *start;
> + dma_addr_t addr;
> +};
> +
> +struct qup_i2c_bam_rx {
> + struct qup_i2c_tag scratch_tag;
> + struct dma_chan *dma_rx;
> + struct scatterlist *sg_rx;
> +};
> +
> +struct qup_i2c_bam_tx {
> + struct qup_i2c_tag footer_tag;
> + struct dma_chan *dma_tx;
> + struct scatterlist *sg_tx;
> +};
> +
The only difference between above 2 structures is name of the fields.
Please, just define one struct qup_i2c_bam and instantiate it twice.
> struct qup_i2c_dev {
> struct device*dev;
> void __iomem*base;
> @@ -154,14 +189,20 @@ struct qup_i2c_dev {
>
> int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
> struct i2c_msg *msg);
> + int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
> + struct i2c_msg *msg);
> +
> /* Current i2c_msg in i2c_msgs */
> int cmsg;
> /* total num of i2c_msgs */
> int num;
>
> - int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
> - struct i2c_msg *msg);
> -
> + /* dma parameters */
> + boolis_dma;
> + struct dma_pool *dpool;
> + struct qup_i2c_tag start_tag;
> + struct qup_i2c_bam_rx brx;
> + struct qup_i2c_bam_tx btx;
> struct completionxfer;
> };
>
> @@ -238,6 +279,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup,
> u32 req_state)
> return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
> }
>
> +static void qup_i2c_flush(struct qup_i2c_dev *qup)
> +{
> + u32 val = readl(qup->base + QUP_STATE);
> +
> + val |= QUP_I2C_FLUSH;
> + writel(val, qup->base + QUP_STATE);
> +}
> +
Used in only one place.
>
> +static void qup_i2c_bam_cb(void *data)
> +{
> + struct qup_i2c_dev *qup = data;
> +
> + complete(&qup->xfer);
> +}
> +
> +void qup_sg_set_buf(struct scatterlist *sg, void *buf, struct qup_i2c_tag
> *tg,
> + unsigned int buflen, struct
> qup_i2c_dev *qup,
> + int map, int dir)
> +{
> + sg_set_buf(sg, buf, buflen);
> + dma_map_sg(qup->dev, sg, 1, dir);
> +
> + if (!map)
> + sg_dma_address(sg) = tg->addr + ((u8 *)buf - tg->start);
Changing DMA address that we just mapped?
> +}
> +
> +static void qup_i2c_rel_dma(struct qup_i2c_dev *qup)
> +{
> + if (qup->btx.dma_tx)
> + dma_release_channel(qup->btx.dma_tx);
> + if (qup->brx.dma_rx)
> + dma_release_channel(qup->brx.dma_rx);
> + qup->btx.dma_tx = NULL;
> + qup->brx.dma_rx = NULL;
> +}
> +
> +static int qup_i2c_req_dma(struct qup_i2c_dev *qup)
> +{
> + if (!qup->btx.dma_tx) {
> + qup->btx.dma_tx = dma_request_slave_channel(qup->dev, "tx");
Please use dma_request_slave_channel_reason() and let deferred probe work.
> + if (!qup->btx.dma_tx) {
> + dev_err(qup->dev, "\n tx channel not available");
> + return -ENODEV;
> + }
> + }
> +
> + if (!qup->brx.dma_rx) {
> + qup->brx.dma_rx = dma_request_slave_channel(qup->dev, "rx");
> + if (!qup->brx.dma_rx) {
> + dev_err(qup->dev, "\n rx channel not available");
> + qup_i2c_rel_dma(qup);
> + return -ENODEV;
> + }
> + }
> + return 0;
> +}
> +
> +static int bam_do_xfer(struct qup_i2c_dev *qup,
[PATCH v8 0/9] Add simple NVMEM Framework via regmap.
Hi Greg,
This patchset adds a new simple NVMEM framework to kernel, and it is tested
with various drivers like "QCOM thermal sensors", "QCOM cpr driver",
"begal bone cape manager" and few more on the way.
Thankyou all for providing inputs and comments on previous versions of this
patchset. Here is the v8 of the patchset addressing all the issues raised as
part of previous versions review.
Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they
all had to duplicate pretty much the same code to register a sysfs file, allow
in-kernel users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
Introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs.
After learning few things about QCOM qfprom and other eeprom/efuses, which
has packed fields at bit level. Which makes it important to add support to
such memories. This version adds support to this type of non volatile
memories by adding support to bit level nvmem-cells.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
patch 1-4 Introduces the NVMEM framework.
Patch 5-6 Adds Qualcomm specific qfprom driver.
Patch 7 migrates an existing driver to nvmem framework.
Patch 8 adds entry in MAINTAINERS.
Its also possible to migrate other nvmem drivers to this framework, and I think
some of them already posted patches based on this framework.
Providers APIs:
nvmem_register/unregister();
Consumers APIs:
Cell based apis for both DT/Non-DT:
nvmem_cell_get()/nvmem_cell_put();
devm_nvmem_cell_get()/devm_nvmem_cell_put();
of_nvmem_cell_get()
nvmem_cell_read()/nvmem_cell_write();
Raw byte access apis for both DT/non-DT.
nvmem_device_get()/nvmem_device_put()
devm_nvmem_device_get()/nvmem_device_put()
of_nvmem_device_get()
nvmem_device_read()/nvmem_device_write();
nvmem_device_cell_read()/nvmem_device_cell_write();
Device Tree:
/* Provider */
qfprom: qfprom@0070 {
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};
tsens_calibration_bckp: calib_bckp@504 {
reg = <0x504 0x11>;
bits = <6 128>
};
pvs_version: pvs-version@6 {
reg = <0x6 0x2>
bit-offset = 7;
bits = <7 2>
};
speed_bin: speed-bin@c{
reg = <0xc 0x1>;
bits = <2 3>;
};
...
};
/* Consumer */
tsens {
...
nvmem-cells = <&tsens_calibration>;
nvmem-cell-names = "calibration";
};
userspace interface: binary file in /sys/bus/nvmem/devices/*/nvmem
ex:
hexdump /sys/bus/nvmem/devices/qfprom0/nvmem
000
*
0a0 db10 2240 e000 0c00 0c00 0c00
000
...
*
0001000
Changes since v7 (https://lwn.net/Articles/650734/)
* Fixed various style and documentation reated comments
from Stephen Boyd, Stephen Wahren and Joe Perches.
* Fixed read-only flag as suggested by Philipp Zabel
* Changed bit level bindings as suggesed by Rob Herring.
Changes since v6 (https://lkml.org/lkml/2015/6/24/325)
* Replaced class usage with bus, suggested by Stephen Boyd.
* various cosmetic and header cleanups suggested by Stefan Wahren
* changed nvmem-cell property to nvmem-cells spotted by Rajendra Nayak
Changes since v5(https://lkml.org/lkml/2015/5/21/643)
* skipped regmap patches which are already merged by Mark.
* Fixed lot of style related comments by Stephen.
* Fixed sunxi driver.
* added devm_* variants requested by Stephen.
* added of_* variants requested by Pantelis Antoniou
* added read_only options for non-dt drivers.
* added basic how-to doc.
Changes since v4(https://lkml.org/lkml/2015/3/30/725)
* rename eeprom to nvmem suggested by Matt Porter
* added bit level support to nvmem cells, if not framework is
not usable for qcom platforms.
* removed ternary operator shortcut suggested by Mark B.
* unified consumer/provider apis for both DT and non-DT.
* added name support for cell.
* added bit level bindings.
*
[PATCH v8 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework
From: Maxime Ripard
Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.
Signed-off-by: Maxime Ripard
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla
---
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
.../bindings/misc/allwinner,sunxi-sid.txt | 17 ---
.../bindings/nvmem/allwinner,sunxi-sid.txt | 21 +++
drivers/misc/eeprom/Kconfig| 13 --
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c| 156
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/sunxi_sid.c | 159 +
9 files changed, 193 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
delete mode 100644
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
create mode 100644 drivers/nvmem/sunxi_sid.c
diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What: /sys/devices/*//eeprom
-Date: August 2013
-Contact: Oliver Schinagl
-Description: read-only access to the SID (Security-ID) on current
- A-series SoC's from Allwinner. Currently supports A10, A10s, A13
- and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
- whereas the newer A20 SoC exposes 512 bytes split into sections.
- Besides the 16 bytes of SID, there's also an SJTAG area,
- HDMI-HDCP key and some custom keys. Below a quick overview, for
- details see the user manual:
- 0x000 128 bit root-key (sun[457]i)
- 0x010 128 bit boot-key (sun7i)
- 0x020 64 bit security-jtag-key (sun7i)
- 0x028 16 bit key configuration (sun7i)
- 0x02b 16 bit custom-vendor-key (sun7i)
- 0x02c 320 bit low general key (sun7i)
- 0x040 32 bit read-control access (sun7i)
- 0x064 224 bit low general key (sun7i)
- 0x080 2304 bit HDCP-key (sun7i)
- 0x1a0 768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
- Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
-- reg: Should contain registers location and length
-
-Example for sun4i:
- sid@01c23800 {
- compatible = "allwinner,sun4i-a10-sid";
- reg = <0x01c23800 0x10>
- };
-
-Example for sun7i:
- sid@01c23800 {
- compatible = "allwinner,sun7i-a20-sid";
- reg = <0x01c23800 0x200>
- };
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
new file mode 100644
index 000..d543ed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example for sun4i:
+ sid@01c23800 {
+ compatible = "allwinner,sun4i-a10-sid";
+ reg = <0x01c23800 0x10>
+ };
+
+Example for sun7i:
+ sid@01c23800 {
+ compatible = "allwinner,sun7i-a20-sid";
+ reg = <0x01c23800 0x200>
+ };
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
If unsure, say N.
-config EEPROM_SUNXI_SID
- tristate "Allwinner sunxi security ID support"
- depends on ARCH_SUNXI && SYSFS
- help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing
[PATCH v8 6/9] nvmem: qfprom: Add Qualcomm QFPROM support.
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store
things like calibration data, speed bins.. etc. Drivers like cpufreq,
thermal sensors would read out this data for configuring the driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/nvmem/Kconfig | 15 +
drivers/nvmem/Makefile | 4 +++
drivers/nvmem/qfprom.c | 86 ++
3 files changed, 105 insertions(+)
create mode 100644 drivers/nvmem/qfprom.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index de90c82..fa85805 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -11,3 +11,18 @@ menuconfig NVMEM
will be called nvmem_core.
If unsure, say no.
+
+if NVMEM
+
+config QCOM_QFPROM
+ tristate "QCOM QFPROM Support"
+ depends on ARCH_QCOM || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via nvmem interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem_qfprom.
+
+endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 6df2c69..ff44fe9 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -4,3 +4,7 @@
obj-$(CONFIG_NVMEM)+= nvmem_core.o
nvmem_core-y := core.o
+
+# Devices
+obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
+nvmem_qfprom-y := qfprom.o
diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
new file mode 100644
index 000..ba5e2b4
--- /dev/null
+++ b/drivers/nvmem/qfprom.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+static struct regmap_config qfprom_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .reg_stride = 1,
+};
+
+static struct nvmem_config econfig = {
+ .name = "qfprom",
+ .owner = THIS_MODULE,
+};
+
+static int qfprom_remove(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+ return nvmem_unregister(nvmem);
+}
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ qfprom_regmap_config.max_register = resource_size(res) - 1;
+
+ regmap = devm_regmap_init_mmio(dev, base, &qfprom_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(regmap);
+ }
+ econfig.dev = dev;
+ nvmem = nvmem_register(&econfig);
+ if (IS_ERR(nvmem))
+ return PTR_ERR(nvmem);
+
+ platform_set_drvdata(pdev, nvmem);
+
+ return 0;
+}
+
+static const struct of_device_id qfprom_of_match[] = {
+ { .compatible = "qcom,qfprom",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+ .probe = qfprom_probe,
+ .remove = qfprom_remove,
+ .driver = {
+ .name = "qcom,qfprom",
+ .of_match_table = qfprom_of_match,
+ },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR("Srinivas Kandagatla ");
+MODULE_DESCRIPTION("Qualcomm QFPROM driver");
+MODULE_LICENSE("GPL v2");
--
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 v8 7/9] nvmem: qfprom: Add bindings for qfprom
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple nvmem framework.
Reviewed-by: Stephen Boyd
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/nvmem/qfprom.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/qfprom.txt
diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt
b/Documentation/devicetree/bindings/nvmem/qfprom.txt
new file mode 100644
index 000..4ad68b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/qfprom.txt
@@ -0,0 +1,35 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+ qfprom: qfprom@0070 {
+ compatible = "qcom,qfprom";
+ reg = <0x0070 0x8000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x4404 0x10>;
+ };
+ };
+
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+ tsens {
+ ...
+ nvmem-cells = <&tsens_calibration>;
+ nvmem-cell-names = "calibration";
+ };
--
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 v8 5/9] Documentation: nvmem: add nvmem api level and how-to doc
This patch add basic how-to and api summary documentation for simple
NVMEM framework.
Signed-off-by: Srinivas Kandagatla
---
Documentation/nvmem/nvmem.txt | 152 ++
1 file changed, 152 insertions(+)
create mode 100644 Documentation/nvmem/nvmem.txt
diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt
new file mode 100644
index 000..dbd40d8
--- /dev/null
+++ b/Documentation/nvmem/nvmem.txt
@@ -0,0 +1,152 @@
+ NVMEM SUBSYSTEM
+ Srinivas Kandagatla
+
+This document explains the NVMEM Framework along with the APIs provided,
+and how to use it.
+
+1. Introduction
+===
+*NVMEM* is the abbreviation for Non Volatile Memory layer. It is used to
+retrieve configuration of SOC or Device specific data from non volatile
+memories like eeprom, efuses and so on.
+
+Before this framework existed, NVMEM drivers like eeprom were stored in
+drivers/misc, where they all had to duplicate pretty much the same code to
+register a sysfs file, allow in-kernel users to access the content of the
+devices they were driving, etc.
+
+This was also a problem as far as other in-kernel users were involved, since
+the solutions used were pretty much different from one driver to another, there
+was a rather big abstraction leak.
+
+This framework aims at solve these problems. It also introduces DT
+representation for consumer devices to go get the data they require (MAC
+Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. This
+framework is based on regmap, so that most of the abstraction available in
+regmap can be reused, across multiple types of buses.
+
+NVMEM Providers
+
+NVMEM provider refers to an entity that implements methods to initialize, read
+and write the non-volatile memory.
+
+2. Registering/Unregistering the NVMEM provider
+===
+
+A NVMEM provider can register with NVMEM core by supplying relevant
+nvmem configuration to nvmem_register(), on success core would return a valid
+nvmem_device pointer.
+
+nvmem_unregister(nvmem) is used to unregister a previously registered provider.
+
+For example, a simple qfprom case:
+
+static struct nvmem_config econfig = {
+ .name = "qfprom",
+ .owner = THIS_MODULE,
+};
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+ ...
+ econfig.dev = &pdev->dev;
+ nvmem = nvmem_register(&econfig);
+ ...
+}
+
+It is mandatory that the NVMEM provider has a regmap associated with its
+struct device. Failure to do would return error code from nvmem_register().
+
+NVMEM Consumers
+
+NVMEM consumers are the entities which make use of the NVMEM provider to
+read from and to NVMEM.
+
+3. NVMEM cell based consumer APIs
+=
+
+NVMEM cells are the data entries/fields in the NVMEM.
+The NVMEM framework provides 3 APIs to read/write NVMEM cells.
+
+struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *name);
+struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *name);
+
+void nvmem_cell_put(struct nvmem_cell *cell);
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
+
+void *nvmem_cell_read(struct nvmem_cell *cell, ssize_t *len);
+int nvmem_cell_write(struct nvmem_cell *cell, void *buf, ssize_t len);
+
+*nvmem_cell_get() apis will get a reference to nvmem cell for a given id,
+and nvmem_cell_read/write() can then read or write to the cell.
+Once the usage of the cell is finished the consumer should call
*nvmem_cell_put()
+to free all the allocation memory for the cell.
+
+4. Direct NVMEM device based consumer APIs
+==
+
+In some instances it is necessary to directly read/write the NVMEM.
+To facilitate such consumers NVMEM framework provides below apis.
+
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
+struct nvmem_device *devm_nvmem_device_get(struct device *dev,
+ const char *name);
+void nvmem_device_put(struct nvmem_device *nvmem);
+int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_write(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+int nvmem_device_cell_write(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+
+Before the consumers can read/write NVMEM directly, it should get hold
+of nvmem_controller from one of the *nvmem_device_get() api.
+
+The difference between these apis and cell based apis is that these apis always
+take nvmem_device as parameter.
+
+5. Releasing a reference to the NVMEM
+=
+
+When a consumers n
[PATCH v8 9/9] nvmem: Add to MAINTAINERS for nvmem framework
This patch adds MAINTAINERS to nvmem framework. Signed-off-by: Srinivas Kandagatla --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..90e0d94 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7263,6 +7263,15 @@ S: Supported F: drivers/block/nvme* F: include/linux/nvme.h +NVMEM FRAMEWORK +M: Srinivas Kandagatla +M: Maxime Ripard +S: Maintained +F: drivers/nvmem/ +F: Documentation/devicetree/bindings/nvmem/ +F: include/linux/nvmem-consumer.h +F: include/linux/nvmem-provider.h + NXP-NCI NFC DRIVER M: Cl??ment Perrochaud R: Charles Gorand -- 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 v8 4/9] nvmem: Add bindings for simple nvmem framework
This patch adds bindings for simple nvmem framework which allows nvmem
consumers to talk to nvmem providers to get access to nvmem cell data.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/nvmem/nvmem.txt | 80 +++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.txt
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt
b/Documentation/devicetree/bindings/nvmem/nvmem.txt
new file mode 100644
index 000..b52bc11
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
@@ -0,0 +1,80 @@
+= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in NVMEMs like eeprom, efuses and so on.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on NVMEM, for the OS to be able to retrieve these information
+and act upon it. Obviously, the OS has to know about where to retrieve
+these data from, and where they are stored on the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+of this node.
+
+Optional properties:
+ read-only: Mark the provider as read only.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in nvmem provider.
+
+Required properties:
+reg: specifies the offset in byte within the storage device.
+
+Optional properties:
+
+bits: Is pair of bit location and number of bits, which specifies offset
+ in bit and number of bits within the address range specified by reg
property.
+ Offset takes values from 0-7.
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@0070 {
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+
+ tsens_calibration_bckp: calib_bckp@504 {
+ reg = <0x504 0x11>;
+ bits = <6 128>
+ };
+
+ pvs_version: pvs-version@6 {
+ reg = <0x6 0x2>
+ bits = <7 2>
+ };
+
+ speed_bin: speed-bin@c{
+ reg = <0xc 0x1>;
+ bits = <2 3>;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells/providers.
+
+Required-properties:
+nvmem-cells: list of phandle to the nvmem data cells.
+nvmem-cell-names: names for the each nvmem-cells specified. Required if
+ nvmem-cells is used.
+
+Optional-properties:
+nvmem : list of phandles to nvmem providers.
+nvmem-names: names for the each nvmem provider. required if nvmem is used.
+
+For example:
+
+ tsens {
+ ...
+ nvmem-cells = <&tsens_calibration>;
+ nvmem-cell-names = "calibration";
+ };
--
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 v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
This patch adds just providers part of the framework just to enable easy
review.
Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
where they all had to duplicate pretty much the same code to register
a sysfs file, allow in-kernel users to access the content of the devices
they were driving, etc.
This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data
they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
from the nvmems.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/nvmem/Kconfig | 13 ++
drivers/nvmem/Makefile | 6 +
drivers/nvmem/core.c | 384 +
include/linux/nvmem-consumer.h | 23 +++
include/linux/nvmem-provider.h | 47 +
7 files changed, 476 insertions(+)
create mode 100644 drivers/nvmem/Kconfig
create mode 100644 drivers/nvmem/Makefile
create mode 100644 drivers/nvmem/core.c
create mode 100644 include/linux/nvmem-consumer.h
create mode 100644 include/linux/nvmem-provider.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 6e973b8..4e2e6aa 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -184,4 +184,6 @@ source "drivers/android/Kconfig"
source "drivers/nvdimm/Kconfig"
+source "drivers/nvmem/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index b64b49f..4c270f5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_NVMEM)+= nvmem/
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
new file mode 100644
index 000..de90c82
--- /dev/null
+++ b/drivers/nvmem/Kconfig
@@ -0,0 +1,13 @@
+menuconfig NVMEM
+ tristate "NVMEM Support"
+ select REGMAP
+ help
+ Support for NVMEM(Non Volatile Memory) devices like EEPROM, EFUSES...
+
+ This framework is designed to provide a generic interface to NVMEM
+ from both the Linux Kernel and the userspace.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem_core.
+
+ If unsure, say no.
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
new file mode 100644
index 000..6df2c69
--- /dev/null
+++ b/drivers/nvmem/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for nvmem drivers.
+#
+
+obj-$(CONFIG_NVMEM)+= nvmem_core.o
+nvmem_core-y := core.o
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
new file mode 100644
index 000..bde5528
--- /dev/null
+++ b/drivers/nvmem/core.c
@@ -0,0 +1,384 @@
+/*
+ * nvmem framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla
+ * Copyright (C) 2013 Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+struct nvmem_device {
+ const char *name;
+ struct regmap *regmap;
+ struct module *owner;
+ struct device dev;
+ int stride;
+ int word_size;
+ int ncells;
+ int id;
+ int users;
+ size_t size;
+ boolread_only;
+};
+
+struct nvmem_cell {
+ const char *name;
+ int offset;
+ int bytes;
+ int bit_offset;
+ int nbits;
+ struct nvmem_device *nvmem;
+ struct list_headnode;
+};
+
+static DEFINE_MUTEX(nvmem_mutex);
+static DEFINE_IDA(nvmem_ida);
+
+static LIST_HEAD(nvmem_cells);
+static DEFINE_MUTEX(nvmem_cells_mutex);
+
+#define to_nvmem_device(d) container_of(d, struct nvmem_device, dev)
+
+static ssize_t bin_attr_nvmem_read(struct file *fil
Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
Hi,
On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
> Hi Chunfeng,
>
> On Wed, Jul 8, 2015 at 5:41 PM, Chunfeng Yun
> wrote:
> > Signed-off-by: Chunfeng Yun
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +++
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi| 27
> > +++
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index f433c21..cb63dc3 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -13,6 +13,7 @@
> > */
> >
> > /dts-v1/;
> > +#include
> > #include "mt8173.dtsi"
> >
> > / {
> > @@ -32,6 +33,15 @@
> > };
> >
> > chosen { };
> > +
> > + usb_p1_vbus: fixedregulator@0 {
>
> Why @0 ?
It is the first fixed regulator, so set it to 0 as a index.
I will remove it later
>
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb_vbus";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > };
> >
> > &pwrap {
> > @@ -211,3 +221,8 @@
> > &uart0 {
> > status = "okay";
> > };
> > +
> > +&usb {
> > + reg-vusb33-supply = <&mt6397_vusb_reg>;
> > + reg-vbus-supply = <&usb_p1_vbus>;
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 0696f8f..452bd0a 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Sort alphabetically, so:
> power before reset
>
Ok
> > #include "mt8173-pinfunc.h"
> >
> > / {
> > @@ -393,6 +394,32 @@
> > #size-cells = <0>;
> > status = "disabled";
> > };
> > +
> > + usb: usb30@1127 {
> > + compatible = "mediatek,mt8173-xhci";
> > + reg = <0 0x1127 0 0x1000>;
> > + interrupts = ;
> > + usb-phy = <&u3phy>;
> > + usb3-lpm-capable;
> > + clocks = <&topckgen CLK_TOP_USB30_SEL>;
> > + clock-names = "sys_mac";
> > + };
> > +
> > + u3phy: usb-phy@11271000 {
> > + compatible = "mediatek,mt8173-u3phy";
> > + reg = <0 0x11271000 0 0x3000>,
> > + <0 0x1128 0 0x2>;
> > + power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> > + usb-wakeup-ctrl = <&pericfg>;
> > + wakeup-src = <1>;
> > + u2port-num = <2>;
>
> Mediatek specific properties should be prefixed with "mediatek,".
> I also find it nicer if you put the standard properties first:
> (compatible, reg, clocks, clock-names, power-domains)
> then device specific properties:
> (usb-wakeup-ctrl, wakeup-src, u2port-num)
> and then the final:
> status="disabled";
>
> This last is currently missing, so please add it, too.
>
I will revise it. Thanks a lot.
> Also, is there some pinctrl settings that must be set for USB?
>
There is no special pinctrl setting for USB on EVB board on which driver
is tested.
> Lastly, I could not quite figure out which patch this set was based on.
> Patch [0] mentions v4.2-rc1, however, the .dts changes in this patch
> did not apply cleanly.
> Perhaps it was based on a particular patch of Matthias tree?
>
Yes, it is.
> Thanks!
> -Dan
>
> > + clocks = <&pericfg CLK_PERI_USB0>,
> > +<&pericfg CLK_PERI_USB1>,
> > +<&apmixedsys CLK_APMIXED_REF2USB_TX>;
> > + clock-names = "wakeup_deb_p0",
> > + "wakeup_deb_p1",
> > + "u3phya_ref";
> > + };
> > };
> > };
> >
> > --
> > 1.8.1.1.dirty
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
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/5] dt-bindings: Add a binding for Mediatek xHCI host controller
On Fri, 2015-07-10 at 11:31 +0300, Roger Quadros wrote:
> Hi,
>
> On 08/07/15 12:41, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > .../devicetree/bindings/usb/mt8173-xhci.txt| 27
> > ++
> > 1 file changed, 27 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..94cec94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,27 @@
> > +MT65XX xhci
> > +
> > +The device node for Mediatek SOC usb3.0 host controller
> > +
> > +Required properties:
> > + - compatible : supports "mediatek,mt8173-xhci"
> > + - reg: Offset and length of registers
> > + - interrupts : Interrupt mode, number and trigger mode
> > + - reg-vusb33-supply: regulator of usb avdd3.3v
> > + - reg-vbus-supply : regulator of vbus;
>
> General trend is to use -supply.
> We already know it is a regulator so no need to add "reg-"
>
> So those two can be
>
> vusb33-supply:
> vbus-supply:
>
Ok, thanks
>
> > + - usb-phy : the phy that xhci will bind
> > + - usb3-lpm-capable: supports USB3 LPM
> > + - clocks : must support all clocks that xhci needs
> > + - clock-names: should be "sys_mac" for sys and mac clocks
> > +
> > +Example:
> > +usb: usb30@1127 {
> > + compatible = "mediatek,mt8173-xhci";
> > + reg = <0 0x1127 0 0x1000>;
> > + interrupts = ;
> > + reg-vusb33-supply = <&mt6397_vusb_reg>;
> > + reg-vbus-supply = <&usb_p1_vbus>;
> > + usb-phy = <&u3phy>;
> > + usb3-lpm-capable;
> > + clocks = <&topckgen CLK_TOP_USB30_SEL>;
> > + clock-names = "sys_mac";
> > +};
> >
>
> cheers,
> -roger
--
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] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
On Thursday, July 16, 2015 5:02 AM, Bjorn Andersson wrote:
>
> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> be in the backlight framework and not in the LED framework. This moves
> the driver and adapts to the backlight api instead.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
> drivers/leds/Kconfig | 8 ---
> drivers/leds/Makefile | 1 -
> drivers/video/backlight/Kconfig| 8 +++
> drivers/video/backlight/Makefile | 1 +
> .../backlight/pm8941-wled.c} | 59
> ++
> 6 files changed, 36 insertions(+), 46 deletions(-)
> rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c}
> (90%)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> index a85a964d61f5..424f8444a6cd 100644
> --- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
Please move this txt file to 'backlight' directory.
> @@ -5,10 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> -- label: The label for this led
> - See Documentation/devicetree/bindings/leds/common.txt
> -- linux,default-trigger: Default trigger assigned to the LED
> - See Documentation/devicetree/bindings/leds/common.txt
> +- label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> - qcom,ext-gen: bool; use externally generated modulator signal to dim
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 9ad35f72ab4c..b8d4b965ca2a 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -578,14 +578,6 @@ config LEDS_VERSATILE
> This option enabled support for the LEDs on the ARM Versatile
> and RealView boards. Say Y to enabled these.
>
> -config LEDS_PM8941_WLED
> - tristate "LED support for the Qualcomm PM8941 WLED block"
> - depends on LEDS_CLASS
> - select REGMAP
> - help
> - This option enables support for the 'White' LED block
> - on Qualcomm PM8941 PMICs.
> -
> comment "LED Triggers"
> source "drivers/leds/trigger/Kconfig"
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 8d6a24a2f513..abe96d960ebe 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -63,7 +63,6 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> obj-$(CONFIG_LEDS_SYSCON)+= leds-syscon.o
> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> -obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
> obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
>
> # LED SPI Drivers
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 0505b796d743..6c67c5430933 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,6 +299,14 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>
> +config BACKLIGHT_PM8941_WLED
> + tristate "Qualcomm PM8941 WLED Driver"
> + depends on LEDS_CLASS
LEDS_CLASS?
Please check your patch carefully.
One more thing,
Did you test this patch with the board?
If not, I will not accept this patch, unless other people send 'Tested-by'.
Best regards,
Jingoo Han
> + select REGMAP
> + help
> + If you have the Qualcomm PM8941, say Y to enable a driver for the
> + WLED block.
> +
> config BACKLIGHT_SAHARA
> tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> depends on X86
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index d67073f9d421..16ec534cff30 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200)+= ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> +obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
> obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> diff --git a/drivers/leds/leds-pm8941-wled.c
> b/drivers/video/backlight/pm8941-wled.c
> similarity index 90%
> rename from drivers/leds/leds-pm8941-wled.c
> rename to drivers/video/backlight/pm8941-wled.c
> index bf64a593fbf1..4f5ae95331a1 100644
> --- a/drivers/leds/leds-pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -11,7 +11,7 @@
> */
>
> #include
Re: [PATCH] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
On Thursday, July 16, 2015 5:01 PM, Jacek Anaszewski wrote:
> On 07/15/2015 10:02 PM, Bjorn Andersson wrote:
> > The Qualcomm PM8941 WLED block is used for backlight and should therefor
> > be in the backlight framework and not in the LED framework. This moves
> > the driver and adapts to the backlight api instead.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> > .../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
> > drivers/leds/Kconfig | 8 ---
> > drivers/leds/Makefile | 1 -
> > drivers/video/backlight/Kconfig| 8 +++
> > drivers/video/backlight/Makefile | 1 +
> > .../backlight/pm8941-wled.c} | 59
> > ++
> > 6 files changed, 36 insertions(+), 46 deletions(-)
> > rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c}
> > (90%)
>
> Acked-by: Jacek Anaszewski
If you are not an author of this driver or a maintainer affected by this patch,
Just 'Reviewed-by' looks good.
Best regards,
Jingoo Han
>
> --
> Best Regards,
> Jacek Anaszewski
--
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/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey
From: S Twiss
Add device tree bindings for the DA9062 OnKey driver component
Signed-off-by: Steve Twiss
---
Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
da9062.txttotal: 0 errors, 0 warnings, 97 lines checked
This patch applies against linux-next and next-20150708
Documentation/devicetree/bindings/mfd/da9062.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
b/Documentation/devicetree/bindings/mfd/da9062.txt
index 5765ed9..7752093 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -5,6 +5,7 @@ DA9062 consists of a large and varied group of sub-devices:
Device Supply NamesDescription
-- ---
da9062-regulator: : LDOs & BUCKs
+da9062-onkey: : On Key
da9062-watchdog : : Watchdog Timer
==
@@ -41,6 +42,18 @@ Sub-nodes:
Documentation/devicetree/bindings/regulator/regulator.txt
+- onkey : This node defines the OnKey settings for controlling the key
+ functionality of the device. The node should contain the compatible property
+ with the value "dlg,da9063-onkey".
+
+ Optional onkey 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.
+
- watchdog: This node defines the settings for the watchdog driver associated
with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
if a node is created.
@@ -59,6 +72,11 @@ Example:
compatible = "dlg,da9062-watchdog";
};
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ dlg,disable-key-power;
+ };
+
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
--
end-of-patch for PATCH V2
--
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 2/3] onkey: da9063: 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
---
Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
Kconfig total: 0 errors, 14 warnings, 810 lines checked
da9063_onkey.ctotal: 0 errors, 2 warnings, 305 lines checked
Changes in V2:
- Altered Kconfig to use the line "Dialog DA9062/63 OnKey"
- Rename of da9063_compatible_onkey_regmap to da906x_chip_config
- char *name changed to const char *name
- Rename struct da9063_compatible_onkey {} back to struct da9063_onkey
This patch applies against linux-next and next-20150708
drivers/input/misc/Kconfig| 8 +--
drivers/input/misc/da9063_onkey.c | 129 ++
2 files changed, 108 insertions(+), 29 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..2610cfa 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 for 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;
+ int onkey_nonkey_lock_mask;
+ int onkey_key_reset_mask;
+ int onkey_shutdown_mask;
+ /* NAMES */
+ const char *name;
+};
struct da9063_onkey {
- struct da9063 *hw;
struct delayed_work work;
struct input_dev *input;
struct device *dev;
+ struct regmap *regmap;
+ const struct da906x_chip_config *config;
+ char phys[32];
bool key_power;
};
+static const struct da906x_chip_config da9063_regs = {
+ /* REGS */
+ .onkey_status = DA9063_REG_STATUS_A,
+ .onkey_pwr_signalling = DA9063_REG_CONTROL_B,
+ .onkey_fault_log = DA9063_REG_FAULT_LOG,
+ .onkey_shutdown = DA9063_REG_CONTROL_F,
+ /* MASKS */
+ .onkey_nonkey_mask = DA9063_NONKEY,
+ .onkey_nonkey_lock_mask = DA9063_NONKEY_LOCK,
+ .onkey_key_reset_mask = DA9063_KEY_RESET,
+ .onkey_shutdown_mask = DA9063_SHUTDOWN,
+ /* NAMES */
+ .name = DA9063_DRVNAME_ONKEY,
+};
+
+static const struct da906x_chip_config da9062_regs = {
+ /* REGS */
+ .onkey_status = DA9062AA_STATUS_A,
+ .onkey_pwr_signalling = DA9062AA_CONTROL_B,
+ .onkey_fault_log = DA9062AA_FAULT_LOG,
+ .onkey_shutdown = DA9062AA_CONTROL_F,
+ /* MASKS */
+ .onkey_nonkey_mask = DA9062AA_NONKEY_MASK,
+ .onkey_nonkey_lock_mask = DA9062AA_NONKEY_LOCK_MASK,
+ .onkey_key_reset_mask = DA9062AA_KEY_RESET_MASK,
+ .onkey_shutdown_mask = DA9062AA_SHUTDOWN_MASK,
+ /* NAMES */
+ .name = "da9062-onkey",
+};
+
+static const struct of_device_id da9063_compatible_reg_id_table[] = {
+ { .compatible = "dlg,da9063-onkey", .data = &da9063_regs },
+ { .compatible = "dlg,da9062-onkey", .data = &da9062_regs },
+ { },
+};
+
static void da9063_poll_on(struct work_struct *work)
{
- struct da9063_onkey *onkey = container_of(work,
[PATCH V2 0/3] da9062: Add DA9062 OnKey support using the existing DA9063 OnKey driver
From: S Twiss This patch set adds OnKey support for the Dialog DA9062 Power Management IC. Changes are made to the existing DA9063 OnKey component so that functionality in this device driver can be re-used to support the DA9062 OnKey. This following patch set re-uses the existing kernel OnKey driver for chips whose OnKey blocks are functionally similar to the DA9063 OnKey. The main points for the MFD core and device tree changes are as follows. - Alteration of the DA9063 OnKey Kconfig needs to be updated to depend on both MFD_DA9063 "or" MFD_DA9062. There is no explicit DA9062 OnKey Kconfig. - The DA9062 MFD core should add a new OnKey resource as usual and an entry in the mfd_cell to support a component name and of_compatible for "da9062-onkey" and "dlg,da9062-onkey". - The device tree binding support should include a compatible string for "dlg,da9062-onkey" The main points for the OnKey changes are as follows: A generic structure is used (called da906x_chip_config) to hold all generic registers and bitmasks for use with this type of OnKey component. Functions in the DA9063 OnKey will be refactored to use this compatibility struct and all accesses to generic registers/masks will be made through this table look-up instead of using defines from the register header files directly Linkage between the DA9062 MFD and the DA9063 OnKey driver is created through the use of an of_match_table entry in the platform_driver structure. A re-work of da9063_onkey_probe() is necessary to use the of_match_node() and dev_get_regmap() functions: this will provide initialisation of the generic registers and masks and allow access to the regmap according to the correct device tree specification. The addition of a of_device_id table for DA9063 and DA9062 default data is created. In this patch set the following is provided: - [PATCH V2 1/3]: MFD changes in DA9062 to support OnKey - [PATCH V2 2/3]: Update existing DA9063 OnKey to add DA9062 support - [PATCH V2 3/3]: Device tree bindings for DA9062 OnKey component This patch applies against linux-next and next-20150708 Thank you, Steve Twiss, Dialog Semiconductor Ltd. S Twiss (3): mfd: da9062: Support for the DA9063 OnKey in the DA9062 core onkey: da9063: Add DA9062 OnKey capability to DA9063 OnKey driver devicetree: da9062: Add device tree bindings for DA9062 OnKey Documentation/devicetree/bindings/mfd/da9062.txt | 18 drivers/input/misc/Kconfig | 8 +- drivers/input/misc/da9063_onkey.c| 129 ++- drivers/mfd/da9062-core.c| 11 ++ 4 files changed, 137 insertions(+), 29 deletions(-) -- end-of-patch for PATCH V2 -- 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/3] mfd: da9062: Support for the DA9063 OnKey in the DA9062 core
From: S Twiss
Add MFD core driver support for a OnKey component
- MFD core adds the resource da9062_onkey_resources[] for the OnKey
- An appropriate value has been added into mfd_cell da9062_devs[] to
support component .name = "da9062-onkey" and
.of_compatible = "dlg,da9062-onkey"
Signed-off-by: Steve Twiss
---
Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
da9062-core.c total: 0 errors, 0 warnings, 523 lines checked
Changes in V2:
- No change
This patch applies against linux-next and next-20150708
drivers/mfd/da9062-core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 4cf0643..0732977 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -118,6 +118,10 @@ static struct resource da9062_wdt_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_WDG_WARN, 1, "WD_WARN", IORESOURCE_IRQ),
};
+static struct resource da9062_onkey_resources[] = {
+ DEFINE_RES_NAMED(DA9062_IRQ_ONKEY, 1, "ONKEY", IORESOURCE_IRQ),
+};
+
static const struct mfd_cell da9062_devs[] = {
{
.name = "da9062-core",
@@ -141,6 +145,13 @@ static const struct mfd_cell da9062_devs[] = {
.resources = da9062_thermal_resources,
.of_compatible = "dlg,da9062-thermal",
},
+ {
+ .name = "da9062-onkey",
+ .num_resources = ARRAY_SIZE(da9062_onkey_resources),
+ .resources = da9062_onkey_resources,
+ .of_compatible = "dlg,da9062-onkey",
+ },
+
};
static int da9062_clear_fault_log(struct da9062 *chip)
--
end-of-patch for PATCH V2
--
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 v13 2/3] drm/i2c: tda998x: Change drvdata for audio extension
The device drvdata is used for component bind, but points to the
encoder/connector structure which is hidden from the slave encoder.
For audio extension, the slave encoder private data must be accessible,
so, this patch changes drvdata to the slave encoder private data and
sets it in case of slave encoder use.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b0a730a..655ebb0 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1453,6 +1453,8 @@ static int tda998x_encoder_init(struct i2c_client *client,
encoder_slave->slave_priv = priv;
encoder_slave->slave_funcs = &tda998x_encoder_slave_funcs;
+ dev_set_drvdata(&client->dev, priv);
+
return 0;
}
@@ -1580,7 +1582,7 @@ static int tda998x_bind(struct device *dev, struct device
*master, void *data)
if (!priv)
return -ENOMEM;
- dev_set_drvdata(dev, priv);
+ dev_set_drvdata(dev, &priv->base);
if (dev->of_node)
crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
@@ -1639,7 +1641,9 @@ err_encoder:
static void tda998x_unbind(struct device *dev, struct device *master,
void *data)
{
- struct tda998x_priv2 *priv = dev_get_drvdata(dev);
+ struct tda998x_priv *priv_s = dev_get_drvdata(dev);
+ struct tda998x_priv2 *priv =
+ container_of(priv_s, struct tda998x_priv2, base);
drm_connector_cleanup(&priv->connector);
drm_encoder_cleanup(&priv->encoder);
--
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 v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter
The tda998x CODEC maintains the audio constraints according to
the HDMI device parameters (EDID) and sets dynamically the input ports
in the TDA998x I2C driver on start/stop audio streaming.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 80 +++
include/sound/tda998x.h | 15 +
sound/soc/codecs/Kconfig | 6 ++
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tda998x.c| 132 ++
5 files changed, 235 insertions(+)
create mode 100644 sound/soc/codecs/tda998x.c
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 655ebb0..90a508f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -758,6 +758,66 @@ tda998x_configure_audio(struct tda998x_priv *priv,
tda998x_write_aif(priv, p);
}
+#if IS_ENABLED(CONFIG_SND_SOC_TDA998X)
+/* tda998x audio codec interface */
+
+/* return the ELD to the CODEC */
+static u8 *tda998x_get_eld(struct device *dev)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct drm_encoder *encoder = priv->encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_connector *connector;
+
+ if (!priv->is_hdmi_sink
+|| !encoder->crtc)
+ return NULL;
+
+ list_for_each_entry(connector, &drm->mode_config.connector_list, head) {
+ if (connector->encoder == encoder)
+ return connector->eld;
+ }
+ return NULL;
+}
+
+/* switch the audio port and initialize the audio parameters for streaming */
+static int tda998x_set_audio_input(struct device *dev,
+ int port_index,
+ unsigned sample_rate)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_encoder_params *p = &priv->params;
+
+ if (!priv->encoder->crtc)
+ return -ENODEV;
+
+ /* if no port, just disable the audio port */
+ if (port_index == PORT_NONE) {
+ reg_write(priv, REG_ENA_AP, 0);
+ return 0;
+ }
+
+ /* if same audio parameters, just enable the audio port */
+ if (p->audio_cfg == priv->audio.ports[port_index] &&
+ p->audio_sample_rate == sample_rate) {
+ reg_write(priv, REG_ENA_AP, p->audio_cfg);
+ return 0;
+ }
+
+ p->audio_format = priv->audio.port_types[port_index];
+ p->audio_clk_cfg = p->audio_format == AFMT_SPDIF ? 0 : 1;
+ p->audio_cfg = priv->audio.ports[port_index];
+ p->audio_sample_rate = sample_rate;
+ tda998x_configure_audio(priv, &priv->encoder->crtc->hwmode, p);
+ return 0;
+}
+
+static struct tda998x_ops_s tda998x_codec_ops = {
+ .get_eld = tda998x_get_eld,
+ .set_audio_input = tda998x_set_audio_input,
+};
+#endif /* SND_SOC */
+
/* DRM encoder functions */
static void tda998x_encoder_set_config(struct tda998x_priv *priv,
@@ -1123,6 +1183,12 @@ tda998x_encoder_get_modes(struct tda998x_priv *priv,
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+
+#if IS_ENABLED(CONFIG_SND_SOC_TDA998X)
+ if (priv->is_hdmi_sink)
+ drm_edid_to_eld(connector, edid);
+#endif
+
kfree(edid);
return n;
@@ -1158,6 +1224,10 @@ static void tda998x_destroy(struct tda998x_priv *priv)
cancel_delayed_work_sync(&priv->dwork);
}
+#if IS_ENABLED(CONFIG_SND_SOC_TDA998X)
+ if (priv->audio.ports[0])
+ tda9998x_codec_unregister(&priv->hdmi->dev);
+#endif
i2c_unregister_device(priv->cec);
}
@@ -1294,6 +1364,9 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
+ priv->params.audio_frame[1] = 1;/* channels - 1 */
+ priv->params.audio_sample_rate = 48000; /* 48kHz */
+
priv->current_page = 0xff;
priv->hdmi = client;
/* CEC I2C address bound to TDA998x I2C addr by configuration pins */
@@ -1407,6 +1480,13 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
priv->params.audio_clk_cfg =
priv->params.audio_format ==
AFMT_SPDIF ? 0 : 1;
+
+#if IS_ENABLED(CONFIG_SND_SOC_TDA998X)
+ /* and create the audio CODEC */
+ tda9998x_codec_register(&client->dev,
+ &priv->audio,
+ &tda998x_codec_ops);
+#endif
[PATCH v13 1/3] drm/i2c: tda998x: Add support of a DT graph of ports
Two kinds of ports may be declared in a DT graph of ports: video and audio.
This patch accepts the port value from a video port as an alternative
to the video-ports property.
It also accepts audio ports in the case the transmitter is not used as
a slave encoder.
The new file include/sound/tda998x.h prepares to the definition of
a tda998x CODEC.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 51
drivers/gpu/drm/i2c/tda998x_drv.c | 90 +++---
include/sound/tda998x.h| 8 ++
3 files changed, 140 insertions(+), 9 deletions(-)
create mode 100644 include/sound/tda998x.h
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..386b6c3 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -16,6 +16,35 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
+ This property is not used when ports are defined.
+
+Optional nodes:
+
+ - port: up to three ports.
+ The ports are defined according to [1].
+
+Video port.
+ There may be only one video port.
+ This one must contain the following property:
+
+ - port-type: must be "rgb"
+
+ and may contain the optional property:
+
+ - reg: 24 bits value which defines how the video controller
+ output is wired to the TDA998x input (video pins)
+ When absent, the default value is <0x230145>.
+
+Audio ports.
+ There may be one or two audio ports.
+ These ones must contain the following properties:
+
+ - port-type: must be "i2s" or "spdif"
+
+ - reg: 8 bits value which defines how the audio controller
+ output is wired to the TDA998x input (audio pins)
+
+[1] Documentation/devicetree/bindings/graph.txt
Example:
@@ -26,4 +55,26 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
+
+ port@230145 {
+ port-type = "rgb";
+ reg = <0x230145>;
+ hdmi_0: endpoint {
+ remote-endpoint = <&lcd0_0>;
+ };
+ };
+ port@3 {/* AP1 = I2S */
+ port-type = "i2s";
+ reg = <0x03>;
+ tda998x_i2s: endpoint {
+ remote-endpoint = <&audio1_i2s>;
+ };
+ };
+ port@4 { /* AP2 = S/PDIF */
+ port-type = "spdif";
+ reg = <0x04>;
+ tda998x_spdif: endpoint {
+ remote-endpoint = <&audio1_spdif1>;
+ };
+ };
};
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 424228b..b0a730a 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
@@ -47,6 +48,8 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ struct tda998x_audio_s audio;
};
#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)->slave_priv)
@@ -774,6 +777,8 @@ static void tda998x_encoder_set_config(struct tda998x_priv
*priv,
(p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
priv->params = *p;
+ priv->audio.port_types[0] = p->audio_format;
+ priv->audio.ports[0] = p->audio_cfg;
}
static void tda998x_encoder_dpms(struct tda998x_priv *priv, int mode)
@@ -1230,9 +1235,57 @@ static struct drm_encoder_slave_funcs
tda998x_encoder_slave_funcs = {
/* I2C driver functions */
+static int tda998x_parse_ports(struct tda998x_priv *priv,
+ struct device_node *np)
+{
+ struct device_node *of_port;
+ const char *port_type;
+ int ret, audio_index, reg, afmt;
+
+ audio_index = 0;
+ for_each_child_of_node(np, of_port) {
+ if (!of_port->name
+|| of_node_cmp(of_port->name, "port") != 0)
+ continue;
+ ret = of_property_read_string(of_port, "port-type",
+ &port_type);
+ if (ret < 0)
+ continue;
+ ret = of_property_read_u32(of_port, "reg", ®);
+ if (strcmp(port_type, "rgb") == 0) {
+ if (!ret) {
[PATCH v13 0/3] ASoC: tda998x: add a codec to the HDMI transmitter
This patch series asks for Russell King's patch http://article.gmane.org/gmane.linux.ports.arm.kernel/411574 drm/edid: add function to help find SADs to be applayed. v13: - rebase on 4.2.0-rc3 - remove Russell's patches v12: - use Russell King's DRM ELD helper (Mark Brown) v11: - reduce the patch series to adding the tda998x codec only v10: - add the generic dt-card - define the audio ports from a DT graph of ports (Russell King) - reuse HDMI constants (Andrew Jackson - Jyri Sarha) - alloc rate_constraints in codec (Jyri Sarha) - fix bad number of channels (Jyri Sarha) - correct codec generation from config (Russell King - Jyri Sarha) - no module init/exit (Russell King) v9: - back to a TDA998x specific CODEC - more comments - change magic values to constants v8: - change some comments about the patches v7: - remove the change of the K predivider (Jyri Sarha) - add S24_3LE and S32_LE as possible audio formats (Jyri Sarha) - don't move the struct priv2 definition and use the slave encoder private data as the device private data (Russell King) - remove the useless request_module (Russell King/Mark Brown) - don't lock the HDMI module (Russell King) - use platform_device_unregister to remove the codec (Russell King) v6: - extend the HDMI CODEC instead of using a specific CODEC v5: - use the TDA998x private data instead of a specific area for the CODEC interface - the CODEC is TDA998x specific (Mark Brown) v4: - remove all the TDA998x specific stuff from the CODEC - move the EDID scan from the CODEC to the TDA998x - move the CODEC to sound/soc (Mark Brown) - update the audio_sample_rate from the EDID (Andrew Jackson) v3: fix bad rate (Andrew Jackson) v2: check double stream start (Mark Brown) Jean-Francois Moine (3): drm/i2c: tda998x: Add support of a DT graph of ports drm/i2c: tda998x: Change drvdata for audio extension ASoC: tda998x: add a codec to the HDMI transmitter .../devicetree/bindings/drm/i2c/tda998x.txt| 51 ++ drivers/gpu/drm/i2c/tda998x_drv.c | 178 +++-- include/sound/tda998x.h| 23 +++ sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda998x.c | 132 +++ 6 files changed, 381 insertions(+), 11 deletions(-) create mode 100644 include/sound/tda998x.h create mode 100644 sound/soc/codecs/tda998x.c -- 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 V3 02/19] memory: tegra: Add MC flush support
On Mon, Jul 20, 2015 at 12:59:41PM +0300, Peter De Schrijver wrote: > On Fri, Jul 17, 2015 at 01:31:24PM +0200, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Fri, Jul 17, 2015 at 01:20:49PM +0300, Peter De Schrijver wrote: > > > On Fri, Jul 17, 2015 at 11:57:55AM +0200, Thierry Reding wrote: > > > > > Old Signed by an unknown key > > > > > > > > On Mon, Jul 13, 2015 at 01:39:40PM +0100, Jon Hunter wrote: > > > > > The Tegra memory controller implements a flush feature to flush > > > > > pending > > > > > accesses and prevent further accesses from occurring. This feature is > > > > > used when powering down IP blocks to ensure the IP block is in a good > > > > > state. The flushes are organised by software groups and IP blocks are > > > > > assigned in hardware to the different software groups. Add helper > > > > > functions for requesting a handle to an MC flush for a given > > > > > software group and enabling/disabling the MC flush itself. > > > > > > > > > > This is based upon a change by Vince Hsu . > > > > > > > > > > Signed-off-by: Jon Hunter > > > > > --- > > > > > drivers/memory/tegra/mc.c | 110 > > > > > ++ > > > > > drivers/memory/tegra/mc.h | 2 + > > > > > include/soc/tegra/mc.h| 34 ++ > > > > > 3 files changed, 146 insertions(+) > > > > > > > > Do we know if this is actually necessary? I remember having a discussion > > > > with Arnd Bergmann a while ago, and the Linux driver model kind of > > > > assumes that by the time a device is disabled all outstanding accesses > > > > will have stopped. > > > > > > > > Do we have a way to determine that this even makes a difference? Can we > > > > trigger a case where not doing this would cause breakage and see that > > > > adding this fixes that particular issue? > > > > > > > > > > Most likely it is. The memory controller can still be processing requests > > > when the peripheral domain is powergated. This would mean the response > > > cannot > > > be delivered in that case. So we need to be sure there are no outstanding > > > requests before shutting down the domain. > > > > My point is that that's the driver's responsibility anyway, hence making > > the explicit flush unnecessary. > > > > The peripheral driver doesn't know how long a request is queued in the memory > controller. So it can't be responsible for ensuring this. Surely whenever the peripheral reports that the operation is done (be that via some DMA controller interrupt or syncpoint increment) the operation would have flushed from the memory controller. Drivers are already supposed to make sure this is the case when they are removed or suspended, so this would mean that we'd be adding all this code for no real gain. It would also explain why we're currently not seeing any such problems. Also note that I'm not saying no to this, I merely want to make sure that it's necessary, and in order to prove so we need tests to produce enough traffic for this to be exposed, and then we can also verify that the patches actually do what they're supposed to. Thierry signature.asc Description: PGP signature
Re: [PATCH v2 1/2] power: reset: at91: add sama5d3 reset function
On 07/20/2015 02:32 AM, Josh Wu wrote:
This patch introduces a new compatible string: "atmel,sama5d3-rstc" and
new reset function for sama5d3 and later chips.
As in sama5d3 or later chips, we don't have to shutdown the DDR
controller before reset. Shutdown the DDR controller before reset is a
workaround to avoid DDR signal driving the bus, but since sama5d3 and
later chips there is no such a conflict.
So in this patch:
1. the sama5d3 reset function only need to write the rstc register
and return.
2. we can remove the code related with sama5d3 DDR controller as
we don't use it at all.
Signed-off-by: Josh Wu
Acked-by: Nicolas Ferre
Reviewed-by: Guenter Roeck
---
Changes in v2:
- aligned the function parameters to be consist with the coding style
- refined the commit log
- add binding document changes
- use of_device_is_compitable() instead
.../devicetree/bindings/arm/atmel-at91.txt | 2 +-
drivers/power/reset/at91-reset.c | 26 --
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt
b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 424ac8c..dd998b9 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -87,7 +87,7 @@ One interrupt per TC channel in a TC block:
RSTC Reset Controller required properties:
- compatible: Should be "atmel,-rstc".
- can be "at91sam9260" or "at91sam9g45"
+ can be "at91sam9260" or "at91sam9g45" or "sama5d3"
- reg: Should contain registers location and length
Example:
diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index 36dc52f..c378d4e 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
@@ -123,6 +123,15 @@ static int at91sam9g45_restart(struct notifier_block
*this, unsigned long mode,
return NOTIFY_DONE;
}
+static int sama5d3_restart(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ writel(cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PERRST |
AT91_RSTC_PROCRST),
+ at91_rstc_base);
+
+ return NOTIFY_DONE;
+}
+
static void __init at91_reset_status(struct platform_device *pdev)
{
u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
@@ -155,13 +164,13 @@ static void __init at91_reset_status(struct
platform_device *pdev)
static const struct of_device_id at91_ramc_of_match[] = {
{ .compatible = "atmel,at91sam9260-sdramc", },
{ .compatible = "atmel,at91sam9g45-ddramc", },
- { .compatible = "atmel,sama5d3-ddramc", },
{ /* sentinel */ }
};
static const struct of_device_id at91_reset_of_match[] = {
{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9260_restart },
{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
+ { .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
{ /* sentinel */ }
};
@@ -181,13 +190,16 @@ static int at91_reset_of_probe(struct platform_device
*pdev)
return -ENODEV;
}
- for_each_matching_node(np, at91_ramc_of_match) {
- at91_ramc_base[idx] = of_iomap(np, 0);
- if (!at91_ramc_base[idx]) {
- dev_err(&pdev->dev, "Could not map ram controller
address\n");
- return -ENODEV;
+ if (!of_device_is_compatible(pdev->dev.of_node, "atmel,sama5d3-rstc")) {
+ /* we need to shutdown the ddr controller, so get ramc base */
+ for_each_matching_node(np, at91_ramc_of_match) {
+ at91_ramc_base[idx] = of_iomap(np, 0);
+ if (!at91_ramc_base[idx]) {
+ dev_err(&pdev->dev, "Could not map ram controller
address\n");
+ return -ENODEV;
+ }
+ idx++;
}
- idx++;
}
match = of_match_node(at91_reset_of_match, pdev->dev.of_node);
--
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 RFC V1 2/3] onkey: da9063: Add DA9062 OnKey capability to DA9063 OnKey driver
On 17 July 2015 23:51, Dmitry Torokhov wrote:
> Hi Steve,
> On Tue, Jul 14, 2015 at 02:07:50PM +0100, S Twiss wrote:
> > 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 da9063_compatible_onkey_regmap 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_compatible_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
>
> Looks generally good, just a few comments.
>
Hi Dmitry,
Thanks for taking the time to review this.
[...]
> > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> > index d4f0a81..42860f9 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -612,10 +612,10 @@ config INPUT_DA9055_ONKEY
> >
> > config INPUT_DA9063_ONKEY
> > tristate "Dialog DA9063 OnKey"
>
> "Dialog DA9062/63 OnKey" maybe?
Yep.
I can do that.
[...]
> >
> > -struct da9063_onkey {
> > - struct da9063 *hw;
> > +struct da9063_compatible_onkey_regmap {
>
> Maybe call it da906x_chip_config?
I will do this.
> > + /* REGS */
> > + int onkey_status;
> > + int onkey_pwr_signalling;
> > + int onkey_fault_log;
> > + int onkey_shutdown;
> > + /* MASKS */
> > + int onkey_nonkey_mask;
> > + int onkey_nonkey_lock_mask;
> > + int onkey_key_reset_mask;
> > + int onkey_shutdown_mask;
> > + /* NAMES */
> > + char *name;
>
> const char *?
>
Sure -- I'll change that.
> > +};
> > +
> > +struct da9063_compatible_onkey {
>
> If you did not rename the structure your diff would be smaller.
Yep. I can rename this back to what it was previously.
[...]
I'll submit a PATCH V2 with those changes.
Regards,
Steve
--
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/2] ARM: at91: sama5/dt: update rstc to correct compatible string
Le 20/07/2015 11:32, Josh Wu a écrit :
> They'll use "atmel,sama5d3-rstc" for reset function.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Josh Wu
Acked-by: Nicolas Ferre
And we'll have to synchronize with the other patches. The best way to
deal with that can be to take both of them with us through arm-soc.
Sebastian,
1/ as you weren't in the CC list of the original patch, do you want me
to re-send the whole series?
2/ can we take these driver's changes with use through the arm-soc git
tree so that we can manage the synchronization better?
Thanks, bye,
> ---
>
> Changes in v2: None
>
> arch/arm/boot/dts/sama5d3.dtsi | 2 +-
> arch/arm/boot/dts/sama5d4.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 9e2444b..280255b 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -1259,7 +1259,7 @@
> };
>
> rstc@fe00 {
> - compatible = "atmel,at91sam9g45-rstc";
> + compatible = "atmel,sama5d3-rstc";
> reg = <0xfe00 0x10>;
> };
>
> diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
> index 3ee22ee..481196c 100644
> --- a/arch/arm/boot/dts/sama5d4.dtsi
> +++ b/arch/arm/boot/dts/sama5d4.dtsi
> @@ -1277,7 +1277,7 @@
> };
>
> rstc@fc068600 {
> - compatible = "atmel,at91sam9g45-rstc";
> + compatible = "atmel,sama5d3-rstc";
> reg = <0xfc068600 0x10>;
> };
>
>
--
Nicolas Ferre
--
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 4/5] tty/serial: at91: add support to FIFOs
Le 02/07/2015 15:18, Cyrille Pitchen a écrit :
> Depending on the hardware, TX and RX FIFOs may be available. The RX
> FIFO can avoid receive overruns, especially when DMA transfers are
> not used to read data from the Receive Holding Register. For heavy
> system load, The CPU is likely not be able to fetch data fast enough
> from the RHR.
>
> In addition, the RX FIFO can supersede the DMA/PDC to control the RTS
> line when the Hardware Handshaking mode is enabled. Two thresholds
> are to be set for that purpose:
> - When the number of data in the RX FIFO crosses and becomes lower
> than or equal to the low threshold, the RTS line is set to low
> level: the remote peer is requested to send data.
> - When the number of data in the RX FIFO crosses and becomes greater
> than or equal to the high threshold, the RTS line is set to high
> level: the remote peer should stop sending new data.
> - low threshold <= high threshold
> Once these two thresholds are set properly, this new feature is
> enabled by setting the FIFO RTS Control bit of the FIFO Mode Register.
>
> FIFOs also introduce a new multiple data mode: the USART works either
> in multiple data mode or in single data (legacy) mode.
>
> If MODE9 bit is set into the Mode Register or if USMODE is set to
> either LIN_MASTER, LIN_SLAVE or LON_MODE, FIFOs operate in single
> data mode. Otherwise, they operate in multiple data mode.
>
> In this new multiple data mode, accesses to the Receive Holding
> Register or Transmit Holding Register slightly change.
>
> Since this driver implements neither the 9bit data feature (MODE9 bit
> set into the Mode Register) nor LIN modes, the USART works in
> multiple data mode whenever FIFOs are available and enabled. We also
> assume that data are 8bit wide.
>
> In single data mode, 32bit access CAN be used to read a single data
> from RHR or write a single data into THR.
> However in multiple data mode, a 32bit access to RHR now allows us to
> read four consecutive data from RX FIFO. Also a 32bit access to THR
> now allows to write four consecutive data into TX FIFO. So we MUST
> use 8bit access whenever only one data have to be read/written at a
> time.
>
> Signed-off-by: Cyrille Pitchen
Acked-by: Nicolas Ferre
Thanks!
> ---
> drivers/tty/serial/atmel_serial.c | 100
> +++---
> include/linux/atmel_serial.h | 36 ++
> 2 files changed, 130 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index e7c337de31d1..87de21f0c7a3 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -56,6 +56,15 @@
> /* Revisit: We should calculate this based on the actual port settings */
> #define PDC_RX_TIMEOUT (3 * 10)/* 3 bytes */
>
> +/* The minium number of data FIFOs should be able to contain */
> +#define ATMEL_MIN_FIFO_SIZE 8
> +/*
> + * These two offsets are substracted from the RX FIFO size to define the RTS
> + * high and low thresholds
> + */
> +#define ATMEL_RTS_HIGH_OFFSET16
> +#define ATMEL_RTS_LOW_OFFSET 20
> +
> #if defined(CONFIG_SERIAL_ATMEL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> #define SUPPORT_SYSRQ
> #endif
> @@ -141,6 +150,9 @@ struct atmel_uart_port {
> struct mctrl_gpios *gpios;
> int gpio_irq[UART_GPIO_MAX];
> unsigned inttx_done_mask;
> + u32 fifo_size;
> + u32 rts_high;
> + u32 rts_low;
> boolms_irq_enabled;
> boolis_usart; /* usart or uart */
> struct timer_list uart_timer; /* uart timer */
> @@ -191,6 +203,16 @@ static inline void atmel_uart_writel(struct uart_port
> *port, u32 reg, u32 value)
> __raw_writel(value, port->membase + reg);
> }
>
> +static inline u8 atmel_uart_readb(struct uart_port *port, u32 reg)
> +{
> + return __raw_readb(port->membase + reg);
> +}
> +
> +static inline void atmel_uart_writeb(struct uart_port *port, u32 reg, u8
> value)
> +{
> + __raw_writeb(value, port->membase + reg);
> +}
> +
> #ifdef CONFIG_SERIAL_ATMEL_PDC
> static bool atmel_use_pdc_rx(struct uart_port *port)
> {
> @@ -635,7 +657,7 @@ static void atmel_rx_chars(struct uart_port *port)
>
> status = atmel_uart_readl(port, ATMEL_US_CSR);
> while (status & ATMEL_US_RXRDY) {
> - ch = atmel_uart_readl(port, ATMEL_US_RHR);
> + ch = atmel_uart_readb(port, ATMEL_US_RHR);
>
> /*
>* note that the error handling code is
> @@ -686,7 +708,7 @@ static void atmel_tx_chars(struct uart_port *port)
>
> if (port->x_char &&
> (atmel_uart_readl(port, ATMEL_US_CSR) & atmel_port->tx_done_mask)) {
> - atmel_uart_writel(port, ATMEL_US_THR, port->x_char);
> + atmel_uart_writeb(port, ATMEL_US_THR, p
Re: [PATCH v4 3/5] tty/serial: at91: remove bunch of macros to access UART registers
Le 02/07/2015 15:18, Cyrille Pitchen a écrit :
> This patch replaces the UART_PUT_*, resp. UART_GET_*, macros by
> atmel_uart_writel(), resp. atmel_uart_readl(), inline function calls.
>
> Signed-off-by: Cyrille Pitchen
Ok with this move:
Acked-by: Nicolas Ferre
> ---
> drivers/tty/serial/atmel_serial.c | 313
> +++---
> 1 file changed, 159 insertions(+), 154 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index 2a8f528153e7..e7c337de31d1 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -88,37 +88,6 @@ static void atmel_stop_rx(struct uart_port *port);
>
> #define ATMEL_ISR_PASS_LIMIT 256
>
> -/* UART registers. CR is write-only, hence no GET macro */
> -#define UART_PUT_CR(port,v) __raw_writel(v, (port)->membase + ATMEL_US_CR)
> -#define UART_GET_MR(port)__raw_readl((port)->membase + ATMEL_US_MR)
> -#define UART_PUT_MR(port,v) __raw_writel(v, (port)->membase + ATMEL_US_MR)
> -#define UART_PUT_IER(port,v) __raw_writel(v, (port)->membase + ATMEL_US_IER)
> -#define UART_PUT_IDR(port,v) __raw_writel(v, (port)->membase + ATMEL_US_IDR)
> -#define UART_GET_IMR(port) __raw_readl((port)->membase + ATMEL_US_IMR)
> -#define UART_GET_CSR(port) __raw_readl((port)->membase + ATMEL_US_CSR)
> -#define UART_GET_CHAR(port) __raw_readl((port)->membase + ATMEL_US_RHR)
> -#define UART_PUT_CHAR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_US_THR)
> -#define UART_GET_BRGR(port) __raw_readl((port)->membase + ATMEL_US_BRGR)
> -#define UART_PUT_BRGR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_US_BRGR)
> -#define UART_PUT_RTOR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_US_RTOR)
> -#define UART_PUT_TTGR(port, v) __raw_writel(v, (port)->membase +
> ATMEL_US_TTGR)
> -#define UART_GET_IP_NAME(port) __raw_readl((port)->membase +
> ATMEL_US_NAME)
> -#define UART_GET_IP_VERSION(port) __raw_readl((port)->membase +
> ATMEL_US_VERSION)
> -
> - /* PDC registers */
> -#define UART_PUT_PTCR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_PDC_PTCR)
> -#define UART_GET_PTSR(port) __raw_readl((port)->membase + ATMEL_PDC_PTSR)
> -
> -#define UART_PUT_RPR(port,v) __raw_writel(v, (port)->membase + ATMEL_PDC_RPR)
> -#define UART_GET_RPR(port) __raw_readl((port)->membase + ATMEL_PDC_RPR)
> -#define UART_PUT_RCR(port,v) __raw_writel(v, (port)->membase + ATMEL_PDC_RCR)
> -#define UART_PUT_RNPR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_PDC_RNPR)
> -#define UART_PUT_RNCR(port,v)__raw_writel(v, (port)->membase +
> ATMEL_PDC_RNCR)
> -
> -#define UART_PUT_TPR(port,v) __raw_writel(v, (port)->membase + ATMEL_PDC_TPR)
> -#define UART_PUT_TCR(port,v) __raw_writel(v, (port)->membase + ATMEL_PDC_TCR)
> -#define UART_GET_TCR(port) __raw_readl((port)->membase + ATMEL_PDC_TCR)
> -
> struct atmel_dma_buffer {
> unsigned char *buf;
> dma_addr_t dma_addr;
> @@ -212,6 +181,16 @@ to_atmel_uart_port(struct uart_port *uart)
> return container_of(uart, struct atmel_uart_port, uart);
> }
>
> +static inline u32 atmel_uart_readl(struct uart_port *port, u32 reg)
> +{
> + return __raw_readl(port->membase + reg);
> +}
> +
> +static inline void atmel_uart_writel(struct uart_port *port, u32 reg, u32
> value)
> +{
> + __raw_writel(value, port->membase + reg);
> +}
> +
> #ifdef CONFIG_SERIAL_ATMEL_PDC
> static bool atmel_use_pdc_rx(struct uart_port *port)
> {
> @@ -257,7 +236,7 @@ static unsigned int atmel_get_lines_status(struct
> uart_port *port)
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> unsigned int status, ret = 0;
>
> - status = UART_GET_CSR(port);
> + status = atmel_uart_readl(port, ATMEL_US_CSR);
>
> mctrl_gpio_get(atmel_port->gpios, &ret);
>
> @@ -304,9 +283,9 @@ static int atmel_config_rs485(struct uart_port *port,
> unsigned int mode;
>
> /* Disable interrupts */
> - UART_PUT_IDR(port, atmel_port->tx_done_mask);
> + atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>
> - mode = UART_GET_MR(port);
> + mode = atmel_uart_readl(port, ATMEL_US_MR);
>
> /* Resetting serial mode to RS232 (0x0) */
> mode &= ~ATMEL_US_USMODE;
> @@ -316,7 +295,8 @@ static int atmel_config_rs485(struct uart_port *port,
> if (rs485conf->flags & SER_RS485_ENABLED) {
> dev_dbg(port->dev, "Setting UART to RS485\n");
> atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
> - UART_PUT_TTGR(port, rs485conf->delay_rts_after_send);
> + atmel_uart_writel(port, ATMEL_US_TTGR,
> + rs485conf->delay_rts_after_send);
> mode |= ATMEL_US_USMODE_RS485;
> } else {
> dev_dbg(port->dev, "Setting UART to RS232\n");
> @@ -326,10 +306,10 @@ static int atmel_config_rs485(struct uart_port *port,
>
Re: [PATCH v6 3/3] arm64: dts: mt8173: add MT8173 display PWM driver support node
On Mon, Jul 20, 2015 at 4:17 PM, YH Huang wrote:
> Add display PWM node in mt8173-evb.dts and mt8173.dtsi.
>
> Signed-off-by: YH Huang
For the series:
Reviewed-by: Daniel Kurtz
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 22 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index f433c21..b7c1d9f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -34,6 +34,21 @@
> chosen { };
> };
>
> +&pio {
> + disp_pwm0_pins: disp_pwm0_pins {
> + pins1 {
> + pinmux = ;
> + bias-pull-up;
> + };
> + };
> +};
> +
> +&pwm0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&disp_pwm0_pins>;
> + status = "okay";
> +};
> +
> &pwrap {
> pmic: mt6397 {
> compatible = "mediatek,mt6397";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..44cab19 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -393,6 +393,28 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + pwm0: pwm@1401e000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401e000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> +<&mmsys CLK_MM_DISP_PWM0MM>;
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> +
> + pwm1: pwm@1401f000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401f000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM126M>,
> +<&mmsys CLK_MM_DISP_PWM1MM>;
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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 4/7] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
Hi,
On Thu, 2015-07-09 at 08:55 +0530, Sricharan R wrote:
> #define ONE_BYTE 0x1
> +#define QUP_I2C_MX_CONFIG_DURING_RUN BIT(31)
>
> struct qup_i2c_block {
> int count;
> @@ -121,6 +122,7 @@ struct qup_i2c_block {
> int rx_tag_len;
> int data_len;
> u8 tags[6];
> + int config_run;
This is not directly related to "block" control logic, right?
Could it made part of qup_i2c_dev structure?
> };
>
> struct qup_i2c_dev {
> @@ -152,6 +154,10 @@ struct qup_i2c_dev {
>
> int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
> struct i2c_msg *msg);
> + /* Current i2c_msg in i2c_msgs */
> + int cmsg;
> + /* total num of i2c_msgs */
> + int num;
I think it will be simpler with just "bool is_last" evaluated in main xfer loop.
>
> @@ -374,6 +383,9 @@ static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
> /* There are 2 tag bytes that are read in to fifo for every block */
> if (msg->flags & I2C_M_RD)
> qup->blk.rx_tag_len = qup->blk.count * 2;
> +
> + if (qup->cmsg)
> + qup->blk.config_run = QUP_I2C_MX_CONFIG_DURING_RUN;
This could be moved to qup_i2c_xfer_v2() to avoid repeatedly setting it.
> }
Regards,
Ivan
--
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 v11 1/5] drm/layerscape: Add Freescale DCU DRM driver
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.
The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.
The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA BGRA ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.
This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
Acked-by: Daniel Vetter
Reviewed-by: Alison Wang
---
Changed in V11
-set regmap_config.cache_type to REGCACHE_FLAT
Advanced by Alexander Stein
Changed in V10
-adjust commit log, remove meaningless statement
-cleanup code for it's format and style.
-remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
-remove useless sentences: encoder->crtc = crtc; and connector->encoder =
encoder; and so on
-add vendor prefix for panel pandle
-make a DCU_CTRLDESCLN(x, y) to avoid high repetition
-introduce per-SoC capability structure to avoid check on the OF node's
compatible string
-Implement some functions: crtc enable and disable, enable and disable VBLANK,
plane atomic_disable and atomic_enable -atomic_check and so on
-move DCU config sentence to the right place
-move get resources functions to ->probe()
-move fsl,dcu.txt to video/ folder
-add big-endian describe
All advaced by Thierry Reding
Changed in V9
-put node after calling of_drm_find_panel
-split clk_prepare_enable() to clk_prepare() and clk_enable(), just call
clk_prepare once, and check return value
-check regmap_write/regmap_read return return value
-remove useless ".owner= THIS_MODULE,"
All advanced by Mark Yao
Changed in V8
- Remove useless code
#define DRIVER_NAME "fsl-dcu-drm"
MODULE_ALIAS("platform:fsl-dcu-drm");
Adviced by Paul Bolle
Changed in V7
- Remove redundant functions and replace deprecated hooker
Adviced by Daniel Vetter
- Replace drm_platform_init with drm_dev_alloc/register
Adviced by Daniel Vetter
Changed in V6
- Add NEC nl4827hc19_05b panel to panel-simple.c
Adviced by Mark Yao
- Add DRIVER_ATOMIC for driver_features
Adviced by Mark Yao
- check fsl_dev if it's NULL at PM suspend/resume
Adviced by Mark Yao
Changed in V5
- Update commit message
- Add layer registers initialization
- Remove unused functions
- Rename driver folder
Adviced by Stefan Agner
- Move pixel clock control functions to fsl_dcu_drm_drv.c
- remove redundant enable the clock implicitly using regmap
- Add maintainer message
Changed in V4:
-This version doesn't have functionality changed
Just a minor adjustment.
Changed in V3:
- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
Adviced by Daniel Vetter
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt
Changed in v2:
- Add atomic support
Adviced by Daniel Vetter
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility
Adviced by Stefan Agner
.../devicetree/bindings/video/fsl,dcu.txt | 22 ++
MAINTAINERS| 8 +
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/fsl-dcu/Kconfig| 18 +
drivers/gpu/drm/fsl-dcu/Makefile | 7 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 19 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 403 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 197 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c| 23 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 43 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 33 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 261 +
drivers/gpu
Re: [PATCH] ARM: dts: sun4i: Add Iteaduino Plus A10
Hi,
Thanks for your patch.
On Sun, Jul 19, 2015 at 03:45:03PM +0200, Josef Gajdusek wrote:
> Iteaduino Plus A10 is a breakout board + Itead Core A10.
Is there multiple breakout boards available for that module?
> It features 1GB RAM, has most of the A10 pins on a .1" header, 2 USB
> ports, 1 OTG USB port, Ethernet, HDMI, SATA, Speaker/Microphone
> 3.5mm jacks and an SD card slot.
>
> Link to manufacturer wiki: http://wiki.iteadstudio.com/Iteaduino_Plus_A10/A20
Please don't put such links in the commit description. Valid URLs come
and go, the git history doesn't.
> Signed-off-by: Josef Gajdusek
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-iteaduino-plus.dts | 202
> +
> 2 files changed, 203 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-iteaduino-plus.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index adb1826..6104ed1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -529,6 +529,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-hackberry.dtb \
> sun4i-a10-hyundai-a7hd.dtb \
> sun4i-a10-inet97fv2.dtb \
> + sun4i-a10-iteaduino-plus.dts \
> sun4i-a10-jesurun-q5.dtb \
> sun4i-a10-marsboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-iteaduino-plus.dts
> b/arch/arm/boot/dts/sun4i-a10-iteaduino-plus.dts
> new file mode 100644
> index 000..985e155
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-iteaduino-plus.dts
we try to have a DT name that is
---.dts
Which in this case would be sun4i-a10-itead-iteaduino-plus.dts
> @@ -0,0 +1,202 @@
> +/*
> + * Copyright 2015 Josef Gajdusek
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "Iteaduino Plus A10";
> + compatible = "itead,iteaduino-plus-a10", "allwinner,sun4i-a10";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&ahci {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&emac {
> + pinctrl-names = "default";
> + pinctrl-0 = <&emac_pins_a>;
> + phy = <&phy1>;
> + status = "okay";
> +};
> +
> +&emac_sram {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +
> + axp209: pmic@34 {
> + reg = <0x34>;
> + interrupts = <0>;
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
