arm, am1808: using mmc1 controller and dma

[Heiko Schocher]

Hello,

trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller,
and facing problems with using DMA. Deactivating use_dma=0 in the
davinci_mmc controller and mmc works in pio mode without problems.
So there are no hardware problems, pinmux is ok, psc are all on.

Tried this on the AM1808 evalboard TMDXEXP1808L, and Linux 3.1
works with DMA without problems. Difference: On the AM1808 Evalboard
TMDXEXP1808L MMCSD0 controller is used on my am1808 based board
MMCSD1!

Debugging in code and found, that on the am1808 evalboard I get
on startup (first DMA access):

CMD13, arg 0x, R1/R5/R6/R7 response

a status back in mmc_davinci_irq():

TRNDNE (0x1000) Transfer done
RSPDNE (0x0004) Response succesfully has received
DATDNE (0x0001) The data has been fully transmitted

On the am1808 based board with using MMCSD1 I get:

CMD13, arg 0x, R1/R5/R6/R7 response

TRNDNE (0x1000) Transfer done
DRRDY  (0x0400) MMCDRR is ready New data arrived and can be read by cpu or dma
RSPDNE (0x0004) Response succesfully has received

after that command, I see  no more mmc accesses ... some ideas?

Looking in the sprufu5.pdf (AM18x ARM Microprocessor Enhanced Direct
Memory Access (EDMA3) Controller" chapter "2.6 Event, Channel, and
PaRAM Mapping":

"Most of the DMA channels are tied to a specific hardware peripheral
event, thus allowing transfers to be triggered by events from device
peripherals or external hardware."

The mapping is defined in the device specific manual
http://www.ti.com/lit/ds/sprs653b/sprs653b.pdf
chapter "5.9.1 EDMA3 Channel Synchronization Events"

and there I found:

EDMA0 Controller Event 16 MMCSD0 Receive
EDMA0 Controller Event 17 MMCSD0 Transmit

EDMA1 Controller Event 28 MMCSD1 Receive
EDMA1 Controller Event 29 MMCSD1 Transmit

The Linux 3.1 Code is using
EDMA1 Controller Event 28 MMCSD1 Receive
EDMA1 Controller Event 29 MMCSD1 Transmit

as events for the MMCSD1 controller ... so, this should be ok ...
I see no more differences between MMCSD0 and MMCSD1 ... maybe I
miss something?

Have somebody running an am1808 based board with using MMCSD
controller 1?

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

--
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: Setting OMAP DSS fck

[Tomi Valkeinen]

On Thu, 2011-12-01 at 11:23 -0700, Paul Walmsley wrote:
> On Thu, 1 Dec 2011, Tomi Valkeinen wrote:
> 
> > Why is it that the rate of DSS functional clock (dss_dss_clk on OMAP4)
> > cannot be set, but we need to get the parent of the fck, and set the
> > rate of that? The same is on OMAP3.
> > 
> > From driver's perspective I think this only makes things more complex,
> > as the driver is not interested in the parent, only about the dss fck.
> 
> Yeah, I agree.  We've talked about implementing rate changes that 
> percolate up to some higher point in the clock tree, but have never gotten 
> around to it due to other, higher priorities.  And now the common clock 
> discussion has reduced the desire to do much OMAP-specific implementation 
> of this stuff.
> 
> Another (related) problem is that the driver probably needs to know the 
> ranges of the possible values that can be set.

That's true. The DSS driver has knowledge of the possible divider ranges
that the parent clock can use. Not very neat.

And note that the DSS driver needs to know about the possible dividers,
not the clock freq range. We need to get quite exact pixel clocks,
derived via some dividers, and we iterate through the dividers trying to
find a divider set that produces a pixel clock that is close to the
required one.

 Tomi



signature.asc
Description: This is a digitally signed message part

[PATCH-V5 3/3] arm:omap:am33xx: Add low level debugging support

[hvaibhav]

From: Afzal Mohammed 

Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.

Signed-off-by: Afzal Mohammed 
Signed-off-by: Vaibhav Hiremath 
Reviewed-by: Kevin Hilman 
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 13f98e5..7da7126 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3   @ ti816x UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b   98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -109,6 +113,17 @@ omap_uart_lsr: .word   0
str \rp, [\tmp, #8] @ omap_uart_lsr
b   10b

+   /* AM33XX: Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   str \rp, [\tmp, #4] @ omap_uart_virt
+   mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
+   str \rp, [\tmp, #8] @ omap_uart_lsr
+
+   b   10b
+
/* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index 1ab9fd6..e988c92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM33XX serial port */
+#define AM33XX_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI816XUART181
 #define TI816XUART282
 #define TI816XUART383
+#define AM33XXUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 2d45ea3..ff59570 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI816XUART##p)

+#define DEBUG_LL_AM33XX(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM33XXUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -181,6 +185,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);

+   /* AM33XX base boards using UART1 */
+   DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
 }

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[hvaibhav]

From: Afzal Mohammed 

This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.

Signed-off-by: Afzal Mohammed 
Signed-off-by: Vaibhav Hiremath 
Reviewed-by: Kevin Hilman 
---
 arch/arm/mach-omap2/Kconfig  |5 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-am3517evm.c|   21 +
 arch/arm/mach-omap2/io.c |7 +++
 arch/arm/mach-omap2/timer.c  |2 ++
 arch/arm/plat-omap/include/plat/common.h |2 ++
 6 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 09ea525..c0e4a70 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -326,6 +326,11 @@ config MACH_TI8168EVM
depends on SOC_OMAPTI816X
default y

+config MACH_AM335XEVM
+   bool "AM335X Evaluation Module"
+   depends on SOC_OMAPAM33XX
+   default y
+
 config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a12a069..89099a3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -233,6 +233,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o

 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM)   += board-am3517evm.o

 # Platform specific device init code

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index f7df8d3..090457f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -516,3 +516,24 @@ MACHINE_START(OMAP3517EVM, "OMAP3517/AM3517 EVM")
.init_machine   = am3517_evm_init,
.timer  = &omap3_timer,
 MACHINE_END
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+   omap_serial_init();
+   omap_sdrc_init(NULL, NULL);
+   omap_board_config = am335x_evm_config;
+   omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+   /* Maintainer: Texas Instruments */
+   .atag_offset= 0x100,
+   .map_io = am33xx_map_io,
+   .init_early = am33xx_init_early,
+   .init_irq   = ti816x_init_irq,
+   .timer  = &omap3_am33xx_timer,
+   .init_machine   = am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 74e84c6..e958c04 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -460,6 +460,13 @@ void __init ti816x_init_early(void)
omap_hwmod_init_postsetup();
omap3xxx_clk_init();
 }
+
+void __init am33xx_init_early(void)
+{
+   omap2_set_globals_am33xx();
+   omap_common_init_early();
+   omap3xxx_clk_init();
+}
 #endif

 #ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 037b0d7..7b29197 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -333,6 +333,8 @@ OMAP_SYS_TIMER(3)
 OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
2, OMAP3_MPU_SOURCE)
 OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
 #endif

 #ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/common.h 
b/arch/arm/plat-omap/include/plat/common.h
index bb8a6c1..9d7cc3c 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -39,6 +39,7 @@ extern struct sys_timer omap1_timer;
 extern struct sys_timer omap2_timer;
 extern struct sys_timer omap3_timer;
 extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
 extern struct sys_timer omap4_timer;
 extern bool omap_32k_timer_init(void);
 extern int __init omap_init_clocksource_32k(void);
@@ -55,6 +56,7 @@ void omap3_init_early(void);  /* Do not use this one */
 void am35xx_init_early(void);
 void ti816x_init_early(void);
 void omap4430_init_early(void);
+void am33xx_init_early(void);

 extern int omap_dss_reset(struct omap_hwmod *);

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources

[hvaibhav]

From: Afzal Mohammed 

This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.

Signed-off-by: Afzal Mohammed 
Signed-off-by: Vaibhav Hiremath 
Reviewed-by: Kevin Hilman 
---
 arch/arm/mach-omap2/clock3xxx_data.c   |3 +++
 arch/arm/mach-omap2/common.c   |   21 +
 arch/arm/mach-omap2/id.c   |6 ++
 arch/arm/mach-omap2/io.c   |   24 
 arch/arm/mach-omap2/serial.c   |4 ++--
 arch/arm/plat-omap/include/plat/am33xx.h   |   25 +
 arch/arm/plat-omap/include/plat/common.h   |2 ++
 arch/arm/plat-omap/include/plat/hardware.h |1 +
 arch/arm/plat-omap/include/plat/io.h   |   20 
 arch/arm/plat-omap/include/plat/omap34xx.h |2 ++
 arch/arm/plat-omap/io.c|5 +
 11 files changed, 111 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 5d0064a..c1ab6bc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3517,6 +3517,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+   } else if (cpu_is_am33xx()) {
+   cpu_mask = RATE_IN_AM33XX;
+   cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 110e5b9..16bac26 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -128,6 +128,27 @@ void __init omap2_set_globals_ti816x(void)
 {
__omap2_set_globals(&ti816x_globals);
 }
+
+#define AM33XX_TAP_BASE(AM33XX_CTRL_BASE + \
+   TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+   .class  = AM335X_CLASS,
+   .tap= AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE),
+   .ctrl   = AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+   .prm= AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+   .cm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+   __omap2_set_globals(&am33xx_globals);
+}
+
+void __init am33xx_map_io(void)
+{
+   omapam33xx_map_common_io();
+}
 #endif

 #if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f1784ee..37fe42f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -340,6 +340,10 @@ static void __init omap3_check_revision(const char 
**cpu_rev)
break;
}
break;
+   case 0xb944:
+   omap_revision = AM335X_REV_ES1_0;
+   *cpu_rev = "1.0";
+   break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -432,6 +436,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
cpu_name = "TI816X";
+   } else if (cpu_is_am335x()) {
+   cpu_name =  "AM335X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = "OMAP3430/3530";
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index da9bc4a..74e84c6 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -183,7 +183,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn= __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
.type   = MT_DEVICE
+   }
+};
+#endif
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+static struct map_desc omapam33xx_io_desc[] __initdata = {
+   {
+   .virtual= L4_34XX_VIRT,
+   .pfn= __phys_to_pfn(L4_34XX_PHYS),
+   .length = L4_34XX_SIZE,
+   .type   = MT_DEVICE
},
+   {
+   .virtual= L4_WK_AM33XX_VIRT,
+   .pfn= __phys_to_pfn(L4_WK_AM33XX_PHYS),
+   .length = L4_WK_AM33XX_SIZE,
+   .type   = MT_DEVICE
+   }
 };
 #endif

@@ -270,6 +287,13 @@ void __init omapti816x_map_common_io(void)
 }
 #endif

+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init omapam33xx_map_common_io(void)
+{
+   iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+}
+#endif
+
 #ifdef CONFIG_ARCH_OMAP4
 void __init omap

[PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM

[hvaibhav]

From: Vaibhav Hiremath 

This patch set adds support for AM335x device having
Cortex-A8 MPU.

Official website - http://www.ti.com/product/am3359

AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly added device in
the family.
This means, cpu_is_omap34xx(), cpu_is_am33xx() and
cpu_is_am335x() checks return success for AM335X.

Also, I have validated OMAP3 boot test with this patch-series on
OMAP3EVM.

Changes from V4:
- Patches have been reviewed by Kevin Hilman.
- As per Kevin Hilman's comments updated comment in debug-macro.S,
  for AM33XX.

Changes from V3:
- Common platform patch has already been accepted and available
  under linux-omap/soc and linux-omap/master branch.
- Clean-up where cpu_is_ instances are being used and patches
  has been submitted to the list.
- These patches have been created on top of cleanup patches -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58276.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58277.html
- Based on Tony's request, rebased patches against linux-omap/fixes
  (+ common platform patch).

Changes from V2(RFC):
- Rebased against Paul's OMAP_CHIP* cleanup patches
git://git.pwsan.com/linux-2.6_omap_chip_remove_cleanup_3.2

Changes from V1(RFC):
- Created separate cpu/SoC class for AM33XX family of devices,
  due to all known facts. This is been mentioned in main-chain
https://patchwork.kernel.org/patch/1056312/
- BUG Fix in debug-macro.S, which was leading to build failure.
https://patchwork.kernel.org/patch/1056302/

Afzal Mohammed (3):
  arm:omap:am33xx: Update common OMAP machine specific sources
  arm:omap:am33xx: Add AM335XEVM machine support
  arm:omap:am33xx: Add low level debugging support

 arch/arm/mach-omap2/Kconfig|5 
 arch/arm/mach-omap2/Makefile   |1 +
 arch/arm/mach-omap2/board-am3517evm.c  |   21 
 arch/arm/mach-omap2/clock3xxx_data.c   |3 ++
 arch/arm/mach-omap2/common.c   |   21 
 arch/arm/mach-omap2/id.c   |6 
 arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
 arch/arm/mach-omap2/io.c   |   31 
 arch/arm/mach-omap2/serial.c   |4 +-
 arch/arm/mach-omap2/timer.c|2 +
 arch/arm/plat-omap/include/plat/am33xx.h   |   25 +++
 arch/arm/plat-omap/include/plat/common.h   |4 +++
 arch/arm/plat-omap/include/plat/hardware.h |1 +
 arch/arm/plat-omap/include/plat/io.h   |   20 +++
 arch/arm/plat-omap/include/plat/omap34xx.h |2 +
 arch/arm/plat-omap/include/plat/serial.h   |4 +++
 arch/arm/plat-omap/include/plat/uncompress.h   |6 
 arch/arm/plat-omap/io.c|5 
 18 files changed, 175 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h

--
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 03/11] arm:omap:am33xx: Add power domain data

[Rajendra Nayak]

[..]

First some general comments:

At first glance, it seems like there could be much more reuse with OMAP4
code here.  From what I see, AM33x has only one partition compared to
several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4
functions and just use a single partition.

Kevin,

Indeed it looks close to OMAP4, but it becomes difficult and ugly once you
Start getting into implementation details, for example,

  - All PRM offsets don't match, you will end up with
cpu_is_xxx check and handle this. Applicable to all power domains.

OMAP4430_PRM_MPU_INST   0x0300
Vs
AM33XX_PRM_MPU_MOD  0x0E00

OMAP4430_PRM_WKUP_INST  0x1700
Vs
AM33XX_PRM_WKUP_MOD 0x0D00


The above prcm offsets being different on am33xx doesn't really
seem to be the issue since its already part of the powerdomain
struct. See how omap2 and omap3 have different offsets and still end
up using common code. You won't need any cpu_is_* checks for those.

The real problem however seems to be with the completely different
PWSTCTRL and PWSTST offsets. They seem to be so messed up that they are
not even consistent across all powerdomains in the same SoC.
The only solution I could think of to handle these was if we had
a provision to specify the offsets on a per powerdomain level by
adding them to the powerdomain struct. It could be populated only
on SoC's which have these weirdly different offsets and for the rest
it could just get initialized with fixed values for all powerdomains
at init.

Kevin/Paul/Benoit any thoughts?



  - Also there are some differences in logic states of domains as well.

Another important point is, we have considered AM33xx as OMAP3
family of device (ARCH_OMAP3).
So you may end up with number of cpu_is_xxx checks in code.



IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4.

 From what I read (after an admittedly quick glance), the main thing you
need is a way to override the PRM offsets due to the fact that some
crazy person decided to make each instance different.


This was one of the major reason why I had chosen and implemented separately
for AM33xx.



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: OMAP: hwmod: Look for hwmod/module level context lost count if supported

[Rajendra Nayak]

On Tuesday 29 November 2011 11:40 PM, Cousson, Benoit wrote:

Hi Rajendra,

Sorry for the delay, I kind of forgot your series :-(

On 11/3/2011 11:54 AM, Nayak, Rajendra wrote:

Now that OMAP4 has hwmod/module level context lost counters, make
omap_hwmod_get_context_loss_count() return them on platforms where they
exist, else fall back on the pwrdm level counters for older platforms.

Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index ac17748..9d140c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2658,9 +2658,14 @@ u32 omap_hwmod_get_context_loss_count(struct
omap_hwmod *oh)
struct powerdomain *pwrdm;
int ret = 0;

- pwrdm = omap_hwmod_get_pwrdm(oh);
- if (pwrdm)
- ret = pwrdm_get_context_loss_count(pwrdm);
+ if (oh->prcm.omap4.context_offs) {


I don't think it is safe to use that, since this is an union.
You do know what OMAP2 & 3 will put in that location.
It might be zero, but who knows?


Thats true, I need to figure out a better way to identify
when a module level context count is supported and when its
at the pwrdm level. Will repost with a fix.

Thanks for the review.




+ /* Support for per-hwmod context register */
+ ret = oh->prcm.omap4.context_lost_counter;
+ } else {
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ if (pwrdm)
+ ret = pwrdm_get_context_loss_count(pwrdm);
+ }

return ret;
}


Regards,
Benoit


--
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 0/3] Introducing TI's New SoC/board AM335XEVM

[Mohammed, Afzal]

Hi Kevin,

On Thu, Dec 01, 2011 at 20:40:03, Hilman, Kevin wrote:
> "Hiremath, Vaibhav"  writes:
:
> > We can detect the board using on-board EEPROM, so same mach-id
> > should work for both EVM and Beagle. 
> 
> > And also going forward with device tree approach we may
> > not need different id's, right?
> 
> Right, which is why I'm wondering why are there sevral new AM33x
> mach-types when only one of them is being used:
> 
> 3684TI AM335X IA EVMam335xiaevm Afzal Mohammed
> 3589TI AM335X EVM   am335xevm   Vaibhav Bedia
> 3808Beaglebone Boardbeaglebone  Steven Kipisz
> 
> Russell has been trying to cleanup athe mach-types, so if these others
> are not going to be used, I suggest they be deleted.

"3684-TI AM335X IA EVM" is required as IA EVM uses a different UART,
because of which early prints can't be captured, problem mentioned
in http://marc.info/?l=linux-omap&m=131286938723617&w=2


Note: Paul advised to post to linux-arm-ker...@lists.infradead.org,
but it never made to LAKML, even though I sent couple of times and got
a reply "Is being held until the list moderator can review it for
approval. The reason it is being held: Message has a suspicious header"

Regards
Afzal

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 v2] ARM: OMAP1: Fix dpll1 reprogramming related issues

[Tony Lindgren]

* Janusz Krzysztofik  [111201 11:38]:
> After dpll1 reprogramming has been moved from setup_arch() to
> kernel_init(), I've been observing several issues, resulting in
> undesired system behaviour on my Amstrad Delta. This series fixes
> those most important (2/5 and 5/5 v2 previously), with a "stuck at 60MHz
> rate" issue going to be fixed with Tony's proposed solution instead of
> my previous 3/5.
> 
> Janusz Krzysztofik (2):
>   ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate
>   ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
> 
>  arch/arm/mach-omap1/clock_data.c |9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)

Thanks, got these three patches now applied into fixes on top of -rc4.

Can you please try it out to make sure it's all working for you now?

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value

[Laurent Pinchart]

Hi Sergio,

On Thursday 01 December 2011 18:35:20 Aguirre, Sergio wrote:
> On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart wrote:
> > On Thursday 01 December 2011 01:14:51 Sergio Aguirre wrote:
> >> The define should be the result of 1 << Bit number.
> >> 
> >> Bit number for GPOCTL.GPO3 field is 2, which results
> >> in 0x4 value.
> >> 
> >> Signed-off-by: Sergio Aguirre 
> >> ---
> >>  include/linux/mfd/twl6040.h |2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
> >> index 2463c261..2a7ff16 100644
> >> --- a/include/linux/mfd/twl6040.h
> >> +++ b/include/linux/mfd/twl6040.h
> >> @@ -142,7 +142,7 @@
> >> 
> >>  #define TWL6040_GPO1 0x01
> >>  #define TWL6040_GPO2 0x02
> >> -#define TWL6040_GPO3 0x03
> >> +#define TWL6040_GPO3 0x04
> > 
> > What about defining the fields as (1 << x) instead then ?
> 
> I thought about that, but I guess I just wanted to keep it consistent with
> the rest of the file.

I've seen that as well. I'm fine with keeping the above defines if you prefer.

> Maybe I can create a separate patch for changing all these bitwise flags to
> use BIT() macros instead.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Russell King - ARM Linux]

On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> The intention behind the clk_{allow,block}_rate_change() proposal was to 
> allow the current user of the clock to change its rate without having to 
> call clk_{allow,block}_rate_change(), if that driver was the sole user of 
> the clock.

And how does a driver know that?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: OMAP1: Update dpll1 default rate reprogramming method

[Janusz Krzysztofik]

According to comments in omap1_select_table_rate(), reprogramming dpll1
is tricky, and should always be done from SRAM.

While being at it, move OMAP730 special case handling inside
omap_sram_reprogram_clock().

Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1
reprogramming related issues", which it depends on.
Tested on Amstrad Delta.

Signed-off-by: Janusz Krzysztofik 
---
v2 changes:
* was 1/5, now separated with the intention of being deferred until next
  merge window, and refreshed on top of that series,
* Fix replaced with Update in the summary.


 arch/arm/mach-omap1/clock.c  |6 +-
 arch/arm/mach-omap1/clock_data.c |7 +--
 arch/arm/plat-omap/sram.c|3 +++
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 84ef704..3899176 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -215,12 +215,8 @@ int omap1_select_table_rate(struct clk *clk, unsigned long 
rate)
/*
 * In most cases we should not need to reprogram DPLL.
 * Reprogramming the DPLL is tricky, it must be done from SRAM.
-* (on 730, bit 13 must always be 1)
 */
-   if (cpu_is_omap7xx())
-   omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val | 
0x2000);
-   else
-   omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val);
+   omap_sram_reprogram_clock(ptr->dpllctl_val, ptr->ckctl_val);
 
/* XXX Do we need to recalculate the tree below DPLL1 at this point? */
ck_dpll1_p->rate = ptr->pll_rate;
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 0ef1e7d..e616042 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include  /* for omap_sram_reprogram_clock() */
 #include/* for OTG_BASE */
 
 #include "clock.h"
@@ -937,8 +938,10 @@ void __init omap1_clk_late_init(void)
/* Find the highest supported frequency and enable it */
if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
pr_err("System frequencies not set, using default. Check your 
config.\n");
-   omap_writew(0x2290, DPLL_CTL);
-   omap_writew(cpu_is_omap7xx() ? 0x2005 : 0x0005, ARM_CKCTL);
+   /*
+* Reprogramming the DPLL is tricky, it must be done from SRAM.
+*/
+   omap_sram_reprogram_clock(0x2290, 0x0005);
ck_dpll1.rate = OMAP1_DPLL1_SANE_VALUE;
}
propagate_rate(&ck_dpll1);
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 8b28664..312bee8 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -224,6 +224,9 @@ static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 
ckctl);
 void omap_sram_reprogram_clock(u32 dpllctl, u32 ckctl)
 {
BUG_ON(!_omap_sram_reprogram_clock);
+   /* On 730, bit 13 must always be 1 */
+   if (cpu_is_omap7xx())
+   ckctl |= 0x2000;
_omap_sram_reprogram_clock(dpllctl, ckctl);
 }
 
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP1: Remove unsafe clock values from omap1_defconfig

[Janusz Krzysztofik]

DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(), resulting in the defalut rate of 60 MHz
always used instead of the one selected in .config. OTOH, in
omap1_defconfig we currently rely on Kconfig options for the supported
MHz rates in case of boards which boot with dpll1 not set correctly by
their boot loaders.

This means that before we allow for reprogramming of dpll1 rate, we
should remove all unsafe clock selections from omap1_defconfig,
otherwise it will stop booting on boards with imperfect boot loaders,
as it would always try to change to 216MHz.

Keep only one safe clock rate per each supported xtal frequency, i.e.
60MHZ dpll1 for 12MHz xtal and 182MHz dpll1 for 13MHz xtal.

BTW, this change goes into the direction of removing all OMAP1 clock
rate options, planned for next merge window.

Signed-off-by: Janusz Krzysztofik 
---
Resending with commit summary tagged correctly and commit message
updated with info about next merge window planned direction.

 arch/arm/configs/omap1_defconfig |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index a7e7775..945a34f 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -48,12 +48,7 @@ CONFIG_MACH_SX1=y
 CONFIG_MACH_NOKIA770=y
 CONFIG_MACH_AMS_DELTA=y
 CONFIG_MACH_OMAP_GENERIC=y
-CONFIG_OMAP_ARM_216MHZ=y
-CONFIG_OMAP_ARM_195MHZ=y
-CONFIG_OMAP_ARM_192MHZ=y
 CONFIG_OMAP_ARM_182MHZ=y
-CONFIG_OMAP_ARM_168MHZ=y
-# CONFIG_OMAP_ARM_60MHZ is not set
 # CONFIG_ARM_THUMB is not set
 CONFIG_PCCARD=y
 CONFIG_OMAP_CF=y
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

[Janusz Krzysztofik]

Otherwise timing is inaccurate, resulting in devices which depend on it,
like omap-keypad, broken.

Created and tested on top of linux-omap/fixes on Amstrad Delta.

Signed-off-by: Janusz Krzysztofik 
---
v2 changes:
* was 5/5 v2, rebased on 1/2.

 arch/arm/mach-omap1/clock_data.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index b001299..0ef1e7d 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -16,6 +16,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include   /* for machine_is_* */
@@ -927,7 +929,9 @@ int __init omap1_clk_init(void)
 
 void __init omap1_clk_late_init(void)
 {
-   if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
+   unsigned long rate = ck_dpll1.rate;
+
+   if (rate >= OMAP1_DPLL1_SANE_VALUE)
return;
 
/* Find the highest supported frequency and enable it */
@@ -939,4 +943,5 @@ void __init omap1_clk_late_init(void)
}
propagate_rate(&ck_dpll1);
omap1_show_rates();
+   loops_per_jiffy = cpufreq_scale(loops_per_jiffy, rate, ck_dpll1.rate);
 }
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2 v2] ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate

[Janusz Krzysztofik]

Use the exact value found in omap1_rate_table, otherwise I have been
experiencing issues with correct timekeeping on my Amstrad Delta.

Created and tested on top of linux-omap/fixes, not yet in 3.2-rc.

Signed-off-by: Janusz Krzysztofik 
---
v2 changes:
* previous 2/5, refreshed directly on linux-omap/fixes after 1/5
  left for the next merge window.

 arch/arm/mach-omap1/clock_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 1297bb5..b001299 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -934,7 +934,7 @@ void __init omap1_clk_late_init(void)
if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
pr_err("System frequencies not set, using default. Check your 
config.\n");
omap_writew(0x2290, DPLL_CTL);
-   omap_writew(cpu_is_omap7xx() ? 0x3005 : 0x1005, ARM_CKCTL);
+   omap_writew(cpu_is_omap7xx() ? 0x2005 : 0x0005, ARM_CKCTL);
ck_dpll1.rate = OMAP1_DPLL1_SANE_VALUE;
}
propagate_rate(&ck_dpll1);
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2 v2] ARM: OMAP1: Fix dpll1 reprogramming related issues

[Janusz Krzysztofik]

After dpll1 reprogramming has been moved from setup_arch() to
kernel_init(), I've been observing several issues, resulting in
undesired system behaviour on my Amstrad Delta. This series fixes
those most important (2/5 and 5/5 v2 previously), with a "stuck at 60MHz
rate" issue going to be fixed with Tony's proposed solution instead of
my previous 3/5.

Janusz Krzysztofik (2):
  ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate
  ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

 arch/arm/mach-omap1/clock_data.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig

[Tony Lindgren]

* Janusz Krzysztofik  [111201 10:48]:
> On Thursday 01 of December 2011 at 20:04:55, Tony Lindgren wrote:
> > 
> > From: Tony Lindgren 
> > Date: Thu, 1 Dec 2011 11:00:11 -0800
> > Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that 
> > boot at rates below 60MHz
> > 
> > Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix
> > reprogramming of dpll1 rate) fixed a regression for systems that
> > did not rely on bootloader set rates.
> > 
> > However, it also introduced a new problem where the rates selected
> > in .config would not take affect as omap1_select_table_rate
> > currently refuses to reprogram DPLL1 if it's already initialized.
> > 
> > This was not a problem earlier, as the reprogramming was done
> > earlier with ck_dpll1_p->rate uninitialized.
> > 
> > Fix this by forcing the reprogramming on systems booting at rates
> > below 60MHz. Note that the long term fix is to make the rates
> > SoC specific later on.
> > 
> > Thanks for Janusz Krzysztofik  for figuring
> > this one out.
> > 
> > Reported-by: Janusz Krzysztofik 
> > Signed-off-by: Tony Lindgren 
> 
> Acked-by: Janusz Krzysztofik 
> 
> However, this way or another, we are back to your mentioned problem of 
> omap1_defconfig always switching to 216 MHz, I'm afraid. Then, 2a/5 v1 
> "Remove unsafe clock values from omap1_defconfig" can still be helpful.

OK that makes sense now also in case there are other systems that
boot at rates below 60MHz.
 
> Anyway, I'm resending (refreshed) 2/5 and 5/5 as rc fixes as you 
> suggested before, 1/5 "ARM: OMAP1: Fix dpll1 default rate reprogramming 
> method" intended for next, and 2a/5 v2 "ARM: OMAP1: select clock rate by 
> CPU type" also for next but as an RFC. 

Great, sounds like we got the fixes needed for the -rc cycle then.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig

[Janusz Krzysztofik]

On Thursday 01 of December 2011 at 20:04:55, Tony Lindgren wrote:
> 
> From: Tony Lindgren 
> Date: Thu, 1 Dec 2011 11:00:11 -0800
> Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot 
> at rates below 60MHz
> 
> Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix
> reprogramming of dpll1 rate) fixed a regression for systems that
> did not rely on bootloader set rates.
> 
> However, it also introduced a new problem where the rates selected
> in .config would not take affect as omap1_select_table_rate
> currently refuses to reprogram DPLL1 if it's already initialized.
> 
> This was not a problem earlier, as the reprogramming was done
> earlier with ck_dpll1_p->rate uninitialized.
> 
> Fix this by forcing the reprogramming on systems booting at rates
> below 60MHz. Note that the long term fix is to make the rates
> SoC specific later on.
> 
> Thanks for Janusz Krzysztofik  for figuring
> this one out.
> 
> Reported-by: Janusz Krzysztofik 
> Signed-off-by: Tony Lindgren 

Acked-by: Janusz Krzysztofik 

However, this way or another, we are back to your mentioned problem of 
omap1_defconfig always switching to 216 MHz, I'm afraid. Then, 2a/5 v1 
"Remove unsafe clock values from omap1_defconfig" can still be helpful.

Anyway, I'm resending (refreshed) 2/5 and 5/5 as rc fixes as you 
suggested before, 1/5 "ARM: OMAP1: Fix dpll1 default rate reprogramming 
method" intended for next, and 2a/5 v2 "ARM: OMAP1: select clock rate by 
CPU type" also for next but as an RFC. 

Thanks,
Janusz

> 
> diff --git a/arch/arm/mach-omap1/clock_data.c 
> b/arch/arm/mach-omap1/clock_data.c
> index 1297bb5..3f30561 100644
> --- a/arch/arm/mach-omap1/clock_data.c
> +++ b/arch/arm/mach-omap1/clock_data.c
> @@ -930,6 +930,9 @@ void __init omap1_clk_late_init(void)
>   if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
>   return;
>  
> + /* System booting at unusable rate, force reprogramming of DPLL1 */
> + ck_dpll1_p->rate = 0;
> +
>   /* Find the highest supported frequency and enable it */
>   if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
>   pr_err("System frequencies not set, using default. Check your 
> config.\n");
> --
> 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 2a/5 v2] ARM: OMAP1: select clock rate by CPU type

[Tony Lindgren]

* Janusz Krzysztofik  [111201 10:19]:
> On Thursday 01 of December 2011 at 19:22:54, Tony Lindgren wrote:
> > * Janusz Krzysztofik  [111201 01:35]:
> > > On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote:
> > > > 
> > > > We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ 
> > > > options
> > > > too, right?
> > > 
> > > Right, but then, perhaps the initial version of patch 2a/5, which 
> > > already started removing them, from omap1_defconfig for now, then going 
> > > into the right direction while unblocking another regression fix (3/5), 
> > > _is_ a good candidate for an rc fix?
> > 
> > But we did not allow dpll1 reprogramming earlier either,
> 
> Wrong. Without OMAP_CLOCKS_SET_BY_BOOTLOADER selected, we always did, 
> but only once, early at boot, before ck_dpll1_p->rate was set first from 
> omap1_clk_init(), and never retried later, that's why that check which I 
> removed with 3/5 was never in the game until 
> e9b7086b80c4d9e354f4edc9e280ae85a60df408.

Yeah you're right. You found what caused the regression :)
 
> > so we should
> > not need to make all these changes during the -rc cycle. I'm suspecting
> > that we've had this same behaviour for a really long time, and we just
> > have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER
> > option set.
> > 
> > So I'm baffled how your board would be booting at a different rate
> > compared to v3.1, it seems that the logic has not changed there. Or
> > else we have some simple bug somewhere.
> > 
> > Care to try to verify at what point your system started booting at
> > 60MHz rate?
> 
> Since e9b7086b80c4d9e354f4edc9e280ae85a60df408, I guess, and it's hard 
> to confirm wituout bisecting the issue with too early sram call, back 
> until things still worked like before map_io related changes. I will do 
> that if you decide we should try to revert.

No need to bisect, I think we can just reset ck_dpll1_p->rate for
systems booting at below 60MHz rate to force the reprogramming.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig

[Tony Lindgren]

* Janusz Krzysztofik  [111201 10:04]:
> On Thursday 01 of December 2011 at 18:17:58, Tony Lindgren wrote:
> > 
> > --- a/arch/arm/mach-omap1/clock_data.c
> > +++ b/arch/arm/mach-omap1/clock_data.c
> > @@ -927,7 +927,7 @@ int __init omap1_clk_init(void)
> >  
> >  void __init omap1_clk_late_init(void)
> >  {
> > -   if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
> > +   if (ck_dpll1.rate > OMAP1_DPLL1_SANE_VALUE)
> > return;
> >  
> > /* Find the highest supported frequency and enable it */
> 
> This change really makes sense to me, however, knowing the initial 
> (bootloader selected) clock rate my board boots at, which is 
> unfortunately raw 12 MHz, I would be surprised if that helped.

OK, that's not it then. BTW, we should be able to drop that test once
we have your patches applied.
 
> Before e9b7086b80c4d9e354f4edc9e280ae85a60df408, 
> omap1_select_table_rate() was returning the rate selected with .config 
> because it was called early, with ck_dpll1_p->rate uninitialized. Now it 
> is not, and returns nothing, resulting in 60 MHz default. Then, the only 
> way I can see to correct the problem is something like patch 3/5, which 
> you are justifiably affraid of of always switching to 216 MHz with 
> omap1_defconfig.

Ah, you got it! That's what causes the regression. How about the following
fix for the -rc cycle then?

Tony


From: Tony Lindgren 
Date: Thu, 1 Dec 2011 11:00:11 -0800
Subject: [PATCH] ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot 
at rates below 60MHz

Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix
reprogramming of dpll1 rate) fixed a regression for systems that
did not rely on bootloader set rates.

However, it also introduced a new problem where the rates selected
in .config would not take affect as omap1_select_table_rate
currently refuses to reprogram DPLL1 if it's already initialized.

This was not a problem earlier, as the reprogramming was done
earlier with ck_dpll1_p->rate uninitialized.

Fix this by forcing the reprogramming on systems booting at rates
below 60MHz. Note that the long term fix is to make the rates
SoC specific later on.

Thanks for Janusz Krzysztofik  for figuring
this one out.

Reported-by: Janusz Krzysztofik 
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 1297bb5..3f30561 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -930,6 +930,9 @@ void __init omap1_clk_late_init(void)
if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
return;
 
+   /* System booting at unusable rate, force reprogramming of DPLL1 */
+   ck_dpll1_p->rate = 0;
+
/* Find the highest supported frequency and enable it */
if (omap1_select_table_rate(&virtual_ck_mpu, ~0)) {
pr_err("System frequencies not set, using default. Check your 
config.\n");
--
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 2a/5 v2] ARM: OMAP1: select clock rate by CPU type

[Janusz Krzysztofik]

On Thursday 01 of December 2011 at 19:22:54, Tony Lindgren wrote:
> * Janusz Krzysztofik  [111201 01:35]:
> > On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote:
> > > 
> > > We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ 
> > > options
> > > too, right?
> > 
> > Right, but then, perhaps the initial version of patch 2a/5, which 
> > already started removing them, from omap1_defconfig for now, then going 
> > into the right direction while unblocking another regression fix (3/5), 
> > _is_ a good candidate for an rc fix?
> 
> But we did not allow dpll1 reprogramming earlier either,

Wrong. Without OMAP_CLOCKS_SET_BY_BOOTLOADER selected, we always did, 
but only once, early at boot, before ck_dpll1_p->rate was set first from 
omap1_clk_init(), and never retried later, that's why that check which I 
removed with 3/5 was never in the game until 
e9b7086b80c4d9e354f4edc9e280ae85a60df408.

> so we should
> not need to make all these changes during the -rc cycle. I'm suspecting
> that we've had this same behaviour for a really long time, and we just
> have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER
> option set.
> 
> So I'm baffled how your board would be booting at a different rate
> compared to v3.1, it seems that the logic has not changed there. Or
> else we have some simple bug somewhere.
> 
> Care to try to verify at what point your system started booting at
> 60MHz rate?

Since e9b7086b80c4d9e354f4edc9e280ae85a60df408, I guess, and it's hard 
to confirm wituout bisecting the issue with too early sram call, back 
until things still worked like before map_io related changes. I will do 
that if you decide we should try to revert.

Thanks,
Janusz
--
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 2a/5] Remove unsafe clock values from omap1_defconfig

[Janusz Krzysztofik]

On Thursday 01 of December 2011 at 18:17:58, Tony Lindgren wrote:
> * Janusz Krzysztofik  [111201 01:20]:
[snip]
> > Perhaps 
> > we should rather think of reverting a few commits which caused all these 
> > problems if fixing them all during rc cycle seems not possible? I 
> > haven't bisected them yet, rather concentrated on providing fixes, but I 
> > can still try to do it, starting back from the original issue 
> > (http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.
> 
> We can't revert that because the SRAM init has been moved to later for
> map_io. 

Yes, I know that. What I don't know yet is what else should be reverted 
to fix the original issue other than applying  
e9b7086b80c4d9e354f4edc9e280ae85a60df408, which seems to introduce (or 
maybe 'exhibit' is a better word here) more bugs than it fixes.

> But if that patch changed the behaviour on your board, then that's
> the problem we should fix.
> 
> If you're now stuck at 60MHz rate, care to see if the following patch
> makes the kernel behave the same way as before for you?
[snip]
> 
> --- a/arch/arm/mach-omap1/clock_data.c
> +++ b/arch/arm/mach-omap1/clock_data.c
> @@ -927,7 +927,7 @@ int __init omap1_clk_init(void)
>  
>  void __init omap1_clk_late_init(void)
>  {
> - if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
> + if (ck_dpll1.rate > OMAP1_DPLL1_SANE_VALUE)
>   return;
>  
>   /* Find the highest supported frequency and enable it */

This change really makes sense to me, however, knowing the initial 
(bootloader selected) clock rate my board boots at, which is 
unfortunately raw 12 MHz, I would be surprised if that helped.

Before e9b7086b80c4d9e354f4edc9e280ae85a60df408, 
omap1_select_table_rate() was returning the rate selected with .config 
because it was called early, with ck_dpll1_p->rate uninitialized. Now it 
is not, and returns nothing, resulting in 60 MHz default. Then, the only 
way I can see to correct the problem is something like patch 3/5, which 
you are justifiably affraid of of always switching to 216 MHz with 
omap1_defconfig.

Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Mark Brown]

On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:

> So for example, if you had a driver that did:

> c = clk_get(dev, clk_name);
> clk_enable(c);
> clk_set_rate(c, clk_rate);

> and c was currently not enabled by any other driver on the system, and 
> nothing else had called clk_block_rate_change(c), then the rate change 
> would be allowed to proceed.  (modulo any notifier activity, etc.)  

> So clk_{allow,block}_rate_change() was simply intended to allow or 
> restrict other users of the same clock, not the current user.

Ah, sorry!  I'd totally misunderstood what you were proposing.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Paul Walmsley]

Hi Mark,

On Thu, 1 Dec 2011, Mark Brown wrote:

> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
> 
> > Clock rate/parent-change notifiers are requirements for DVFS use-cases, 
> > and they must be paired with something like the 
> > clk_{allow,block}_rate_change() functions to work efficiently.  I intend 
> > to comment on this later; it's not a simple problem.  It might be worth 
> > noting that Tero and I implemented a simplified version of this for the 
> > N900.
> 
> I'm thinking that if we're going to have clk_{allow,block}_rate_change()
> we may as well make that the main interface to enable rate changes - if
> a device wants to change the clock rate it allows rate changes using
> that interface rather than by disabling the clocks.  I've got devices
> which can do glitch free updates of active clocks so having to disable
> would be a real restriction, and cpufreq would have issues with actually
> disabling the clock too I expect.

The intention behind the clk_{allow,block}_rate_change() proposal was to 
allow the current user of the clock to change its rate without having to 
call clk_{allow,block}_rate_change(), if that driver was the sole user of 
the clock.

So for example, if you had a driver that did:

c = clk_get(dev, clk_name);
clk_enable(c);
clk_set_rate(c, clk_rate);

and c was currently not enabled by any other driver on the system, and 
nothing else had called clk_block_rate_change(c), then the rate change 
would be allowed to proceed.  (modulo any notifier activity, etc.)  

So clk_{allow,block}_rate_change() was simply intended to allow or 
restrict other users of the same clock, not the current user.


- 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 v3 3/5] clk: introduce the common clock framework

[Turquette, Mike]

On Thu, Dec 1, 2011 at 6:42 AM, Mark Brown
 wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
>> Clock rate/parent-change notifiers are requirements for DVFS use-cases,
>> and they must be paired with something like the
>> clk_{allow,block}_rate_change() functions to work efficiently.  I intend
>> to comment on this later; it's not a simple problem.  It might be worth
>> noting that Tero and I implemented a simplified version of this for the
>> N900.
>
> I'm thinking that if we're going to have clk_{allow,block}_rate_change()
> we may as well make that the main interface to enable rate changes - if
> a device wants to change the clock rate it allows rate changes using
> that interface rather than by disabling the clocks.  I've got devices
> which can do glitch free updates of active clocks so having to disable
> would be a real restriction, and cpufreq would have issues with actually
> disabling the clock too I expect.
>

I agree that imposing a "disable clk before changing rate" policy in
the framework core is a bad idea.  During discussion on the
CLK_GATE_SET_RATE flag in the patch #2 Shawn commented that he has
some clks that must be enabled to change their rates (I assume he
means PLLs but that detail doesn't really matter).

Regards,
Mike
--
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: Setting OMAP DSS fck

[Paul Walmsley]

On Thu, 1 Dec 2011, Tomi Valkeinen wrote:

> Why is it that the rate of DSS functional clock (dss_dss_clk on OMAP4)
> cannot be set, but we need to get the parent of the fck, and set the
> rate of that? The same is on OMAP3.
> 
> From driver's perspective I think this only makes things more complex,
> as the driver is not interested in the parent, only about the dss fck.

Yeah, I agree.  We've talked about implementing rate changes that 
percolate up to some higher point in the clock tree, but have never gotten 
around to it due to other, higher priorities.  And now the common clock 
discussion has reduced the desire to do much OMAP-specific implementation 
of this stuff.

Another (related) problem is that the driver probably needs to know the 
ranges of the possible values that can be set.


- 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 2a/5 v2] ARM: OMAP1: select clock rate by CPU type

[Tony Lindgren]

* Janusz Krzysztofik  [111201 01:35]:
> On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote:
> > 
> > We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options
> > too, right?
> 
> Right, but then, perhaps the initial version of patch 2a/5, which 
> already started removing them, from omap1_defconfig for now, then going 
> into the right direction while unblocking another regression fix (3/5), 
> _is_ a good candidate for an rc fix?

But we did not allow dpll1 reprogramming earlier either, so we should
not need to make all these changes during the -rc cycle. I'm suspecting
that we've had this same behaviour for a really long time, and we just
have not seen it as omap1_defconfig had OMAP_CLOCKS_SET_BY_BOOTLOADER
option set.

So I'm baffled how your board would be booting at a different rate
compared to v3.1, it seems that the logic has not changed there. Or
else we have some simple bug somewhere.

Care to try to verify at what point your system started booting at
60MHz rate?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume

[Chris Ball]

Hi,

On Tue, Nov 22 2011, Eliad Peller wrote:
> When an mmc card has the MMC_PM_KEEP_POWER flag, it shouldn't
> be powered off on suspend (and thus doesn't have to be powered-on
> on resume)
>
> While on it, change the suspend flow a bit, to make it a bit
> easier to follow.
>
> Signed-off-by: Eliad Peller 

Tony, feel free to merge this patchset (if you're happy with the rest of
it) through your tree, with my:

Acked-by: Chris Ball 

for this patch.  Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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 01/11] TWL6030: Add mapping for auxiliary regs

[Aguirre, Sergio]

Hi Balaji,

Thanks for the review.

On Thu, Dec 1, 2011 at 9:58 AM, T Krishnamoorthy, Balaji
 wrote:
> On Thu, Dec 1, 2011 at 5:44 AM, Sergio Aguirre  wrote:
>> Signed-off-by: Sergio Aguirre 
>> ---
>>  drivers/mfd/twl-core.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
>> index bfbd660..e26b564 100644
>> --- a/drivers/mfd/twl-core.c
>> +++ b/drivers/mfd/twl-core.c
>> @@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
>>        { SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
>>        { SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
>>
>> -       { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
>> +       { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },
>
> Instead you can use TWL6030_MODULE_ID1, with base address as
> zero for all registers in auxiliaries register map.

Ok.

I'm actually thinking about this, and in the process on reviewing the
need to access those registers.

I should probably be using the regulator framework to control VAUX3 instead...

Thanks for your inputs.

Regards,
Sergio

>
>>        { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
>>        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
>>        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
>> --
>> 1.7.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

[Aguirre, Sergio]

Hi Laurent,

On Thu, Dec 1, 2011 at 11:26 AM, Laurent Pinchart
 wrote:
> Hi Sergio,
>
> On Thursday 01 December 2011 01:14:49 Sergio Aguirre wrote:
>> Hi everyone,
>>
>> This is the second version of the OMAP4 ISS driver,
>> now ported to the Media Controller framework AND supporting
>> videobuf2 framework.
>
> Thanks a lot for working on this.

And thanks to you for the patience and interest. I hope to make faster
updates from now on :)

>
>> This patchset should apply cleanly on top of v3.2-rc3 kernel tag.
>>
>> This driver attempts to provide an fully open source solution to
>> control the OMAP4 Imaging SubSystem (a.k.a. ISS).
>>
>> Starts with just CSI2-A interface support, and pretends to be
>> ready for expansion to add support to the many ISS block modules
>> as possible.
>>
>> Please see newly added documentation for more details:
>>
>> Documentation/video4linux/omap4_camera.txt
>>
>> Any comments/complaints are welcome. :)
>
> I've started reviewing the patches, but it might take some time as I got lots
> on my plate at the moment. I will concentrate on the ISS patch (06/11) first.
> The sensor drivers are needed now for testing purpose, but can get their share
> of love later.

Brilliant! That's fine with me.

Thanks for your time. I really appreciate it.

Regards,
Sergio

>
>> Changes since v1:
>> - Simplification of auxclk handling in board files. (Pointed out by: Roger
>> Quadros) - Cleanup of Camera support enablement for 4430sdp & panda.
>> (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted
>> platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2
>> migration (Removal of custom iss_queue buffer handling driver) - Proper
>> GPO3 handling for CAM_SEL in 4430sdp.
>>
>> Sergio Aguirre (10):
>>   TWL6030: Add mapping for auxiliary regs
>>   mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
>>   OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
>>   OMAP4: Add base addresses for ISS
>>   v4l: Add support for omap4iss driver
>>   v4l: Add support for ov5640 sensor
>>   v4l: Add support for ov5650 sensor
>>   arm: omap4430sdp: Add support for omap4iss camera
>>   arm: omap4panda: Add support for omap4iss camera
>>   arm: Add support for CMA for omap4iss driver
>>
>> Stanimir Varbanov (1):
>>   v4l: Introduce sensor operation for getting interface configuration
>>
>>  Documentation/video4linux/omap4_camera.txt    |   60 ++
>>  arch/arm/mach-omap2/Kconfig                   |   54 +
>>  arch/arm/mach-omap2/Makefile                  |    3 +
>>  arch/arm/mach-omap2/board-4430sdp-camera.c    |  221 
>>  arch/arm/mach-omap2/board-omap4panda-camera.c |  198 
>>  arch/arm/mach-omap2/devices.c                 |   40 +
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |   16 +-
>>  arch/arm/plat-omap/include/plat/omap4-iss.h   |   42 +
>>  arch/arm/plat-omap/include/plat/omap44xx.h    |    9 +
>>  drivers/media/video/Kconfig                   |   25 +
>>  drivers/media/video/Makefile                  |    3 +
>>  drivers/media/video/omap4iss/Makefile         |    6 +
>>  drivers/media/video/omap4iss/iss.c            | 1179
>> ++ drivers/media/video/omap4iss/iss.h            |
>> 133 +++
>>  drivers/media/video/omap4iss/iss_csi2.c       | 1324
>> + drivers/media/video/omap4iss/iss_csi2.h       |
>> 166 +++
>>  drivers/media/video/omap4iss/iss_csiphy.c     |  215 
>>  drivers/media/video/omap4iss/iss_csiphy.h     |   69 ++
>>  drivers/media/video/omap4iss/iss_regs.h       |  238 +
>>  drivers/media/video/omap4iss/iss_video.c      | 1192
>> ++ drivers/media/video/omap4iss/iss_video.h      |
>> 205 
>>  drivers/media/video/ov5640.c                  |  972 ++
>>  drivers/media/video/ov5650.c                  |  524 ++
>>  drivers/mfd/twl-core.c                        |    2 +-
>>  include/linux/mfd/twl6040.h                   |    2 +-
>>  include/media/ov5640.h                        |   10 +
>>  include/media/ov5650.h                        |   10 +
>>  include/media/v4l2-chip-ident.h               |    2 +
>>  include/media/v4l2-subdev.h                   |   42 +
>>  29 files changed, 6957 insertions(+), 5 deletions(-)
>>  create mode 100644 Documentation/video4linux/omap4_camera.txt
>>  create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
>>  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
>>  create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h
>>  create mode 100644 drivers/media/video/omap4iss/Makefile
>>  create mode 100644 drivers/media/video/omap4iss/iss.c
>>  create mode 100644 drivers/media/video/omap4iss/iss.h
>>  create mode 100644 drivers/media/video/omap4iss/iss_csi2.c
>>  create mode 100644 drivers/media/video/omap4iss/iss_csi2.h
>>  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c
>>  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h
>>  create mode 100644 drivers/media/video/omap4iss/iss

Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

[Aguirre, Sergio]

Hi Sakari,

On Thu, Dec 1, 2011 at 10:14 AM, Sakari Ailus  wrote:
> Hi Sergio,
>
> Thanks for the patchset!!

And thanks for your attention :)

>
> On Wed, Nov 30, 2011 at 06:14:49PM -0600, Sergio Aguirre wrote:
>> Hi everyone,
>>
>> This is the second version of the OMAP4 ISS driver,
>> now ported to the Media Controller framework AND supporting
>> videobuf2 framework.
>>
>> This patchset should apply cleanly on top of v3.2-rc3 kernel tag.
>>
>> This driver attempts to provide an fully open source solution to
>> control the OMAP4 Imaging SubSystem (a.k.a. ISS).
>>
>> Starts with just CSI2-A interface support, and pretends to be
>> ready for expansion to add support to the many ISS block modules
>> as possible.
>>
>> Please see newly added documentation for more details:
>>
>> Documentation/video4linux/omap4_camera.txt
>
> I propose s/omap4_camera/omap4iss/, according to the path name in the
> drivers/media/video directory.

Makes sense. Will fix.

>
>> Any comments/complaints are welcome. :)
>>
>> Changes since v1:
>> - Simplification of auxclk handling in board files. (Pointed out by: Roger 
>> Quadros)
>> - Cleanup of Camera support enablement for 4430sdp & panda. (Pointed out by: 
>> Roger Quadros)
>> - Use of HWMOD declaration for assisted platform_device creation. (Pointed 
>> out by: Felipe Balbi)
>> - Videobuf2 migration (Removal of custom iss_queue buffer handling driver)
>
> I'm happy to see it's using videobuf2!

Yeah, I'll definitely need it for multi-planar buffer handling for
NV12 buffer capturing.

Resizer can color convert from YUV422->YUV420 NV12 now, and expects 2 pointers
(1 for Y, and 1 for UV 2x2 sampled) to be programmed in HW.

>
> I have no other comments quite yet. :-)

Ok, let me know if you find something eye-popping ugly in there. I'll
be happy to fix it. :)

Thanks and Regards,
Sergio

>
> Cheers,
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi     jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value

[Aguirre, Sergio]

Hi Laurent,

Thanks for the review.

On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart
 wrote:
> Hi Sergio,
>
> On Thursday 01 December 2011 01:14:51 Sergio Aguirre wrote:
>> The define should be the result of 1 << Bit number.
>>
>> Bit number for GPOCTL.GPO3 field is 2, which results
>> in 0x4 value.
>>
>> Signed-off-by: Sergio Aguirre 
>> ---
>>  include/linux/mfd/twl6040.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
>> index 2463c261..2a7ff16 100644
>> --- a/include/linux/mfd/twl6040.h
>> +++ b/include/linux/mfd/twl6040.h
>> @@ -142,7 +142,7 @@
>>
>>  #define TWL6040_GPO1                 0x01
>>  #define TWL6040_GPO2                 0x02
>> -#define TWL6040_GPO3                 0x03
>> +#define TWL6040_GPO3                 0x04
>
> What about defining the fields as (1 << x) instead then ?

I thought about that, but I guess I just wanted to keep it
consistent with the rest of the file.

Maybe I can create a separate patch for changing all these bitwise
flags to use BIT() macros instead.

Thanks and Regards,
Sergio

>
>>
>>  /* ACCCTL (0x2D) fields */
>
> --
> Regards,
>
> Laurent Pinchart
--
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 05/11] OMAP4: Add base addresses for ISS

[Aguirre, Sergio]

Hi Laurent,

Thanks for the review.

On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart
 wrote:
> Hi Sergio,
>
> On Thursday 01 December 2011 01:14:54 Sergio Aguirre wrote:
>> NOTE: This isn't the whole list of features that the
>> ISS supports, but the only ones supported at the moment.
>>
>> Signed-off-by: Sergio Aguirre 
>> ---
>>  arch/arm/mach-omap2/devices.c              |   32
>>  arch/arm/plat-omap/include/plat/omap44xx.h |
>>   9 +++
>>  2 files changed, 41 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>> index c15cfad..b48aeea 100644
>> --- a/arch/arm/mach-omap2/devices.c
>> +++ b/arch/arm/mach-omap2/devices.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>
> I try to keep headers sorted alphabetically when possible, but that might just
> be me.

No problem. I can change it.

>
>>
>>  #include "mux.h"
>>  #include "control.h"
>> @@ -217,6 +218,37 @@ int omap3_init_camera(struct isp_platform_data *pdata)
>>       return platform_device_register(&omap3isp_device);
>>  }
>>
>> +int omap4_init_camera(struct iss_platform_data *pdata, struct
>> omap_board_data *bdata)
>> +{
>> +     struct platform_device *pdev;
>> +     struct omap_hwmod *oh;
>> +     struct iss_platform_data *omap4iss_pdata;
>> +     char *oh_name = "iss";
>> +     char *name = "omap4iss";
>
> Would const char or static const char help the compiler putting the strings to
> a read-only section ?

Right. Will fix.

>
>> +     unsigned int id = -1;
>> +
>> +     oh = omap_hwmod_lookup(oh_name);
>> +     if (!oh) {
>> +             pr_err("Could not look up %s\n", oh_name);
>> +             return -ENODEV;
>> +     }
>> +
>> +     omap4iss_pdata = pdata;
>> +
>> +     pdev = omap_device_build(name, id, oh, omap4iss_pdata,
>> +                     sizeof(struct iss_platform_data), NULL, 0, 0);
>
> This is the only location where id is used, maybe you could pass -1 directly
> to the function ?

Ditto.

Thanks and regards,
Sergio

>
>> +
>> +     if (IS_ERR(pdev)) {
>> +             WARN(1, "Can't build omap_device for %s:%s.\n",
>> +                                             name, oh->name);
>> +             return PTR_ERR(pdev);
>> +     }
>> +
>> +     oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
>> +
>> +     return 0;
>> +}
>> +
>>  static inline void omap_init_camera(void)
>>  {
>>  #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
>> diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
>> b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..31432aa 100644
>> --- a/arch/arm/plat-omap/include/plat/omap44xx.h
>> +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
>> @@ -49,6 +49,15 @@
>>  #define OMAP44XX_MAILBOX_BASE                (L4_44XX_BASE + 0xF4000)
>>  #define OMAP44XX_HSUSB_OTG_BASE              (L4_44XX_BASE + 0xAB000)
>>
>> +#define OMAP44XX_ISS_BASE                    0x5200
>> +#define OMAP44XX_ISS_TOP_BASE                        (OMAP44XX_ISS_BASE + 
>> 0x0)
>> +#define OMAP44XX_ISS_CSI2_A_REGS1_BASE               (OMAP44XX_ISS_BASE + 
>> 0x1000)
>> +#define OMAP44XX_ISS_CAMERARX_CORE1_BASE     (OMAP44XX_ISS_BASE + 0x1170)
>> +
>> +#define OMAP44XX_ISS_TOP_END                 (OMAP44XX_ISS_TOP_BASE + 256 - 
>> 1)
>> +#define OMAP44XX_ISS_CSI2_A_REGS1_END                
>> (OMAP44XX_ISS_CSI2_A_REGS1_BASE +
>> 368 - 1) +#define
>> OMAP44XX_ISS_CAMERARX_CORE1_END               
>> (OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 -
>> 1) +
>>  #define OMAP4_MMU1_BASE                      0x55082000
>>  #define OMAP4_MMU2_BASE                      0x4A066000
>
> --
> Regards,
>
> Laurent Pinchart
--
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 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

[Laurent Pinchart]

Hi Sergio,

On Thursday 01 December 2011 01:14:49 Sergio Aguirre wrote:
> Hi everyone,
> 
> This is the second version of the OMAP4 ISS driver,
> now ported to the Media Controller framework AND supporting
> videobuf2 framework.

Thanks a lot for working on this.

> This patchset should apply cleanly on top of v3.2-rc3 kernel tag.
> 
> This driver attempts to provide an fully open source solution to
> control the OMAP4 Imaging SubSystem (a.k.a. ISS).
> 
> Starts with just CSI2-A interface support, and pretends to be
> ready for expansion to add support to the many ISS block modules
> as possible.
> 
> Please see newly added documentation for more details:
> 
> Documentation/video4linux/omap4_camera.txt
> 
> Any comments/complaints are welcome. :)

I've started reviewing the patches, but it might take some time as I got lots 
on my plate at the moment. I will concentrate on the ISS patch (06/11) first. 
The sensor drivers are needed now for testing purpose, but can get their share 
of love later.

> Changes since v1:
> - Simplification of auxclk handling in board files. (Pointed out by: Roger
> Quadros) - Cleanup of Camera support enablement for 4430sdp & panda.
> (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted
> platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2
> migration (Removal of custom iss_queue buffer handling driver) - Proper
> GPO3 handling for CAM_SEL in 4430sdp.
> 
> Sergio Aguirre (10):
>   TWL6030: Add mapping for auxiliary regs
>   mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
>   OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
>   OMAP4: Add base addresses for ISS
>   v4l: Add support for omap4iss driver
>   v4l: Add support for ov5640 sensor
>   v4l: Add support for ov5650 sensor
>   arm: omap4430sdp: Add support for omap4iss camera
>   arm: omap4panda: Add support for omap4iss camera
>   arm: Add support for CMA for omap4iss driver
> 
> Stanimir Varbanov (1):
>   v4l: Introduce sensor operation for getting interface configuration
> 
>  Documentation/video4linux/omap4_camera.txt|   60 ++
>  arch/arm/mach-omap2/Kconfig   |   54 +
>  arch/arm/mach-omap2/Makefile  |3 +
>  arch/arm/mach-omap2/board-4430sdp-camera.c|  221 
>  arch/arm/mach-omap2/board-omap4panda-camera.c |  198 
>  arch/arm/mach-omap2/devices.c |   40 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c|   16 +-
>  arch/arm/plat-omap/include/plat/omap4-iss.h   |   42 +
>  arch/arm/plat-omap/include/plat/omap44xx.h|9 +
>  drivers/media/video/Kconfig   |   25 +
>  drivers/media/video/Makefile  |3 +
>  drivers/media/video/omap4iss/Makefile |6 +
>  drivers/media/video/omap4iss/iss.c| 1179
> ++ drivers/media/video/omap4iss/iss.h| 
> 133 +++
>  drivers/media/video/omap4iss/iss_csi2.c   | 1324
> + drivers/media/video/omap4iss/iss_csi2.h   | 
> 166 +++
>  drivers/media/video/omap4iss/iss_csiphy.c |  215 
>  drivers/media/video/omap4iss/iss_csiphy.h |   69 ++
>  drivers/media/video/omap4iss/iss_regs.h   |  238 +
>  drivers/media/video/omap4iss/iss_video.c  | 1192
> ++ drivers/media/video/omap4iss/iss_video.h  | 
> 205 
>  drivers/media/video/ov5640.c  |  972 ++
>  drivers/media/video/ov5650.c  |  524 ++
>  drivers/mfd/twl-core.c|2 +-
>  include/linux/mfd/twl6040.h   |2 +-
>  include/media/ov5640.h|   10 +
>  include/media/ov5650.h|   10 +
>  include/media/v4l2-chip-ident.h   |2 +
>  include/media/v4l2-subdev.h   |   42 +
>  29 files changed, 6957 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/video4linux/omap4_camera.txt
>  create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
>  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
>  create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h
>  create mode 100644 drivers/media/video/omap4iss/Makefile
>  create mode 100644 drivers/media/video/omap4iss/iss.c
>  create mode 100644 drivers/media/video/omap4iss/iss.h
>  create mode 100644 drivers/media/video/omap4iss/iss_csi2.c
>  create mode 100644 drivers/media/video/omap4iss/iss_csi2.h
>  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c
>  create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h
>  create mode 100644 drivers/media/video/omap4iss/iss_regs.h
>  create mode 100644 drivers/media/video/omap4iss/iss_video.c
>  create mode 100644 drivers/media/video/omap4iss/iss_video.h
>  create mode 100644 drivers/media/video/ov5640.c
>  create mode 100644 drivers/media/video/ov5650.c
>  create mode 100644 include/media/ov5640.h
>  create mode 100644 include/media/ov5650.h

-- 
Regards,

Laurent Pinchar

Re: [PATCH v2 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value

[Laurent Pinchart]

Hi Sergio,

On Thursday 01 December 2011 01:14:51 Sergio Aguirre wrote:
> The define should be the result of 1 << Bit number.
> 
> Bit number for GPOCTL.GPO3 field is 2, which results
> in 0x4 value.
> 
> Signed-off-by: Sergio Aguirre 
> ---
>  include/linux/mfd/twl6040.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
> index 2463c261..2a7ff16 100644
> --- a/include/linux/mfd/twl6040.h
> +++ b/include/linux/mfd/twl6040.h
> @@ -142,7 +142,7 @@
> 
>  #define TWL6040_GPO1 0x01
>  #define TWL6040_GPO2 0x02
> -#define TWL6040_GPO3 0x03
> +#define TWL6040_GPO3 0x04

What about defining the fields as (1 << x) instead then ?

> 
>  /* ACCCTL (0x2D) fields */

-- 
Regards,

Laurent Pinchart
--
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 05/11] OMAP4: Add base addresses for ISS

[Laurent Pinchart]

Hi Sergio,

On Thursday 01 December 2011 01:14:54 Sergio Aguirre wrote:
> NOTE: This isn't the whole list of features that the
> ISS supports, but the only ones supported at the moment.
> 
> Signed-off-by: Sergio Aguirre 
> ---
>  arch/arm/mach-omap2/devices.c  |   32
>  arch/arm/plat-omap/include/plat/omap44xx.h | 
>   9 +++
>  2 files changed, 41 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c15cfad..b48aeea 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

I try to keep headers sorted alphabetically when possible, but that might just 
be me.

> 
>  #include "mux.h"
>  #include "control.h"
> @@ -217,6 +218,37 @@ int omap3_init_camera(struct isp_platform_data *pdata)
>   return platform_device_register(&omap3isp_device);
>  }
> 
> +int omap4_init_camera(struct iss_platform_data *pdata, struct
> omap_board_data *bdata)
> +{
> + struct platform_device *pdev;
> + struct omap_hwmod *oh;
> + struct iss_platform_data *omap4iss_pdata;
> + char *oh_name = "iss";
> + char *name = "omap4iss";

Would const char or static const char help the compiler putting the strings to 
a read-only section ?

> + unsigned int id = -1;
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + return -ENODEV;
> + }
> +
> + omap4iss_pdata = pdata;
> +
> + pdev = omap_device_build(name, id, oh, omap4iss_pdata,
> + sizeof(struct iss_platform_data), NULL, 0, 0);

This is the only location where id is used, maybe you could pass -1 directly 
to the function ?

> +
> + if (IS_ERR(pdev)) {
> + WARN(1, "Can't build omap_device for %s:%s.\n",
> + name, oh->name);
> + return PTR_ERR(pdev);
> + }
> +
> + oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
> +
> + return 0;
> +}
> +
>  static inline void omap_init_camera(void)
>  {
>  #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
> b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..31432aa 100644
> --- a/arch/arm/plat-omap/include/plat/omap44xx.h
> +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
> @@ -49,6 +49,15 @@
>  #define OMAP44XX_MAILBOX_BASE(L4_44XX_BASE + 0xF4000)
>  #define OMAP44XX_HSUSB_OTG_BASE  (L4_44XX_BASE + 0xAB000)
> 
> +#define OMAP44XX_ISS_BASE0x5200
> +#define OMAP44XX_ISS_TOP_BASE(OMAP44XX_ISS_BASE + 
> 0x0)
> +#define OMAP44XX_ISS_CSI2_A_REGS1_BASE   (OMAP44XX_ISS_BASE + 
> 0x1000)
> +#define OMAP44XX_ISS_CAMERARX_CORE1_BASE (OMAP44XX_ISS_BASE + 0x1170)
> +
> +#define OMAP44XX_ISS_TOP_END (OMAP44XX_ISS_TOP_BASE + 256 - 
> 1)
> +#define OMAP44XX_ISS_CSI2_A_REGS1_END
> (OMAP44XX_ISS_CSI2_A_REGS1_BASE +
> 368 - 1) +#define
> OMAP44XX_ISS_CAMERARX_CORE1_END   
> (OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 -
> 1) +
>  #define OMAP4_MMU1_BASE  0x55082000
>  #define OMAP4_MMU2_BASE  0x4A066000

-- 
Regards,

Laurent Pinchart
--
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 2a/5] Remove unsafe clock values from omap1_defconfig

[Tony Lindgren]

* Janusz Krzysztofik  [111201 01:20]:
> 
> If you still ask me for my opinion: with patch 3/5 omitted, then not 
> being able to run at any other frequency than 60 MHz instead of usual 
> 150 since the board support was introduced first, isn't this a 
> regression?

Yes, assuming that the behaviour for your board has changed by something
after v3.1, such as commit e9b7086b80c4d9e354f4edc9e280ae85a60df408.

> Having a choice of upgrading to 3.2 and running my 
> application on not very powerfull board at 60 MHz, or keep running 3.1 
> at 150, guess what I chose? If I were a distro kernel package 
> maintainer, guess what I would chose?

Right, that's certainly not intentional :)

> > It seems that we've had the issue of not actually changing the rate
> > for a while, right?
> 
> This was not an issue before dpll1 reprogramming has been moved out from 
> omap1_clk_init(), as an rc fix to another bug introduced in 3.2. Perhaps 
> we should rather think of reverting a few commits which caused all these 
> problems if fixing them all during rc cycle seems not possible? I 
> haven't bisected them yet, rather concentrated on providing fixes, but I 
> can still try to do it, starting back from the original issue 
> (http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.

We can't revert that because the SRAM init has been moved to later for
map_io. But if that patch changed the behaviour on your board, then that's
the problem we should fix.

If you're now stuck at 60MHz rate, care to see if the following patch
makes the kernel behave the same way as before for you? Sorry for dragging
this on, but I'd like to find out what exactly changed the behaviour for
your board.
 
> Anyway, did you mean resending those 2/5 and 5/5 without any changes, 
> only renumbered as 1/2 and 2/2?

Well the numbers will not show up in git, so no changes needed there :)

But let's figure out first what changed the behaviour for your board.

Regards,

Tony

--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -927,7 +927,7 @@ int __init omap1_clk_init(void)
 
 void __init omap1_clk_late_init(void)
 {
-   if (ck_dpll1.rate >= OMAP1_DPLL1_SANE_VALUE)
+   if (ck_dpll1.rate > OMAP1_DPLL1_SANE_VALUE)
return;
 
/* Find the highest supported frequency and enable it */
--
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: Setting OMAP DSS fck

[Turquette, Mike]

On Thu, Dec 1, 2011 at 12:58 AM, Cousson, Benoit  wrote:
> On 12/1/2011 9:16 AM, Tomi Valkeinen wrote:
>>  From driver's perspective I think this only makes things more complex,
>> as the driver is not interested in the parent, only about the dss fck.
>
> Fully agree. It should transparent for the driver.

The new common clk patches do try to take care of this.  A child clk
may be marked with CLK_PARENT_RATE_CHANGE flag which tells
clk_set_rate to (potentially) propagate up to the parent and change
it's rate.

This won't help you currently Tomi, but you can take comfort knowing
that someday your driver won't have to know details about dss_fck's
parent ;-)

Regards,
Mike
--
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 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support

[Sakari Ailus]

Hi Sergio,

Thanks for the patchset!!

On Wed, Nov 30, 2011 at 06:14:49PM -0600, Sergio Aguirre wrote:
> Hi everyone,
> 
> This is the second version of the OMAP4 ISS driver,
> now ported to the Media Controller framework AND supporting
> videobuf2 framework.
> 
> This patchset should apply cleanly on top of v3.2-rc3 kernel tag.
> 
> This driver attempts to provide an fully open source solution to
> control the OMAP4 Imaging SubSystem (a.k.a. ISS).
> 
> Starts with just CSI2-A interface support, and pretends to be
> ready for expansion to add support to the many ISS block modules
> as possible.
> 
> Please see newly added documentation for more details:
> 
> Documentation/video4linux/omap4_camera.txt

I propose s/omap4_camera/omap4iss/, according to the path name in the
drivers/media/video directory.

> Any comments/complaints are welcome. :)
> 
> Changes since v1:
> - Simplification of auxclk handling in board files. (Pointed out by: Roger 
> Quadros)
> - Cleanup of Camera support enablement for 4430sdp & panda. (Pointed out by: 
> Roger Quadros)
> - Use of HWMOD declaration for assisted platform_device creation. (Pointed 
> out by: Felipe Balbi)
> - Videobuf2 migration (Removal of custom iss_queue buffer handling driver)

I'm happy to see it's using videobuf2!

I have no other comments quite yet. :-)

Cheers,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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 01/11] TWL6030: Add mapping for auxiliary regs

[T Krishnamoorthy, Balaji]

On Thu, Dec 1, 2011 at 5:44 AM, Sergio Aguirre  wrote:
> Signed-off-by: Sergio Aguirre 
> ---
>  drivers/mfd/twl-core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index bfbd660..e26b564 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
>        { SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
>        { SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
>
> -       { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
> +       { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },

Instead you can use TWL6030_MODULE_ID1, with base address as
zero for all registers in auxiliaries register map.

>        { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
>        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
>        { SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
> --
> 1.7.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 03/11] arm:omap:am33xx: Add power domain data

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

>> -Original Message-
>> From: Hilman, Kevin
>> Sent: Thursday, December 01, 2011 6:34 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
>> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal; Patil,
>> Rachna
>> Subject: Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
>> 
>> Vaibhav Hiremath  writes:
>> 
>> > From: Afzal Mohammed 
>> >
>> > This patch adds AM33XX power domain data,
>> > corresponding API's to access PRM module and
>> > PRM register offsets & bit fields.
>> >
>> > Signed-off-by: Rachna Patil 
>> > Signed-off-by: Vaibhav Hiremath 
>> > Signed-off-by: Afzal Mohammed 
>> 
>> First some general comments:
>> 
>> At first glance, it seems like there could be much more reuse with OMAP4
>> code here.  From what I see, AM33x has only one partition compared to
>> several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4
>> functions and just use a single partition.
> Kevin,
>
> Indeed it looks close to OMAP4, but it becomes difficult and ugly once you
> Start getting into implementation details, for example,
>
>  - All PRM offsets don't match, you will end up with
> cpu_is_xxx check and handle this. Applicable to all power domains.
>
>   OMAP4430_PRM_MPU_INST   0x0300
>   Vs
>   AM33XX_PRM_MPU_MOD  0x0E00
>
>   OMAP4430_PRM_WKUP_INST  0x1700
>   Vs
>   AM33XX_PRM_WKUP_MOD 0x0D00
>
>  - Also there are some differences in logic states of domains as well.
>
> Another important point is, we have considered AM33xx as OMAP3 family
> of device (ARCH_OMAP3).  So you may end up with number of cpu_is_xxx
> checks in code.

If we end up with cpu_is_* checks in the code, we're doing it wrong.

I understand there are lots of differences with OMAP4, but from what I'm
looking at (at least for the power domains in this patch) there most of
those differences are handled in the data files, and the code could be
shared.

For example, looking at powerdomain33xx.c, this looks exactly like the
OMAP4 version except

- you have 2 new AM33XX_PRM_* defines (which are the same as OMAP4 version)
- you have a new register access functions: am33xx_prminst_read_inst_reg()...

So, my question is: if you could update the OMAP4 code to be able to
override the register access read/write functions, would you even need a
new powerdomain33xx.c?

Your am33xx_ version doesn't take a partition argument, but that would
be easy to remedy, and the AM33x powerdomains could be updated to all
declare a default partition.

Anyways, I'll let Benoit/Paul/Rajendra take it from here, as they're the
ones who know this code the best.

Kevin
--
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 00/11] arm:omap:am33xx: Add basic voltage, power, clock & HWMOD data

[Kevin Hilman]

On 12/01/2011 06:58 AM, Kevin Hilman wrote:
> Can you create a branch for base am33x support against a recent mainline
> (like v3.2-rc3) for easier review/testing of just the AM33x support?

Nevermind, I now see your am335x-staging branch in the Arago tree you
mentioned.

Thanks,

Kevin

--
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 0/3] Introducing TI's New SoC/board AM335XEVM

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

>> -Original Message-
>> From: Hilman, Kevin
>> Sent: Thursday, December 01, 2011 5:09 AM
>> To: Hiremath, Vaibhav; Russell King
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
>> ker...@lists.infradead.org; p...@pwsan.com
>> Subject: Re: [PATCH-V4 0/3] Introducing TI's New SoC/board AM335XEVM
>> 
>> Vaibhav Hiremath  writes:
>> 
>> > This patch set adds support for AM335x device having
>> > Cortex-A8 MPU.
>> >
>> > Official website - http://www.ti.com/product/am3359
>> >
>> > AM335X is treated as another OMAP3 variant, where,
>> > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
>> > and the respective type is AM335X, which is newly added device in
>> > the family.
>> > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
>> > cpu_is_am335x() checks return success for AM335X.
>> >
>> > Also, I have validated OMAP3 boot test with this patch-series on
>> OMAP3EVM.
>> 
>> After fixing the minor comment on patch 3/3, feel free to add:
>> 
>> Reviewed-by: Kevin Hilman 
>> 
> Thanks Kevin, for the review.
>
>
>> Also, I was surprised to discover that this booted on my (recently
>> arrived) BeagleBone.  It seems that u-boot (from Angstrom) is passing
>> the machine ID of the AM335x EVM[1], even though there is another
>> machine ID for the BeagleBone[2].  Is that expected?
>
> We can detect the board using on-board EEPROM, so same mach-id
> should work for both EVM and Beagle. 

> And also going forward with device tree approach we may
> not need different id's, right?

Right, which is why I'm wondering why are there sevral new AM33x
mach-types when only one of them is being used:

3684TI AM335X IA EVMam335xiaevm Afzal Mohammed
3589TI AM335X EVM   am335xevm   Vaibhav Bedia
3808Beaglebone Boardbeaglebone  Steven Kipisz

Russell has been trying to cleanup athe mach-types, so if these others
are not going to be used, I suggest they be deleted.

> But I am surprised to see that beaglebone is booting fine for you,
> did you get Linux console?

Oh, sorry for the confusion.  No, it didn't boot to console.  It just
booted far enought to see that your this series was working and it was
getting started, but it eventually hangs because of missing MPU hwmod:

[...]
[0.00] omap_hwmod: timer1: cannot setup_one: MPU initiator hwmod mpu 
not yet registered  
 
[0.00] [ cut here ]   
[0.00] kernel BUG at /work/kernel/omap/dev/arch/arm/mach-omap2/timer.c: 
214!

Kevin
--
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/3] arm:omap:am33xx: Add low level debugging support

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

>> Vaibhav Hiremath  writes:
>> 
>> > From: Afzal Mohammed 
>> >
>> > Add support for low level debugging on AM335X EVM (AM33XX family).
>> > Currently only support for UART1 console, which is used on AM335X EVM
>> > is added.
>> >
>> > Signed-off-by: Afzal Mohammed 
>> > Signed-off-by: Vaibhav Hiremath 
>> 
>> One minor comment below...
>> 
>> > ---
>> >  arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
>> >  arch/arm/plat-omap/include/plat/serial.h   |4 
>> >  arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
>> >  3 files changed, 26 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
>> b/arch/arm/mach-omap2/include/mach/debug-macro.S
>> > index 13f98e5..ce543ae 100644
>> > --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
>> > +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
>> > @@ -72,6 +72,8 @@ omap_uart_lsr:   .word   0
>> >beq 82f @ configure UART2
>> >cmp \rp, #TI816XUART3   @ ti816x UART offsets different
>> >beq 83f @ configure UART3
>> > +  cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
>> > +  beq 84f @ configure UART1
>> >cmp \rp, #ZOOM_UART @ only on zoom2/3
>> >beq 95f @ configure ZOOM_UART
>> >
>> > @@ -100,7 +102,9 @@ omap_uart_lsr: .word   0
>> >b   98f
>> >  83:   mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
>> >b   98f
>> > -
>> > +84:   ldr \rp, =AM33XX_UART1_BASE
>> > +  and \rp, \rp, #0x00ff
>> > +  b   97f
>> >  95:   ldr \rp, =ZOOM_UART_BASE
>> >str \rp, [\tmp, #0] @ omap_uart_phys
>> >ldr \rp, =ZOOM_UART_VIRT
>> > @@ -110,6 +114,17 @@ omap_uart_lsr:.word   0
>> >b   10b
>> >
>> >/* Store both phys and virt address for the uart */
>> 
>> Please update this comment to clarify that this block is for AM33xx
>> only, and update the following one as the catch all.
>> 
> Ok, will update.
>
>> > +97:   add \rp, \rp, #0x4400   @ phys base
>> > +  str \rp, [\tmp, #0] @ omap_uart_phys
>> > +  sub \rp, \rp, #0x4400   @ phys base
>> > +  add \rp, \rp, #0xf900   @ virt base
>> > +  str \rp, [\tmp, #4] @ omap_uart_virt
>> > +  mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
>> > +  str \rp, [\tmp, #8] @ omap_uart_lsr
>> 
>> The last 3 lines are unnecessarily duplicated.  They can be shared with
>> the common block that follows.  IOW, only the base addresses are
>> different, the rest of the operations are shared.
>> 
> I thought about this, but then code looks complex & ugly, just to save
> duplication of 3 lines. So I added separate code for AM33xx devices.

Yeah, you're right.

Your original version is better.   Please just update the comments
around the 2 blocks then.

Thanks,

Kevin
--
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 00/11] arm:omap:am33xx: Add basic voltage, power, clock & HWMOD data

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

>> -Original Message-
>> From: Hilman, Kevin
>> Sent: Thursday, December 01, 2011 7:12 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
>> arm-ker...@lists.infradead.org; Cousson, Benoit
>> Subject: Re: [RFC PATCH 00/11] arm:omap:am33xx: Add basic voltage, power,
>> clock & HWMOD data
>> 
>> Vaibhav Hiremath  writes:
>> 
>> > This patch series adds support for AM335X basic voltage, power,
>> > clock and HWMOD data to existing OMAP framework.
>> 
>> This series is missing patch 05/11.
>> 
> Ohhh...not sure what went bad.
>
> You can access it from, 
> http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=commit;h=c2754eb60b65c6c574f2d6d871d8846358e40414
>
>
> I had published the whole series @ Arago.
>

OK, but using Arago, I will also get a bunch of other out of tree code.

Can you create a branch for base am33x support against a recent mainline
(like v3.2-rc3) for easier review/testing of just the AM33x support?

Kevin
--
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 01/11] arm:omap:am33xx: Add voltage domain data

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

>> -Original Message-
>> From: Hilman, Kevin
>> Sent: Thursday, December 01, 2011 5:41 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
>> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal
>> Subject: Re: [RFC PATCH 01/11] arm:omap:am33xx: Add voltage domain data
>> 
>> Vaibhav Hiremath  writes:
>> 
>> > From: Afzal Mohammed 
>> >
>> > Currently dummy voltage domain data is being created
>> > in order to succeed boot process.
>> > Nothing has been done w.r.t actual hardware (voltage control).
>> >
>> > Signed-off-by: Afzal Mohammed 
>> > Signed-off-by: Vaibhav Hiremath 
>> 
>> [...]
>> 
>> > --- /dev/null
>> > +++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c
>> > @@ -0,0 +1,37 @@
>> > +/*
>> > + * AM33XX voltage domain data
>> > + *
>> > + * Copyright (C) 2011 Texas Instruments, Inc.
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + */
>> > +#include 
>> > +#include 
>> > +
>> > +#include "voltage.h"
>> > +
>> > +static struct voltagedomain am33xx_voltdm_mpu = {
>> > +  .name = "mpu",
>> > +};
>> 
>> According to the TRM, there is no MPU voltage domain.  Only CORE and RTC
>> exist.
>> 
>> However, looking at the data manual (SPRS717 Oct 2011), it seems that
>> some packages have a separate VDD_MPU while others have a combined
>> VDD_MPU and VDD_CORE.
>> 
>> This should be clarified and documented in the changelog.
>> 
>
>
> No, we do have VDD_MPU specifically documented in TRM (SPRUH73 - October2011).
>
> The TRM is accessible at - http://www.ti.com/lit/ug/spruh73/spruh73.pdf

That link doesn't work for me, I think you meant

 http://www.ti.com/lit/ug/spruh73a/spruh73a.pdf

which is the document I'm reading.  Specifically it says:

8.1.1.10 Voltage and Power Domains

The following table shows how the device core logic is partitioned into
two core logic voltage domains and four power domains. The table lists
which voltage and power domain a functional module belongs.

Table 8-25. Core Logic Voltage and Power Domains
  Logic Voltage Domain Name|  Module
  -
  CORE |  All Core Modules
  RTC  |  RTC

8.1.1.10.1 Voltage Domains

The core logic is divided into two voltage domains: VDD_CORE and
VDD_RTC.



However, in reading other parts of the TRM, it clearly references
VDD_MPU and the data manual also references a separate VDD_MPU.

My point in this comment was that since the TRM is rather unclear on
this, the changelog should be more verbose, and take care to clear up
any thing that's wrong or unclear in the TRM.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Mark Brown]

On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:

> Clock rate/parent-change notifiers are requirements for DVFS use-cases, 
> and they must be paired with something like the 
> clk_{allow,block}_rate_change() functions to work efficiently.  I intend 
> to comment on this later; it's not a simple problem.  It might be worth 
> noting that Tero and I implemented a simplified version of this for the 
> N900.

I'm thinking that if we're going to have clk_{allow,block}_rate_change()
we may as well make that the main interface to enable rate changes - if
a device wants to change the clock rate it allows rate changes using
that interface rather than by disabling the clocks.  I've got devices
which can do glitch free updates of active clocks so having to disable
would be a real restriction, and cpufreq would have issues with actually
disabling the clock too I expect.
--
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 10/11] arm: omap4panda: Add support for omap4iss camera

[Aguirre, Sergio]

Hi Vaibhav,

Thanks for the comments.

On Thu, Dec 1, 2011 at 12:24 AM, Hiremath, Vaibhav  wrote:
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
>> Sent: Thursday, December 01, 2011 5:45 AM
>> To: linux-me...@vger.kernel.org
>> Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
>> sakari.ai...@iki.fi; Aguirre, Sergio
>> Subject: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera
>>
>> This adds support for camera interface with the support for
>> following sensors:
>>
>> - OV5640
>> - OV5650
>>
>> Signed-off-by: Sergio Aguirre 
>> ---
>>  arch/arm/mach-omap2/Kconfig                   |   27 
>>  arch/arm/mach-omap2/Makefile                  |    1 +
>>  arch/arm/mach-omap2/board-omap4panda-camera.c |  198
>> +
>>  3 files changed, 226 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
>>
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index f883abb..0fc5ce9 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -358,6 +358,33 @@ config MACH_OMAP4_PANDA
>>       select OMAP_PACKAGE_CBS
>>       select REGULATOR_FIXED_VOLTAGE
>>
>> +config MACH_OMAP4_PANDA_CAMERA_SUPPORT
>> +     bool "OMAP4 Panda Board Camera support"
>> +     depends on MACH_OMAP4_PANDA
>> +     select MEDIA_SUPPORT
>> +     select MEDIA_CONTROLLER
>> +     select VIDEO_DEV
>> +     select VIDEO_V4L2_SUBDEV_API
>> +     select VIDEO_OMAP4
>> +     help
>> +       Enable Camera HW support for PandaBoard.
>> +       This is for using the OMAP4 ISS CSI2A Camera sensor
>> +       interface.
>> +
>> +choice
>> +     prompt "Camera sensor to use"
>> +     depends on MACH_OMAP4_PANDA_CAMERA_SUPPORT
>> +     default MACH_OMAP4_PANDA_CAM_OV5650
>> +
>> +     config MACH_OMAP4_PANDA_CAM_OV5640
>> +             bool "Use OmniVision OV5640 Camera"
>> +             select VIDEO_OV5640
>> +
>> +     config MACH_OMAP4_PANDA_CAM_OV5650
>> +             bool "Use OmniVision OV5650 Camera"
>> +             select VIDEO_OV5650
>> +endchoice
>> +
>>  config OMAP3_EMU
>>       bool "OMAP3 debugging peripherals"
>>       depends on ARCH_OMAP3
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index 8bc446a..e80724d 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_TI8168EVM)              += board-
>> ti8168evm.o
>>  # Platform specific device init code
>>
>>  obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT)       += 
>> board-4430sdp-camera.o
>> +obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT)        += board-omap4panda-
>> camera.o
>>
> Can't this be merged into single file? Do we really need separate file for 
> every board here?
>
> I am sure you would have thought about this.

:)

Well, not really, to be honest.

I could have a single file, but wouldn't that make it more complex?

I mean, every board has it's own HW connection specs, like sensor MCLK source,
and different power up sequences. How would you probe for all, without messing
with an invalid GPIO on that board?

Have you resolved a similar case for other OMAP/Davinci boards?

>
>>  omap-flash-$(CONFIG_MTD_NAND_OMAP2)  := board-flash.o
>>  omap-flash-$(CONFIG_MTD_ONENAND_OMAP2)       := board-flash.o
>> diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
>> b/arch/arm/mach-omap2/board-omap4panda-camera.c
>> new file mode 100644
>> index 000..02ef36e
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
>> @@ -0,0 +1,198 @@
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#include "devices.h"
>> +#include "../../../drivers/media/video/omap4iss/iss.h"
>> +
> I believe this is not good practice to include files directly from drivers 
> folder. You should divide the header file such that, driver specific 
> information stays in driver/... and platform specific goes into include/...

Right. Will fix.

>
>> +#include "control.h"
>> +#include "mux.h"
>> +
>> +#define PANDA_GPIO_CAM_PWRDN         45
>> +#define PANDA_GPIO_CAM_RESET         83
>> +
>> +static struct clk *panda_cam_aux_clk;
>> +
>> +static int panda_ov5640_power(struct v4l2_subdev *subdev, int on)
>> +{
>> +     struct iss_device *iss = v4l2_dev_to_iss_device(subdev->v4l2_dev);
>> +     int ret = 0;
> You are not using this variable at all, you can get rid of this.

Right. Will fix.

>
>> +     struct iss_csiphy_dphy_cfg dphy;
>> +     struct iss_csiphy_lanes_cfg lanes;
>> +     unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this
>> */
>> +
>> +     memset(&lanes, 0, sizeof(lanes));
>> +     memset(&dphy, 0, sizeof(dphy));
>> +
>> +     lanes.clk.pos = 1;
>> +     lanes.clk.pol = 0;
>> +     lanes.data[0].pos = 2;
>> +     lanes.data[0].pol = 0;
>> +  

Re: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections

[Aguirre, Sergio]

Hi Vaibhav,

Thanks for the comments.

On Thu, Dec 1, 2011 at 12:34 AM, Hiremath, Vaibhav  wrote:
>
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
>> Sent: Thursday, December 01, 2011 5:45 AM
>> To: linux-me...@vger.kernel.org
>> Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
>> sakari.ai...@iki.fi; Aguirre, Sergio
>> Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
>> sections
>>
>> Signed-off-by: Sergio Aguirre 
>> ---
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   16 +---
>>  1 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
>> omap2/omap_hwmod_44xx_data.c
>> index 7695e5d..1b59e2f 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> @@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
>> *omap44xx_iss_masters[] = {
>>
>>  static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
>>       {
>> -             .pa_start       = 0x5200,
>> -             .pa_end         = 0x52ff,
>> +             .pa_start       = OMAP44XX_ISS_TOP_BASE,
>> +             .pa_end         = OMAP44XX_ISS_TOP_END,
>> +             .flags          = ADDR_TYPE_RT
>> +     },
>> +     {
>> +             .pa_start       = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
>> +             .pa_end         = OMAP44XX_ISS_CSI2_A_REGS1_END,
>> +             .flags          = ADDR_TYPE_RT
>> +     },
>> +     {
>> +             .pa_start       = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
>> +             .pa_end         = OMAP44XX_ISS_CAMERARX_CORE1_END,
>>               .flags          = ADDR_TYPE_RT
>>       },
> This patch will result in build failure, because, the above base addresses
> are getting defined in the next patch
>
> [PATCH v2 05/11] OMAP4: Add base addresses for ISS

Agreed. Will revisit "git-bisectability" of the patch series. Will fix.

Regards,
Sergio

>
> Thanks,
> Vaibhav
>
>>       { }
>> @@ -5350,7 +5360,7 @@ static __initdata struct omap_hwmod
>> *omap44xx_hwmods[] = {
>>       &omap44xx_ipu_c1_hwmod,
>>
>>       /* iss class */
>> -/*   &omap44xx_iss_hwmod, */
>> +     &omap44xx_iss_hwmod,
>>
>>       /* iva class */
>>       &omap44xx_iva_hwmod,
>> --
>> 1.7.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" 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: [RFC PATCH 00/11] arm:omap:am33xx: Add basic voltage, power, clock & HWMOD data

[Cousson, Benoit]

On 12/1/2011 1:02 PM, Hiremath, Vaibhav wrote:

-Original Message-
From: Hilman, Kevin
Sent: Thursday, December 01, 2011 7:12 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
arm-ker...@lists.infradead.org; Cousson, Benoit
Subject: Re: [RFC PATCH 00/11] arm:omap:am33xx: Add basic voltage, power,
clock&  HWMOD data

Vaibhav Hiremath  writes:


This patch series adds support for AM335X basic voltage, power,
clock and HWMOD data to existing OMAP framework.


This series is missing patch 05/11.


Ohhh...not sure what went bad.


This is probably due to the size of the patch. It cannot be > 100k to 
reach the mailing list.


Regards,
Benoit
--
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 07/11] arm:omap:am33xx: Add irq, dma and module base addr to SoC header files

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 7:16 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal
> Subject: Re: [RFC PATCH 07/11] arm:omap:am33xx: Add irq, dma and module
> base addr to SoC header files
> 
> Vaibhav Hiremath  writes:
> 
> > This patch creats seperate irq and dma defination header file
> > and updates the module base addresses required for HWMOD data.
> >
> > Signed-off-by: Afzal Mohammed 
> > Signed-off-by: Vaibhav Hiremath 
> 
> These headers/defines should no longer be needed.  Instead, as with
> OMAP4, the raw values are used in the hwmod data (and we'll be moving
> device tree for these values.)
> 
Ok, will clean this up in next version.

Thanks,
Vaibhav

> Kevin
--
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 00/11] arm:omap:am33xx: Add basic voltage, power, clock & HWMOD data

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 7:12 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit
> Subject: Re: [RFC PATCH 00/11] arm:omap:am33xx: Add basic voltage, power,
> clock & HWMOD data
> 
> Vaibhav Hiremath  writes:
> 
> > This patch series adds support for AM335X basic voltage, power,
> > clock and HWMOD data to existing OMAP framework.
> 
> This series is missing patch 05/11.
> 
Ohhh...not sure what went bad.

You can access it from, 
http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=commit;h=c2754eb60b65c6c574f2d6d871d8846358e40414


I had published the whole series @ Arago.

Thanks,
Vaibhav

> Kevin
--
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 03/11] arm:omap:am33xx: Add power domain data

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 6:34 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal; Patil,
> Rachna
> Subject: Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
> 
> Vaibhav Hiremath  writes:
> 
> > From: Afzal Mohammed 
> >
> > This patch adds AM33XX power domain data,
> > corresponding API's to access PRM module and
> > PRM register offsets & bit fields.
> >
> > Signed-off-by: Rachna Patil 
> > Signed-off-by: Vaibhav Hiremath 
> > Signed-off-by: Afzal Mohammed 
> 
> First some general comments:
> 
> At first glance, it seems like there could be much more reuse with OMAP4
> code here.  From what I see, AM33x has only one partition compared to
> several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4
> functions and just use a single partition.
Kevin,

Indeed it looks close to OMAP4, but it becomes difficult and ugly once you
Start getting into implementation details, for example,

 - All PRM offsets don't match, you will end up with
cpu_is_xxx check and handle this. Applicable to all power domains.

OMAP4430_PRM_MPU_INST   0x0300
Vs
AM33XX_PRM_MPU_MOD  0x0E00

OMAP4430_PRM_WKUP_INST  0x1700
Vs
AM33XX_PRM_WKUP_MOD 0x0D00

 - Also there are some differences in logic states of domains as well.

Another important point is, we have considered AM33xx as OMAP3
family of device (ARCH_OMAP3).
So you may end up with number of cpu_is_xxx checks in code.

> 
> IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4.
>
> From what I read (after an admittedly quick glance), the main thing you
> need is a way to override the PRM offsets due to the fact that some
> crazy person decided to make each instance different.
> 
This was one of the major reason why I had chosen and implemented separately
for AM33xx. 


> If you modified the OMAP4 base so that the _prminst_read_inst_reg()
> could be customized, wouldn't that work for AM33xx?
> 
> > ---
> >  arch/arm/mach-omap2/powerdomain.h   |4 +-
> >  arch/arm/mach-omap2/powerdomain33xx.c   |  155 
> >  arch/arm/mach-omap2/powerdomains33xx_data.c |  115 +
> >  arch/arm/mach-omap2/prm-regbits-33xx.h  |  357
> +++
> >  arch/arm/mach-omap2/prm33xx.h   |  123 +
> >  arch/arm/mach-omap2/prminst33xx.c   |   74 ++
> >  arch/arm/mach-omap2/prminst33xx.h   |   25 ++
> >  7 files changed, 852 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
> >  create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
> >  create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
> >  create mode 100644 arch/arm/mach-omap2/prm33xx.h
> >  create mode 100644 arch/arm/mach-omap2/prminst33xx.c
> >  create mode 100644 arch/arm/mach-omap2/prminst33xx.h
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-
> omap2/powerdomain.h
> > index 0d72a8a..9efa823 100644
> > --- a/arch/arm/mach-omap2/powerdomain.h
> > +++ b/arch/arm/mach-omap2/powerdomain.h
> > @@ -69,7 +69,7 @@
> >   * Maximum number of clockdomains that can be associated with a
> powerdomain.
> >   * CORE powerdomain on OMAP4 is the worst case
> >   */
> > -#define PWRDM_MAX_CLKDMS   9
> > +#define PWRDM_MAX_CLKDMS   11
> 
> Comment before this needs update  as well.
> 
Ok.

> >  /* XXX A completely arbitrary number. What is reasonable here? */
> >  #define PWRDM_TRANSITION_BAILOUT 10
> > @@ -223,10 +223,12 @@ bool pwrdm_can_ever_lose_context(struct
> powerdomain *pwrdm);
> >  extern void omap242x_powerdomains_init(void);
> >  extern void omap243x_powerdomains_init(void);
> >  extern void omap3xxx_powerdomains_init(void);
> > +extern void am33xx_powerdomains_init(void);
> >  extern void omap44xx_powerdomains_init(void);
> >
> >  extern struct pwrdm_ops omap2_pwrdm_operations;
> >  extern struct pwrdm_ops omap3_pwrdm_operations;
> > +extern struct pwrdm_ops am33xx_pwrdm_operations;
> >  extern struct pwrdm_ops omap4_pwrdm_operations;
> >
> >  /* Common Internal functions used across OMAP rev's */
> 
> [...]
> 
> > diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-
> omap2/prm33xx.h
> > new file mode 100644
> > index 000..0fd5c6e
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/prm33xx.h
> > @@ -0,0 +1,123 @@
> > +/*
> > + * AM33XX PRM instance offset macros
> > + *
> > + * Copyright (C) 2011 Texas Instruments Incorporated -
> http://www.ti.com/
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; 

RE: [RFC PATCH 04/11] arm:omap:am33xx: Integrate powerdomain to OMAP power framework

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 6:35 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal
> Subject: Re: [RFC PATCH 04/11] arm:omap:am33xx: Integrate powerdomain to
> OMAP power framework
> 
> Vaibhav Hiremath  writes:
> 
> > From: Afzal Mohammed 
> >
> > Hook up AM33XX power domain to OMAP framework.
> >
> > Signed-off-by: Afzal Mohammed 
> > Signed-off-by: Vaibhav Hiremath 
> 
> Should be combined with previous patch.
> 

Ok, will take care in next version.

Thanks,
Vaibhav

> Kevin
--
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 02/11] arm:omap:am33xx: Integrate voltage domain data

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 5:43 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal
> Subject: Re: [RFC PATCH 02/11] arm:omap:am33xx: Integrate voltage domain
> data
> 
> Vaibhav Hiremath  writes:
> 
> > From: Afzal Mohammed 
> >
> > Hook up AM33XX voltage domain info to OMAP framework.
> >
> > Signed-off-by: Afzal Mohammed 
> > Signed-off-by: Vaibhav Hiremath 
> 
> Should be  part of previous patch.
> 
Ok, will take care in next version.

Thanks,
Vaibhav


> Kevin
--
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 01/11] arm:omap:am33xx: Add voltage domain data

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 5:41 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux-
> arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal
> Subject: Re: [RFC PATCH 01/11] arm:omap:am33xx: Add voltage domain data
> 
> Vaibhav Hiremath  writes:
> 
> > From: Afzal Mohammed 
> >
> > Currently dummy voltage domain data is being created
> > in order to succeed boot process.
> > Nothing has been done w.r.t actual hardware (voltage control).
> >
> > Signed-off-by: Afzal Mohammed 
> > Signed-off-by: Vaibhav Hiremath 
> 
> [...]
> 
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c
> > @@ -0,0 +1,37 @@
> > +/*
> > + * AM33XX voltage domain data
> > + *
> > + * Copyright (C) 2011 Texas Instruments, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include 
> > +#include 
> > +
> > +#include "voltage.h"
> > +
> > +static struct voltagedomain am33xx_voltdm_mpu = {
> > +   .name = "mpu",
> > +};
> 
> According to the TRM, there is no MPU voltage domain.  Only CORE and RTC
> exist.
> 
> However, looking at the data manual (SPRS717 Oct 2011), it seems that
> some packages have a separate VDD_MPU while others have a combined
> VDD_MPU and VDD_CORE.
> 
> This should be clarified and documented in the changelog.
> 


No, we do have VDD_MPU specifically documented in TRM (SPRUH73 - October2011).

The TRM is accessible at - http://www.ti.com/lit/ug/spruh73/spruh73.pdf


> > +static struct voltagedomain am33xx_voltdm_core = {
> > +   .name = "core",
> > +};
> > +
> > +static struct voltagedomain am33xx_voltdm_rtc = {
> > +   .name = "rtc",
> > +};
> 
> Won't these basically empty voltage domains fail during voltage init?
> At a minimum, it seems they should have '.scaling = false' as well until
> voltage scalling is supported.
> 

It won't fail, but I agree to your point that we should clearly specify
the state here.
I will add ".scaling = false" in next version.

Thanks a ton for the review.

Thanks,
Vaibhav

> > +static struct voltagedomain *voltagedomains_am33xx[] __initdata = {
> > +   &am33xx_voltdm_mpu,
> > +   &am33xx_voltdm_core,
> > +   &am33xx_voltdm_rtc,
> > +   NULL,
> > +};
> > +
> > +void __init am33xx_voltagedomains_init(void)
> > +{
> > +   voltdm_init(voltagedomains_am33xx);
> > +}
> 
> Kevin
--
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 0/3] Introducing TI's New SoC/board AM335XEVM

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 5:09 AM
> To: Hiremath, Vaibhav; Russell King
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
> ker...@lists.infradead.org; p...@pwsan.com
> Subject: Re: [PATCH-V4 0/3] Introducing TI's New SoC/board AM335XEVM
> 
> Vaibhav Hiremath  writes:
> 
> > This patch set adds support for AM335x device having
> > Cortex-A8 MPU.
> >
> > Official website - http://www.ti.com/product/am3359
> >
> > AM335X is treated as another OMAP3 variant, where,
> > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> > and the respective type is AM335X, which is newly added device in
> > the family.
> > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > cpu_is_am335x() checks return success for AM335X.
> >
> > Also, I have validated OMAP3 boot test with this patch-series on
> OMAP3EVM.
> 
> After fixing the minor comment on patch 3/3, feel free to add:
> 
> Reviewed-by: Kevin Hilman 
> 
Thanks Kevin, for the review.


> Also, I was surprised to discover that this booted on my (recently
> arrived) BeagleBone.  It seems that u-boot (from Angstrom) is passing
> the machine ID of the AM335x EVM[1], even though there is another
> machine ID for the BeagleBone[2].  Is that expected?
Kevin,

We can detect the board using on-board EEPROM, so same mach-id
should work for both EVM and Beagle. 
And also going forward with device tree approach we may
not need different id's, right?

But I am surprised to see that beaglebone is booting fine for you,
did you get Linux console?
Actually the board won't boot without some patches,
(I have published on arago), especially inside, gpmc_init,
omap_sram_init, omap3_pm_init and omap3_twl_init.

Thanks,
Vaibhav

> 
> I also see that the mach-types for this are in Russell's for-next
> branch.  In order for us to merge this into Tony's master branch, we'll
> need to see if Russell can pull the mach-types updates into
> devel-stable.  Russell?
> 
> Kevin
> 
> [1] http://www.arm.linux.org.uk/developer/machines/list.php?id=3589
> [2] http://www.arm.linux.org.uk/developer/machines/list.php?id=3808
--
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/3] arm:omap:am33xx: Add low level debugging support

[Hiremath, Vaibhav]

> -Original Message-
> From: Hilman, Kevin
> Sent: Thursday, December 01, 2011 5:03 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
> ker...@lists.infradead.org; p...@pwsan.com; Mohammed, Afzal
> Subject: Re: [PATCH-V4 3/3] arm:omap:am33xx: Add low level debugging
> support
> 
> Hi Vaibhav,
> 
> Vaibhav Hiremath  writes:
> 
> > From: Afzal Mohammed 
> >
> > Add support for low level debugging on AM335X EVM (AM33XX family).
> > Currently only support for UART1 console, which is used on AM335X EVM
> > is added.
> >
> > Signed-off-by: Afzal Mohammed 
> > Signed-off-by: Vaibhav Hiremath 
> 
> One minor comment below...
> 
> > ---
> >  arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
> >  arch/arm/plat-omap/include/plat/serial.h   |4 
> >  arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
> >  3 files changed, 26 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
> b/arch/arm/mach-omap2/include/mach/debug-macro.S
> > index 13f98e5..ce543ae 100644
> > --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
> > +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
> > @@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
> > beq 82f @ configure UART2
> > cmp \rp, #TI816XUART3   @ ti816x UART offsets different
> > beq 83f @ configure UART3
> > +   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
> > +   beq 84f @ configure UART1
> > cmp \rp, #ZOOM_UART @ only on zoom2/3
> > beq 95f @ configure ZOOM_UART
> >
> > @@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
> > b   98f
> >  83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
> > b   98f
> > -
> > +84:ldr \rp, =AM33XX_UART1_BASE
> > +   and \rp, \rp, #0x00ff
> > +   b   97f
> >  95:ldr \rp, =ZOOM_UART_BASE
> > str \rp, [\tmp, #0] @ omap_uart_phys
> > ldr \rp, =ZOOM_UART_VIRT
> > @@ -110,6 +114,17 @@ omap_uart_lsr: .word   0
> > b   10b
> >
> > /* Store both phys and virt address for the uart */
> 
> Please update this comment to clarify that this block is for AM33xx
> only, and update the following one as the catch all.
> 
Ok, will update.

> > +97:add \rp, \rp, #0x4400   @ phys base
> > +   str \rp, [\tmp, #0] @ omap_uart_phys
> > +   sub \rp, \rp, #0x4400   @ phys base
> > +   add \rp, \rp, #0xf900   @ virt base
> > +   str \rp, [\tmp, #4] @ omap_uart_virt
> > +   mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
> > +   str \rp, [\tmp, #8] @ omap_uart_lsr
> 
> The last 3 lines are unnecessarily duplicated.  They can be shared with
> the common block that follows.  IOW, only the base addresses are
> different, the rest of the operations are shared.
> 
I thought about this, but then code looks complex & ugly, just to save
duplication of 3 lines. So I added separate code for AM33xx devices.

If you still think it should be done, then How about below change -


-   /* Store both phys and virt address for the uart */
-98:add \rp, \rp, #0x4800   @ phys base
+   /* AM33XX: Store both phys and virt address for the uart */
+96:add \rp, \rp, #0x4400   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
-   sub \rp, \rp, #0x4800   @ phys base
-   add \rp, \rp, #0xfa00   @ virt base
-   str \rp, [\tmp, #4] @ omap_uart_virt
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+97:str \rp, [\tmp, #4] @ omap_uart_virt
mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
str \rp, [\tmp, #8] @ omap_uart_lsr

b   10b

+   /* Store both phys and virt address for the uart */
+98:add \rp, \rp, #0x4800   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4800   @ phys base
+   add \rp, \rp, #0xfa00   @ virt base
+   b   97b
+


Thanks,
Vaibhav

> > +   b   10b
> > +
> > +   /* Store both phys and virt address for the uart */
> >  98:add \rp, \rp, #0x4800   @ phys base
> > str \rp, [\tmp, #0] @ omap_uart_phys
> > sub \rp, \rp, #0x4800   @ phys base
> 
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a me

Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig

[Janusz Krzysztofik]

On Thursday 01 of December 2011 at 10:54:09, Janusz Krzysztofik wrote:
> 
> Anyway, did you mean resending those 2/5 and 5/5 without any changes, 
> only renumbered as 1/2 and 2/2?

This was not a very clever question, sorry. Answering myself: 2/5 must 
be refreshed if not on top of 1/5.

Thanks,
Janusz
--
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 2a/5 v2] ARM: OMAP1: select clock rate by CPU type

[Janusz Krzysztofik]

On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote:
> 
> We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options
> too, right?

Right, but then, perhaps the initial version of patch 2a/5, which 
already started removing them, from omap1_defconfig for now, then going 
into the right direction while unblocking another regression fix (3/5), 
_is_ a good candidate for an rc fix?

Thanks,
Janusz
--
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 2a/5] Remove unsafe clock values from omap1_defconfig

[Janusz Krzysztofik]

I've unintentionally answered off-line, sorry, re-adding all Cc:'s.

On Thursday 01 of December 2011 at 03:27:51, Tony Lindgren wrote:
> * Janusz Krzysztofik  [30 17:40]:
> > On Wednesday 30 of November 2011 at 23:32:42, Tony Lindgren wrote:
> > >  
> > > Can you please split your series into two: Fix(es) for the -rc cycle,
> > > then patches that can be left for the next merge window.
> > 
> > From my point of view, all 5 are important fixes. Please decide 
> > yourself, having the following information provided:
> > 
> > 1/5: inspired by in-line comments about running from sram requirement
> > (works without this one for me),
> > 
> > 2/5: without this one, system clock runs way too fast if dpll1 is 
> > reprogrammed to default rate,
> > 
> > 3/5: without this one, all boards with bootloaders not setting rate 
> > correctly, like Amstrad Delta, will run at default rate, despite 
> > any .config selections, no matter if omap1_defconfig or custom,
> > 
> > 2a/5: required by 3/5,
> > 
> > 5/5: without this one, BogoMIPS is not updated after dpll1 reprogramme, 
> > breaking omap_keypad at least.
> > 
> > and please let me know which I should resend as fixes and which not.
> 
> How about 2 and 5 as fixes during the -rc, then the rest for the
> merge window? That is assuming that those are enough for you to have
> things mostly working.

If you still ask me for my opinion: with patch 3/5 omitted, then not 
being able to run at any other frequency than 60 MHz instead of usual 
150 since the board support was introduced first, isn't this a 
regression? Having a choice of upgrading to 3.2 and running my 
application on not very powerfull board at 60 MHz, or keep running 3.1 
at 150, guess what I chose? If I were a distro kernel package 
maintainer, guess what I would chose?

> It seems that we've had the issue of not actually changing the rate
> for a while, right?

This was not an issue before dpll1 reprogramming has been moved out from 
omap1_clk_init(), as an rc fix to another bug introduced in 3.2. Perhaps 
we should rather think of reverting a few commits which caused all these 
problems if fixing them all during rc cycle seems not possible? I 
haven't bisected them yet, rather concentrated on providing fixes, but I 
can still try to do it, starting back from the original issue 
(http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.

> If that's the case, I'd rather not start messing
> with that during the -rc cycle.
> 
> Regards,
> 
> Tony

I don't feel like a person who makes the final decision.

Anyway, did you mean resending those 2/5 and 5/5 without any changes, 
only renumbered as 1/2 and 2/2?

Thanks,
Janusz
--
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: Setting OMAP DSS fck

[Cousson, Benoit]

Hi Tomi,

On 12/1/2011 9:16 AM, Tomi Valkeinen wrote:

Hi,

Why is it that the rate of DSS functional clock (dss_dss_clk on OMAP4)
cannot be set, but we need to get the parent of the fck, and set the
rate of that? The same is on OMAP3.


This is a limitation of the clock fmwk, you cannot change the rate if 
you do not have a .set_rate function in your clock node. It is not 
propagated automatically to the parent.


In your case, here is the parent:

static struct clk dpll_per_m5x2_ck = {
.name   = "dpll_per_m5x2_ck",
.parent = &dpll_per_x2_ck,
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_PER,
.clksel_mask= OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
.ops= &clkops_omap4_dpllmx_ops,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate   = &omap2_clksel_set_rate,
};

And here is the child you are trying to set the rate to.

static struct clk dss_dss_clk = {
.name   = "dss_dss_clk",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
.enable_bit = OMAP4430_OPTFCLKEN_DSSCLK_SHIFT,
.clkdm_name = "l3_dss_clkdm",
.parent = &dpll_per_m5x2_ck,
.recalc = &followparent_recalc,
};

Propagating a set_rate to a parent is not a simple task because the fmwk 
do not have a clue about the siblings you might potentially have. And 
changing the parent will have an impact on every potential children.


In this case, it seems that there is only one child, so it might be 
possible.


I know this kind of issue was discussed during the new common clock fmwk 
discussion.


I'm Cc'ing Mike who will know the status of such feature.


 From driver's perspective I think this only makes things more complex,
as the driver is not interested in the parent, only about the dss fck.


Fully agree. It should transparent for the driver.

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] clk: introduce the common clock framework

[Russell King - ARM Linux]

On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> 1. When a clock user calls clk_enable() on a clock, the clock framework 
> should prevent other users of the clock from changing the clock's rate.  
> This should persist until the clock user calls clk_disable() (but see also 
> #2 below).  This will ensure that clock users can rely on the rate 
> returned by clk_get_rate(), as long as it's called between clk_enable() 
> and clk_disable().  And since the clock's rate is guaranteed to remain the 
> same during this time, code that cannot tolerate clock rate changes 
> without special handling (such as driver code for external I/O devices) 
> will work safely without further modification.

So, if you have a PLL whose parent clock is not used by anything else.
You want to program it to a certain rate.

You call clk_disable() on the PLL clock.  This walks up the tree and
disables the parent.  You then try to set the rate using clk_set_rate().
clk_set_rate() in this circumstance can't wait for the PLL to lock
because it can't - there's no reference clock for it.

You then call clk_enable().  The PLL now takes its time to lock.  You
can't sleep in clk_enable() because it might be called from atomic
contexts, so you have to spin waiting for this.

Overloading clk_disable/clk_enable in this way is a bad solution to
this problem.
--
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] mdt nand: omap2+ use platform options

[Artem Bityutskiy]

On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote:
> Options from struct omap_nand_platform_data are not used.
> Apply options after nand_scan_ident to avoid overwrite due to
> NAND_CHIPOPTIONS_MSK.
> So you can pass options from platformcode
> 
> Signed-off-by: Jan Weitzel 

Pushed to l2-mtd-2.6.git, thank you!

--
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] mdt nand: omap2+ use platform options

[Jan Weitzel]

Am Mittwoch, den 30.11.2011, 12:31 -0800 schrieb Brian Norris:
> On Tue, Nov 29, 2011 at 1:00 AM, Jan Weitzel  wrote:
> > Options from struct omap_nand_platform_data are not used.
> > Apply options after nand_scan_ident to avoid overwrite due to
> > NAND_CHIPOPTIONS_MSK.
> > So you can pass options from platformcode
> 
> Just to clarify, were the pdata->options ever used before? And does
> struct omap_nand_platform_data even have such a field?

No not used, but field exists. There is also a devsize field which is
used to provide NAND_BUSWIDTH_16 to info->nand.options
(drivers/mtd/nand/omap2.c)
Jan

> Brian
> --
> 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

Setting OMAP DSS fck

[Tomi Valkeinen]

Hi,

Why is it that the rate of DSS functional clock (dss_dss_clk on OMAP4)
cannot be set, but we need to get the parent of the fck, and set the
rate of that? The same is on OMAP3.

From driver's perspective I think this only makes things more complex,
as the driver is not interested in the parent, only about the dss fck.

 Tomi



signature.asc
Description: This is a digitally signed message part