Re: [PATCH 3/3] drivers: bus: Move omap gpmc code to live under drivers
Hi Tony, On Friday 21 November 2014 03:58 AM, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/Makefile | 2 +- drivers/bus/Kconfig | 3 +++ drivers/bus/Makefile | 3 ++- arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c | 0 5 files changed, 7 insertions(+), 2 deletions(-) rename arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c (100%) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f4d06ae..3021901 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -80,6 +80,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC select OMAP_DM_TIMER + select OMAP_GPMC select PINCTRL select SOC_BUS select TI_PRIV_EDMA diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3e824f8..bd85741 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-omap/include # Common support -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ +obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ omap_device.o sram.o drm.o diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 603eb1b..09aacc8 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -27,6 +27,9 @@ config MVEBU_MBUS Driver needed for the MBus configuration on Marvell EBU SoCs (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP). +config OMAP_GPMC + bool + config OMAP_OCP2SCP tristate OMAP OCP2SCP DRIVER depends on ARCH_OMAP2PLUS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18..96e77dd 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -5,7 +5,8 @@ obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o obj-$(CONFIG_IMX_WEIM) += imx-weim.o obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o I guess this is unrelated to $subject. Shouldn't this be dropped? Thanks and regards, Lokesh + +obj-$(CONFIG_OMAP_GPMC) += omap-gpmc.o # Interconnect bus driver for OMAP SoCs. obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o diff --git a/arch/arm/mach-omap2/gpmc.c b/drivers/bus/omap-gpmc.c similarity index 100% rename from arch/arm/mach-omap2/gpmc.c rename to drivers/bus/omap-gpmc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] drivers: bus: Move omap gpmc code to live under drivers
Hi Tony, On 11/21/2014 12:28 AM, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/Makefile | 2 +- drivers/bus/Kconfig | 3 +++ drivers/bus/Makefile | 3 ++- arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c | 0 5 files changed, 7 insertions(+), 2 deletions(-) rename arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c (100%) Should we move it to drivers/memory/ instead? TI_AEMIF driver lives there. This is similar to OMAP-GPMC for but for Davinci and Keystone platforms. diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f4d06ae..3021901 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -80,6 +80,7 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC select OMAP_DM_TIMER + select OMAP_GPMC select PINCTRL select SOC_BUS select TI_PRIV_EDMA diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3e824f8..bd85741 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-omap/include # Common support -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ +obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ omap_device.o sram.o drm.o diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 603eb1b..09aacc8 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -27,6 +27,9 @@ config MVEBU_MBUS Driver needed for the MBus configuration on Marvell EBU SoCs (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP). +config OMAP_GPMC + bool + Description? I had put this from a similar patch that I created earlier +This driver is for the General Purpose Memory Controller (GPMC) +present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows +interfacing to a variety of asynchronous as well as synchronous +memory drives like NOR, NAND, OneNAND, SRAM. + cheers, -roger config OMAP_OCP2SCP tristate OMAP OCP2SCP DRIVER depends on ARCH_OMAP2PLUS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18..96e77dd 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -5,7 +5,8 @@ obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o obj-$(CONFIG_IMX_WEIM) += imx-weim.o obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o + +obj-$(CONFIG_OMAP_GPMC) += omap-gpmc.o # Interconnect bus driver for OMAP SoCs. obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o diff --git a/arch/arm/mach-omap2/gpmc.c b/drivers/bus/omap-gpmc.c similarity index 100% rename from arch/arm/mach-omap2/gpmc.c rename to drivers/bus/omap-gpmc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
Tony, On 11/21/2014 12:28 AM, Tony Lindgren wrote: We still need to support platform data for omap3 until it's booting in device tree only mode. So let's add platform_data/omap-gpmc.h for that, and a minimal linux/omap-gpmc.h for the save and restore used by the PM code. Once omap3 boots in device tree only mode, we can make the data structures in platform_data/omap-gpmc.h private to the GPMC driver. Note that we can now also remove gpmc-nand.h and gpmc-onenand.h. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-cm-t35.c | 1 - arch/arm/mach-omap2/board-cm-t3517.c | 1 - arch/arm/mach-omap2/board-flash.c | 4 +- arch/arm/mach-omap2/board-flash.h | 1 - arch/arm/mach-omap2/board-n8x0.c | 2 - arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 1 - arch/arm/mach-omap2/gpmc-nand.c| 1 - arch/arm/mach-omap2/gpmc-onenand.c | 1 - arch/arm/mach-omap2/gpmc-onenand.h | 24 --- arch/arm/mach-omap2/gpmc.c | 64 +- arch/arm/mach-omap2/gpmc.h | 224 + arch/arm/mach-omap2/pm34xx.c | 2 +- .../gpmc-nand.h = include/linux/omap-gpmc.h | 18 +- include/linux/platform_data/omap-gpmc.h| 177 15 files changed, 255 insertions(+), 268 deletions(-) delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h rename arch/arm/mach-omap2/gpmc-nand.h = include/linux/omap-gpmc.h (54%) create mode 100644 include/linux/platform_data/omap-gpmc.h snip diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h index 707f6d5..4dfb889 100644 --- a/arch/arm/mach-omap2/gpmc.h +++ b/arch/arm/mach-omap2/gpmc.h @@ -7,225 +7,5 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ - -#ifndef __OMAP2_GPMC_H -#define __OMAP2_GPMC_H - -#include linux/platform_data/mtd-nand-omap2.h - -/* Maximum Number of Chip Selects */ -#define GPMC_CS_NUM 8 - -#define GPMC_CS_CONFIG1 0x00 -#define GPMC_CS_CONFIG2 0x04 -#define GPMC_CS_CONFIG3 0x08 -#define GPMC_CS_CONFIG4 0x0c -#define GPMC_CS_CONFIG5 0x10 -#define GPMC_CS_CONFIG6 0x14 -#define GPMC_CS_CONFIG7 0x18 -#define GPMC_CS_NAND_COMMAND 0x1c -#define GPMC_CS_NAND_ADDRESS 0x20 -#define GPMC_CS_NAND_DATA0x24 - -/* Control Commands */ -#define GPMC_CONFIG_RDY_BSY 0x0001 -#define GPMC_CONFIG_DEV_SIZE 0x0002 -#define GPMC_CONFIG_DEV_TYPE 0x0003 -#define GPMC_SET_IRQ_STATUS 0x0004 -#define GPMC_CONFIG_WP 0x0005 - -#define GPMC_ENABLE_IRQ 0x000d - -/* ECC commands */ -#define GPMC_ECC_READ0 /* Reset Hardware ECC for read */ -#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */ -#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */ - -#define GPMC_CONFIG1_WRAPBURST_SUPP (1 31) -#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30) -#define GPMC_CONFIG1_READTYPE_ASYNC (0 29) -#define GPMC_CONFIG1_READTYPE_SYNC (1 29) -#define GPMC_CONFIG1_WRITEMULTIPLE_SUPP (1 28) -#define GPMC_CONFIG1_WRITETYPE_ASYNC(0 27) -#define GPMC_CONFIG1_WRITETYPE_SYNC (1 27) -#define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val 3) 25) -#define GPMC_CONFIG1_PAGE_LEN(val) ((val 3) 23) -#define GPMC_CONFIG1_WAIT_READ_MON (1 22) -#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21) -#define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val 3) 18) -#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16) -#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12) -#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1) -#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10) -#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0) -#define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8) -#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4) -#define GPMC_CONFIG1_FCLK_DIV(val) (val 3) -#define GPMC_CONFIG1_FCLK_DIV2 (GPMC_CONFIG1_FCLK_DIV(1)) -#define GPMC_CONFIG1_FCLK_DIV3 (GPMC_CONFIG1_FCLK_DIV(2)) -#define GPMC_CONFIG1_FCLK_DIV4 (GPMC_CONFIG1_FCLK_DIV(3)) -#define GPMC_CONFIG7_CSVALID (1 6) - -#define GPMC_DEVICETYPE_NOR 0 -#define GPMC_DEVICETYPE_NAND 2 -#define GPMC_CONFIG_WRITEPROTECT 0x0010 -#define WR_RD_PIN_MONITORING 0x0060 -#define GPMC_IRQ_FIFOEVENTENABLE 0x01 -#define GPMC_IRQ_COUNT_EVENT 0x02 - -#define GPMC_BURST_4 4 /* 4 word burst */ -#define GPMC_BURST_8
Re: [PATCH 2/3] ARM: OMAP2+: Move GPMC initcall to devices.c
On 11/21/2014 12:28 AM, Tony Lindgren wrote:
This will us allow to just move gpmc.c to live under drivers
in the next patch.
Note that we now also remove the omap specific check for the
initcall. That's OK as gpmc_probe() checks for the pdata
and bails out for other platforms compiled in.
Cc: Arnd Bergmann a...@arndb.de
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
I guess gpmc_init can't still be put under module_init() till we have fixed up
some more issues in the GPMC driver. But it shouldn't prevent us from making
the move to drivers/, so
Acked-by: Roger Quadros rog...@ti.com
cheers,
-roger
---
arch/arm/mach-omap2/devices.c | 26 ++
arch/arm/mach-omap2/gpmc.c| 31 +--
2 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 324f02b..110256a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -445,3 +445,29 @@ static int __init omap2_init_devices(void)
return 0;
}
omap_arch_initcall(omap2_init_devices);
+
+static int __init omap_gpmc_init(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *oh_name = gpmc;
+
+ /*
+ * if the board boots up with a populated DT, do not
+ * manually add the device from this initcall
+ */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(omap-gpmc, -1, oh, NULL, 0);
+ WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
+
+ return PTR_RET(pdev);
+}
+omap_postcore_initcall(omap_gpmc_init);
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc14f25..80dfb17 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -37,9 +37,6 @@
#include linux/platform_data/mtd-nand-omap2.h
#include linux/platform_data/mtd-onenand-omap2.h
-#include soc.h
-#include omap_device.h
-
#include asm/mach-types.h
#define DEVICE_NAME omap-gpmc
@@ -2010,35 +2007,9 @@ static __exit void gpmc_exit(void)
}
-omap_postcore_initcall(gpmc_init);
+postcore_initcall(gpmc_init);
module_exit(gpmc_exit);
-static int __init omap_gpmc_init(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- char *oh_name = gpmc;
-
- /*
- * if the board boots up with a populated DT, do not
- * manually add the device from this initcall
- */
- if (of_have_populated_dt())
- return -ENODEV;
-
- oh = omap_hwmod_lookup(oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n, oh_name);
- return -ENODEV;
- }
-
- pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
-
- return PTR_RET(pdev);
-}
-omap_postcore_initcall(omap_gpmc_init);
-
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
On Friday 21 November 2014 10:56 AM, Paul Walmsley wrote:
On Fri, 21 Nov 2014, Vignesh R wrote:
On 11/20/2014 12:39 PM, Paul Walmsley wrote:
On Tue, 4 Nov 2014, Vignesh R wrote:
This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
hwmod structures of tscadc has been moved to ipblock_data so that it can
be reused in am43xx. The clock domain names are separately set for am33xx
and am43xx. Thus tscadc dt entries can now be added to am43xx board
dt files.
Signed-off-by: Vignesh R vigne...@ti.com
...
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 6e57b8ad0db5..b92a7c7825fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
...
+static void am33xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l4hs_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l4_wkup_clkdm);
+}
+
+static void am43xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l3_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l3s_tsc_clkdm);
+}
+
...
+ am33xx_hwmod_clockdomain();
I looked at this patch and the one before it. Is there some reason why we
need to share these two hwmods between AM33xx and AM43xx? It seems
cleaner just to add the ADC data directly to the AM43xx hwmod data file,
not touch the AM33xx data, and not add another runtime data update for the
clockdomains. Unless there's something that I'm missing?
I wanted to reuse hwmod structures. Except for clockdomain and offset,
rest of the hwmod data are same for AM33xx and AM43xx. Adding data to AM43xx
hwmod file just duplicates these structures. Do you still want me to move
them
to AM43xx file?
Yes. It looks to me like the number of lines saved by eliminating the
duplication is not too different than the number of lines added with the
dynamic clockdomain rewriting. Plus then we can avoid the dynamic
clockdomain rewriting that we are only doing for two IP blocks. Ideally
the hwmod data is meant to be static, not changed at runtime. For the
moment we are stuck with the CLKCTRL rewriting but I personally consider
that to be a hack.
Ok, will add ADC data to AM43xx and post v3.
Regards
Vignesh
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] ARM: OMAP2+: hwmod: AM43x: add hwmod support for ADC on AM43xx
This patch adds hwmod support for ADC on AM43xx. Since clockdomain
and offsets of adc_tsc are different from AM33xx, ADC data has been
directly added to AM43xx hwmod file.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index fea01aa3ef42..b47f6ad0928c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -417,6 +417,37 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/*
+ * 'adc/tsc' class
+ * TouchScreen Controller (Anolog-To-Digital Converter)
+ */
+static struct omap_hwmod_class_sysconfig am43xx_adc_tsc_sysc = {
+ .rev_offs = 0x00,
+ .sysc_offs = 0x10,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_adc_tsc_hwmod_class = {
+ .name = adc_tsc,
+ .sysc = am43xx_adc_tsc_sysc,
+};
+
+static struct omap_hwmod am43xx_adc_tsc_hwmod = {
+ .name = adc_tsc,
+ .class = am43xx_adc_tsc_hwmod_class,
+ .clkdm_name = l3s_tsc_clkdm,
+ .main_clk = adc_tsc_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* dss */
static struct omap_hwmod am43xx_dss_core_hwmod = {
@@ -547,6 +578,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_wkup__gpio0 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l4_wkup__adc_tsc = {
+ .master = am33xx_l4_wkup_hwmod,
+ .slave = am43xx_adc_tsc_hwmod,
+ .clk= dpll_core_m4_div2_ck,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if am43xx_l4_hs__cpgmac0 = {
.master = am43xx_l4_hs_hwmod,
.slave = am33xx_cpgmac0_hwmod,
@@ -789,6 +827,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_wkup__i2c1,
am43xx_l4_wkup__gpio0,
am43xx_l4_wkup__wd_timer1,
+ am43xx_l4_wkup__adc_tsc,
am43xx_l3_s__qspi,
am33xx_l4_per__dcan0,
am33xx_l4_per__dcan1,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm
This patch adds tscadc DT entries for am437x-gp-evm
and am43x-epos-evm.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 20
arch/arm/boot/dts/am437x-gp-evm.dts | 8
arch/arm/boot/dts/am43x-epos-evm.dts | 8
3 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 46660ffd2b65..cb73e5eb6971 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -667,6 +667,26 @@
};
};
+ tscadc: tscadc@44e0d000 {
+ compatible = ti,am3359-tscadc;
+ reg = 0x44e0d000 0x1000;
+ ti,hwmods = adc_tsc;
+ interrupts = GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH;
+ clocks = adc_tsc_fck;
+ clock-names = fck;
+ status = disabled;
+
+ tsc {
+ compatible = ti,am3359-tsc;
+ };
+
+ adc {
+ #io-channel-cells = 1;
+ compatible = ti,am3359-adc;
+ };
+
+ };
+
sham: sham@5310 {
compatible = ti,omap5-sham;
ti,hwmods = sham;
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a521ac0a7d5a..7553bb7b2ca9 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -343,6 +343,14 @@
status = okay;
};
+tscadc {
+ status = okay;
+
+ adc {
+ ti,adc-channels = 0 1 2 3 4 5 6 7;
+ };
+};
+
ecap0 {
status = okay;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index f7e9bba10bd6..2ac693fd51da 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -519,6 +519,14 @@
status = okay;
};
+tscadc {
+ status = okay;
+
+ adc {
+ ti,adc-channels = 0 1 2 3 4 5 6 7;
+ };
+};
+
ecap0 {
status = okay;
pinctrl-names = default;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] Add support for ADC on am437x-gp and am43x-epos-evm
This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. tscadc DT node has been added to am437x-gp and am43x-epos DT files. With these patches, ADC functionalities are now available on am43xx. Change log: v3: Add ADC hwmod data to AM43xx hwmod file instead of sharing hwmod structures betweem AM33xx and AM43xx. v2: Removed phy addresses in hwmod. Using DT instead. Removed unused ti,am4372 compatible string. Use macro to set clk domain name. Fixed subject format of all patches Vignesh R (2): ARM: OMAP2+: hwmod: AM43x: add hwmod support for ADC on AM43xx ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm arch/arm/boot/dts/am4372.dtsi | 20 +++ arch/arm/boot/dts/am437x-gp-evm.dts| 8 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 8 ++ arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 39 ++ 4 files changed, 75 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] drivers: bus: Move omap gpmc code to live under drivers
On Friday 21 November 2014 11:15:05 Roger Quadros wrote: On 11/21/2014 12:28 AM, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Awesome! arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/Makefile | 2 +- drivers/bus/Kconfig | 3 +++ drivers/bus/Makefile | 3 ++- arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c | 0 5 files changed, 7 insertions(+), 2 deletions(-) rename arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c (100%) Should we move it to drivers/memory/ instead? TI_AEMIF driver lives there. This is similar to OMAP-GPMC for but for Davinci and Keystone platforms. Agreed, using drivers/memory sounds better. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote: The series looks good to me, and works for me. Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches. I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells. As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it. With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. signature.asc Description: Digital signature
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Thursday 20 November 2014 08:10 PM, Richard Cochran wrote: On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote: I tested this using lcd7 cape connected to beaglebone black. The latest kernel I could find on this board was a TI BSP based v3.14 kernel. So I had to port these patches to that kernel. Cc Robert Nelson to see if he knows about a more recent kernel supporting that cape. What is missing from mainline for the black? (I thought it was fully supported by now.) Black is supported, but LCD7 cape is not. I did not see any breakage with these patches applied although I did not see any noticeable performance improvement as well. So, the jumping on pen-up persists, right? That means the patch series does not provide a general fix for that issue. Not sure how to reproduce the jumping on pen-up. I was able to draw circles, sign my name and actually today I wrote up the whole English alphabet on the screen. Picture here. https://drive.google.com/file/d/0ByWLwvGx8MeyVF9CTlhHU0FHMFk/view?usp=sharing Is there any particular pattern you want me to test with? I would still like to test with a more recent kernel on LCD7 cape. So, if anyone has ideas (other than I porting the LCD7 support) please let me know. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 01:23 PM, Mark Brown wrote: On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote: The series looks good to me, and works for me. Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches. I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells. OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The issue about generic HDMI codec, that Jean-Francois (and soon me) is trying to solve - applies to the cases where a generic cpu-dai is connected to an external HDMI encoder with i2s (or s/pdif, unfortunately do not have such HW). In these cases the structure of the ASoC setup resembles closely the usual pattern of ASoC cards. The main difference is just that the codec IP also handling the video and there are no mixers, etc. I am currently trying to find the common denominator between tda998x and SiI9022 HDMI encoder chips to come up with a generic solution for the external HDMI encoder case. However, this work is completely separate to the omap-hdmi-audio and its review should not be delayed because of the hdmi codec work. Best regards, Jyri As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it. With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. (Sorry, I forgot to comment this part.) The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). Another target was to make configuring the audio as simple as possible. Because everything needed for HDMI audio is always there if the video side is correctly configured, there should be no need for any additional configuration (in DT or otherwise) to get the audio working. Now simply selecting omap-hdmi-audio is enough. There is no complex cross dependencies to the video side any more, the audio driver simply does find its device if the HDMI video driver is not probed. But indeed, in functional sense the whole series - apart from the couple of fixes in the beginning - is just moving the code around. Best regards, Jyri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: make more use of mmc library functionality
Thanks. What should I rebase against? Is 3.18-rc sufficient or is there some other tree I should work against? Thanks, NeilBrown git://git.linaro.org/people/ulf.hansson/mmc.git Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote: Not sure how to reproduce the jumping on pen-up. Does the cursor stay in exactly the same spot when you lift up the stylus? Then you don't have the issue. On the BB white using the LCD4 cape and the shipped debian kernel, the cursor *does* jump away, but not as often or as far as on the custom design I was working with. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] Exynos7: Adding USB 3.0 support
The series has dependency on a) [PATCH v7 0/7] Enable support for Samsung Exynos7 SoC http://www.spinics.net/lists/linux-samsung-soc/msg38734.html b) [GIT PULL] Samsung clock changes for 3.19 - specifically the clock dt bindings header. http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142 c) tty: serial: samsung: Clean-up selection of number of available UARTs http://www.spinics.net/lists/linux-samsung-soc/msg37418.html d) dts, kbuild: Implement support for dtb vendor subdirs(merged in linux-next) https://lkml.org/lkml/2014/10/21/654 e) Samsung pinctrl patches for v3.19 http://www.spinics.net/lists/linux-samsung-soc/msg38744.html Tested on Exynos7-espresso board with 3.18-rc5 and above dependencies. Clubbing the pinctrl, clk, and usb driver changes alongwith the dt changes together in this series only so as to avoid having 'n' number of dependencies. The USB driver patches in this series were part of [1] sent earlier. [1] [PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7 https://lkml.org/lkml/2014/10/7/191 Vivek Gautam (11): pinctrl: exynos: Add BUS1 pin controller for exynos7 dwc3: exynos: Remove local variable for clock from probe dwc3: exynos: Add provision for suspend clock dwc3: exynos: Add provision for AXI UpScaler clock on exynos7 phy: exynos5-usbdrd: Add pipe-clk, utmi-clk and itp-clk support phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS clk: exynos7: Add required clock tree for USB arm64: exynos: Add bus1 pinctrl node on exynos7 arm64: dts: Enable USB 3.0 controller on exynos7 arm64: dts: exynos7-espresso: Add regulators for Vbus and Vbus-Boost .../devicetree/bindings/phy/samsung-phy.txt|6 + .../devicetree/bindings/usb/exynos-usb.txt |6 +- arch/arm64/boot/dts/exynos/exynos7-espresso.dts| 43 +++ arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi| 26 arch/arm64/boot/dts/exynos/exynos7.dtsi| 42 ++ drivers/clk/samsung/clk-exynos7.c | 64 + drivers/phy/Kconfig|2 +- drivers/phy/phy-exynos5-usbdrd.c | 136 +--- drivers/pinctrl/samsung/pinctrl-exynos.c | 12 ++ drivers/usb/dwc3/dwc3-exynos.c | 39 +- include/dt-bindings/clock/exynos7-clk.h|9 +- 11 files changed, 354 insertions(+), 31 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] pinctrl: exynos: Add BUS1 pin controller for exynos7
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Linus Walleij linus.wall...@linaro.org
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..caca5b5 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,13 @@ static const struct samsung_pin_bank_data
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, gpr3, 0x0c),
};
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, gpf0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, gpf4, 0x10),
+ EXYNOS_PIN_BANK_EINTG(6, 0x120, gph1, 0x20),
+};
+
const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1349,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
__initconst = {
.pin_banks = exynos7_pin_banks7,
.nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 8 BUS1 data */
+ .pin_banks = exynos7_pin_banks8,
+ .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
+ .eint_gpio_init = exynos_eint_gpio_init,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] dwc3: exynos: Remove local variable for clock from probe
There's no need to keep one local variable for clock, and
then assign the same to 'clk' member of dwc3_exynos.
Just cleaning it up.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3951a65..7109de7 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -106,7 +106,6 @@ static int dwc3_exynos_remove_child(struct device *dev,
void *unused)
static int dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos *exynos;
- struct clk *clk;
struct device *dev = pdev-dev;
struct device_node *node = dev-of_node;
@@ -133,15 +132,13 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return ret;
}
- clk = devm_clk_get(dev, usbdrd30);
- if (IS_ERR(clk)) {
+ exynos-dev = dev;
+
+ exynos-clk = devm_clk_get(dev, usbdrd30);
+ if (IS_ERR(exynos-clk)) {
dev_err(dev, couldn't get clock\n);
return -EINVAL;
}
-
- exynos-dev = dev;
- exynos-clk = clk;
-
clk_prepare_enable(exynos-clk);
exynos-vdd33 = devm_regulator_get(dev, vdd33);
@@ -185,7 +182,7 @@ err4:
err3:
regulator_disable(exynos-vdd33);
err2:
- clk_disable_unprepare(clk);
+ clk_disable_unprepare(exynos-clk);
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] dwc3: exynos: Add provision for suspend clock
DWC3 controller on Exynos SoC series have separate control for
suspend clock which replaces pipe3_rx_pclk as clock source to
a small part of DWC3 core that operates when SS PHY is in its
lowest power state (P3) in states SS.disabled and U3.
Suggested-by: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 7109de7..af15ab3 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *susp_clk;
+
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,6 +143,13 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
}
clk_prepare_enable(exynos-clk);
+ exynos-susp_clk = devm_clk_get(dev, usbdrd30_susp_clk);
+ if (IS_ERR(exynos-susp_clk)) {
+ dev_dbg(dev, no suspend clk specified\n);
+ exynos-susp_clk = NULL;
+ }
+ clk_prepare_enable(exynos-susp_clk);
+
exynos-vdd33 = devm_regulator_get(dev, vdd33);
if (IS_ERR(exynos-vdd33)) {
ret = PTR_ERR(exynos-vdd33);
@@ -182,6 +191,7 @@ err4:
err3:
regulator_disable(exynos-vdd33);
err2:
+ clk_disable_unprepare(exynos-susp_clk);
clk_disable_unprepare(exynos-clk);
return ret;
}
@@ -194,6 +204,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
+ clk_disable_unprepare(exynos-susp_clk);
clk_disable_unprepare(exynos-clk);
regulator_disable(exynos-vdd33);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] dwc3: exynos: Add provision for AXI UpScaler clock on exynos7
DWC3 controller on Exynos7 SoC has separate control for
AXI UpScaler which connects DWC3 DRD controller to AXI bus.
Get the gate clock for the same to control it across power
cycles.
Suggested-by: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/devicetree/bindings/usb/exynos-usb.txt |6 --
drivers/usb/dwc3/dwc3-exynos.c | 17 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index a3b5990..9b4dbe3 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -82,8 +82,10 @@ Example:
DWC3
Required properties:
- - compatible: should be samsung,exynos5250-dwusb3 for USB 3.0 DWC3
- controller.
+ - compatible: should be one of the following -
+ samsung,exynos5250-dwusb3: for USB 3.0 DWC3 controller on
+ Exynos5250/5420.
+ samsung,exynos7-dwusb3: for USB 3.0 DWC3 controller on Exynos7.
- #address-cells, #size-cells : should be '1' if the device has sub-nodes
with 'reg' property.
- ranges: allows valid 1:1 translation between child's address space and
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index af15ab3..6ae8fe5 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -36,6 +36,7 @@ struct dwc3_exynos {
struct clk *clk;
struct clk *susp_clk;
+ struct clk *axius_clk;
struct regulator*vdd33;
struct regulator*vdd10;
@@ -150,6 +151,17 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
}
clk_prepare_enable(exynos-susp_clk);
+ if (of_device_is_compatible(node, samsung,exynos7-dwusb3)) {
+ exynos-axius_clk = devm_clk_get(dev, usbdrd30_axius_clk);
+ if (IS_ERR(exynos-axius_clk)) {
+ dev_err(dev, no AXI UpScaler clk specified\n);
+ return -ENODEV;
+ }
+ clk_prepare_enable(exynos-axius_clk);
+ } else {
+ exynos-axius_clk = NULL;
+ }
+
exynos-vdd33 = devm_regulator_get(dev, vdd33);
if (IS_ERR(exynos-vdd33)) {
ret = PTR_ERR(exynos-vdd33);
@@ -191,6 +203,7 @@ err4:
err3:
regulator_disable(exynos-vdd33);
err2:
+ clk_disable_unprepare(exynos-axius_clk);
clk_disable_unprepare(exynos-susp_clk);
clk_disable_unprepare(exynos-clk);
return ret;
@@ -204,6 +217,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
+ clk_disable_unprepare(exynos-axius_clk);
clk_disable_unprepare(exynos-susp_clk);
clk_disable_unprepare(exynos-clk);
@@ -216,6 +230,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id exynos_dwc3_match[] = {
{ .compatible = samsung,exynos5250-dwusb3 },
+ { .compatible = samsung,exynos7-dwusb3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
@@ -226,6 +241,7 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ clk_disable(exynos-axius_clk);
clk_disable(exynos-clk);
regulator_disable(exynos-vdd33);
@@ -251,6 +267,7 @@ static int dwc3_exynos_resume(struct device *dev)
}
clk_enable(exynos-clk);
+ clk_enable(exynos-axius_clk);
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] phy: exynos5-usbdrd: Add pipe-clk, utmi-clk and itp-clk support
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
Additionally, separate gate control is available for the clock
used for ITP (Isochronous Transfer Packet) generation.
So get the same and control in the phy-exynos5-usbdrd driver.
Suggested-by: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt|6 ++
drivers/phy/phy-exynos5-usbdrd.c | 104
2 files changed, 92 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 15e0f2c..d5bad92 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
- compatible : Should be set to one of the following supported values:
- samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
- samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+ - samsung,exynos7-usbdrd-phy - for exynos7 SoC.
- reg : Register offset and length of USB DRD PHY register set;
- clocks: Clock IDs array as required by the controller
- clock-names: names of clocks correseponding to IDs in the clock property;
@@ -138,6 +139,11 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+ - optional clocks: Exynos7 SoC has now following additional
+ gate clocks available:
+ - phy_pipe: for PIPE3 phy
+ - phy_utmi: for UTMI+ phy
+ - itp: for ITP generation
- samsung,pmu-syscon: phandle for PMU system controller interface, used to
control pmu registers for power isolation.
- #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index f756aca..3654712 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -141,6 +141,7 @@ struct exynos5_usbdrd_phy_drvdata {
const struct exynos5_usbdrd_phy_config *phy_cfg;
u32 pmu_offset_usbdrd0_phy;
u32 pmu_offset_usbdrd1_phy;
+ bool has_common_clk_gate;
};
/**
@@ -148,6 +149,9 @@ struct exynos5_usbdrd_phy_drvdata {
* @dev: pointer to device instance of this platform device
* @reg_phy: usb phy controller register memory base
* @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
+ * @itpclk: clock for ITP generation
* @drv_data: pointer to SoC level driver data structure
* @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
* instances each with its 'phy' and 'phy_cfg'.
@@ -155,12 +159,14 @@ struct exynos5_usbdrd_phy_drvdata {
*reference clocks' for SS and HS operations
* @ref_clk: reference clock to PHY block from which PHY's
* operational clocks are derived
- * @ref_rate: rate of above reference clock
*/
struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+ struct clk *pipeclk;
+ struct clk *utmiclk;
+ struct clk *itpclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -447,6 +453,11 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
dev_dbg(phy_drd-dev, Request to power_on usbdrd_phy phy\n);
clk_prepare_enable(phy_drd-ref_clk);
+ if (!phy_drd-drv_data-has_common_clk_gate) {
+ clk_prepare_enable(phy_drd-pipeclk);
+ clk_prepare_enable(phy_drd-utmiclk);
+ clk_prepare_enable(phy_drd-itpclk);
+ }
/* Enable VBUS supply */
if (phy_drd-vbus) {
@@ -464,6 +475,11 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
fail_vbus:
clk_disable_unprepare(phy_drd-ref_clk);
+ if (!phy_drd-drv_data-has_common_clk_gate) {
+ clk_disable_unprepare(phy_drd-itpclk);
+ clk_disable_unprepare(phy_drd-utmiclk);
+ clk_disable_unprepare(phy_drd-pipeclk);
+ }
return ret;
}
@@ -483,6 +499,11 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd-vbus);
clk_disable_unprepare(phy_drd-ref_clk);
+ if (!phy_drd-drv_data-has_common_clk_gate) {
+ clk_disable_unprepare(phy_drd-itpclk);
+ clk_disable_unprepare(phy_drd-pipeclk);
+ clk_disable_unprepare(phy_drd-utmiclk);
+ }
return 0;
}
@@ -506,6 +527,57 @@ static struct phy_ops exynos5_usbdrd_phy_ops = {
.owner = THIS_MODULE,
[PATCH 06/11] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Some Exynos boards have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-exynos5-usbdrd.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 3654712..1f54639 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -159,6 +159,8 @@ struct exynos5_usbdrd_phy_drvdata {
*reference clocks' for SS and HS operations
* @ref_clk: reference clock to PHY block from which PHY's
* operational clocks are derived
+ * vbus: VBUS regulator for phy
+ * vbus_boost: Boost regulator for VBUS present on few Exynos boards
*/
struct exynos5_usbdrd_phy {
struct device *dev;
@@ -178,6 +180,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+ struct regulator *vbus_boost;
};
static inline
@@ -460,11 +463,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
}
/* Enable VBUS supply */
+ if (phy_drd-vbus_boost) {
+ ret = regulator_enable(phy_drd-vbus_boost);
+ if (ret) {
+ dev_err(phy_drd-dev,
+ Failed to enable VBUS boost supply\n);
+ goto fail_vbus;
+ }
+ }
+
if (phy_drd-vbus) {
ret = regulator_enable(phy_drd-vbus);
if (ret) {
dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
- goto fail_vbus;
+ goto fail_vbus_boost;
}
}
@@ -473,6 +485,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
return 0;
+fail_vbus_boost:
+ if (phy_drd-vbus_boost)
+ regulator_disable(phy_drd-vbus_boost);
+
fail_vbus:
clk_disable_unprepare(phy_drd-ref_clk);
if (!phy_drd-drv_data-has_common_clk_gate) {
@@ -497,6 +513,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd-vbus)
regulator_disable(phy_drd-vbus);
+ if (phy_drd-vbus_boost)
+ regulator_disable(phy_drd-vbus_boost);
clk_disable_unprepare(phy_drd-ref_clk);
if (!phy_drd-drv_data-has_common_clk_gate) {
@@ -690,7 +708,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
break;
}
- /* Get Vbus regulator */
+ /* Get Vbus regulators */
phy_drd-vbus = devm_regulator_get(dev, vbus);
if (IS_ERR(phy_drd-vbus)) {
ret = PTR_ERR(phy_drd-vbus);
@@ -701,6 +719,16 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
phy_drd-vbus = NULL;
}
+ phy_drd-vbus_boost = devm_regulator_get(dev, vbus-boost);
+ if (IS_ERR(phy_drd-vbus_boost)) {
+ ret = PTR_ERR(phy_drd-vbus_boost);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS boost supply regulator\n);
+ phy_drd-vbus_boost = NULL;
+ }
+
dev_vdbg(dev, Creating usbdrd_phy phy\n);
for (i = 0; i EXYNOS5_DRDPHYS_NUM; i++) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS
This PHY controller is also present on Exynos7 platform in arch-exynos family. So PHY_EXYNOS5_USBDRD should now depend on ARCH_EXYNOS. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2a436e6..1514e40 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -193,7 +193,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on ARCH_EXYNOS OF depends on HAS_IOMEM depends on USB_DWC3_EXYNOS select GENERIC_PHY -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] clk: exynos7: Add required clock tree for USB
Adding required gate clocks for USB3.0 DRD controller
present on Exynos7.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/clk/samsung/clk-exynos7.c | 64 +++
include/dt-bindings/clock/exynos7-clk.h |9 -
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index ea4483b..3128593 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -343,6 +343,8 @@ static struct samsung_mux_clock top1_mux_clks[] __initdata
= {
MUX(0, mout_aclk_fsys0_200, mout_top1_group1, MUX_SEL_TOP13, 28, 2),
MUX(0, mout_sclk_mmc2, mout_top1_group1, MUX_SEL_TOP1_FSYS0, 24, 2),
+ MUX(0, mout_sclk_usbdrd300, mout_top1_group1,
+ MUX_SEL_TOP1_FSYS0, 28, 2),
MUX(0, mout_sclk_mmc1, mout_top1_group1, MUX_SEL_TOP1_FSYS1, 24, 2),
MUX(0, mout_sclk_mmc0, mout_top1_group1, MUX_SEL_TOP1_FSYS1, 28, 2),
@@ -356,6 +358,8 @@ static struct samsung_div_clock top1_div_clks[] __initdata
= {
DIV(DOUT_SCLK_MMC2, dout_sclk_mmc2, mout_sclk_mmc2,
DIV_TOP1_FSYS0, 24, 4),
+ DIV(0, dout_sclk_usbdrd300, mout_sclk_usbdrd300,
+ DIV_TOP1_FSYS0, 28, 4),
DIV(DOUT_SCLK_MMC1, dout_sclk_mmc1, mout_sclk_mmc1,
DIV_TOP1_FSYS1, 24, 4),
@@ -366,6 +370,8 @@ static struct samsung_div_clock top1_div_clks[] __initdata
= {
static struct samsung_gate_clock top1_gate_clks[] __initdata = {
GATE(CLK_SCLK_MMC2, sclk_mmc2, dout_sclk_mmc2,
ENABLE_SCLK_TOP1_FSYS0, 24, CLK_SET_RATE_PARENT, 0),
+ GATE(0, sclk_usbdrd300, dout_sclk_usbdrd300,
+ ENABLE_SCLK_TOP1_FSYS0, 28, 0, 0),
GATE(CLK_SCLK_MMC1, sclk_mmc1, dout_sclk_mmc1,
ENABLE_SCLK_TOP1_FSYS1, 24, CLK_SET_RATE_PARENT, 0),
@@ -647,7 +653,12 @@ CLK_OF_DECLARE(exynos7_clk_peris,
samsung,exynos7-clock-peris,
/* Register Offset definitions for CMU_FSYS0 (0x10E9) */
#define MUX_SEL_FSYS00 0x0200
#define MUX_SEL_FSYS01 0x0204
+#define MUX_SEL_FSYS02 0x0208
+#define ENABLE_ACLK_FSYS00 0x0800
#define ENABLE_ACLK_FSYS01 0x0804
+#define ENABLE_SCLK_FSYS01 0x0A04
+#define ENABLE_SCLK_FSYS02 0x0A08
+#define ENABLE_SCLK_FSYS04 0x0A10
/*
* List of parent clocks for Muxes in CMU_FSYS0
@@ -655,10 +666,29 @@ CLK_OF_DECLARE(exynos7_clk_peris,
samsung,exynos7-clock-peris,
PNAME(mout_aclk_fsys0_200_p) = { fin_pll, dout_aclk_fsys0_200 };
PNAME(mout_sclk_mmc2_p)= { fin_pll, sclk_mmc2 };
+PNAME(mout_sclk_usbdrd300_p) = { fin_pll, sclk_usbdrd300 };
+PNAME(mout_phyclk_usbdrd300_udrd30_phyclk_p) = { fin_pll,
+ phyclk_usbdrd300_udrd30_phyclock };
+PNAME(mout_phyclk_usbdrd300_udrd30_pipe_pclk_p)= { fin_pll,
+ phyclk_usbdrd300_udrd30_pipe_pclk };
+
+/* fixed rate clocks used in the FSYS0 block */
+struct samsung_fixed_rate_clock fixed_rate_clks_fsys0[] __initdata = {
+ FRATE(0, phyclk_usbdrd300_udrd30_phyclock, NULL,
+ CLK_IS_ROOT, 6000),
+ FRATE(0, phyclk_usbdrd300_udrd30_pipe_pclk, NULL,
+ CLK_IS_ROOT, 12500),
+};
+
static unsigned long fsys0_clk_regs[] __initdata = {
MUX_SEL_FSYS00,
MUX_SEL_FSYS01,
+ MUX_SEL_FSYS02,
+ ENABLE_ACLK_FSYS00,
ENABLE_ACLK_FSYS01,
+ ENABLE_SCLK_FSYS01,
+ ENABLE_SCLK_FSYS02,
+ ENABLE_SCLK_FSYS04,
};
static struct samsung_mux_clock fsys0_mux_clks[] __initdata = {
@@ -666,11 +696,45 @@ static struct samsung_mux_clock fsys0_mux_clks[]
__initdata = {
MUX_SEL_FSYS00, 24, 1),
MUX(0, mout_sclk_mmc2_user, mout_sclk_mmc2_p, MUX_SEL_FSYS01, 24, 1),
+ MUX(0, mout_sclk_usbdrd300_user, mout_sclk_usbdrd300_p,
+ MUX_SEL_FSYS01, 28, 1),
+
+ MUX(0, mout_phyclk_usbdrd300_udrd30_pipe_pclk_user,
+ mout_phyclk_usbdrd300_udrd30_pipe_pclk_p,
+ MUX_SEL_FSYS02, 24, 1),
+ MUX(0, mout_phyclk_usbdrd300_udrd30_phyclk_user,
+ mout_phyclk_usbdrd300_udrd30_phyclk_p,
+ MUX_SEL_FSYS02, 28, 1),
};
static struct samsung_gate_clock fsys0_gate_clks[] __initdata = {
+ GATE(ACLK_AXIUS_USBDRD30X_FSYS0X, aclk_axius_usbdrd30x_fsys0x,
+ mout_aclk_fsys0_200_user,
+ ENABLE_ACLK_FSYS00, 19, 0, 0),
+
+ GATE(ACLK_USBDRD300, aclk_usbdrd300, mout_aclk_fsys0_200_user,
+ ENABLE_ACLK_FSYS01, 29, 0, 0),
GATE(ACLK_MMC2, aclk_mmc2, mout_aclk_fsys0_200_user,
ENABLE_ACLK_FSYS01, 31, 0, 0),
+
+ GATE(SCLK_USBDRD300_SUSPENDCLK, sclk_usbdrd300_suspendclk,
+ mout_sclk_usbdrd300_user,
+ ENABLE_SCLK_FSYS01, 4, 0, 0),
+ GATE(SCLK_USBDRD300_REFCLK, sclk_usbdrd300_refclk, fin_pll,
+
[PATCH 09/11] arm64: exynos: Add bus1 pinctrl node on exynos7
BUS1 pinctrl provides gpios for usb and power regulator
available on exynos7-espresso board. So add relevant device
node for pinctrl-bus1.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 26 +++
arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
2 files changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..9648e03 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -335,6 +335,32 @@
};
};
+pinctrl_bus1 {
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf4: gpf4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
+
pinctrl_nfc {
gpj0: gpj0 {
gpio-controller;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index d7a37c3..90048b2 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = pinctrl_ese;
pinctrl6 = pinctrl_fsys0;
pinctrl7 = pinctrl_fsys1;
+ pinctrl8 = pinctrl_bus1;
};
cpus {
@@ -242,6 +243,12 @@
interrupts = 0 383 0;
};
+ pinctrl_bus1: pinctrl@1487 {
+ compatible = samsung,exynos7-pinctrl;
+ reg = 0x1487 0x1000;
+ interrupts = 0 384 0;
+ };
+
pinctrl_nfc: pinctrl@14cd {
compatible = samsung,exynos7-pinctrl;
reg = 0x14cd 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] arm64: dts: Enable USB 3.0 controller on exynos7
Adding USB 3.0 DRD controller device node, with its clock
and phy information to enable using the same on Exynos7.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 90048b2..e633b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -531,6 +531,41 @@
clocks = clock_peric0 PCLK_PWM;
clock-names = timers;
};
+
+ usbdrd3: usb@1540 {
+ compatible = samsung,exynos7-dwusb3;
+ clocks = clock_fsys0 ACLK_USBDRD300,
+clock_fsys0 SCLK_USBDRD300_SUSPENDCLK,
+clock_fsys0 ACLK_AXIUS_USBDRD30X_FSYS0X;
+ clock-names = usbdrd30, usbdrd30_susp_clk,
+ usbdrd30_axius_clk;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = snps,dwc3;
+ reg = 0x1540 0x1;
+ interrupts = 0 223 0;
+ phys = usbdrd_phy 0, usbdrd_phy 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
+ usbdrd_phy: phy@1550 {
+ compatible = samsung,exynos7-usbdrd-phy;
+ reg = 0x1550 0x100;
+ clocks =
+ clock_fsys0 ACLK_USBDRD300,
+ clock_fsys0 OSCCLK_PHY_CLKOUT_USB30_PHY,
+ clock_fsys0 PHYCLK_USBDRD300_UDRD30_PIPE_PCLK_USER,
+ clock_fsys0 PHYCLK_USBDRD300_UDRD30_PHYCLK_USER,
+ clock_fsys0 SCLK_USBDRD300_REFCLK;
+ clock-names = phy, ref, phy_pipe, phy_utmi,
+ itp;
+ samsung,pmu-syscon = pmu_system_controller;
+ #phy-cells = 1;
+ };
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] arm64: dts: exynos7-espresso: Add regulators for Vbus and Vbus-Boost
Adding fixed voltage regulators for Vbus and Vbus-boost required
by USB 3.0 DRD controller on Exynos7-espresso board.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 5424cc4..2dedd5e 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -30,6 +30,28 @@
device_type = memory;
reg = 0x0 0x4000 0x0 0xC000;
};
+
+ usb30_vbus_reg: regulator-usb30 {
+ compatible = regulator-fixed;
+ regulator-name = VBUS_5V;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph1 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb30_vbus_en;
+ enable-active-high;
+ };
+
+ usb3drd_vboost_5v: regulator-usb3drd-vboost {
+ compatible = regulator-fixed;
+ regulator-name = VUSB_VBUS_5V;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpf4 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb3drd_vboost_en;
+ enable-active-high;
+ };
};
fin_pll {
@@ -40,6 +62,22 @@
status = okay;
};
+pinctrl_bus1 {
+ usb30_vbus_en: usb30-vbus-en {
+ samsung,pins = gph1-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb3drd_vboost_en: usb3drd-vboost-en {
+ samsung,pins = gpf4-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
rtc {
status = okay;
};
@@ -82,3 +120,8 @@
bus-width = 4;
disable-wp;
};
+
+usbdrd_phy {
+ vbus-supply = usb30_vbus_reg;
+ vbus-boost-supply = usb3drd_vboost_5v;
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
I tested version 4 of the patch series on a custom design and I saw also the jumps as described by Richard. I played a little with the sample delay and it got better but I couldn't completely remove the jumps. The other issue I had with version 3, the pen_ups during the busy loop, is solved. I experienced some pen_up misses during the busy loop if I used a too high sample delay, without the sample delay it was ok. Thanks, Hannes 2014-11-21 14:10 GMT+01:00 Richard Cochran richardcoch...@gmail.com: On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote: Not sure how to reproduce the jumping on pen-up. Does the cursor stay in exactly the same spot when you lift up the stylus? Then you don't have the issue. On the BB white using the LCD4 cape and the shipped debian kernel, the cursor *does* jump away, but not as often or as far as on the custom design I was working with. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Exynos7: Adding USB 3.0 support
On Fri, Nov 21, 2014 at 07:05:43PM +0530, Vivek Gautam wrote: The series has dependency on a) [PATCH v7 0/7] Enable support for Samsung Exynos7 SoC http://www.spinics.net/lists/linux-samsung-soc/msg38734.html b) [GIT PULL] Samsung clock changes for 3.19 - specifically the clock dt bindings header. http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142 c) tty: serial: samsung: Clean-up selection of number of available UARTs http://www.spinics.net/lists/linux-samsung-soc/msg37418.html d) dts, kbuild: Implement support for dtb vendor subdirs(merged in linux-next) https://lkml.org/lkml/2014/10/21/654 e) Samsung pinctrl patches for v3.19 http://www.spinics.net/lists/linux-samsung-soc/msg38744.html Tested on Exynos7-espresso board with 3.18-rc5 and above dependencies. Clubbing the pinctrl, clk, and usb driver changes alongwith the dt changes together in this series only so as to avoid having 'n' number of dependencies. The USB driver patches in this series were part of [1] sent earlier. [1] [PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7 https://lkml.org/lkml/2014/10/7/191 I took dwc3 driver patches. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Friday 21 November 2014 08:41 PM, Johannes Pointner wrote: I tested version 4 of the patch series on a custom design and I saw also the jumps as described by Richard. I played a little with the sample delay and it got better but I couldn't completely remove the jumps. And before the patches were applied, there were no jumps at all? Which kernel are you using for testing? Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] i2c: omap: don't reset controller if Arbitration Lost detected
On Fri, Nov 21, 2014 at 01:28:44AM +0400, Alexander Kochetkov wrote:
Arbitration Lost is a expected situation in a multimaster environment.
IP correctly detect it.
The only reason for reseting IP in the AL case is to be sure to
avoid advisory 1.94 (omap3) and errata i595 (omap4):
I2C: After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer with workaround: The MST and STT bits inside
I2C_CON should be set to 1 at the same moment (avoid setting the
MST bit to 1 while STT = 0).
The driver never writes MST and STT bits separately and doesn't
create condition for errata. So the reset is not necessary.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Tested on BBB and AM437x Starter Kit
Tested-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ffb9c0..47103e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -707,13 +707,17 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return 0;
/* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
+ if (dev-cmd_err (OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
omap_i2c_reset(dev);
__omap_i2c_init(dev);
return -EIO;
}
+ if (dev-cmd_err OMAP_I2C_STAT_AL) {
+ return -EIO;
+ }
+
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
On Fri, Nov 21, 2014 at 01:28:43AM +0400, Alexander Kochetkov wrote:
In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.
Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
and results in controller timeout. More over, in some cases IP could
interrupt another master's transfer and corrupt data on wire.
The commit implement method allowing to prevent IP from entering into
controller timeout state and from data corruption state.
The one drawback is the need to wait for 10ms before the first transfer.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Tested on BBB and AM437x Starter Kit
Tested-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 103
+
1 file changed, 103 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a021733..3ffb9c0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -58,6 +58,9 @@
/* timeout for pm runtime autosuspend */
#define OMAP_I2C_PM_TIMEOUT 1000/* ms */
+/* timeout for making decision on bus free status */
+#define OMAP_I2C_BUS_FREE_TIMEOUT (msecs_to_jiffies(10))
+
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
OMAP_I2C_REV_REG = 0,
@@ -210,6 +213,9 @@ struct omap_i2c_dev {
*/
u32 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedbb_valid:1; /* true when BB-bit reflects
+ * the I2C bus state
+ */
unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
@@ -336,7 +342,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
/* SYSC register is cleared by the reset; rewrite it */
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
+ /* Schedule I2C-bus monitoring on the next transfer */
+ dev-bb_valid = 0;
}
+
return 0;
}
@@ -449,6 +458,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-scllstate = scll;
dev-sclhstate = sclh;
+ if (dev-rev OMAP_I2C_OMAP1_REV_2) {
+ /* Not implemented */
+ dev-bb_valid = 1;
+ }
+
__omap_i2c_init(dev);
return 0;
@@ -473,6 +487,91 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+/*
+ * Wait while BB-bit doesn't reflect the I2C bus state
+ *
+ * In a multimaster environment, after IP software reset, BB-bit value
doesn't
+ * correspond to the current bus state. It may happen what BB-bit will be 0,
+ * while the bus is busy due to another I2C master activity.
+ * Here are BB-bit values after reset:
+ * SDA SCL BB NOTES
+ * 0 00 1, 2
+ * 1 00 1, 2
+ * 0 11
+ * 1 10 3
+ * Later, if IP detect SDA=0 and SCL=1 (ACK) or SDA 1-0 while SCL=1 (START)
+ * combinations on the bus, it set BB-bit to 1.
+ * If IP detect SDA 0-1 while SCL=1 (STOP) combination on the bus,
+ * it set BB-bit to 0 and BF to 1.
+ * BB and BF bits correctly tracks the bus state while IP is suspended
+ * BB bit became valid on the next FCLK clock after CON_EN bit set
+ *
+ * NOTES:
+ * 1. Any transfer started when BB=0 and bus is busy wouldn't be
+ *completed by IP and results in controller timeout.
+ * 2. Any transfer started when BB=0 and SCL=0 results in IP
+ *starting to drive SDA low. In that case IP corrupt data
+ *on the bus.
+ * 3. Any transfer started in the middle of another master's transfer
+ *results in unpredictable results and data corruption
+ */
+static int omap_i2c_wait_for_bb_valid(struct omap_i2c_dev *dev)
+{
+ unsigned long bus_free_timeout = 0;
+ unsigned long timeout;
+ int bus_free = 0;
+ u16 stat, systest;
+
+ if (dev-bb_valid)
+ return 0;
+
+ timeout = jiffies + OMAP_I2C_TIMEOUT;
+ while (1) {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ /*
+ * We will see BB or BF event in a case IP had detected any
+ * activity on the I2C bus. Now IP correctly tracks the bus
+ * state. BB-bit value is valid.
+ */
+ if (stat (OMAP_I2C_STAT_BB | OMAP_I2C_STAT_BF))
+ break;
+
+ /*
+ * Otherwise, we must look signals on the bus to make
+
Re: [PATCH 1/4] i2c: omap: cleanup register definitions
On Fri, Nov 21, 2014 at 01:28:42AM +0400, Alexander Kochetkov wrote:
Delete STAT_AD0 mask as unrelated to current IP (omap1?).
Delete DEBUG conditional around SYSTEST masks group.
Add SYSTEST functional mode masks for SCL and SDA.
Add STAT_BF mask.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Tested on BBB and AM437x Starter Kit
Tested-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9af7095..a021733 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -102,7 +102,7 @@ enum {
#define OMAP_I2C_STAT_ROVR (1 11) /* Receive overrun */
#define OMAP_I2C_STAT_XUDF (1 10) /* Transmit underflow */
#define OMAP_I2C_STAT_AAS(1 9)/* Address as slave */
-#define OMAP_I2C_STAT_AD0(1 8)/* Address zero */
+#define OMAP_I2C_STAT_BF (1 8)/* Bus Free */
#define OMAP_I2C_STAT_XRDY (1 4)/* Transmit data ready */
#define OMAP_I2C_STAT_RRDY (1 3)/* Receive data ready */
#define OMAP_I2C_STAT_ARDY (1 2)/* Register access ready */
@@ -150,16 +150,20 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test
enable */
#define OMAP_I2C_SYSTEST_FREE(1 14) /* Free running
mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK (3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+/* Functional mode */
+#define OMAP_I2C_SYSTEST_SCL_I_FUNC (1 8)/* SCL line input value
*/
+#define OMAP_I2C_SYSTEST_SCL_O_FUNC (1 7)/* SCL line output
value */
+#define OMAP_I2C_SYSTEST_SDA_I_FUNC (1 6)/* SDA line input value
*/
+#define OMAP_I2C_SYSTEST_SDA_O_FUNC (1 5)/* SDA line output
value */
+/* SDA/SCL IO mode */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line
sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line
drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line
sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line
drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK (1 0)
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/4] i2c: omap: add notes related to i2c multimaster mode
On Fri, Nov 21, 2014 at 01:28:45AM +0400, Alexander Kochetkov wrote: No functional changes. Signed-off-by: Alexander Kochetkov al.koc...@gmail.com heh: Tested on BBB and AM437x Starter Kit Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 47103e7..4e3642c 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -304,6 +304,12 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev) omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); /* + * NOTE: right after setting CON_EN, STAT_BB could be 0 while the + * bus is busy. It will be changed to 1 on the next IP FCLK clock. + * udelay(1) will be enough to fix that. + */ + + /* * Don't write to this register if the IE state is 0 as it can * cause deadlock. */ @@ -664,7 +670,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, if (!dev-b_hw stop) w |= OMAP_I2C_CON_STP; - + /* + * NOTE: STAT_BB bit could became 1 here if another master occupy + * the bus. IP successfully complete transfer when the bus will be + * free again (BB reset to 0). + */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w); /* -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH] i2c: omap: fix i207 errata handling
On Fri, Nov 21, 2014 at 04:16:51AM +0400, Alexander Kochetkov wrote:
commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided
by
errata.
According to errata ISR must filter out spurious RDR before data read not
after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.
Restored pre 6d9939f6514 way of handling errata.
Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
Tested on BBB and AM437x Starter Kit
Tested-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..e7cbcb0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -958,11 +958,13 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (dev-fifo_size)
num_bytes = dev-buf_len;
- omap_i2c_receive_data(dev, num_bytes, true);
-
- if (dev-errata I2C_OMAP_ERRATA_I207)
+ if (dev-errata I2C_OMAP_ERRATA_I207) {
i2c_omap_errata_i207(dev, stat);
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8) 0x3F;
+ }
+ omap_i2c_receive_data(dev, num_bytes, true);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
continue;
}
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
* Roger Quadros rog...@ti.com [141121 01:30]: On 11/21/2014 12:28 AM, Tony Lindgren wrote: +#include linux/omap-gpmc.h +#include linux/platform_data/omap-gpmc.h I think we should get rid for mach-omap2/gpmc.h and include the above two headers wherever needed. Well I'm trying to keep the churn on patching all board-*.c files down to minimum until they just get dropped. So let's keep gpmc.h around still for a little while for all the board-*.c files. diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 175564c..88721df 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -29,6 +29,7 @@ #include linux/delay.h #include linux/slab.h #include linux/omap-dma.h +#include linux/omap-gpmc.h #include linux/platform_data/gpio-omap.h #include trace/events/power.h @@ -43,7 +44,6 @@ #include common.h #include cm3xxx.h #include cm-regbits-34xx.h -#include gpmc.h #include prm-regbits-34xx.h #include prm3xxx.h #include pm.h And for the files that will stay around, let's not include gpmc.h. --- /dev/null +++ b/include/linux/platform_data/omap-gpmc.h @@ -0,0 +1,177 @@ +/* + * General-Purpose Memory Controller for OMAP2 + * + * Copyright (C) 2005-2006 Nokia Corporation + * + * 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. + */ + +#ifndef __OMAP2_GPMC_H +#define __OMAP2_GPMC_H + +#include linux/platform_data/mtd-nand-omap2.h Why do need to include this header here? Probably left over from the old code, that looks unnecessary. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote: On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). But in what way is it broken and how did this happen? Why are none of the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. signature.asc Description: Digital signature
Re: [PATCH 2/3] ARM: OMAP2+: Move GPMC initcall to devices.c
* Roger Quadros rog...@ti.com [141121 01:43]: On 11/21/2014 12:28 AM, Tony Lindgren wrote: This will us allow to just move gpmc.c to live under drivers in the next patch. Note that we now also remove the omap specific check for the initcall. That's OK as gpmc_probe() checks for the pdata and bails out for other platforms compiled in. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com I guess gpmc_init can't still be put under module_init() till we have fixed up some more issues in the GPMC driver. But it shouldn't prevent us from making the move to drivers/, so Acked-by: Roger Quadros rog...@ti.com Yeah I figured it's too close to the merge cycle to start playing with the initcall levels. It may already be possible to make it just module_init() but let's do that as separate patches after the move. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] drivers: bus: Move omap gpmc code to live under drivers
* Arnd Bergmann a...@arndb.de [141121 03:17]: On Friday 21 November 2014 11:15:05 Roger Quadros wrote: On 11/21/2014 12:28 AM, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Awesome! arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/Makefile | 2 +- drivers/bus/Kconfig | 3 +++ drivers/bus/Makefile | 3 ++- arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c | 0 5 files changed, 7 insertions(+), 2 deletions(-) rename arch/arm/mach-omap2/gpmc.c = drivers/bus/omap-gpmc.c (100%) Should we move it to drivers/memory/ instead? TI_AEMIF driver lives there. This is similar to OMAP-GPMC for but for Davinci and Keystone platforms. Agreed, using drivers/memory sounds better. Good point, I forgot we have separate drivers/memory and drivers/bus. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. signature.asc Description: Digital signature
Re: [PATCH 1/3] ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
* Tony Lindgren t...@atomide.com [141121 08:18]: * Roger Quadros rog...@ti.com [141121 01:30]: On 11/21/2014 12:28 AM, Tony Lindgren wrote: +#include linux/omap-gpmc.h +#include linux/platform_data/omap-gpmc.h I think we should get rid for mach-omap2/gpmc.h and include the above two headers wherever needed. Well I'm trying to keep the churn on patching all board-*.c files down to minimum until they just get dropped. So let's keep gpmc.h around still for a little while for all the board-*.c files. diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 175564c..88721df 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -29,6 +29,7 @@ #include linux/delay.h #include linux/slab.h #include linux/omap-dma.h +#include linux/omap-gpmc.h #include linux/platform_data/gpio-omap.h #include trace/events/power.h @@ -43,7 +44,6 @@ #include common.h #include cm3xxx.h #include cm-regbits-34xx.h -#include gpmc.h #include prm-regbits-34xx.h #include prm3xxx.h #include pm.h And for the files that will stay around, let's not include gpmc.h. After updating this patch to remove include of gpmc.h in any files this patch touches, we still have gpmc.h left in 11 files we're not touching right now. If we want to patch those, we can do it later on in a separate patch to avoid creating more dependencies between branches. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] drivers: bus: Move omap gpmc code to live under drivers
* Lokesh Vutla lokeshvu...@ti.com [141121 00:09]: On Friday 21 November 2014 03:58 AM, Tony Lindgren wrote: --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -5,7 +5,8 @@ obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o obj-$(CONFIG_IMX_WEIM) += imx-weim.o obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o I guess this is unrelated to $subject. Shouldn't this be dropped? Yes thanks for catching that. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] ARM: OMAP2+: hwmod: AM43x: add hwmod support for ADC on AM43xx
On Fri, 21 Nov 2014, Vignesh R wrote: This patch adds hwmod support for ADC on AM43xx. Since clockdomain and offsets of adc_tsc are different from AM33xx, ADC data has been directly added to AM43xx hwmod file. Signed-off-by: Vignesh R vigne...@ti.com Thanks, will try to queue this for v3.19. Will update my previous pull request. Otherwise it's v3.20 material. Note that I cannot test this patch locally due to the lack of an AM43xx board. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] i2c: omap: don't reset controller if Arbitration Lost detected
On Fri, Nov 21, 2014 at 01:28:44AM +0400, Alexander Kochetkov wrote:
Arbitration Lost is a expected situation in a multimaster environment.
IP correctly detect it.
The only reason for reseting IP in the AL case is to be sure to
avoid advisory 1.94 (omap3) and errata i595 (omap4):
I2C: After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer with workaround: The MST and STT bits inside
I2C_CON should be set to 1 at the same moment (avoid setting the
MST bit to 1 while STT = 0).
The driver never writes MST and STT bits separately and doesn't
create condition for errata. So the reset is not necessary.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
---
drivers/i2c/busses/i2c-omap.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ffb9c0..47103e7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -707,13 +707,17 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return 0;
/* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
+ if (dev-cmd_err (OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
omap_i2c_reset(dev);
__omap_i2c_init(dev);
return -EIO;
}
+ if (dev-cmd_err OMAP_I2C_STAT_AL) {
+ return -EIO;
+ }
The errno for AL is -EAGAIN. Curly braces are not needed.
+
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
--
1.7.9.5
signature.asc
Description: Digital signature
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
Before the patches were also jumps but I thought it is something Vignesh should know. Maybe there is some fix for that too? As Richard also noted, it would be nice if ti could let us know how to get the delay values right. By trial and error is IMHO not the best way. For the testing I used 3.16.7. 2014-11-21 16:37 GMT+01:00 Sekhar Nori nsek...@ti.com: On Friday 21 November 2014 08:41 PM, Johannes Pointner wrote: I tested version 4 of the patch series on a custom design and I saw also the jumps as described by Richard. I played a little with the sample delay and it got better but I couldn't completely remove the jumps. And before the patches were applied, there were no jumps at all? Which kernel are you using for testing? Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
Just move to drivers as further clean-up can now happen there finally. Let's also add Roger and me to the MAINTAINERS so we get notified for any patches related to GPMC. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- MAINTAINERS | 8 arch/arm/mach-omap2/Kconfig | 2 ++ arch/arm/mach-omap2/Makefile | 2 +- drivers/memory/Kconfig | 8 drivers/memory/Makefile | 1 + arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c | 0 6 files changed, 20 insertions(+), 1 deletion(-) rename arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c (100%) diff --git a/MAINTAINERS b/MAINTAINERS index dab92a7..78cc059 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6629,6 +6629,14 @@ L: linux-omap@vger.kernel.org S: Maintained F: sound/soc/omap/ +OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT +M: Roger Quadros rog...@ti.com +M: Tony Lindgren t...@atomide.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/memory/omap-gpmc.c +F: arch/arm/mach-omap2/*gpmc* + OMAP FRAMEBUFFER SUPPORT M: Tomi Valkeinen tomi.valkei...@ti.com L: linux-fb...@vger.kernel.org diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f4d06ae..0ea218e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -79,7 +79,9 @@ config ARCH_OMAP2PLUS select CLKSRC_MMIO select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC + select MEMORY select OMAP_DM_TIMER + select OMAP_GPMC select PINCTRL select SOC_BUS select TI_PRIV_EDMA diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3e824f8..bd85741 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-omap/include # Common support -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ +obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ omap_device.o sram.o drm.o diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 6d91c27..6759de7 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -41,6 +41,14 @@ config TI_EMIF parameters and other settings during frequency, voltage and temperature changes +config OMAP_GPMC + bool + help + This driver is for the General Purpose Memory Controller (GPMC) + present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows + interfacing to a variety of asynchronous as well as synchronous + memory drives like NOR, NAND, OneNAND, SRAM. + config MVEBU_DEVBUS bool Marvell EBU Device Bus Controller default y diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index c32d319..a7d410f 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -8,6 +8,7 @@ endif obj-$(CONFIG_ATMEL_SDRAMC) += atmel-sdramc.o obj-$(CONFIG_TI_AEMIF) += ti-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o +obj-$(CONFIG_OMAP_GPMC)+= omap-gpmc.o obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o diff --git a/arch/arm/mach-omap2/gpmc.c b/drivers/memory/omap-gpmc.c similarity index 100% rename from arch/arm/mach-omap2/gpmc.c rename to drivers/memory/omap-gpmc.c -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP2+: Move GPMC initcall to devices.c
This will us allow to just move gpmc.c to live under drivers
in the next patch.
Note that we now also remove the omap specific check for the
initcall. That's OK as gpmc_probe() checks for the pdata
and bails out for other platforms compiled in.
Also the postcore_initcall() maybe possible to change to
just regular module_init(), but let's do that in separate
patch after the move to drivers is done.
Cc: Arnd Bergmann a...@arndb.de
Acked-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 26 ++
arch/arm/mach-omap2/gpmc.c| 31 +--
2 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 324f02b..110256a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -445,3 +445,29 @@ static int __init omap2_init_devices(void)
return 0;
}
omap_arch_initcall(omap2_init_devices);
+
+static int __init omap_gpmc_init(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ char *oh_name = gpmc;
+
+ /*
+* if the board boots up with a populated DT, do not
+* manually add the device from this initcall
+*/
+ if (of_have_populated_dt())
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ pdev = omap_device_build(omap-gpmc, -1, oh, NULL, 0);
+ WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
+
+ return PTR_RET(pdev);
+}
+omap_postcore_initcall(omap_gpmc_init);
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc14f25..80dfb17 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -37,9 +37,6 @@
#include linux/platform_data/mtd-nand-omap2.h
#include linux/platform_data/mtd-onenand-omap2.h
-#include soc.h
-#include omap_device.h
-
#include asm/mach-types.h
#defineDEVICE_NAME omap-gpmc
@@ -2010,35 +2007,9 @@ static __exit void gpmc_exit(void)
}
-omap_postcore_initcall(gpmc_init);
+postcore_initcall(gpmc_init);
module_exit(gpmc_exit);
-static int __init omap_gpmc_init(void)
-{
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- char *oh_name = gpmc;
-
- /*
-* if the board boots up with a populated DT, do not
-* manually add the device from this initcall
-*/
- if (of_have_populated_dt())
- return -ENODEV;
-
- oh = omap_hwmod_lookup(oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n, oh_name);
- return -ENODEV;
- }
-
- pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
-
- return PTR_RET(pdev);
-}
-omap_postcore_initcall(omap_gpmc_init);
-
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
We still need to support platform data for omap3 until it's booting
in device tree only mode. So let's add platform_data/omap-gpmc.h for
that, and a minimal linux/omap-gpmc.h for the save and restore used
by the PM code.
Let's also keep a minimal mach-omap2/gpmc.h still around to avoid
churn on the board-*.c files. Once omap3 boots in device tree only
mode, we can drop mach-omap2/gpmc.h and we can make the data
structures in platform_data/omap-gpmc.h private to the GPMC driver.
Note that we can now also remove gpmc-nand.h and gpmc-onenand.h.
Cc: Arnd Bergmann a...@arndb.de
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-am3517crane.c| 1 +
arch/arm/mach-omap2/board-cm-t35.c | 3 +-
arch/arm/mach-omap2/board-cm-t3517.c | 3 +-
arch/arm/mach-omap2/board-flash.c | 4 +-
arch/arm/mach-omap2/board-flash.h | 1 -
arch/arm/mach-omap2/board-n8x0.c | 2 -
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +-
arch/arm/mach-omap2/gpmc-nand.c| 3 +-
arch/arm/mach-omap2/gpmc-onenand.c | 3 +-
arch/arm/mach-omap2/gpmc-onenand.h | 24 ---
arch/arm/mach-omap2/gpmc.c | 64 +-
arch/arm/mach-omap2/gpmc.h | 228 +
arch/arm/mach-omap2/pm34xx.c | 2 +-
.../gpmc-nand.h = include/linux/omap-gpmc.h | 18 +-
include/linux/platform_data/omap-gpmc.h| 177
16 files changed, 265 insertions(+), 273 deletions(-)
delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h
rename arch/arm/mach-omap2/gpmc-nand.h = include/linux/omap-gpmc.h (54%)
create mode 100644 include/linux/platform_data/omap-gpmc.h
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 212c316..fd16b76f 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -24,6 +24,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/platform_data/omap-gpmc.h
#include asm/mach-types.h
#include asm/mach/arch.h
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index c6df8ee..91738a1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -25,6 +25,7 @@
#include linux/input/matrix_keypad.h
#include linux/delay.h
#include linux/gpio.h
+#include linux/omap-gpmc.h
#include linux/platform_data/gpio-omap.h
#include linux/platform_data/at24.h
@@ -51,8 +52,6 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
#include common-board-devices.h
-#include gpmc.h
-#include gpmc-nand.h
#define CM_T35_GPIO_PENDOWN57
#define SB_T35_USB_HUB_RESET_GPIO 167
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 8a2c167..794756d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/leds.h
+#include linux/omap-gpmc.h
#include linux/rtc-v3020.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
@@ -41,7 +42,6 @@
#include common.h
#include linux/platform_data/mtd-nand-omap2.h
-#include gpmc.h
#include am35xx.h
@@ -50,7 +50,6 @@
#include hsmmc.h
#include common-board-devices.h
#include am35xx-emac.h
-#include gpmc-nand.h
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
static struct gpio_led cm_t3517_leds[] = {
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 2d245c2..b536b5a6 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -13,18 +13,18 @@
*/
#include linux/kernel.h
+#include linux/omap-gpmc.h
#include linux/platform_device.h
#include linux/mtd/physmap.h
#include linux/io.h
+#include linux/platform_data/omap-gpmc.h
#include linux/platform_data/mtd-nand-omap2.h
#include linux/platform_data/mtd-onenand-omap2.h
#include soc.h
#include common.h
#include board-flash.h
-#include gpmc-onenand.h
-#include gpmc-nand.h
#define REG_FPGA_REV 0x10
#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index 2fb5d41..ea9aaeb 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -12,7 +12,6 @@
*/
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
-#include gpmc.h
#define PDC_NOR1
#define PDC_NAND 2
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 97767a2..49c3c25 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -22,7
[PATCHv2 0/3] Move omap GPMC to live in drivers/memory
Hi, Here's version 2 of the patches to move omap GPMC (General Purpose Memory Controller) to live under drivers for further clean-up work. Changes from the first version are: - Few randconfig fixes for the first patch in the series - Don't include mach-omap2/gpmc.h any longer in any files we touch in this patch series, just keep it around for legacy reasons - Move GPMC to drivers/memory instead of drivers/bus Regards, Tony Tony Lindgren (3): ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header ARM: OMAP2+: Move GPMC initcall to devices.c memory: gpmc: Move omap gpmc code to live under drivers MAINTAINERS| 8 + arch/arm/mach-omap2/Kconfig| 2 + arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-cm-t35.c | 3 +- arch/arm/mach-omap2/board-cm-t3517.c | 3 +- arch/arm/mach-omap2/board-flash.c | 4 +- arch/arm/mach-omap2/board-flash.h | 1 - arch/arm/mach-omap2/board-n8x0.c | 2 - arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +- arch/arm/mach-omap2/devices.c | 26 +++ arch/arm/mach-omap2/gpmc-nand.c| 3 +- arch/arm/mach-omap2/gpmc-onenand.c | 3 +- arch/arm/mach-omap2/gpmc-onenand.h | 24 --- arch/arm/mach-omap2/gpmc.h | 228 + arch/arm/mach-omap2/pm34xx.c | 2 +- drivers/memory/Kconfig | 8 + drivers/memory/Makefile| 1 + .../gpmc.c = drivers/memory/omap-gpmc.c | 91 +--- .../gpmc-nand.h = include/linux/omap-gpmc.h | 18 +- include/linux/platform_data/omap-gpmc.h| 177 22 files changed, 310 insertions(+), 302 deletions(-) delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h rename arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c (95%) rename arch/arm/mach-omap2/gpmc-nand.h = include/linux/omap-gpmc.h (54%) create mode 100644 include/linux/platform_data/omap-gpmc.h -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
On Fri, Nov 21, 2014 at 10:34:16AM -0800, Tony Lindgren wrote: Just move to drivers as further clean-up can now happen there finally. Let's also add Roger and me to the MAINTAINERS so we get notified for any patches related to GPMC. Cc: Arnd Bergmann a...@arndb.de Cc: Roger Quadros rog...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- MAINTAINERS | 8 arch/arm/mach-omap2/Kconfig | 2 ++ arch/arm/mach-omap2/Makefile | 2 +- drivers/memory/Kconfig | 8 drivers/memory/Makefile | 1 + arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c | 0 6 files changed, 20 insertions(+), 1 deletion(-) rename arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c (100%) diff --git a/MAINTAINERS b/MAINTAINERS index dab92a7..78cc059 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6629,6 +6629,14 @@ L: linux-omap@vger.kernel.org S: Maintained F: sound/soc/omap/ +OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT +M: Roger Quadros rog...@ti.com +M: Tony Lindgren t...@atomide.com +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/memory/omap-gpmc.c +F: arch/arm/mach-omap2/*gpmc* + OMAP FRAMEBUFFER SUPPORT M: Tomi Valkeinen tomi.valkei...@ti.com L: linux-fb...@vger.kernel.org diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f4d06ae..0ea218e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -79,7 +79,9 @@ config ARCH_OMAP2PLUS select CLKSRC_MMIO select GENERIC_IRQ_CHIP select MACH_OMAP_GENERIC + select MEMORY select OMAP_DM_TIMER + select OMAP_GPMC select PINCTRL select SOC_BUS select TI_PRIV_EDMA diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3e824f8..bd85741 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-omap/include # Common support -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \ +obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \ omap_device.o sram.o drm.o diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 6d91c27..6759de7 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -41,6 +41,14 @@ config TI_EMIF parameters and other settings during frequency, voltage and temperature changes +config OMAP_GPMC + bool shouldn't you make this selectable ? I might want to build a kernel without GPMC support because my board just doesn't use GPMC :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
* Felipe Balbi ba...@ti.com [141121 10:40]: On Fri, Nov 21, 2014 at 10:34:16AM -0800, Tony Lindgren wrote: --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -41,6 +41,14 @@ config TI_EMIF parameters and other settings during frequency, voltage and temperature changes +config OMAP_GPMC + bool shouldn't you make this selectable ? I might want to build a kernel without GPMC support because my board just doesn't use GPMC :-) Eventually yes, but let's keep it separate from this move. We'd have to do something like this: - Make omap MTD drivers depend on OMAP_GPMC - Make tusb6010 depend on OMAP_GPMC - Make smc911x depend on OMAP_GPMC - Build arch/arm/mach-omap2/*gpmc*.c conditionally depending on OMAP_GPMC Adding stubs for omap-gpmc probably does not make sense as these devices really depend on GPMC. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL v2] ARM: OMAP2+: some more hwmod clock patches for v3.19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 79005fbd3e1d671d08c45c9140ee9826efdc367c: ARM: OMAP2+: hwmod: drop unnecessary list initialization (2014-11-13 09:36:55 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.19/omap-b2 for you to fetch changes up to 1f074f996482220f90fbe3dcfafeb3db46ec748a: Merge branch 'adc-support-v3.19' into omap-b-for-v3.19 (2014-11-21 11:05:05 -0700) - Several more OMAP patches targeted for v3.19. They include: - - OMAP4/5: DSS hwmod cleanup patches from Tomi Valkeinen. - - DRA7xx: hwmod data support for UARTs 7 through 10. - - AM43xx: hwmod data support for the onboard ADC. Basic build, boot, and PM test reports are here: http://www.pwsan.com/omap/testlogs/omap-b-for-v3.19/20141121110550/ Note that I cannot test the DRA7xx or AM43xx patches, since I do not have these boards. - Ambresh K (1): ARM: DRA7: hwmod data: Add missing UART hwmod data Paul Walmsley (2): Merge branch 'dra7xx-uart-hwmod-v3.19' into omap-b-for-v3.19 Merge branch 'adc-support-v3.19' into omap-b-for-v3.19 Tomi Valkeinen (6): ARM: OMAP2+: hwmod: add parent_hwmod support ARM: OMAP5: hwmod: set DSS submodule parent hwmods ARM: OMAP4: hwmod: set DSS submodule parent hwmods ARM: OMAP4: hwmod: use MODULEMODE properly ARM: OMAP4: fix RFBI iclk ARM: dts: omap4.dtsi: remove dss_fck Vignesh R (1): ARM: OMAP2+: hwmod: AM43x: add hwmod support for ADC on AM43xx arch/arm/boot/dts/omap4.dtsi | 2 +- arch/arm/boot/dts/omap44xx-clocks.dtsi | 8 --- arch/arm/mach-omap2/omap_hwmod.c | 22 +++ arch/arm/mach-omap2/omap_hwmod.h | 8 +++ arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 39 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 25 +--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 5 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 100 + 8 files changed, 191 insertions(+), 18 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUb4+tAAoJEMePsQ0LvSpL1a8P+gI4wOY+CbUF77ya5r40nVsR zkfYpzEZUaNXWXxB2muPuJIEbv3GEU/ytiyDzApKfnILbIuOnHtUPl+du6mivr88 v5SeRSOUDPldvv0pEzB+QM9u0ugheWbBTTYwIRoUPvy2Ns2wj7lr6rRmu56aRhSe +a4uryYUidSeVNS7ssw5n6L2eTLe2dQZvrn6TF/LewRQ8TbmjCNPESfvsEPBGyW6 mNNbO4dT0fLHQqki+lHDiEMe3LD+vrzYJpyrluDXLw9eJdVLKqg08klPUEFGiNRU zKcaqebrqqQRwrjrr3MygxgtXDQ9rgBSiW6jRXMe9bXdXnnQeEga0yOLd37pWMIz JXh9AhBW+lLCWqydr+/z/KlnEY/1VyXa6u8tIAX4Egzv2oIMnwzrZfjNtMGykFk3 2pczwb5Ftync/D/80QsR/iwqiNd6rzfDMz+1ALNO5ywuhFrYlCVFgPRfxayLfsbl FSIv8QzJ6vPiRebIfZGoGWddnKnnSBItJgqJuk1lqHbSjrB+o+ODRUGuaKRO1ZYJ ZM7Ar9AMuhw8Zwv23RZfgvsgqG4PGc2gnACy1B9iW7xzVHAdQ/b4rG9DI9whfpQ0 BewTTEvRmVx9xXJnyAPnsQIK8wodG7i0M7j3eWUSnGmYVR3SOYwssJspwzSIzhMC JwqOODpI8W9/oMyd+RUB =GlT7 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote: Before the patches were also jumps but I thought it is something Vignesh should know. Maybe there is some fix for that too? As Richard also noted, it would be nice if ti could let us know how to get the delay values right. By trial and error is IMHO not the best way. That is not only an opinion, it is a matter of fact. TI really dropped the ball on this one. I thought the patch series was a sign they finally were going to properly address this issue. Wrong again. The data sheet for the TI part used to have a reference to an app-note for the touch controller. spruh73f page 1154 The Pen IRQ can only occur if the correct Pen Ctrl bits are high (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if the correct ground transistor biasing is set in the StepConfig [N] Register. Refer to the application notes for the correct settings. I searched high and low for this application note. Then, the data sheet got revised. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
-Original Message- From: Richard Cochran [mailto:richardcoch...@gmail.com] On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote: Before the patches were also jumps but I thought it is something Vignesh should know. Maybe there is some fix for that too? I believe I've seen the jumping behavior pop up at a couple random times in my testing. I think it relates to the hardware not properly registering a pen-up interrupt. When that's happening can you try running ts_calibrate? If you're not registering a pen-up event then you won't be able to advance through those touch points. Is this behavior related to capturing ADC samples, or do you see this behavior even without capturing ADC samples? As Richard also noted, it would be nice if ti could let us know how to get the delay values right. By trial and error is IMHO not the best way. That is not only an opinion, it is a matter of fact. TI really dropped the ball on this one. I thought the patch series was a sign they finally were going to properly address this issue. Wrong again. These patches originate from work I did on TI's SDK 7.00 (3.12 kernel). The touchscreen is working beautifully in that environment and we are putting forth significant effort to bring those improvements to the community. Things do not seem to be working as well with the current mainline kernel. I've been reviewing various patches between 3.12 and the mainline to understand why it's different. I believe I have figured this out, and I have discussions going separately with individuals that contributed those patches in order to come up with the best possible solution, i.e. we likely need a few additional changes to this patch set. The CHARGECONFIG delay serves precisely the same purpose as the udelay in the original code base. How did you determine the udelay value in the first place? I went through the effort of figuring out a way to make the delay into a HARDWARE delay instead of a software delay so that it could be removed from the ISR. That delay time relates to settling time and so it's going to be dependent on your PCB. You could hook up an oscilloscope and attempt to capture this parameter from the signals themselves. Personally I think that's a lot more difficult than just doing a few iterations of testing. The data sheet for the TI part used to have a reference to an app-note for the touch controller. spruh73f page 1154 The Pen IRQ can only occur if the correct Pen Ctrl bits are high (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if the correct ground transistor biasing is set in the StepConfig [N] Register. Refer to the application notes for the correct settings. I searched high and low for this application note. Then, the data sheet got revised. Such an application note does not exist, which explains why you didn't find it and why we have removed that reference from the TRM. Sorry for your trouble. We always strive for accurate documentation. -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] i2c: omap: don't reset controller if Arbitration Lost detected
Arbitration Lost is an expected situation in a multimaster
environment. I2C controller (IP) correctly detect and report AL.
The only one visible reason for reseting IP in the AL case is
to avoid advisory 1.94 (omap3) and errata i595 (omap4): I2C:
After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer.
Errata workaround states: The MST and STT bits inside I2C_CON
should be set to 1 at the same moment (avoid setting the MST bit
to 1 while STT = 0). The driver never set MST and STT bits
separately and doesn't create condition for errata. So the reset
is not necessary.
Also corrected return value for AL to -EAGAIN.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
---
On 21.10.2014 21:11, Wolfram Sang w...@the-dreams.de wrote:
The errno for AL is -EAGAIN. Curly braces are not needed.
Thank you, Wolfram, fixed.
drivers/i2c/busses/i2c-omap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ffb9c0..02da567 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -707,13 +707,15 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return 0;
/* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
- OMAP_I2C_STAT_XUDF)) {
+ if (dev-cmd_err (OMAP_I2C_STAT_ROVR | OMAP_I2C_STAT_XUDF)) {
omap_i2c_reset(dev);
__omap_i2c_init(dev);
return -EIO;
}
+ if (dev-cmd_err OMAP_I2C_STAT_AL)
+ return -EAGAIN;
+
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix i207 errata handling
21 нояб. 2014 г., в 19:08, Felipe Balbi ba...@ti.com написал(а): Tested on BBB and AM437x Starter Kit Tested-by: Felipe Balbi ba...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com 21 нояб. 2014 г., в 0:10, Aaro Koskinen aaro.koski...@iki.fi написал(а): I could not see any breakage or anything wrong on OMAP2 OMAP3. On OMAP1 I don't have anything on the OMAP I2C bus, so cannot really test anything there. Tested-by: Aaro Koskinen aaro.koski...@iki.fi 21 нояб. 2014 г., в 21:11, Wolfram Sang w...@the-dreams.de написал(а): The errno for AL is -EAGAIN. Curly braces are not needed. Guys, I really appreciate you help. So much testing and review. I could not have done one. Thank you! Alexander. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix i207 errata handling
21 нояб. 2014 г., в 3:29, Alexander Kochetkov al.koc...@gmail.com написал(а): Found by code review. Real impact haven't seen. Tested on Beagleboard XM C. Does anybody know the certain rare conditions when RDR errata appears? I tested without luck (Beagleboard XM C). Spent half a day trying to catch the errata without luck. Tried to simulate noise on the bus in hope it may happen. Tried to run with OMAP_I2C_FLAG_NO_FIFO flag. What a mystery errata. Hiding. Anyway, thanks! Have a nice weekend! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v2] ARM: OMAP2+: some more hwmod clock patches for v3.19
* Paul Walmsley p...@pwsan.com [141121 11:19]: Hi Tony The following changes since commit 79005fbd3e1d671d08c45c9140ee9826efdc367c: ARM: OMAP2+: hwmod: drop unnecessary list initialization (2014-11-13 09:36:55 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.19/omap-b2 for you to fetch changes up to 1f074f996482220f90fbe3dcfafeb3db46ec748a: Merge branch 'adc-support-v3.19' into omap-b-for-v3.19 (2014-11-21 11:05:05 -0700) Several more OMAP patches targeted for v3.19. They include: - OMAP4/5: DSS hwmod cleanup patches from Tomi Valkeinen. - DRA7xx: hwmod data support for UARTs 7 through 10. - AM43xx: hwmod data support for the onboard ADC. Basic build, boot, and PM test reports are here: http://www.pwsan.com/omap/testlogs/omap-b-for-v3.19/20141121110550/ Note that I cannot test the DRA7xx or AM43xx patches, since I do not have these boards. Pulling into omap-for-v3.19/soc thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: Add devicetree for NovaTech OrionLXm
* Felipe Balbi ba...@ti.com [141117 11:10]: On Mon, Nov 17, 2014 at 01:02:35PM -0600, George McCollister wrote: This adds the NovaTech OrionLXm which is based on the AM335x SoC http://www.novatechweb.com/substation-automation/orionlxm/ RAM: 512MiB Flash: 4GB eMMC Ethernet PHYs: 2x Micrel KSZ8041FTLI USB ports are used internally by the expansion cards. Internal micro SD slot is available. Signed-off-by: George McCollister george.mccollis...@gmail.com this looks might better to my eyes: Reviewed-by: Felipe Balbi ba...@ti.com Applying into omap-for-v3.19/dt-v2 thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
* NeilBrown ne...@suse.de [141118 19:45]: On Wed, 12 Nov 2014 16:31:54 -0600 Felipe Balbi ba...@ti.com wrote: this is actually what the USB Battery Charging spec requires us to implement. If Linux is doing differently, it's a bug on Linux which should be fixed :-) No host is allowed to source more then one unit load (100mA in LS/FS/HS, 150mA in SS) until the device is fully enumerated. Host are also required to drop max current budget to 8mA (IIRC) if the device doesn't enumerate for however many minutes (I guess it was a pretty long threshold, something like half an hour or so. My memory fails me right now). I think the twl4030 driver does do the right thing unless the allow_usb module parameter is set, in which case it enables charging at a higher rate which is 600mA (default value of BCIIREF1). It would be nice if the driver could check if a charger was plugged in and act accordingly. The charger I have for my openmoko is identified by a 47K resistor between ID and ground. The twl4030 can detect that easily enough, but it isn't very standard. Sounds doable to me, feel free to patch it up since you guys are using the twl4030 charger :) The standard is of course to have D+ and D- shorted, but I don't know if the twl4030 can detect that? If it can, then getting some very early code to check for the short (or the 47k resistor) and quickly enabling charging might be a sufficient solution. I guess. Note that there's also the USB BC1.2 spec that is more complicated than having the data lines shorted. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
* Daniel Thompson daniel.thomp...@linaro.org [141117 06:53]: The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi Looks OK to me, probably best that these are queued all together so: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
* Roger Quadros rog...@ti.com [141117 05:10]: The SoC contains 2 DCAN modules. Add them. Thanks applying all into omap-for-v3.19/dt-v2. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Gumstix DuoVero: Bind vdac regulator to hdmi node
* Adam YH Lee adam.yh@gmail.com [141113 10:06]:
The HDMI node does not have a power supply attached. As a result its
power regulator, VDAC, shuts off on boot and screen loses signal.
This attaches VDAC (vdda_hdmi_dac) to HDMI's vdda-supply.
Applying into omap-for-v3.19/dt-v2 thanks.
Tony
Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
arch/arm/boot/dts/omap4-duovero-parlor.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts
b/arch/arm/boot/dts/omap4-duovero-parlor.dts
index 6dc84d9..1a78f01 100644
--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -177,6 +177,7 @@
hdmi {
status = ok;
+ vdda-supply = vdac;
pinctrl-names = default;
pinctrl-0 = dss_hdmi_pins;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: OMAP3-N900: add si4713 support
* Sebastian Reichel s...@kernel.org [141114 17:49]: Add si4713 node to the N900 device tree file. Applying into omap-for-v3.19/dt-v2 thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DTS: ARM: OMAP3-N900: Add n900-battery support
* Sebastian Reichel s...@kernel.org [141114 18:10]: This adds support for the N900's battery to the Nokia N900 DTS file. Applying this too thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: dts: DRA7: Add node for RTC
* Lokesh Vutla lokeshvu...@ti.com [141119 04:26]:
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
Applying into omap-for-v3.19/dt-v2 thanks.
Tony
---
Changes since v1:
- Fixed rtc dt node label.
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..5d92562 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+ rtc@48838000 {
+ compatible = ti,am3352-rtc;
+ reg = 0x48838000 0x100;
+ interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = rtcss;
+ clocks = sys_32k_ck;
+ };
+
omap_control_usb2phy1: control-phy@4a002300 {
compatible = ti,control-phy-usb2;
reg = 0x4a002300 0x4;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: dts: sbc-t3x: add more features support
* Dmitry Lifshitz lifsh...@compulab.co.il [141118 01:15]: Add support for more SBC-T3x single board computers features: * CM-T3x CoM and SB-T35 baseboard EEPROMs * TV out * Touchscreen * CM-T3x30 audio * CM-T3x30 keypad Applying all into omap-for-v3.19/dt-v2 thanks. Tony Dmitry Lifshitz (9): ARM: dts: cm-t3x: cleanup comments indentation ARM: dts: cm-t3x: add ADS7846 touchscreen support ARM: OMAP2+: remove cm-t3x touchscreen pdata quirk ARM: dts: cm-t3x: add EEPROM support ARM: dts: sb-t35: add EEPROM support ARM: dts: cm-t3x: add TV out support ARM: dts: sbc-t3x: add TV out display alias ARM: dts: sbc-t3x30: add audio support ARM: dts: cm-t3x30: add keypad support arch/arm/boot/dts/omap3-cm-t3x.dtsi | 119 +++-- arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 31 + arch/arm/boot/dts/omap3-sb-t35.dtsi | 36 ++ arch/arm/boot/dts/omap3-sbc-t3517.dts |1 + arch/arm/boot/dts/omap3-sbc-t3530.dts |1 + arch/arm/boot/dts/omap3-sbc-t3730.dts |1 + arch/arm/mach-omap2/pdata-quirks.c|3 - 7 files changed, 183 insertions(+), 9 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/10] ARM: dts: am4372: Add DCAN nodes
* Tony Lindgren t...@atomide.com [141121 15:52]: * Roger Quadros rog...@ti.com [141117 05:10]: The SoC contains 2 DCAN modules. Add them. Thanks applying all into omap-for-v3.19/dt-v2. Oops, have to drop these as they cause this on make dtbs: DTC arch/arm/boot/dts/dra7-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/am57xx-beagle-x15.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d DTC arch/arm/boot/dts/dra72-evm.dtb Warning (reg_format): reg property in /soc/can@481cc000 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (reg_format): reg property in /soc/can@481d has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481cc000 Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/can@481d Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/can@481d Care to update the patches for that and then do a pull request for me? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: dts: sbc-t3x: add more features support
* Tony Lindgren t...@atomide.com [141121 16:04]: * Dmitry Lifshitz lifsh...@compulab.co.il [141118 01:15]: Add support for more SBC-T3x single board computers features: * CM-T3x CoM and SB-T35 baseboard EEPROMs * TV out * Touchscreen * CM-T3x30 audio * CM-T3x30 keypad Applying all into omap-for-v3.19/dt-v2 thanks. Had to remove pinctr reference for missing i2c1_pins in omap3-cm-t3x.dtsi for make dtbs to work. And had to drop the audio and tv patches because missing reference to vdac. Please update the missing patches against current omap-for-v3.19/dt-v2 that I just pushed out. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm
* Vignesh R vigne...@ti.com [141121 02:18]: This patch adds tscadc DT entries for am437x-gp-evm and am43x-epos-evm. Applying into omap-for-v3.19/dt-v2 thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] arm: omap: omap2plus_defconfig: enable ECAP and EHRPWM
* Felipe Balbi ba...@ti.com [141118 10:08]: Many of AM335x and AM437x hook backlight to one of these two devices. By enabling their drivers we make sure pwm-backlight can do its thing. Applying patches 1 - 5 to omap-for-v3.19/soc thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] input: touchscreen: edt-ft5x06: fix driver autoprobing
Hi Wolfram,
On Tue, Nov 18, 2014 at 02:19:07PM -0600, Felipe Balbi wrote:
On Tue, Nov 18, 2014 at 12:14:21PM -0800, Dmitry Torokhov wrote:
On Tue, Nov 18, 2014 at 02:03:40PM -0600, Felipe Balbi wrote:
On Tue, Nov 18, 2014 at 11:59:02AM -0800, Dmitry Torokhov wrote:
On Tue, Nov 18, 2014 at 01:27:42PM -0600, Felipe Balbi wrote:
Because with OF we can pass more specific
compatible flags (such as edt-ft5306) instead
of generic edt-ft5x06, when i2c-core's
of_i2c_register_devices() tries to request_module(),
it'll request it with a non-existent specific module
alias.
In order to have this driver autoprobing again, we
just need to add missing MODULE_ALIAS() entries to
edt-ft5x06 driver.
Thanks to Dmitry for noticing that it actually should
autoprobe even with of_device_id.
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: linux-in...@vger.kernel.org
Cc: sta...@vger.kernel.org # v3.15+
Fixes: dac90dc2 (Input: edt-ft5x06 - add DT support)
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/input/touchscreen/edt-ft5x06.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index ee3434f..bcbf688 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1147,6 +1147,9 @@ static struct i2c_driver edt_ft5x06_ts_driver =
{
module_i2c_driver(edt_ft5x06_ts_driver);
+MODULE_ALIAS(i2c:edt-ft5206);
+MODULE_ALIAS(i2c:edt-ft5306);
+MODULE_ALIAS(i2c:edt-ft5406);
MODULE_AUTHOR(Simon Budig simon.bu...@kernelconcepts.de);
MODULE_DESCRIPTION(EDT FT5x06 I2C Touchscreen Driver);
MODULE_LICENSE(GPL);
--
2.1.0.GIT
Here is what I see if I run modinfo on the module:
dtor@dtor-ws:~/kernel/work$ modinfo
drivers/input/touchscreen/edt-ft5x06.ko
filename:
/home/dtor/kernel/work/drivers/input/touchscreen/edt-ft5x06.ko
license:GPL
description:EDT FT5x06 I2C Touchscreen Driver
author: Simon Budig simon.bu...@kernelconcepts.de
alias: i2c:edt-ft5x06
alias: of:N*T*Cedt,edt-ft5406*
alias: of:N*T*Cedt,edt-ft5306*
alias: of:N*T*Cedt,edt-ft5206*
depends:i2c-core
intree: Y
vermagic: 3.17.0+ SMP preempt mod_unload
As you can see we already have what I consider proper modaliases for the
driver. Why don't they work? Is it because modprobe doe snot know how to
handle OF-style modaliases or device's uevents are missing OF data in
them?
no, it's because i2c call request_module for i2c:edt-ft5306. i2c core
never uses any of the of aliases.
1. I think both i2c and spi are cheating in this regard: they should
rely on normal driver request paths through udev.
2. I2C should emit proper modalias for devices coming by the way of
devicetree. It already does special handling for ACPI, it needs to do
the same for OF. I think SPI does the right thing there.
I'll let Wolfram comment here for I2C.
Can you comment on this ? As of today i2c-based drivers will probe with
DT-based boot if DT's compatible is set to the same id as in struct
i2c_device_id. No i2c driver with of_device_id can autoprobe using OF
ids.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/4] i2c: omap: don't reset controller if Arbitration Lost detected
On Sat, Nov 22, 2014 at 02:51:47AM +0400, Alexander Kochetkov wrote:
Arbitration Lost is an expected situation in a multimaster
environment. I2C controller (IP) correctly detect and report AL.
The only one visible reason for reseting IP in the AL case is
to avoid advisory 1.94 (omap3) and errata i595 (omap4): I2C:
After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer.
Errata workaround states: The MST and STT bits inside I2C_CON
should be set to 1 at the same moment (avoid setting the MST bit
to 1 while STT = 0). The driver never set MST and STT bits
separately and doesn't create condition for errata. So the reset
is not necessary.
Also corrected return value for AL to -EAGAIN.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
you could have kept my tested-by and reviewed-by:
Tested-by: Felipe Balbi ba...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
On 21.10.2014 21:11, Wolfram Sang w...@the-dreams.de wrote:
The errno for AL is -EAGAIN. Curly braces are not needed.
Thank you, Wolfram, fixed.
drivers/i2c/busses/i2c-omap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ffb9c0..02da567 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -707,13 +707,15 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
return 0;
/* We have an error */
- if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
- OMAP_I2C_STAT_XUDF)) {
+ if (dev-cmd_err (OMAP_I2C_STAT_ROVR | OMAP_I2C_STAT_XUDF)) {
omap_i2c_reset(dev);
__omap_i2c_init(dev);
return -EIO;
}
+ if (dev-cmd_err OMAP_I2C_STAT_AL)
+ return -EAGAIN;
+
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
