Re: [PATCH] i2c: omap: fix NACK and Arbitration Lost irq handling
On Tue, Nov 18, 2014 at 09:00:58PM +0400, Alexander Kochetkov wrote: > commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts) > changed the interrupt handler to complete transfers without clearing > XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be > fired again. As a result, ISR keep processing transfer after it was already > complete (from the driver code point of view). > > A didn't see real impacts of the 1d7afc9, but it is really bad idea to > have ISR running on user data after transfer was complete. > > It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be > handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32). > > According to specs (if I understood correctly), in case of NACK and AL driver > must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and > NACK, AL, ARDY, and XDR (Master Transmitter Mode). > > All that is done down the code under the if condition: > if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ... > > The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so > no interrupts is fired after ISR informs the rest of driver what transfer > complete. > > Note: instead of removing break under NACK case, we could just replace 'break' > with 'continue' and allow NACK transfer to finish using ARDY event. I found > that NACK and ARDY bits usually set together. That case confirm TI wiki: > http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK > > In order if someone interested in the event traces for NACK and AL cases, > I sent them to mailing list. > > Tested on Beagleboard XM C. > > Signed-off-by: Alexander Kochetkov > Fixes: 1d7afc9 i2c: omap: ack IRQ in parts > Cc: # v3.7+ > Applied to for-current, thanks! signature.asc Description: Digital signature
Re: [PATCH] Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
> > Tested on Beagleboard XM C. > > > > Signed-off-by: Alexander Kochetkov > > Cc: # v3.7+ > > This is good, but subject is wrong. That fixes line should not be the > subject, it should be here after Cc :-) I'll take this as an Ack unless you protest. signature.asc Description: Digital signature
Re: [PATCH v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
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
> > ...
> >
> >> 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.
- 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 v2 2/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
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
> ...
>
>> 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?
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
Re: [PATCH] i2c: omap: fix i207 errata handling
21 нояб. 2014 г., в 3:16, Alexander Kochetkov написал(а): > 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. It's is seen if open 6d9939f651419a63e09^ and 6d9939f651419a63e09 side by side: 6d9939f651419a63e09^: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-omap.c?id=540a4790f7da0d3ca5ad9d726f198a5eb4db05ec#n800 6d9939f651419a63e09: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-omap.c?id=6d9939f651419a63e091105663821f9c7d3fec37#n800 Errata "2C: RDR Flag May Be Incorrectly Set" http://www.ti.com/lit/er/sprz319f/sprz319f.pdf 21 нояб. 2014 г., в 3:16, Alexander Kochetkov написал(а): > 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). -- 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] i2c: omap: fix i207 errata handling
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
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
---
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
--
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] drivers: bus: Move omap gpmc code to live under drivers
Just move to drivers as further clean-up can now happen there finally. Cc: Arnd Bergmann Cc: Roger Quadros Signed-off-by: Tony Lindgren --- 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 + +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 -- 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 0/3] Move omap GPMC to live in drivers/bus
Hi all, Looks like we can now finally move omap GPMC (General Purpose Memory Controller) to live under drivers for further clean-up work. 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 drivers: bus: Move omap gpmc code to live under drivers arch/arm/mach-omap2/Kconfig| 1 + arch/arm/mach-omap2/Makefile | 2 +- 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/devices.c | 26 +++ 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.h | 224 + arch/arm/mach-omap2/pm34xx.c | 2 +- drivers/bus/Kconfig| 3 + drivers/bus/Makefile | 3 +- .../mach-omap2/gpmc.c => drivers/bus/omap-gpmc.c | 91 ++--- .../gpmc-nand.h => include/linux/omap-gpmc.h | 18 +- include/linux/platform_data/omap-gpmc.h| 177 20 files changed, 287 insertions(+), 298 deletions(-) delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h rename arch/arm/mach-omap2/gpmc.c => drivers/bus/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
[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.
Cc: Arnd Bergmann
Cc: Roger Quadros
Signed-off-by: Tony Lindgren
---
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
#include
-#include "soc.h"
-#include "omap_device.h"
-
#include
#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.
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
Cc: Roger Quadros
Signed-off-by: Tony Lindgren
---
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
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index c6df8ee..2dbf4ce 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -52,7 +52,6 @@
#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..56621a5 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -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
+#include
#include
#include
#include
+#include
#include
#include
#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
#include
-#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 +22,6 @@
#include
#include
#include
-#include
#include
#include
@@ -32,7 +31,6 @@
#include "common.h"
#include "mmc.h"
#include "soc.h"
-#include "gpmc-onenand.h"
#include "common-board-devices.h"
#define TUSB6010_ASYNC_CS 1
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index f322016..adab2c2e 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -51,7 +51,7 @@
#include "sdram-micron-mt46h32m32lf-6.h"
#include "hsmmc.h"
#include "common-board-devices.h"
-#include "gpmc-nand.h"
+#include "gpmc.h"
#define PANDORA_WIFI_IRQ_GPIO 21
#define PANDORA_WIFI_NRESET_GPIO 23
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 30e7d4c..acd754f 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -55,7 +55,6 @@
#include "hsmmc.h"
#include "common-board-devices.h"
#include "gpmc.h"
-#include "gpmc-onenand.h"
#include "soc.h"
#include "omap-secure.h"
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index cb776431..3c21a9b 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -19,7 +19,6 @@
#include "gpmc.h"
#include "soc.h"
-#include "gpmc-nand.h"
/* minimum size for IO mapping */
#d
[PATCH 3/4] i2c: omap: don't reset controller if Arbitration Lost detected
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
---
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
--
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/4] i2c: omap: cleanup register definitions
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
---
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
--
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/4] i2c: omap: implement workaround for handling invalid BB-bit values
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
---
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_TIMEOUT1000/* 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
+* the right decision.
+*/
+ systest = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ if ((systest & OMAP_I2C_SYSTEST_SCL_I_FUNC) &&
+ (systest & OMAP_I2C
[PATCH 4/4] i2c: omap: add notes related to i2c multimaster mode
No functional changes. Signed-off-by: Alexander Kochetkov --- 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 -- 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
[RFC 0/4] i2c: omap: patch series related to multimaster mode
Here is the patch series intended to improve stability of i2c-omap driver in the i2c multimaster environments. Tested on Beagleboard XM C. For now all fine. No controller timeouts, no data corruptions. Also impelemented i2c bus fault detection during startup and after reset. So, instead of the message "controller timeout" blaming IP, you get "timeout waiting for bus ready". What do think about it? Signed-off-by: Alexander Kochetkov --- -- 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 NACK and Arbitration Lost irq handling
On Tue, Nov 18, 2014 at 09:00:58PM +0400, Alexander Kochetkov wrote:
> commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
> changed the interrupt handler to complete transfers without clearing
> XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
> fired again. As a result, ISR keep processing transfer after it was already
> complete (from the driver code point of view).
>
> A didn't see real impacts of the 1d7afc9, but it is really bad idea to
> have ISR running on user data after transfer was complete.
>
> It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
> handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
>
> According to specs (if I understood correctly), in case of NACK and AL driver
> must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
> NACK, AL, ARDY, and XDR (Master Transmitter Mode).
>
> All that is done down the code under the if condition:
> if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
>
> The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
> no interrupts is fired after ISR informs the rest of driver what transfer
> complete.
>
> Note: instead of removing break under NACK case, we could just replace 'break'
> with 'continue' and allow NACK transfer to finish using ARDY event. I found
> that NACK and ARDY bits usually set together. That case confirm TI wiki:
> http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
>
> In order if someone interested in the event traces for NACK and AL cases,
> I sent them to mailing list.
>
> Tested on Beagleboard XM C.
>
> Signed-off-by: Alexander Kochetkov
> Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
> Cc: # v3.7+
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
> ---
> drivers/i2c/busses/i2c-omap.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 90dcc2e..9af7095 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
> if (stat & OMAP_I2C_STAT_NACK) {
> err |= OMAP_I2C_STAT_NACK;
> omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
> - break;
> }
>
> if (stat & OMAP_I2C_STAT_AL) {
> dev_err(dev->dev, "Arbitration lost\n");
> err |= OMAP_I2C_STAT_AL;
> omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
> - break;
> }
>
> /*
> --
> 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
--
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 0/3] Add support for ADC on am437x-gp and am43x-epos-evm
On Fri, 14 Nov 2014, Tony Lindgren wrote: > * Vignesh R [141113 20:09]: > > > > On Tuesday 04 November 2014 04:45 PM, Vignesh R wrote: > > > This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. > > > The ADC clock hwmod data of am33xx has been moved to commom place so that > > > both am43xx and am33xx can reuse them. > > > tscadc DT node has been adided to am437x-gp and am43x-epos dt files. > > > With these patches, ADC functionalities are now available on am43xx. > > > > > > Changelog: > > > > > > 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 > > > > > > > Please accept these patches. > > Adding Paul to Cc, I don't think Paul has seen these, probably because > get_maintainer.pl did not catch these hwmod files? Yeah we didn't have top-level coverage for the data files and my attempts to find other in-depth reviewers has so far failed. So just sent this: http://marc.info/?l=linux-omap&m=141650684712440&w=2 Want to take it upstream? - 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] MAINTAINERS: add maintainer for OMAP hwmod data
I wind up reviewing and committing most of the OMAP hwmod data patches, so, add myself to MAINTAINERS there so folks will cc me. Signed-off-by: Paul Walmsley Cc: Tony Lindgren Cc: Benoît Cousson --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c444907ccd69..d904e13a4d54 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6716,6 +6716,12 @@ L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* +OMAP HWMOD DATA +M: Paul Walmsley +L: linux-omap@vger.kernel.org +S: Maintained +F: arch/arm/mach-omap2/omap_hwmod*data* + OMAP HWMOD DATA FOR OMAP4-BASED DEVICES M: Benoît Cousson L: linux-omap@vger.kernel.org -- 2.1.3
[PATCH 3/7] dwc3: dwc3-keystone: fix error return code
From: Julia Lawall
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
The patches in this series are independent of each other.
drivers/usb/dwc3/dwc3-keystone.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index dd8d2df..fe3b933 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -123,6 +123,7 @@ static int kdwc3_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "missing irq\n");
+ error = irq;
goto err_irq;
}
--
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 0/7] fix error return code
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c@i;
|
ret = -c@i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}
@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@
// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != &ret
when any
(
if (<+... ret = e5 ...+>) S1
|
if (<+... &ret ...+>) S1
|
if@p2(<+...x = fn(...)...+>)
{
... when != ret = e6
when forall
return@p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+=e4\|ret-=e4\)
when != &ret
(
if (<+... ret = e3 ...+>) S
|
if (<+... &ret ...+>) S
|
if@p2(<+...\(x != 0\|x < 0\|x == NULL\|IS_ERR(x)\)...+>)
{
... when != ret = e2
when forall
return@p3 ret;
}
)
)
... when any
}
@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@
f(...) { <...pr@p(...,c,...)...> }
@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@
f(...) { ... when any
g@p(...,ret,...)
... when any
}
@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@
// ignore the above if there is some path where the variable is set to
// something else
(
if@p1 (\(ret < 0\|ret != 0\)) S1
|
ret@p1 = 0
)
... when any
\(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\|&ret\)
... when any
if@p2(...) S2
@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@
ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+=e1\|ret-=e1\)
when != &ret
when any
if@p2(...) S2
@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@
// likewise ignore it if there has been an intervening return
ret@p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if@p2(...) S2
@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
//
--
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] ARM: OMAP2+: some clock/hwmod patches for v3.19
On Fri, 14 Nov 2014, Tony Lindgren wrote: > Pulling into omap-for-v3.19/soc thanks. FYI, looks like there are > few more open hwmod related threads you may want to look at: Thanks for the ping... > [PATCH v2 0/3] Add support for ADC on am437x-gp and am43x-epos-evm Just posted some comments about this ADC one. > [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods > [PATCH] ARM: DRA7: hwmod data: Add missing UART hwmod data Reviewed & pulled these into a branch and just sent the pull request; thanks. Looks like Lokesh has another DRA7xx hwmod data patch for RTC that seems to be a fix. Have sent some comments. That one might come in late for v3.18-rc if it turns out to pertain to those kernels. - 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
[GIT PULL] 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-b for you to fetch changes up to eb039a175163ebc2df4612c4a5393143017ce473: Merge branch 'dra7xx-uart-hwmod-v3.19' into omap-b-for-v3.19 (2014-11-20 01:50:32 -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. Basic build, boot, and PM test reports are here: http://www.pwsan.com/omap/testlogs/omap-b-for-v3.19/20141120015256/ Note that I cannot test the DRA7xx patches in any way, since I do not have a DRA7xx board. - Ambresh K (1): ARM: DRA7: hwmod data: Add missing UART hwmod data Paul Walmsley (1): Merge branch 'dra7xx-uart-hwmod-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 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_44xx_data.c | 25 +--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 5 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 100 + 7 files changed, 152 insertions(+), 18 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUbiQwAAoJEMePsQ0LvSpL1ScP/AsalZD18RBF9M9KKbdmbBLj hyeapk+7jkBS3ZOIinbOqJkK2hPQahf7tA8GHsgmlaU/EQJNzaTmXEN+ka9Om0nJ pZXpo87rsmJCqZaamxk66PXOStZXw2P+fDZSkxJFXK7rZrXH19BEvpxbwKtaEYMx Xv2TdaUvcgOJR2Sh4s2C9fxLYmuUzbMsdTYyPyKO/UL5WUteTk1UpR0dkEbYYOS3 HBBX4kpxwijfi8SMI+A/+EYwUw8lc7qvMeOk3vC14xn6IitB0dH6ZNCmTm5IJK6+ kn7AJnYlMcPVwEvK0bbUVMhjtxx2foceTb5rkhIBGfW1GWx22r75wD+Kv+bekwrQ XCPcImj8PfKstKZqmnHP82i2sJxpiE5nwiqQNoGgRz9YE/x6MTu/xGR4uUoTOg86 LSVm+HM/dLd99+DyWIgDwj9zwluZYGcLrBSYjiUAnxhOVtb6MaGVQSQ819gv75ep l1eINopMGYnLHq/GwEPzsJ0zA4gEWylLJJ+JB0cc7RpL9M9c5R+1sxwn4Sv80bly +StV0fKBtEo8f/FEonhbc3Du8iVKN297fsM4TFp2hCYnghCGVLyTrEfKpwlZb3YK I7LSLpJFq7rCkFqt0de2T5jKx2C1LNaZ+7rLfjpQejWTj9wRenGKE3hwV11UQj/q ng7oGIaPepOB2Z78FXex =cDw/ -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: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
On Thu, 20 Nov 2014, Lokesh Vutla wrote:
> On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote:
> > RTC IP have kicker feature which prevents spurious writes to its registers.
> > In order to write into any of the RTC registers, KICK values has te be
> > written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc
> > sysconfig register without writing into any kick register which is a noop.
> > When autoidle is allowed for rtc, interruts are not received until IDLEMODE
> > is set to SIDLE_SMART_WKUP.
> > Adding a reset function to unlock RTC registers so that IDLEMODE is
> > updated.
> Ping..!!
> Is this patch acceptable?
Lokesh
1. This looks like a fix. Is this intended to go in as a v3.18-rc patch,
or against v3.19? If so it would be very helpful for the maintainers if
you were to state that somewhere.
2. Your patch unlocks the RTC registers, but never relocks it. This seems
to defeat the point of the spurious write protection. Shouldn't your
patch only unlock the RTC immediately before the hwmod code touches the
RTC registers, and then relock it immediately afterwards, per SPRUHZ6
section 23.4.3.3? If so then the .reset function pointer is the wrong
place for this; I would suggest adding some .lock and .unlock function
pointers that are to be called before and after any register write to the
IP block.
3. Your macros don't mention DRA7xx specifically. Does this sequence
apply to some other TI chips, or just DRA7xx? Please document this in a
comment above the macros, and possibly change the name of the macros to
refer to DRA7XX.
- Paul
>
> Thanks and regards,
> Lokesh
> >
> > Signed-off-by: Lokesh Vutla
> > ---
> > arch/arm/mach-omap2/omap_hwmod.h | 1 +
> > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
> > arch/arm/mach-omap2/omap_hwmod_reset.c| 23 +++
> > 3 files changed, 25 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.h
> > b/arch/arm/mach-omap2/omap_hwmod.h
> > index 512f809..3703f99 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.h
> > +++ b/arch/arm/mach-omap2/omap_hwmod.h
> > @@ -744,6 +744,7 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod
> > *oh);
> > */
> >
> > extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
> > +int omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
> >
> > /*
> > * Chip variant-specific hwmod init routines - XXX should be converted
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > index 5684f11..90e1df4 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > @@ -1584,6 +1584,7 @@ static struct omap_hwmod_class_sysconfig
> > dra7xx_rtcss_sysc = {
> > static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> > .name = "rtcss",
> > .sysc = &dra7xx_rtcss_sysc,
> > + .reset = &omap_hwmod_rtc_unlock,
> > };
> >
> > /* rtcss */
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
> > b/arch/arm/mach-omap2/omap_hwmod_reset.c
> > index 65e186c..b825a28 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_reset.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
> > @@ -30,6 +30,12 @@
> >
> > #include "omap_hwmod.h"
> >
> > +#define RTC_KICK0_REG_OFFSET 0x6c
> > +#define RTC_KICK1_REG_OFFSET 0x70
> > +
> > +#define RTC_KICK0_VALUE0x83E70B13
> > +#define RTC_KICK1_VALUE0x95A4F1E0
> > +
> > /**
> > * omap_hwmod_aess_preprogram - enable AESS internal autogating
> > * @oh: struct omap_hwmod *
> > @@ -51,3 +57,20 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
> >
> > return 0;
> > }
> > +
> > +/**
> > + * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
> > + * @oh: struct omap_hwmod *
> > + *
> > + * RTC IP have kicker feature. This prevents spurious writes to its
> > registers.
> > + * In order to write into any of the RTC registers, KICK values has te be
> > + * written in respective KICK registers. This is needed for hwmod to write
> > into
> > + * sysconfig register.
> > + */
> > +int omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> > +{
> > + omap_hwmod_write(RTC_KICK0_VALUE, oh, RTC_KICK0_REG_OFFSET);
> > + omap_hwmod_write(RTC_KICK1_VALUE, oh, RTC_KICK1_REG_OFFSET);
> > +
> > + return 0;
> > +}
> >
>
- 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 2/2] i2c: omap: fix "Too much work in one IRQ" irq handling
Hi, thanks for the list! > latest, v3 (same as v2, fixed subject line): > https://patchwork.ozlabs.org/patch/412095/ Yes, I have an eye on this one. Only waiting for the test results from older platforms by Aaro. > Sorry, for making so much noise. No problem, this is part of the process. Still, assistance like yours with this list is very much appreciated so I can focus on actual review! Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH 2/2] i2c: omap: fix "Too much work in one IRQ" irq handling
Hello, 18 нояб. 2014 г., в 19:12, Wolfram Sang написал(а): > I got confused with all the patches sent out for his issues. Can you ack > them once you are fine and mention if you consider them important for > this or the next release? That would be really helpful! Duplicate/Obsolete (v1): https://patchwork.ozlabs.org/patch/411059/ https://patchwork.ozlabs.org/patch/411060/ https://patchwork.ozlabs.org/patch/411081/ https://patchwork.ozlabs.org/patch/411084/ v2 (in review by Aaro) https://patchwork.ozlabs.org/patch/411714/ comment to v2: https://patchwork.ozlabs.org/patch/411740/ latest, v3 (same as v2, fixed subject line): https://patchwork.ozlabs.org/patch/412095/ So, for now only one (v2 or v3) patch should be accepted or declined. All others should be dropped and forgotten. Sorry, for making so much noise. 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: [GIT PULL 2/3] omap gpmc changes for v3.19
* Tony Lindgren [141120 08:11]:
> * Arnd Bergmann [141120 03:04]:
> > On Wednesday 12 November 2014, Tony Lindgren wrote:
> > > GPMC (General Purpose Memory Controller) changes for omaps. These
> > > changes allow us to drop dependencies to bootloader timings now
> > > that the known device tree entries have been fixed. So we can now
> > > require proper timings to be configured and get rid of the legacy
> > > smsc91x code.
> > >
> > > Note that this branch has a dependency to the related device tree
> > > branch sent in a separate pull request as timings are now required.
> >
> > Does this mean you are breaking compatibility with old dtb files?
> >
> > Can you be more specific which machines are affected?
>
> Not breaking compability. We had timings missing in the .dts files
> for a few devices that caused all kinds of hacks in the GPMC code.
Hmm actually I take it back, this is breaking compability for booting
with old .dtb for smc91x on 2430sdp and 8250 on zoom3. In those cases
these devices would now refuse to probe because of the missing
timings because of the extra checks in the GPMC code.
However, these two boards are only used in three automated build and
boot test systems AFAIK. And almost certainly they are using appended
dtb anyways because of the lack of support for them in current
u-boot.
> Now those are all fixed up and we are actually using the bindings.
For reference, the .dts files with missing timings were smc91x on
omap2430-sdp.dts 8250 in omap-zoom-common.dtsi. So the dependencies
are:
b5399ea8453a ("ARM: dts: Add GPMC timings for omap zoom serial port")
1bb37404397d ("ARM: dts: Add smc91x GPMC configuration for 2430sdp")
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: [GIT PULL 2/3] omap gpmc changes for v3.19
* Arnd Bergmann [141120 03:04]: > On Wednesday 12 November 2014, Tony Lindgren wrote: > > GPMC (General Purpose Memory Controller) changes for omaps. These > > changes allow us to drop dependencies to bootloader timings now > > that the known device tree entries have been fixed. So we can now > > require proper timings to be configured and get rid of the legacy > > smsc91x code. > > > > Note that this branch has a dependency to the related device tree > > branch sent in a separate pull request as timings are now required. > > Does this mean you are breaking compatibility with old dtb files? > > Can you be more specific which machines are affected? Not breaking compability. We had timings missing in the .dts files for a few devices that caused all kinds of hacks in the GPMC code. Now those are all fixed up and we are actually using the bindings. 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: [GIT PULL 1/2] omap non-urgent fixes for v3.19
* Arnd Bergmann [141120 01:48]: > On Tuesday 11 November 2014, Tony Lindgren wrote: > > > > Fixes for omap3 that are not urgent. Mostly to remove unnecessary > > noise during the boot with pointless errors and warnings. > > > > > Pulled into next/fixes-non-critical. We didn't have any other patches in > there, > so I started out with -rc3 to avoid the back-merge problem. Any reason why > you didn't base this on -rc1 like the other branches? I was probably originally planning to have the dmesg warning and error fixes merged into omap-for-v3.18/fixes branch and have that automatically fast forward to -rc3 without rebasing. No other dependency that I can think of. 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: [GIT PULL 2/2] omap prcm clean-up for v3.19
* Arnd Bergmann [141120 03:10]: > On Tuesday 11 November 2014, Tony Lindgren wrote: > > Clean-up series for omap PRCM (Power Reset Clock Module) from > > Tero Kristo to move things a bit closer to becoming a proper > > device driver. > > Pulled into next/soc, as some of the changes seem slightly more invasive > than what I'd expect from a pure cleanup branch. > > Please let me know if this needs to be put into cleanup instead because > some other patches are based on top. OK next/soc is just fine for these. 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 v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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.) > 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. > I also tested this series on AM335x EVM using the v3.18-rc5 kernel. > Again, no breakage but no improvement as well. You still have jumps on a pen up event? 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
Brad, What you wrote is just the kind of thing one would like to see in the cover letter or change log... On Thu, Nov 20, 2014 at 02:23:30PM +, Griffis, Brad wrote: > In that thread the user was registering multiple press events for a single > press. By increasing the udelay to 1.5ms they were able to solve the > problem. Of course, having a 1.5ms delay in your ISR is a really bad thing > to do... I fully support removing the aweful ISR delay, as long as the result works! > I have another customer that was experiencing the same issue of registering > multiple press events, and sure enough the 1.5ms delay "fixed" their problem > too. The patches allowed them to remove that gigantic delay from the ISR > because that software delay has now become a hardware delay via CHARGECONFIG. > That customer is the one that needed 0xB000 which is MUCH larger than the > value of 0x400 that was working fine for me on the EVM. It would be really nice for TI to explain to board designers how to calculate the proper value. 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: Nori, Sekhar > Sent: Thursday, November 20, 2014 7:56 AM > > I also tested this series on AM335x EVM using the v3.18-rc5 kernel. > Again, no breakage but no improvement as well. The primary goal was not necessarily to improve performance of the touchscreen itself. It was to reduce unnecessary CPU overhead introduced by the 275us udelay in the ISR. On a related note, that 275us udelay is not something that worked for all boards. For example, see the following forum thread: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/217587/775152.aspx#775152 In that thread the user was registering multiple press events for a single press. By increasing the udelay to 1.5ms they were able to solve the problem. Of course, having a 1.5ms delay in your ISR is a really bad thing to do... I have another customer that was experiencing the same issue of registering multiple press events, and sure enough the 1.5ms delay "fixed" their problem too. The patches allowed them to remove that gigantic delay from the ISR because that software delay has now become a hardware delay via CHARGECONFIG. That customer is the one that needed 0xB000 which is MUCH larger than the value of 0x400 that was working fine for me on the EVM. -- 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 Tuesday 18 November 2014 10:42 PM, Dmitry Torokhov wrote: > On Tue, Nov 18, 2014 at 02:30:05PM +, Lee Jones wrote: >> On Fri, 14 Nov 2014, Vignesh R wrote: >> >>> In one shot mode, sequencer automatically disables all enabled steps at >>> the end of each cycle. (both ADC steps and TSC steps) Hence these steps >>> need not be saved in reg_se_cache for clearing these steps at a later >>> stage. >>> Also, when ADC wakes up Sequencer should not be busy executing any of the >>> config steps except for the charge step. Previously charge step was 1 ADC >>> clock cycle and hence it was ignored. >>> >>> Signed-off-by: Vignesh R >>> --- >>> drivers/mfd/ti_am335x_tscadc.c | 7 +-- >>> include/linux/mfd/ti_am335x_tscadc.h | 1 + >>> 2 files changed, 6 insertions(+), 2 deletions(-) >> >> Code looks better now. >> >> Acked-by: Lee Jones >> >> What's the plan for this series? > > I am waiting for the interested parties to provide more feedback. So far > I have seen a few reports saying that they see issues with the series > applied. 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. I did not see any breakage with these patches applied although I did not see any noticeable performance improvement as well. I also tested along with continuous loop reading from /sys/bus/iio/devices/iio:device0/in_voltage5_raw I have pushed the kernel I used here in case anyone wants to take a look at my porting. http://git.ti.com/cgit/cgit.cgi/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel.git/log/?h=am335x-tsc-test I also tested this series on AM335x EVM using the v3.18-rc5 kernel. Again, no breakage but no improvement as well. All testing was done using ts_test FWIW, you can add: Tested-by: Sekhar Nori 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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pavel, On 11/20/2014 01:12 PM, Pavel Machek wrote: Hi! I would also swap the segments of a property name to follow the convention as in case of "regulator-max-microamp". Updated version: == Optional properties for child nodes: - max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) - flash-max-microamp : maximum intensity in microamperes of the flash LED; it is mandatory if the led should support the flash mode - flash-timeout-microsec : timeout in microseconds after which the flash led is turned off Works for me. Do you want to submit a patch or should I do it? You can submit a patch for leds/common.txt and a separate patch for the adp1653 with a reference to the leds/common.txt for the child nodes. - indicator-pattern : identifier of the blinking pattern for the indicator led This would need a bit more documentation, no? - indicator-pattern : identifier of the blinking pattern for the indicator led; valid identifiers should be defined in the documentation of the parent node. I wouldn't go for pre-defined identifiers as the pattern can be a combination of various settings like ramp-up, ramp-down, pulse time etc. Drivers should expose only few combinations of these settings in my opinion, like e.g. leds-lm355x.c does. Regards, Jacek -- 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: [RFC] adp1653: Add device tree bindings for LED controller
On 11/19/2014 10:45 AM, Jacek Anaszewski wrote: Hi Pavel, Sakari, On 11/18/2014 05:51 PM, Pavel Machek wrote: Hi! If the hardware LED changes with one that needs different current, the block for the adp1653 stays the same, but white LED block should be updated with different value. I think that you are talking about sub nodes. Indeed I am leaning towards this type of design. I think I am :-). I agree that flash-timeout should be per led - an array, similarly as in case of iout's. Agreed about per-led, disagreed about the array. As all the fields would need arrays, and as LED system currently does not use arrays for label and linux,default-trigger, I believe we should follow existing design and model it as three devices. (It _is_ physically three devices.) Right, I missed that the leds/common.txt describes child node. I propose following modifications to the binding: Optional properties for child nodes: - iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - iout-mode-flash : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led - iout-mode-indicator : initial intensity in microamperes of the indicator LED; it is required to enable support for the indicator led - max-iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - max-iout-mode-flash : maximum intensity in microamperes of the flash LED - max-iout-mode-indicator : maximum intensity in microamperes of the indicator LED - flash-timeout :timeout in microseconds after which flash led is turned off Ok, I took a look, and "iout" is notation I understand, but people may have trouble with and I don't see it used anywhere else. Also... do we need both "current" and "max-current" properties? But regulators already have "regulator-max-microamp" property. So what about: max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) max-flash-microamp : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led flash-timeout-microseconds : timeout in microseconds after which flash led is turned off If you had indicator on the same led, I guess indicator-microamp : recommended intensity in microamperes of the LED for indication ...would do? Ongoing discussion allowed me for taking a look at the indicator issue from different perspective. This is also vital for the issue of whether a v4l2-flash sub-device should be created per device or per sub-led [1]. Currently each sub-led is represented as a separate device tree sub node and the led drivers create separate LED class device for the sub nodes. What this implies is that indicator led also must be represented by the separate LED class device. This is contrary to the way how V4L2 Flash API approaches this issue, as it considers a flash device as a regulator chip driven through a bus. The API allows to set the led in torch or flash mode and implicitly assumes that there can be additional indicator led supported, which can't be turned on separately, but the drivers apply the indicator current to the indicator led when the torch or flash led is activated. I propose to create separate v4l2-flash device for the indicator led, and treat it as a regular sub-led similarly like it is done in the LED subsystem. LED Flash class driver would only add a flag LED_DEV_CAP_INDICATOR and basing on it the v4l2-flash sub-device would create only V4L2_CID_FLASH_INDICATOR_INTENSITY control for it. There could ba also additional control added: V4L2_CID_FLASH_INDICATOR_PATTERN to support the feature supported by some LED class drivers. From the media device perspective such an approach would be harmful, as the indicator led could be turned on right I intended here "wouldn't be harmful". before strobing the flash or turning the torch on, by separate calls to different v4l2-flash sub-devices. The design described above would allow for avoiding issues I touched in the message [1]. Regarding DT documentation: I would also swap the segments of a property name to follow the convention as in case of "regulator-max-microamp". Updated version: == Optional properties for child nodes: - max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) - flash-max-microamp : maximum intensity in microamperes of the flash LED; it is mandatory if the led should support the flash mode - flash-timeout-microsec : timeout in microseconds after which the flash led is turned off - indicator-pattern : identifier of the blinking pattern for the indicator led
Re: [RFC] adp1653: Add device tree bindings for LED controller
Hi! > >> But regulators already have "regulator-max-microamp" property. So what > >> about: > >> > >> max-microamp : maximum intensity in microamperes of the LED > >> (torch LED for flash devices) > >> max-flash-microamp : initial intensity in microamperes of the > >> flash LED; it is required to enable support > >> for the flash led > >> flash-timeout-microseconds : timeout in microseconds after which flash > >> led is turned off > >> > >> If you had indicator on the same led, I guess > >> > >> indicator-microamp : recommended intensity in microamperes of the LED > >> for indication > > The value for the indicator is maximum as well, not just a > recommendation. Actually, no. This is all for one LED, if you want to use it as a flash, torch and indicator. You already know the maximum value with max-microamp. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC] adp1653: Add device tree bindings for LED controller
Hi! > I would also swap the segments of a property name to follow the convention > as in case of "regulator-max-microamp". > > Updated version: > > == > > Optional properties for child nodes: > - max-microamp : maximum intensity in microamperes of the LED >(torch LED for flash devices) > - flash-max-microamp : maximum intensity in microamperes of the > flash LED; it is mandatory if the led should > support the flash mode > - flash-timeout-microsec : timeout in microseconds after which the flash > led is turned off Works for me. Do you want to submit a patch or should I do it? > - indicator-pattern : identifier of the blinking pattern for the > indicator led > This would need a bit more documentation, no? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 01/15] clk: divider: replace bitfield width with mask
On 20/11/14 11:19, Tero Kristo wrote: > On 11/20/2014 01:15 AM, James Hogan wrote: >> - Updated assignment of clk_divider::width in imx, rockchip, st, sunxi, >>ti clock components to use mask instead (not tested), using the >>following semantic patch: > > Hi James/Mike, > > This patch currently causes a build breakage with omap2plus_defconfig. > Reason being you are modifying the clk_divider struct, but not touching > the code under drivers/clk/ti/divider.c which uses it. The fixes are > basically the same you have done for clk-divider.c, the contents of this > file are mostly just copied under TI clock driver. Thanks for pointing that out! I'll fix and improve my grep-fu to find other such cases. Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH 01/15] clk: divider: replace bitfield width with mask
On 11/20/2014 01:15 AM, James Hogan wrote:
From: Mike Turquette
The forthcoming Device Tree binding for the divider clock type will use
a bitfield mask instead of bitfield width, which is what the current
basic divider implementation uses.
This patch replaces the u8 width in struct clk_divider with a u32 mask.
The divider code is updated to use the bit mask internally but the two
registration functions still accept the width to maintain compatibility
with existing users.
Also updated in this patch is the clk-private.h divider macro and
various clock divider implementations that are based on struct
clk_divider.
Signed-off-by: Mike Turquette
[james.ho...@imgtec.com: forward port, fix new uses of width]
Signed-off-by: James Hogan
Tested-by: Shawn Guo
Tested-by: Heiko Stuebner
Reviewed-by: Heiko Stuebner
Cc: "Emilio López"
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Tero Kristo
Cc: linux-omap@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
---
Changes since original:
- Forward ported
- Adjust new div_mask from recent patch "clk-divider: Fix READ_ONLY when
divider > 1"
- Updated assignment of clk_divider::width in imx, rockchip, st, sunxi,
ti clock components to use mask instead (not tested), using the
following semantic patch:
Hi James/Mike,
This patch currently causes a build breakage with omap2plus_defconfig.
Reason being you are modifying the clk_divider struct, but not touching
the code under drivers/clk/ti/divider.c which uses it. The fixes are
basically the same you have done for clk-divider.c, the contents of this
file are mostly just copied under TI clock driver.
-Tero
virtual context
virtual patch
@depends on context@
struct clk_divider clk;
expression e;
@@
*clk.width = e
@depends on patch@
struct clk_divider clk;
expression e;
@@
-clk.width = fls(e)
+clk.mask = e
@depends on patch@
struct clk_divider *clk;
expression e;
@@
-clk->width = fls(e)
+clk->mask = e
@depends on patch@
struct clk_divider clk;
expression e;
@@
-clk.width = e
+clk.mask = BIT(e) - 1
@depends on patch@
struct clk_divider *clk;
expression e;
@@
-clk->width = e
+clk->mask = BIT(e) - 1
---
arch/arm/mach-imx/clk-busy.c | 2 +-
arch/arm/mach-imx/clk-fixup-div.c | 2 +-
drivers/clk/clk-divider.c | 33 -
drivers/clk/mxs/clk-div.c | 2 +-
drivers/clk/rockchip/clk.c| 2 +-
drivers/clk/st/clk-flexgen.c | 4 ++--
drivers/clk/st/clkgen-mux.c | 4 ++--
drivers/clk/st/clkgen-pll.c | 2 +-
drivers/clk/sunxi/clk-sunxi.c | 2 +-
drivers/clk/ti/divider.c | 2 +-
include/linux/clk-private.h | 2 +-
include/linux/clk-provider.h | 2 +-
12 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-imx/clk-busy.c b/arch/arm/mach-imx/clk-busy.c
index 4bb1bc4..bc88e38 100644
--- a/arch/arm/mach-imx/clk-busy.c
+++ b/arch/arm/mach-imx/clk-busy.c
@@ -95,7 +95,7 @@ struct clk *imx_clk_busy_divider(const char *name, const char
*parent_name,
busy->div.reg = reg;
busy->div.shift = shift;
- busy->div.width = width;
+ busy->div.mask = BIT(width) - 1;
busy->div.lock = &imx_ccm_lock;
busy->div_ops = &clk_divider_ops;
diff --git a/arch/arm/mach-imx/clk-fixup-div.c
b/arch/arm/mach-imx/clk-fixup-div.c
index 21db020..af33b7a 100644
--- a/arch/arm/mach-imx/clk-fixup-div.c
+++ b/arch/arm/mach-imx/clk-fixup-div.c
@@ -115,7 +115,7 @@ struct clk *imx_clk_fixup_divider(const char *name, const
char *parent,
fixup_div->divider.reg = reg;
fixup_div->divider.shift = shift;
- fixup_div->divider.width = width;
+ fixup_div->divider.mask = BIT(width) - 1;
fixup_div->divider.lock = &imx_ccm_lock;
fixup_div->divider.hw.init = &init;
fixup_div->ops = &clk_divider_ops;
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..a432cf8 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -30,8 +30,6 @@
#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
-#define div_mask(d)((1 << ((d)->width)) - 1)
-
static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
{
unsigned int maxdiv = 0;
@@ -57,12 +55,12 @@ static unsigned int _get_table_mindiv(const struct
clk_div_table *table)
static unsigned int _get_maxdiv(struct clk_divider *divider)
{
if (divider->flags & CLK_DIVIDER_ONE_BASED)
- return div_mask(divider);
+ return divider->mask;
if (divider->flags & CLK_DIVIDER_POWER_OF_TWO)
- return 1 << div_mask(divider);
+ return 1 << divider->mask;
if (divider->table)
return _get_table_maxdiv(divider->table);
- return div_mask(divider) + 1;
+ return divider->mask + 1;
}
static unsigned int _get_table_div(const struct clk_div_table *table,
@@ -116,7 +114,7 @@ static unsigned long clk_divider_recalc_rate(s
Re: [GIT PULL 2/2] omap prcm clean-up for v3.19
On Tuesday 11 November 2014, Tony Lindgren wrote: > Clean-up series for omap PRCM (Power Reset Clock Module) from > Tero Kristo to move things a bit closer to becoming a proper > device driver. Pulled into next/soc, as some of the changes seem slightly more invasive than what I'd expect from a pure cleanup branch. Please let me know if this needs to be put into cleanup instead because some other patches are based on top. Thanks, 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: [GIT PULL 2/2] omap driver changes for v3.19
On Friday 14 November 2014, Tony Lindgren wrote: > Few omap driver changes to add minimal device tree support > for the omap 1w driver, and to fix resume and interrupt issues > on the l3-noc driver. Pulled into next/drivers, thanks! 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: [GIT PULL 2/3] omap gpmc changes for v3.19
On Wednesday 12 November 2014, Tony Lindgren wrote: > GPMC (General Purpose Memory Controller) changes for omaps. These > changes allow us to drop dependencies to bootloader timings now > that the known device tree entries have been fixed. So we can now > require proper timings to be configured and get rid of the legacy > smsc91x code. > > Note that this branch has a dependency to the related device tree > branch sent in a separate pull request as timings are now required. Does this mean you are breaking compatibility with old dtb files? Can you be more specific which machines are affected? 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
Hi Mark, On 13/11/14 10:05, Tomi Valkeinen wrote: > Hi Mark, > > On 13/11/14 00:23, Mark Brown wrote: >> On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: >> >>> It would make the most sense to get these in trough fbdev tree. So it >>> would be nice to get acked-bys (if the patches are Ok) for ASoC side >>> changes from appropriate maintainers. >> >> So, this is a very large series which gets reposted every so often to no >> apparent interest from the video side, there's been no response at all > > Sorry for the lack of communication. We've been discussing this series > on irc. It's been mostly about how to manage the device/driver split > between drivers/video/ and sound/ sides. > >> that I can remember and even the earlier bits of the series before it >> starts touching audio don't seem to be getting merged. What's going on >> here? > > The series is all audio in terms of functionality. The first few patches > could probably be merged independently, but I've wanted this whole OMAP > HDMI audio rewrite to be in one series. > > I'll start testing this latest series, and I hope we can merge it for > the next merge window so that we'll finally get the OMAP HDMI audio working. > > I don't have much knowledge of the asoc architecture, so I probably > can't comment much on the sound/ side design. For me the most important > things are that 1) it works 2) I can easily unload/load the modules > (which was broken in some of the earlier versions). 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. Tomi signature.asc Description: OpenPGP digital signature
Re: [GIT PULL 1/3] omap device tree changes for v3.19
On Wednesday 12 November 2014, Tony Lindgren wrote: > The following changes since commit cac7f2429872d3733dc3f9915857b1691da2eb2f: > > Linux 3.18-rc2 (2014-10-26 16:48:41 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.19/dt-part1 > > for you to fetch changes up to 065bd7fe50de5e6d0fd5034cbc87120a558a1219: > > ARM: dts: DRA7: Add aliases for all serial ports (2014-11-12 07:04:37 -0800) > > > Device tree related changes for omaps: > > - Fix currently harmless but wrong sizes for various GPMC connected > devices > > - Set up timings for several GPMC connected devices to get rid of > bootloader dependencies in later patches > > - Enable various drivers for dra7xx > > - Prepare Igep boards to support new variants > > - Add intial support for BeagleBoard-X15 pulled into next/dt, thanks! 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: [GIT PULL 1/2] omap soc changes for v3.19
On Friday 14 November 2014, Tony Lindgren wrote: > The following changes since commit cac7f2429872d3733dc3f9915857b1691da2eb2f: > > Linux 3.18-rc2 (2014-10-26 16:48:41 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.19/clocks-and-pm > > for you to fetch changes up to 9889278181bcdbae882664d8cee5bb0e064397e4: > > Merge tag 'for-v3.19/omap-a' of > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into > omap-for-v3.19/soc (2014-11-14 10:25:12 -0800) > > > SoC related changes for omaps. Mostly to make PM easier to use for > omap4 and later, and to fix clock DPLL fixes by adding determine_rate > and set_rate_and_parent. > pulled into next/soc, thanks! 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: voice calls on N900 working (off-line) was Re: N900 modem support in 3.18-rc1
Hi! > Ok, so realtime audio does not work due to some pulseaudio problems, > but I was able to record a (silent) call and then replay it with > > pacat --rate 4000 ../../../pulseaudio2.raw > > on my PC. I have yet to do some testing on the microphone side. Did someone get pulseaudio to work on n900? It somehow works for me, but not enough to actually produce sound. root@n900:/my# pacat /my/pulseaudio2.raw Connection failure: Connection refused pa_context_connect() failed: Connection refused root@n900:/my# pacmd Welcome to PulseAudio! Use "help" for usage information. >>> list-modules 22 module(s) loaded. index: 0 name: argument: <> used: -1 load once: yes ... mpg123 actually works ok after adjusting the mixers. Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
voice calls on N900 working (off-line) was Re: N900 modem support in 3.18-rc1
Hi! > > REed pulseaudio modules that use cmtspeech will be ready sooner than later > > (I believe in 2-3 monts from now), see on gitorious how fast we progressed > > with -record and -music modules. Sure, -voice module is way more > > complicated, but lots of it is already opensourced, we just need to figure > > out a couple of DSP algorithms(drc, agc, aec, etc) related to call quality. > > But I don't think the driver should wait for those modules to be REed, they > > can be used as is even now, in their closed form for testing. > > https://gitorious.org/pulseaudio-modules-nemo/jusas-tanuk2-mer-packaging/source/6ed34611b49c99b007f614d9dff4d58369876345: > https://github.com/nemomobile/pulseaudio-module-cmtspeech-n9xx/commits/master > > It seems there is already cmtspeech code for pulseaudio? Yes, and it works; but see below. > > Unfortunately all my spare time is dedicated to that PA stuff, so > > I simply can't cleanup cmtspeech driver and send a patch for > > upstreaming. (Pavel, what about you?) > > If somebody gets audio working with your driver and documents the > steps needed in userland I will take care of upstreaming the driver. I got it to work. Ok, so realtime audio does not work due to some pulseaudio problems, but I was able to record a (silent) call and then replay it with pacat --rate 4000 ../../../pulseaudio2.raw on my PC. I have yet to do some testing on the microphone side. I'm using Debian 7 as a a base, and I suggest nfsroot. It seems that libcmtspeechdata + pulseaudio-module-cmtspeech-n9xx is enough to get calls to work. Now. I could not get configure on these packages to work, so I hard-coded build scripts (mkit). You'll need to symlink resulting .so to pulseaudio directory (see /my/pulseaudio-module-cmtspeech-n9xx/src/cmtspeech/mkit). I leave binaries in, since this is non-trivial to compile. Some memory allocation stuff was missing. I faked it; it seems it is not needed in the first call. untar in the root directory of n900. Reset n900, no need to log in into console, connect using ssh -X root@n900. Then go to /my/tui/ofone. Run "./run" -- that should start pulseaudio. Run "./ofone", hit "lowlevel: online", hit "contacts", enter phone number you want to call, hit the number, it should start dialing. Wait a while, hit "lowlevel: hangup". Now you should have: /my/pulseaudio2.raw you can play with pacat above, and /my/pulseaudio.log.*, which contains stuff that needs to be fixed. I've put the archive at http://atrey.karlin.mff.cuni.cz/~pavel/outgoing/n900-my.tgz Have fun! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [GIT PULL 1/2] omap non-urgent fixes for v3.19
On Tuesday 11 November 2014, Tony Lindgren wrote: > > Fixes for omap3 that are not urgent. Mostly to remove unnecessary > noise during the boot with pointless errors and warnings. > Pulled into next/fixes-non-critical. We didn't have any other patches in there, so I started out with -rc3 to avoid the back-merge problem. Any reason why you didn't base this on -rc1 like the other branches? 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: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Hi Paul,
On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote:
> RTC IP have kicker feature which prevents spurious writes to its registers.
> In order to write into any of the RTC registers, KICK values has te be
> written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc
> sysconfig register without writing into any kick register which is a noop.
> When autoidle is allowed for rtc, interruts are not received until IDLEMODE
> is set to SIDLE_SMART_WKUP.
> Adding a reset function to unlock RTC registers so that IDLEMODE is
> updated.
Ping..!!
Is this patch acceptable?
Thanks and regards,
Lokesh
>
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-omap2/omap_hwmod.h | 1 +
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
> arch/arm/mach-omap2/omap_hwmod_reset.c| 23 +++
> 3 files changed, 25 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.h
> b/arch/arm/mach-omap2/omap_hwmod.h
> index 512f809..3703f99 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.h
> +++ b/arch/arm/mach-omap2/omap_hwmod.h
> @@ -744,6 +744,7 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod
> *oh);
> */
>
> extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
> +int omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
>
> /*
> * Chip variant-specific hwmod init routines - XXX should be converted
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 5684f11..90e1df4 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1584,6 +1584,7 @@ static struct omap_hwmod_class_sysconfig
> dra7xx_rtcss_sysc = {
> static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> .name = "rtcss",
> .sysc = &dra7xx_rtcss_sysc,
> + .reset = &omap_hwmod_rtc_unlock,
> };
>
> /* rtcss */
> diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
> b/arch/arm/mach-omap2/omap_hwmod_reset.c
> index 65e186c..b825a28 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_reset.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
> @@ -30,6 +30,12 @@
>
> #include "omap_hwmod.h"
>
> +#define RTC_KICK0_REG_OFFSET 0x6c
> +#define RTC_KICK1_REG_OFFSET 0x70
> +
> +#define RTC_KICK0_VALUE 0x83E70B13
> +#define RTC_KICK1_VALUE 0x95A4F1E0
> +
> /**
> * omap_hwmod_aess_preprogram - enable AESS internal autogating
> * @oh: struct omap_hwmod *
> @@ -51,3 +57,20 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
>
> return 0;
> }
> +
> +/**
> + * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
> + * @oh: struct omap_hwmod *
> + *
> + * RTC IP have kicker feature. This prevents spurious writes to its
> registers.
> + * In order to write into any of the RTC registers, KICK values has te be
> + * written in respective KICK registers. This is needed for hwmod to write
> into
> + * sysconfig register.
> + */
> +int omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> +{
> + omap_hwmod_write(RTC_KICK0_VALUE, oh, RTC_KICK0_REG_OFFSET);
> + omap_hwmod_write(RTC_KICK1_VALUE, oh, RTC_KICK1_REG_OFFSET);
> +
> + return 0;
> +}
>
--
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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pavel, Sakari, On 11/19/2014 06:53 PM, Sakari Ailus wrote: Hi Jacek and Pavel, Jacek Anaszewski wrote: Hi Pavel, Sakari, On 11/18/2014 05:51 PM, Pavel Machek wrote: Hi! If the hardware LED changes with one that needs different current, the block for the adp1653 stays the same, but white LED block should be updated with different value. I think that you are talking about sub nodes. Indeed I am leaning towards this type of design. I think I am :-). I agree that flash-timeout should be per led - an array, similarly as in case of iout's. Agreed about per-led, disagreed about the array. As all the fields would need arrays, and as LED system currently does not use arrays for label and linux,default-trigger, I believe we should follow existing design and model it as three devices. (It _is_ physically three devices.) Right, I missed that the leds/common.txt describes child node. I propose following modifications to the binding: Optional properties for child nodes: - iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - iout-mode-flash : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led - iout-mode-indicator : initial intensity in microamperes of the indicator LED; it is required to enable support for the indicator led - max-iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - max-iout-mode-flash : maximum intensity in microamperes of the flash LED - max-iout-mode-indicator : maximum intensity in microamperes of the indicator LED - flash-timeout :timeout in microseconds after which flash led is turned off Ok, I took a look, and "iout" is notation I understand, but people may have trouble with and I don't see it used anywhere else. Also... do we need both "current" and "max-current" properties? But regulators already have "regulator-max-microamp" property. So what about: max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) max-flash-microamp : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led flash-timeout-microseconds : timeout in microseconds after which flash led is turned off If you had indicator on the same led, I guess indicator-microamp : recommended intensity in microamperes of the LED for indication The value for the indicator is maximum as well, not just a recommendation. ...would do? Ongoing discussion allowed me for taking a look at the indicator issue from different perspective. This is also vital for the issue of whether a v4l2-flash sub-device should be created per device or per sub-led [1]. Currently each sub-led is represented as a separate device tree sub node and the led drivers create separate LED class device for the sub nodes. What this implies is that indicator led also must be represented by the separate LED class device. This is contrary to the way how V4L2 Flash API approaches this issue, as it considers a flash device as a regulator chip driven through a bus. The API allows to set the led in torch or flash mode and implicitly assumes that there can be additional indicator led supported, which can't be turned on separately, but the drivers apply the indicator current to the indicator led when the torch or flash led is activated. The indicator is independent of the flash LED in V4L2 flash API. At least that's how it should be, and in adp1653 the two are independent, but the as3645a can't use indicator with the flash AFAIR. Right. I propose to create separate v4l2-flash device for the indicator led, and treat it as a regular sub-led similarly like it is done in the LED subsystem. LED Flash class driver would only add a flag LED_DEV_CAP_INDICATOR and basing on it the v4l2-flash sub-device would create only V4L2_CID_FLASH_INDICATOR_INTENSITY control for it. There could ba also additional control added: V4L2_CID_FLASH_INDICATOR_PATTERN to support the feature supported by some LED class drivers. Interesting idea. The flash controller is still a single I2C device with common set of faults, for instance. Some devices refuse to work again in case of faults until they are cleared (= read). The V4L2_CID_FLASH_FAULT control should be also supported by the indicator v4l2-flash sub-device then. Could the indicator pattern control be present in the same sub-device? Yes, this was my intention. To conclude - the indicator v4l2-flash sub-device should support up to three controls: - V4L2_CID_FLASH_TORCH_INTENSITY - V4L2_CID_FLASH_FAULT - V4L2_CID_FLASH_INDICATOR_PATTERN (if supported by the LED Flash class driver) V4L2_CID_FLASH_INDICATOR_PATTERN would be a menu control with c
Re: [PATCH] ARM: DRA7: hwmod data: Add missing UART hwmod data
On Tue, 21 Oct 2014, Nishanth Menon wrote: > From: Ambresh K > > We had constrainted hwmod entries to entries in dts which were present > only for default mapped interrupts, the ones such as UARTs > 6 which > needed IRQ crossbar configured were never added to hwmod database. > > Add them now that IRQ crossbar is functional > > Without this, enabling UARTs7 to 10 in dts results in the following crash: > [1.893829] omap_uart 4842.serial: _od_fail_runtime_resume: FIXME: > missing hwmod/omap_dev info > [1.903381] Unhandled fault: imprecise external abort (0x1406) at > 0x > [1.903381] [ cut here ] > [1.903381] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 > l3_interrupt_handler+0x2ac/0x32c() > [1.903411] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 > (Read): Data Access in User mode during Functional access > [1.903411] Modules linked in: > [1.903411] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW > 3.18.0-rc1-dirty #3 > [1.903442] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [1.903442] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [1.903472] [] (dump_stack) from [] > (warn_slowpath_common+0x6c/0x8c) > [1.903472] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [1.903472] [] (warn_slowpath_fmt) from [] > (l3_interrupt_handler+0x2ac/0x32c) > [1.903503] [] (l3_interrupt_handler) from [] > (handle_irq_event_percpu+0x60/0x230) > [1.903503] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x3c/0x5c) > [1.903503] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xc4/0x190) > [1.903503] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x20/0x30) > [1.903533] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x64/0xb8) > [1.903533] [] (__handle_domain_irq) from [] > (gic_handle_irq+0x20/0x60) > [1.903533] [] (gic_handle_irq) from [] > (__irq_svc+0x44/0x5c) > [1.903533] Exception stack(0xc08d1f60 to 0xc08d1fa8) > [1.903564] 1f60: 0001 0001 c08dc930 c08d > > [1.903564] 1f80: ffed c0978028 c08d89dc c08d8978 c08d1fa8 > c0083fc0 c000f160 > [1.903564] 1fa0: 2013 > [1.903564] [] (__irq_svc) from [] > (arch_cpu_idle+0x20/0x3c) > [1.903594] [] (arch_cpu_idle) from [] > (cpu_startup_entry+0x198/0x338) > [1.903594] [] (cpu_startup_entry) from [] > (start_kernel+0x358/0x3c4) > [1.903594] [] (start_kernel) from [<80008074>] (0x80008074) > [1.903594] ---[ end trace 293fc95d463cff71 ]--- > [2.117553] Internal error: : 1406 [#1] SMP ARM > [2.122314] Modules linked in: > [2.125518] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW > 3.18.0-rc1-dirty #3 > [2.133850] task: ed868b80 ti: ed86a000 task.ti: ed86a000 > [2.139526] PC is at serial_omap_probe+0x2fc/0x514 > [2.144561] LR is at trace_hardirqs_on_caller+0xec/0x1c4 > [2.150146] pc : []lr : []psr: 4013 > [2.150146] sp : ed86be18 ip : ed9bb57c fp : f005e000 > [2.162231] r10: 012a r9 : ed9b4f80 r8 : edc5bdcd > [2.167724] r7 : edc58810 r6 : ed9bb400 r5 : ed9bb410 r4 : edc5bc10 > [2.174560] r3 : r2 : r1 : 0014 r0 : ffed > [2.181427] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > kernel > [2.189117] Control: 10c5387d Table: 8000406a DAC: 0015 > [2.195159] Process swapper/0 (pid: 1, stack limit = 0xed86a248) > [2.201477] Stack: (0xed86be18 to 0xed86c000) > [2.206054] be00: > ed9ba2d0 > [2.214660] be20: edc50150 0001 c08cba58 ed9bb410 > ffed c09481d8 > [2.223236] be40: c09481d8 c08cba58 c039bcfc > c1170958 ed9bb410 > [2.231842] be60: ed9bb444 c039a6f4 ed9bb410 c09481d8 ed9bb444 > c08dc698 > [2.240447] be80: edc4a100 c039a8b0 c09481d8 c039a81c c0399060 > ed8afaa8 ed92c110 > [2.249053] bea0: c09481d8 edc482c0 c0949308 c0399ee0 c077f80c c09481d8 > ed86a000 c09481d8 > [2.257659] bec0: ed86a000 c08dc698 c039b088 > ed86a000 c08a1924 > [2.266235] bee0: c08a1904 c00089c4 > 6093 > [2.274841] bf00: 0004 ed868b80 0004 6053 > 0001 > [2.283447] bf20: c0083ea8 0001 ed86a000 c08334bc ef7fc307 > 00b2 c0059358 > [2.292053] bf40: c07e176c c083299c 0006 0006 c08cb588 c08b69cc > 0006 c08b69ac > [2.300659] bf60: c097a280 00b2 c08cba58 c0869588 c0869e04 > 0006 0006 > [2.309234] bf80: c0869588 c05dfd7c > > [2.317840] bfa0: c05dfd84 c000e668 > > [2.326446] bfc
