RE: State of LDP3430 platform

2011-02-24 Thread Janorkar, Mayuresh 


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Thursday, February 24, 2011 4:20 AM
 To: Russell King - ARM Linux
 Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh;
 Woodruff, Richard
 Subject: Re: State of LDP3430 platform
 
 * Russell King - ARM Linux li...@arm.linux.org.uk [110212 08:09]:
  On Sat, Feb 12, 2011 at 04:02:16PM +, Russell King - ARM Linux
 wrote:
   Another LDP3430 report...
  
   The LDP3430 seems to be getting there, but:
  
   1. LCD screen seems wrong.  The X display looks rather large, and
  flickery - looks like the LCD timing parameters are wrong.  Some
  text disappears off the RHS.
  
  fbset reports:
 mode 240x320-510
 # D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz
 geometry 240 320 240 320 16
 timings 20833 3 39 2 7 3 1
 accel false
 rgba 5/11,6/5,5/0,0/0
  
  kernel config:
 CONFIG_FB_OMAP=y
 CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
  
  with the supplied kernel:
 mode 640x480-64
 # D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz
 geometry 640 480 640 640 16
 timings 46295 40 4 8 2 4 2
 accel false
 rgba 5/11,6/5,5/0,0/0
  so the LCD timings in the kernel appear to be wrong for the panel
  on the LDP.  What is 'CONFIG_FB_OMAP_LCD_VGA'?  There's *no* help

I would send a patch for this to Tomi.

  for this configuration option so god only knows what it's right
  setting should be.  Please give it some help text to explain what
  it is and what it does.
I think it is because x_res and y_res of panel are set to QVGA (320 X 240)
and the content sent is VGA (640 X 480)


With CONFIG_FB_OMAP_LCD_VGA=y the resolution taken is VGA (640 X 480)
You can check drivers/video/omap/lcd_ldp.c
http://lxr.linux.no/#linux+v2.6.37/drivers/video/omap/lcd_ldp.c#L185

 
  LCD works better with FB_OMAP_LCD_VGA set, but why is this necessary?

This would set the resolution to VGA (640 X 480)

3430 SDP has a switch to toggle between VGA (640 X 480) and QQVGA (320 X 240). 
So this switch must also be toggled along with the when we are booting a kernel 
with CONFIG_FB_OMAP_LCD_VGA=y

In LDP it is controlled by a GPIO:
#define LCD_PANEL_QVGA_GPIO 56
Depending on value of this the resolution is selected.
If LCD_PANEL_QVGA_GPIO is 1 then resolution is 320 X 240

Also, could you please share other CONFIG options which you are enabling over 
omap2plus_defconfig? (Otherwise please share .config)

-Thanks,
Mayuresh

 
   2. Keyboard - numeric keys produce wrong ascii for their labelled
  function.  This is from /dev/tty1 with X running:
  
 1 gives nothing 2 gives 4   3 gives 7
 4 gives 2   5 gives 5   6 gives 8
 7 gives 3   8 gives nothing 9 gives 9
 * gives nothing 0 gives E   # gives nothing
  
  off-hook (green phone) gives 0
  on-hook (red phone) gives 1b5b31397e
  
  Killing X and then running evtest on /dev/input/event1 doesn't
  return any events, neither does reading /dev/tty1 for the twl4030
  keypad - the numeric keys are completely dead.  /proc/interrupts
  shows no new interrupt counts when pressing the key for
  'twl4030_keypad'.  Unbinding/rebinding the twl4030 driver doesn't
  sort it out, neither does restarting X.
 
  3. Touchscreen is dead, presumably because no devices are bound to
 ads7846 SPI driver.
 
  ls -al /sys/bus/spi/devices/
  total 0
  drwxr-xr-x  2 root root 0 Jan  1 01:02 .
  drwxr-xr-x  4 root root 0 Jan  1 01:02 ..
  lrwxrwxrwx  1 root root 0 Jan  1 01:02 spi1.0 -
 ../../../devices/platform/omap2_mcspi.1/spi1.0
 
  is the only SPI device which appears, but is unbound.  I'm sure this
 used
  to work at some point.
 
 Anybody from TI looking into these?
 
 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
--
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: State of LDP3430 platform

2011-02-24 Thread Russell King - ARM Linux 
On Thu, Feb 24, 2011 at 01:51:50PM +0530, Janorkar, Mayuresh wrote:
 Also, could you please share other CONFIG options which you are enabling
 over omap2plus_defconfig? (Otherwise please share .config)

Attached.
#
# Automatically generated make config: don't edit
# Linux/arm 2.6.38-rc4 Kernel Configuration
# Sat Feb 12 16:43:38 2011
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_SCHED_CLOCK=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_LZO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set
CONFIG_HAVE_SPARSE_IRQ=y
# CONFIG_GENERIC_PENDING_IRQ is not set
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=cfq
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
#

RE: State of LDP3430 platform

2011-02-24 Thread Rajendra Nayak 
 -Original Message-
 From: Rajendra Nayak [mailto:rna...@ti.com]
 Sent: Thursday, February 24, 2011 12:39 PM
 To: Richard Woodruff; Tony Lindgren; Russell King - ARM Linux
 Cc: linux-omap@vger.kernel.org; Paul Walmsley; Santosh Shilimkar
 Subject: RE: State of LDP3430 platform

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Woodruff, Richard
  Sent: Thursday, February 24, 2011 4:53 AM
  To: Tony Lindgren; Russell King - ARM Linux
  Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh
  Subject: RE: State of LDP3430 platform
 
   From: Tony Lindgren [mailto:t...@atomide.com]
   Sent: Wednesday, February 23, 2011 4:50 PM
 
   Anybody from TI looking into these?
 
  I'll poke some folks and check.  I've not booted my LDP for a while.

 There was a regulator mapping issue on 3430SDP because of
 which tocuhscreen was broken and is now fixed with this patch
 http://marc.info/?l=linux-arm-kernelm=129673276608954w=2
 Looks like the same issue on LDP. Will check it up.

This one should now have LDP TS working..
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45306.html


 Regards,
 Rajendra

 
  As an older 3430 dev board its lost its shine compared to 3630 and
4430
 dev boards.
 
  Regards,
  Richard W.
 
  --
  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: State of LDP3430 platform

2011-02-23 Thread Tony Lindgren 
* Russell King - ARM Linux li...@arm.linux.org.uk [110212 08:09]:
 On Sat, Feb 12, 2011 at 04:02:16PM +, Russell King - ARM Linux wrote:
  Another LDP3430 report...
  
  The LDP3430 seems to be getting there, but:
  
  1. LCD screen seems wrong.  The X display looks rather large, and
 flickery - looks like the LCD timing parameters are wrong.  Some
 text disappears off the RHS.
  
 fbset reports:
  mode 240x320-510
  # D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz
  geometry 240 320 240 320 16
  timings 20833 3 39 2 7 3 1
  accel false
  rgba 5/11,6/5,5/0,0/0
  
 kernel config:
  CONFIG_FB_OMAP=y
  CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
  
 with the supplied kernel:
  mode 640x480-64
  # D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz
  geometry 640 480 640 640 16
  timings 46295 40 4 8 2 4 2
  accel false
  rgba 5/11,6/5,5/0,0/0
 so the LCD timings in the kernel appear to be wrong for the panel
 on the LDP.  What is 'CONFIG_FB_OMAP_LCD_VGA'?  There's *no* help
 for this configuration option so god only knows what it's right
 setting should be.  Please give it some help text to explain what
 it is and what it does.
 
 LCD works better with FB_OMAP_LCD_VGA set, but why is this necessary?
 
  2. Keyboard - numeric keys produce wrong ascii for their labelled
 function.  This is from /dev/tty1 with X running:
  
  1 gives nothing 2 gives 4   3 gives 7
  4 gives 2   5 gives 5   6 gives 8
  7 gives 3   8 gives nothing 9 gives 9
  * gives nothing 0 gives E   # gives nothing
  
 off-hook (green phone) gives 0
 on-hook (red phone) gives 1b5b31397e
  
 Killing X and then running evtest on /dev/input/event1 doesn't
 return any events, neither does reading /dev/tty1 for the twl4030
 keypad - the numeric keys are completely dead.  /proc/interrupts
 shows no new interrupt counts when pressing the key for
 'twl4030_keypad'.  Unbinding/rebinding the twl4030 driver doesn't
 sort it out, neither does restarting X.
 
 3. Touchscreen is dead, presumably because no devices are bound to
ads7846 SPI driver.
 
 ls -al /sys/bus/spi/devices/
 total 0
 drwxr-xr-x  2 root root 0 Jan  1 01:02 .
 drwxr-xr-x  4 root root 0 Jan  1 01:02 ..
 lrwxrwxrwx  1 root root 0 Jan  1 01:02 spi1.0 - 
 ../../../devices/platform/omap2_mcspi.1/spi1.0
 
 is the only SPI device which appears, but is unbound.  I'm sure this used
 to work at some point.

Anybody from TI looking into these?

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: State of LDP3430 platform

2011-02-23 Thread Woodruff, Richard 
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Wednesday, February 23, 2011 4:50 PM

 Anybody from TI looking into these?

I'll poke some folks and check.  I've not booted my LDP for a while.

As an older 3430 dev board its lost its shine compared to 3630 and 4430 dev 
boards.

Regards,
Richard W.

--
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: State of LDP3430 platform

2011-02-23 Thread Rajendra Nayak 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Woodruff, Richard
 Sent: Thursday, February 24, 2011 4:53 AM
 To: Tony Lindgren; Russell King - ARM Linux
 Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh
 Subject: RE: State of LDP3430 platform

  From: Tony Lindgren [mailto:t...@atomide.com]
  Sent: Wednesday, February 23, 2011 4:50 PM

  Anybody from TI looking into these?

 I'll poke some folks and check.  I've not booted my LDP for a while.

There was a regulator mapping issue on 3430SDP because of
which tocuhscreen was broken and is now fixed with this patch
http://marc.info/?l=linux-arm-kernelm=129673276608954w=2
Looks like the same issue on LDP. Will check it up.

Regards,
Rajendra


 As an older 3430 dev board its lost its shine compared to 3630 and 4430
dev boards.

 Regards,
 Richard W.

 --
 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: State of LDP3430 platform

2011-02-12 Thread Russell King - ARM Linux 
Another LDP3430 report...

The LDP3430 seems to be getting there, but:

1. LCD screen seems wrong.  The X display looks rather large, and
   flickery - looks like the LCD timing parameters are wrong.  Some
   text disappears off the RHS.

   fbset reports:
mode 240x320-510
# D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz
geometry 240 320 240 320 16
timings 20833 3 39 2 7 3 1
accel false
rgba 5/11,6/5,5/0,0/0

   kernel config:
CONFIG_FB_OMAP=y
CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2

   with the supplied kernel:
mode 640x480-64
# D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz
geometry 640 480 640 640 16
timings 46295 40 4 8 2 4 2
accel false
rgba 5/11,6/5,5/0,0/0
   so the LCD timings in the kernel appear to be wrong for the panel
   on the LDP.  What is 'CONFIG_FB_OMAP_LCD_VGA'?  There's *no* help
   for this configuration option so god only knows what it's right
   setting should be.  Please give it some help text to explain what
   it is and what it does.

2. Keyboard - numeric keys produce wrong ascii for their labelled
   function.  This is from /dev/tty1 with X running:

1 gives nothing 2 gives 4   3 gives 7
4 gives 2   5 gives 5   6 gives 8
7 gives 3   8 gives nothing 9 gives 9
* gives nothing 0 gives E   # gives nothing

   off-hook (green phone) gives 0
   on-hook (red phone) gives 1b5b31397e

   Killing X and then running evtest on /dev/input/event1 doesn't
   return any events, neither does reading /dev/tty1 for the twl4030
   keypad - the numeric keys are completely dead.  /proc/interrupts
   shows no new interrupt counts when pressing the key for
   'twl4030_keypad'.  Unbinding/rebinding the twl4030 driver doesn't
   sort it out, neither does restarting X.
--
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: State of LDP3430 platform

2011-02-12 Thread Russell King - ARM Linux 
On Sat, Feb 12, 2011 at 04:02:16PM +, Russell King - ARM Linux wrote:
 Another LDP3430 report...
 
 The LDP3430 seems to be getting there, but:
 
 1. LCD screen seems wrong.  The X display looks rather large, and
flickery - looks like the LCD timing parameters are wrong.  Some
text disappears off the RHS.
 
fbset reports:
   mode 240x320-510
   # D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz
   geometry 240 320 240 320 16
   timings 20833 3 39 2 7 3 1
   accel false
   rgba 5/11,6/5,5/0,0/0
 
kernel config:
   CONFIG_FB_OMAP=y
   CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 
with the supplied kernel:
   mode 640x480-64
   # D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz
   geometry 640 480 640 640 16
   timings 46295 40 4 8 2 4 2
   accel false
   rgba 5/11,6/5,5/0,0/0
so the LCD timings in the kernel appear to be wrong for the panel
on the LDP.  What is 'CONFIG_FB_OMAP_LCD_VGA'?  There's *no* help
for this configuration option so god only knows what it's right
setting should be.  Please give it some help text to explain what
it is and what it does.

LCD works better with FB_OMAP_LCD_VGA set, but why is this necessary?

 2. Keyboard - numeric keys produce wrong ascii for their labelled
function.  This is from /dev/tty1 with X running:
 
   1 gives nothing 2 gives 4   3 gives 7
   4 gives 2   5 gives 5   6 gives 8
   7 gives 3   8 gives nothing 9 gives 9
   * gives nothing 0 gives E   # gives nothing
 
off-hook (green phone) gives 0
on-hook (red phone) gives 1b5b31397e
 
Killing X and then running evtest on /dev/input/event1 doesn't
return any events, neither does reading /dev/tty1 for the twl4030
keypad - the numeric keys are completely dead.  /proc/interrupts
shows no new interrupt counts when pressing the key for
'twl4030_keypad'.  Unbinding/rebinding the twl4030 driver doesn't
sort it out, neither does restarting X.

3. Touchscreen is dead, presumably because no devices are bound to
   ads7846 SPI driver.

ls -al /sys/bus/spi/devices/
total 0
drwxr-xr-x  2 root root 0 Jan  1 01:02 .
drwxr-xr-x  4 root root 0 Jan  1 01:02 ..
lrwxrwxrwx  1 root root 0 Jan  1 01:02 spi1.0 - 
../../../devices/platform/omap2_mcspi.1/spi1.0

is the only SPI device which appears, but is unbound.  I'm sure this used
to work at some point.
--
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: State of LDP3430 platform

2011-01-19 Thread Jarkko Nikula 
On Tue, 18 Jan 2011 12:36:26 -0700 (MST)
Paul Walmsley p...@pwsan.com wrote:

 This is due to the recent ARM init_sched_clock() changes and the late
 initialization of the counter_32k clock source.  More information here:
 
http://marc.info/?l=linux-omapm=129513468605208w=2
 
 Fix by initializing the counter_32k clocksource during the machine timer
 initialization.
 
 Reported-by: Russell King rmk+ker...@arm.linux.org.uk
 Tested-by: Thomas Weber we...@corscience.de
 Signed-off-by: Paul Walmsley p...@pwsan.com
 ---
Thanks Paul. My tested-by is late as this in already in your pull
request but wanted to comment that this makes the mainline working on
omap3 after commit 211baa7
ARM: sched_clock: allow init_sched_clock() to be called early

-- 
Jarkko
--
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] omap1: Fix sched_clock implementation when both MPU timer and 32K timer are used (Re: State of LDP3430 platform)

2011-01-19 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [110118 15:20]:
 * Tony Lindgren t...@atomide.com [110118 14:34]:
  For omap15xx and 730 we need to use the MPU timer
  as the 32K timer is not available. For omap16xx
  we want to use the 32K timer because of PM. Fix this
  by allowing to build in both timers.
 
 This still needs one more patch to deal with the
 sched_clock for MPU timer..

And here's that patch to make sched_clock work with both
timers.

Tony

From: Tony Lindgren t...@atomide.com
Date: Tue, 18 Jan 2011 17:00:00 -0800
Subject: [PATCH] omap1: Fix sched_clock implementation when both MPU timer and 
32K timer are used

Earlier patches select HAVE_SCHED_CLOCK for omaps. To have working sched_clock
also for MPU timer, we need to implement it in a way where the right one gets
selected during the runtime.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -219,6 +219,24 @@ static struct clocksource clocksource_mpu = {
 
 static DEFINE_CLOCK_DATA(cd);
 
+static inline unsigned long long notrace _omap_mpu_sched_clock(void)
+{
+   u32 cyc = mpu_read(clocksource_mpu);
+   return cyc_to_sched_clock(cd, cyc, (u32)~0);
+}
+
+#ifndef CONFIG_OMAP_32K_TIMER
+unsigned long long notrace sched_clock(void)
+{
+   return _omap_mpu_sched_clock();
+}
+#else
+static unsigned long long notrace omap_mpu_sched_clock(void)
+{
+   return _omap_mpu_sched_clock();
+}
+#endif
+
 static void notrace mpu_update_sched_clock(void)
 {
u32 cyc = mpu_read(clocksource_mpu);
@@ -262,6 +280,30 @@ static inline void omap_mpu_timer_init(void)
 }
 #endif /* CONFIG_OMAP_MPU_TIMER */
 
+#if defined(CONFIG_OMAP_MPU_TIMER)  defined(CONFIG_OMAP_32K_TIMER)
+static unsigned long long (*preferred_sched_clock)(void);
+
+unsigned long long notrace sched_clock(void)
+{
+   if (!preferred_sched_clock)
+   return 0;
+
+   return preferred_sched_clock();
+}
+
+static inline void preferred_sched_clock_init(bool use_32k_sched_clock)
+{
+   if (use_32k_sched_clock)
+   preferred_sched_clock = omap_32k_sched_clock;
+   else
+   preferred_sched_clock = omap_mpu_sched_clock;
+}
+#else
+static inline void preferred_sched_clock_init(bool use_32k_sched_clcok)
+{
+}
+#endif
+
 static inline int omap_32k_timer_usable(void)
 {
int res = false;
@@ -283,8 +325,12 @@ static inline int omap_32k_timer_usable(void)
  */
 static void __init omap_timer_init(void)
 {
-   if (!omap_32k_timer_usable())
+   if (omap_32k_timer_usable()) {
+   preferred_sched_clock_init(1);
+   } else {
omap_mpu_timer_init();
+   preferred_sched_clock_init(0);
+   }
 }
 
 struct sys_timer omap_timer = {
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -120,12 +120,24 @@ static DEFINE_CLOCK_DATA(cd);
 #define SC_MULT40u
 #define SC_SHIFT   17
 
-unsigned long long notrace sched_clock(void)
+static inline unsigned long long notrace _omap_32k_sched_clock(void)
 {
u32 cyc = clocksource_32k.read(clocksource_32k);
return cyc_to_fixed_sched_clock(cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
 }
 
+#ifndef CONFIG_OMAP_MPU_TIMER
+unsigned long long notrace sched_clock(void)
+{
+   return _omap_32k_sched_clock();
+}
+#else
+unsigned long long notrace omap_32k_sched_clock(void)
+{
+   return _omap_32k_sched_clock();
+}
+#endif
+
 static void notrace omap_update_sched_clock(void)
 {
u32 cyc = clocksource_32k.read(clocksource_32k);
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -37,6 +37,7 @@ extern void omap_map_common_io(void);
 extern struct sys_timer omap_timer;
 extern bool omap_32k_timer_init(void);
 extern int __init omap_init_clocksource_32k(void);
+extern unsigned long long notrace omap_32k_sched_clock(void);
 
 extern void omap_reserve(void);
 
--
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] omap1: Fix sched_clock for the MPU timer (Re: State of LDP3430 platform)

2011-01-19 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [110118 14:25]:
 * Paul Walmsley p...@pwsan.com [110118 11:35]:
  
  Here's a slightly updated version of this patch, fixing a bug in one of 
  the comments, and revising the commit message.  There's no functional 
  difference between this and the previous version of this patch.
 
 Thanks, here are two patches to fix the MPU timer, and then allow
 compiling in both the MPU timer and the 32KiHz timer.

I've updated this patch with the following fix to reset the timer
first to get correct PRINTK_TIME timestamps.

Regards,

Tony

--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -228,10 +228,9 @@ static void __init omap_init_clocksource(unsigned long 
rate)
static char err[] __initdata = KERN_ERR
%s: can't register clocksource!\n;
 
-   init_sched_clock(cd, mpu_update_sched_clock, 32, rate);
-
setup_irq(INT_TIMER2, omap_mpu_timer2_irq);
omap_mpu_timer_start(1, ~0, 1);
+   init_sched_clock(cd, mpu_update_sched_clock, 32, rate);
 
if (clocksource_register_hz(clocksource_mpu, rate))
printk(err, clocksource_mpu.name);
--
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: State of LDP3430 platform

2011-01-18 Thread Paul Walmsley 
On Mon, 17 Jan 2011, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [110115 20:31]:
  --- a/arch/arm/mach-omap1/time.c
  +++ b/arch/arm/mach-omap1/time.c
  @@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
   
  omap_init_mpu_timer(rate);
  omap_init_clocksource(rate);
  +   /*
  +* XXX Since this file seems to deal mostly with the MPU timer,
  +* this doesn't seem like the correct place for the sync timer
  +* clocksource init.
  +*/
  +   if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
  +   omap_init_clocksource_32k();
   }
   
   struct sys_timer omap_timer = {
 
 To me it looks like the omap_init_clocksource_32k() call should be
 in arch/arm/mach-omap1/timer32k.c instead.

Just FYI for the lists; Tony and I talked about this off-list; he'll deal 
with this in a subsequent patch to avoid changing the OMAP1 clocksource 
behavior during this patch.


- 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: State of LDP3430 platform

2011-01-18 Thread Paul Walmsley 

Here's a slightly updated version of this patch, fixing a bug in one of 
the comments, and revising the commit message.  There's no functional 
difference between this and the previous version of this patch.


- Paul

[PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

After commit dc548fbbd2ecd0fc3b02301d551e5f8e19ae58fd (ARM: omap: convert 
sched_clock() to use new infrastructure), OMAPs that use the 32KiHz 
synchronization timer as their clocksource crash during boot:

[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.00] pgd = c0004000
[0.00] [] *pgd=
[0.00] Internal error: Oops: 8005 [#1] SMP
[0.00] last sysfs file:
[0.00] Modules linked in:
[0.00] CPU: 0Tainted: GW(2.6.37-07734-g2467802 #7)
[0.00] PC is at 0x0
[0.00] LR is at sched_clock_poll+0x2c/0x3c
[0.00] pc : []lr : [c0060b74]psr: 61d3
[0.00] sp : c058bfd0  ip : c058a000  fp : 
[0.00] r10:   r9 : 411fc092  r8 : 800330c8
[0.00] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
[0.00] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 
[0.00] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.00] Control: 10c53c7f  Table: 8000404a  DAC: 0017

This is due to the recent ARM init_sched_clock() changes and the late
initialization of the counter_32k clock source.  More information here:

   http://marc.info/?l=linux-omapm=129513468605208w=2

Fix by initializing the counter_32k clocksource during the machine timer
initialization.

Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Thomas Weber we...@corscience.de
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap1/time.c   |7 +++
 arch/arm/mach-omap2/timer-gp.c   |   10 --
 arch/arm/plat-omap/counter_32k.c |3 +--
 arch/arm/plat-omap/include/plat/common.h |1 +
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
 
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
+   /*
+* XXX Since this file seems to deal mostly with the MPU timer,
+* this doesn't seem like the correct place for the sync timer
+* clocksource init.
+*/
+   if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
+   omap_init_clocksource_32k();
 }
 
 struct sys_timer omap_timer = {
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..7b7c268 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -42,6 +42,8 @@
 
 #include timer-gp.h
 
+#include plat/common.h
+
 /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
 #define MAX_GPTIMER_ID 12
 
@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
 /* 
  * When 32k-timer is enabled, don't use GPTimer for clocksource
  * instead, just leave default clocksource which uses the 32k
- * sync counter.  See clocksource setup in see plat-omap/common.c. 
+ * sync counter.  See clocksource setup in plat-omap/counter_32k.c
  */
 
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+   omap_init_clocksource_32k();
+}
+
 #else
 /*
  * clocksource
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -160,7 +160,7 @@ void read_persistent_clock(struct timespec *ts)
*ts = *tsp;
 }
 
-static int __init omap_init_clocksource_32k(void)
+int __init omap_init_clocksource_32k(void)
 {
static char err[] __initdata = KERN_ERR
%s: can't register clocksource!\n;
@@ -195,7 +195,6 @@ static int __init omap_init_clocksource_32k(void)
}
return 0;
 }
-arch_initcall(omap_init_clocksource_32k);
 
 #endif /* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) */
 
diff --git a/arch/arm/plat-omap/include/plat/common.h 
b/arch/arm/plat-omap/include/plat/common.h
index 6b8088e..84c707f 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -35,6 +35,7 @@ struct sys_timer;
 
 extern void omap_map_common_io(void);
 extern struct sys_timer omap_timer;
+extern int __init omap_init_clocksource_32k(void);
 
 extern void omap_reserve(void);
 
-- 
1.7.2.3

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

[PATCH] omap1: Fix sched_clock for the MPU timer (Re: State of LDP3430 platform)

2011-01-18 Thread Tony Lindgren 
* Paul Walmsley p...@pwsan.com [110118 11:35]:
 
 Here's a slightly updated version of this patch, fixing a bug in one of 
 the comments, and revising the commit message.  There's no functional 
 difference between this and the previous version of this patch.

Thanks, here are two patches to fix the MPU timer, and then allow
compiling in both the MPU timer and the 32KiHz timer.

Tony

From: Tony Lindgren t...@atomide.com
Date: Tue, 18 Jan 2011 13:25:39 -0800
Subject: [PATCH] omap1: Fix sched_clock for the MPU timer

Otherwise systems using the MPU timer will hang.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -44,11 +44,14 @@
 #include linux/clocksource.h
 #include linux/clockchips.h
 #include linux/io.h
+#include linux/sched.h
 
 #include asm/system.h
 #include mach/hardware.h
 #include asm/leds.h
 #include asm/irq.h
+#include asm/sched_clock.h
+
 #include asm/mach/irq.h
 #include asm/mach/time.h
 
@@ -67,7 +70,7 @@ typedef struct {
 ((volatile omap_mpu_timer_regs_t*)OMAP1_IO_ADDRESS(OMAP_MPU_TIMER_BASE +   
\
 (n)*OMAP_MPU_TIMER_OFFSET))
 
-static inline unsigned long omap_mpu_timer_read(int nr)
+static inline unsigned long notrace omap_mpu_timer_read(int nr)
 {
volatile omap_mpu_timer_regs_t* timer = omap_mpu_timer_base(nr);
return timer-read_tim;
@@ -212,11 +215,21 @@ static struct clocksource clocksource_mpu = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
+static DEFINE_CLOCK_DATA(cd);
+
+static void notrace mpu_update_sched_clock(void)
+{
+   u32 cyc = mpu_read(clocksource_mpu);
+   update_sched_clock(cd, cyc, (u32)~0);
+}
+
 static void __init omap_init_clocksource(unsigned long rate)
 {
static char err[] __initdata = KERN_ERR
%s: can't register clocksource!\n;
 
+   init_sched_clock(cd, mpu_update_sched_clock, 32, rate);
+
setup_irq(INT_TIMER2, omap_mpu_timer2_irq);
omap_mpu_timer_start(1, ~0, 1);
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] omap1: Fix booting for 15xx and 730 with omap1_defconfig (Re: State of LDP3430 platform)

2011-01-18 Thread Tony Lindgren 
For omap15xx and 730 we need to use the MPU timer
as the 32K timer is not available. For omap16xx
we want to use the 32K timer because of PM. Fix this
by allowing to build in both timers.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -9,6 +9,7 @@ config ARCH_OMAP730
depends on ARCH_OMAP1
bool OMAP730 Based System
select CPU_ARM926T
+   select OMAP_MPU_TIMER
select ARCH_OMAP_OTG
 
 config ARCH_OMAP850
@@ -22,6 +23,7 @@ config ARCH_OMAP15XX
default y
bool OMAP15xx Based System
select CPU_ARM925T
+   select OMAP_MPU_TIMER
 
 config ARCH_OMAP16XX
depends on ARCH_OMAP1
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,12 +3,11 @@
 #
 
 # Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
+obj-y := io.o id.o sram.o time.o irq.o mux.o flash.o serial.o devices.o dma.o
 obj-y += clock.o clock_data.o opp_data.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
-obj-$(CONFIG_OMAP_MPU_TIMER)   += time.o
 obj-$(CONFIG_OMAP_32K_TIMER)   += timer32k.o
 
 # Power Management
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -57,6 +57,8 @@
 
 #include plat/common.h
 
+#ifdef CONFIG_OMAP_MPU_TIMER
+
 #define OMAP_MPU_TIMER_BASEOMAP_MPU_TIMER1_BASE
 #define OMAP_MPU_TIMER_OFFSET  0x100
 
@@ -237,12 +239,7 @@ static void __init omap_init_clocksource(unsigned long 
rate)
printk(err, clocksource_mpu.name);
 }
 
-/*
- * ---
- * Timer initialization
- * ---
- */
-static void __init omap_timer_init(void)
+static void __init omap_mpu_timer_init(void)
 {
struct clk  *ck_ref = clk_get(NULL, ck_ref);
unsigned long   rate;
@@ -257,13 +254,38 @@ static void __init omap_timer_init(void)
 
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
-   /*
-* XXX Since this file seems to deal mostly with the MPU timer,
-* this doesn't seem like the correct place for the sync timer
-* clocksource init.
-*/
-   if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
-   omap_init_clocksource_32k();
+}
+
+#else
+static inline void omap_mpu_timer_init(void)
+{
+   pr_err(Bogus timer, should not happen\n);
+}
+#endif /* CONFIG_OMAP_MPU_TIMER */
+
+static inline int omap_32k_timer_usable(void)
+{
+   int res = false;
+
+   if (cpu_is_omap730() || cpu_is_omap15xx())
+   return res;
+
+#ifdef CONFIG_OMAP_32K_TIMER
+   res = omap_32k_timer_init();
+#endif
+
+   return res;
+}
+
+/*
+ * ---
+ * Timer initialization
+ * ---
+ */
+static void __init omap_timer_init(void)
+{
+   if (!omap_32k_timer_usable())
+   omap_mpu_timer_init();
 }
 
 struct sys_timer omap_timer = {
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -52,10 +52,9 @@
 #include asm/irq.h
 #include asm/mach/irq.h
 #include asm/mach/time.h
+#include plat/common.h
 #include plat/dmtimer.h
 
-struct sys_timer omap_timer;
-
 /*
  * ---
  * 32KHz OS timer
@@ -181,14 +180,14 @@ static __init void omap_init_32k_timer(void)
  * Timer initialization
  * ---
  */
-static void __init omap_timer_init(void)
+bool __init omap_32k_timer_init(void)
 {
+   omap_init_clocksource_32k();
+
 #ifdef CONFIG_OMAP_DM_TIMER
omap_dm_timer_init();
 #endif
omap_init_32k_timer();
-}
 
-struct sys_timer omap_timer = {
-   .init   = omap_timer_init,
-};
+   return true;
+}
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -144,12 +144,9 @@ config OMAP_IOMMU_DEBUG
 config OMAP_IOMMU_IVA2
bool
 
-choice
-   prompt System timer
-   default OMAP_32K_TIMER if !ARCH_OMAP15XX
-
 config OMAP_MPU_TIMER
bool Use mpu timer
+   depends on ARCH_OMAP1
help
  Select this option if you want to use the OMAP mpu timer. This
  timer provides more intra-tick resolution than the 32KHz timer,
@@ -158,6 +155,7 @@ config OMAP_MPU_TIMER
 config OMAP_32K_TIMER
bool Use 32KHz timer
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+   default y if (ARCH_OMAP16XX || ARCH_OMAP2PLUS)
help
  Select this option if you want to enable the OMAP 32KHz timer.
  This timer saves power compared to the OMAP_MPU_TIMER, and has
@@ -165,8 +163,6 @@ config OMAP_32K_TIMER
  intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is
  currently only available for OMAP16XX, 24XX, 34XX

Re: [PATCH] omap1: Fix booting for 15xx and 730 with omap1_defconfig (Re: State of LDP3430 platform)

2011-01-18 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [110118 14:34]:
 For omap15xx and 730 we need to use the MPU timer
 as the 32K timer is not available. For omap16xx
 we want to use the 32K timer because of PM. Fix this
 by allowing to build in both timers.

This still needs one more patch to deal with the
sched_clock for MPU timer..

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: State of LDP3430 platform

2011-01-17 Thread Tony Lindgren 
* Woodruff, Richard r-woodru...@ti.com [110115 15:48]:
 
  From: Tony Lindgren [mailto:t...@atomide.com]
  Sent: Friday, January 14, 2011 6:03 PM
 
  I've been seeing this on my omap4 panda. While debugging it, I left
  u-boot console only running for a few minutes to see if that stays up.
  It did.. And after doing that somehow now my panda boots all the way
  and stays up. Weird.
 
 That is a bit weird.  U-boot doesn't do much of anything but spin waiting for 
 characters on serial.  The watchdog normally isn't used.
 
 Thinking back I have experienced goofiness along these lines before.  This 
 had to do with some bad timer initial state assumptions.  The timer's count 
 values and states entering the kernel have caused a trip up.  I had fixed 
 some of these years back.  Its possible some could have snuck back with all 
 the recoding.  Many times the simple have some unanticipated twist.
 
 The watchdog is something which the old kernel used to fall on also.  There 
 were a couple simple trip ups:
 -1- people forgot to turn clock on all together
 -2- next, it was touched before clock frame work was initialized
 -1+2- some code only 'wrote' to watchdog registers.  When memory 
 attribute is device, generally the imprecise abort is ignored by the arm.  
 But some times weirdness slipped in around memory weak memory attribute 
 mishandling.
 
 Sounds like a fun bug/puzzle which good ole Lauterbach would help in.

This happened for a few days both with 2.6.37 and current mainline
kernel. After I started debugging it went away with no changes to
anything.. So can't debug any further at this point unfortunately.

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: State of LDP3430 platform

2011-01-17 Thread Woodruff, Richard 

 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Monday, January 17, 2011 11:35 AM

 This happened for a few days both with 2.6.37 and current mainline
 kernel. After I started debugging it went away with no changes to
 anything.. So can't debug any further at this point unfortunately.

Odd. You might experiment with cold reset vs. warm reset for booting.  Initial 
values of some blocks will be different.

Reset tree is something not usually considered. The behavior depends on what 
level and when it is asserted. Software tends to act like all resets have same 
effect and this is not the case. I've seen folks burned in PM context several 
times at both OMAP and PMIC level.

Also... something happen behind your back.  You can program up the PMIC to take 
a softreset and issue a hardreset.

Regards,
Richard W.

--
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: State of LDP3430 platform

2011-01-17 Thread Tony Lindgren 
Hi,

* Paul Walmsley p...@pwsan.com [110115 20:31]:
 --- a/arch/arm/mach-omap1/time.c
 +++ b/arch/arm/mach-omap1/time.c
 @@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
  
   omap_init_mpu_timer(rate);
   omap_init_clocksource(rate);
 + /*
 +  * XXX Since this file seems to deal mostly with the MPU timer,
 +  * this doesn't seem like the correct place for the sync timer
 +  * clocksource init.
 +  */
 + if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
 + omap_init_clocksource_32k();
  }
  
  struct sys_timer omap_timer = {

To me it looks like the omap_init_clocksource_32k() call should be
in arch/arm/mach-omap1/timer32k.c instead.

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: State of LDP3430 platform

2011-01-16 Thread Thomas Weber 
Am 16.01.2011 05:32, schrieb Paul Walmsley:
 On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:

 On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
 On Fri, 14 Jan 2011, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [101207 19:30]:
 On Tue, 7 Dec 2010, Paul Walmsley wrote:

 Regarding the watchdog problem, unfortunately, I can't reproduce on the 
 BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
 omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
 .config, one of us can try to reproduce the problem with it.  Do the 
 2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
 I've been seeing this on my omap4 panda. While debugging it, I left
 u-boot console only running for a few minutes to see if that stays up.
 It did.. And after doing that somehow now my panda boots all the way
 and stays up. Weird.
 Hmmm, do you think the watchdog is what's killing it?  I don't think 
 leaving u-boot running would affect that?
 Right, well, the LDP3430 (and probably all OMAP) is broken by my
 init_sched_clock() changes because I gave up with testing on OMAP
 platforms.

 Why does OMAP initialize its clock sources soo late, outside of
 the timer initialization?  This means you have no counter in place
 (except for the jiffies counter) during early boot.

 Is there a reason why OMAP uniquely does this?
 I don't think so.

 Patch attached.


 - Paul


 [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

 Linus's master branch, currently at commit
 1b59be2a6cdcb5a12e18d8315c07c94a624de48f (Merge branch 'slab/urgent'
 of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6),
 crashes during boot on OMAP4430 ES2.0 Panda:

 [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
 [0.00] Unable to handle kernel NULL pointer dereference at virtual 
 address 
 [0.00] pgd = c0004000
 [0.00] [] *pgd=
 [0.00] Internal error: Oops: 8005 [#1] SMP
 [0.00] last sysfs file:
 [0.00] Modules linked in:
 [0.00] CPU: 0Tainted: GW(2.6.37-07734-g2467802 #7)
 [0.00] PC is at 0x0
 [0.00] LR is at sched_clock_poll+0x2c/0x3c
 [0.00] pc : []lr : [c0060b74]psr: 61d3
 [0.00] sp : c058bfd0  ip : c058a000  fp : 
 [0.00] r10:   r9 : 411fc092  r8 : 800330c8
 [0.00] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
 [0.00] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 
 [0.00] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
 kernel
 [0.00] Control: 10c53c7f  Table: 8000404a  DAC: 0017

 This is due to the recent ARM init_sched_clock() changes and the late
 initialization of the counter_32k clock source:

http://marc.info/?l=linux-omapm=129513468605208w=2

 Fix by initializing the counter_32k clocksource during the machine timer
 initialization.

 Reported-by: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Paul Walmsley p...@pwsan.com

 ---
  arch/arm/mach-omap1/time.c   |7 +++
  arch/arm/mach-omap2/timer-gp.c   |   10 --
  arch/arm/plat-omap/counter_32k.c |3 +--
  arch/arm/plat-omap/include/plat/common.h |1 +
  4 files changed, 17 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
 index ed7a61f..6ec65e5 100644
 --- a/arch/arm/mach-omap1/time.c
 +++ b/arch/arm/mach-omap1/time.c
 @@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
  
   omap_init_mpu_timer(rate);
   omap_init_clocksource(rate);
 + /*
 +  * XXX Since this file seems to deal mostly with the MPU timer,
 +  * this doesn't seem like the correct place for the sync timer
 +  * clocksource init.
 +  */
 + if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
 + omap_init_clocksource_32k();
  }
  
  struct sys_timer omap_timer = {
 diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
 index 4e48e78..57d53e0 100644
 --- a/arch/arm/mach-omap2/timer-gp.c
 +++ b/arch/arm/mach-omap2/timer-gp.c
 @@ -42,6 +42,8 @@
  
  #include timer-gp.h
  
 +#include plat/common.h
 +
  /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
  #define MAX_GPTIMER_ID   12
  
 @@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
  /* 
   * When 32k-timer is enabled, don't use GPTimer for clocksource
   * instead, just leave default clocksource which uses the 32k
 - * sync counter.  See clocksource setup in see plat-omap/common.c. 
 + * sync counter.  See clocksource setup in plat-omap/timer-32k.c
   */
  
 -static inline void __init omap2_gp_clocksource_init(void) {}
 +static void __init omap2_gp_clocksource_init(void)
 +{
 + omap_init_clocksource_32k();
 +}
 +
  #else
  /*
   * clocksource
 diff --git a/arch/arm/plat-omap/counter_32k.c

Re: State of LDP3430 platform

2011-01-15 Thread Paul Walmsley 
On Fri, 14 Jan 2011, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [101207 19:30]:
  On Tue, 7 Dec 2010, Paul Walmsley wrote:
  
  Regarding the watchdog problem, unfortunately, I can't reproduce on the 
  BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
  omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
  .config, one of us can try to reproduce the problem with it.  Do the 
  2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
 
 I've been seeing this on my omap4 panda. While debugging it, I left
 u-boot console only running for a few minutes to see if that stays up.
 It did.. And after doing that somehow now my panda boots all the way
 and stays up. Weird.

Hmmm, do you think the watchdog is what's killing it?  I don't think 
leaving u-boot running would affect that?


- 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: State of LDP3430 platform

2011-01-15 Thread Russell King - ARM Linux 
On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
 On Fri, 14 Jan 2011, Tony Lindgren wrote:
 
  * Paul Walmsley p...@pwsan.com [101207 19:30]:
   On Tue, 7 Dec 2010, Paul Walmsley wrote:
   
   Regarding the watchdog problem, unfortunately, I can't reproduce on the 
   BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
   omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
   .config, one of us can try to reproduce the problem with it.  Do the 
   2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
  
  I've been seeing this on my omap4 panda. While debugging it, I left
  u-boot console only running for a few minutes to see if that stays up.
  It did.. And after doing that somehow now my panda boots all the way
  and stays up. Weird.
 
 Hmmm, do you think the watchdog is what's killing it?  I don't think 
 leaving u-boot running would affect that?

Right, well, the LDP3430 (and probably all OMAP) is broken by my
init_sched_clock() changes because I gave up with testing on OMAP
platforms.

Why does OMAP initialize its clock sources soo late, outside of
the timer initialization?  This means you have no counter in place
(except for the jiffies counter) during early boot.

Is there a reason why OMAP uniquely does this?
--
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: State of LDP3430 platform

2011-01-15 Thread Woodruff, Richard 

 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Friday, January 14, 2011 6:03 PM

 I've been seeing this on my omap4 panda. While debugging it, I left
 u-boot console only running for a few minutes to see if that stays up.
 It did.. And after doing that somehow now my panda boots all the way
 and stays up. Weird.

That is a bit weird.  U-boot doesn't do much of anything but spin waiting for 
characters on serial.  The watchdog normally isn't used.

Thinking back I have experienced goofiness along these lines before.  This had 
to do with some bad timer initial state assumptions.  The timer's count values 
and states entering the kernel have caused a trip up.  I had fixed some of 
these years back.  Its possible some could have snuck back with all the 
recoding.  Many times the simple have some unanticipated twist.

The watchdog is something which the old kernel used to fall on also.  There 
were a couple simple trip ups:
-1- people forgot to turn clock on all together
-2- next, it was touched before clock frame work was initialized
-1+2- some code only 'wrote' to watchdog registers.  When memory 
attribute is device, generally the imprecise abort is ignored by the arm.  But 
some times weirdness slipped in around memory weak memory attribute mishandling.

Sounds like a fun bug/puzzle which good ole Lauterbach would help in.

Regards,
Richard W.

--
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: State of LDP3430 platform

2011-01-15 Thread Russell King - ARM Linux 
On Sat, Jan 15, 2011 at 11:37:44PM +, Russell King - ARM Linux wrote:
 On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
  On Fri, 14 Jan 2011, Tony Lindgren wrote:
  
   * Paul Walmsley p...@pwsan.com [101207 19:30]:
On Tue, 7 Dec 2010, Paul Walmsley wrote:

Regarding the watchdog problem, unfortunately, I can't reproduce on the 
BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
.config, one of us can try to reproduce the problem with it.  Do the 
2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
   
   I've been seeing this on my omap4 panda. While debugging it, I left
   u-boot console only running for a few minutes to see if that stays up.
   It did.. And after doing that somehow now my panda boots all the way
   and stays up. Weird.
  
  Hmmm, do you think the watchdog is what's killing it?  I don't think 
  leaving u-boot running would affect that?
 
 Right, well, the LDP3430 (and probably all OMAP) is broken by my
 init_sched_clock() changes because I gave up with testing on OMAP
 platforms.
 
 Why does OMAP initialize its clock sources soo late, outside of
 the timer initialization?  This means you have no counter in place
 (except for the jiffies counter) during early boot.
 
 Is there a reason why OMAP uniquely does this?

Right... with that initialization fixed, the LDP3430 boots, and doesn't
reboot during userspace bring-up.  However it doesn't seem to reach a
login prompt (presumably because the change of serial device naming.)

I'm still seeing a flood of MMC errors, eg:

mmcblk0: error -84 transferring data, sector 1847929, nr 184,
 cmd response 0x900, card status 0x900

This means it's regularly seeing data CRC errors.  The original kernel
supplied with the LDP3430 reports no data CRC errors.

--
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: State of LDP3430 platform

2011-01-15 Thread Woodruff, Richard 

 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
 Sent: Saturday, January 15, 2011 5:38 PM
 Why does OMAP initialize its clock sources soo late, outside of
 the timer initialization?  This means you have no counter in place
 (except for the jiffies counter) during early boot.

 Is there a reason why OMAP uniquely does this?

Not any good reason.  I'm aware of historic porting issue and the missed/hidden 
need for early init for some time services.

1st attempts to do really early init (like 7 years back) were messed as not all 
kernel services used to be available when the time early time init functions 
happened.

It was hidden because u-boot had already turned on the same clock the kernel 
level driver used. So there was no failure (until the kernel used something 
else).

Recurring breaks  fixes happened to out of trees as owners changed.  The 
mainline never enabled driver till recently.

Regards,
Richard W.
--
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: State of LDP3430 platform

2011-01-15 Thread Russell King - ARM Linux 
On Sat, Jan 15, 2011 at 06:05:24PM -0600, Woodruff, Richard wrote:
  From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
  Sent: Saturday, January 15, 2011 5:38 PM
  Why does OMAP initialize its clock sources soo late, outside of
  the timer initialization?  This means you have no counter in place
  (except for the jiffies counter) during early boot.
 
  Is there a reason why OMAP uniquely does this?
 
 Not any good reason.  I'm aware of historic porting issue and the missed/
 hidden need for early init for some time services.
 
 1st attempts to do really early init (like 7 years back) were messed as
 not all kernel services used to be available when the time early time
 init functions happened.

The background here is:

We now have common generic sched_clock() support which provides true
full 64-bit nanosecond time measurements, as required by the scheduler
code.

We need sched_clock() initialized before the first use which matters -
which is inside sched_init().

As sched_init() is called by generic code, we don't have much choice over
where it happens during the kernel boot - any change will need a very
good justification because it's risking breaking other architectures.

The only preceding hook we have into generic code is setup_arch(), and
I now provide a .init_early platform callback to setup sched_clock().
The point at which init_sched_clock*() is called defines the sched_clock()
time zero.

However, this is too early to setup the sched_clock() keep-alive soft
timer - this is delayed until the time_init() callback.  This happens
after sched_init(), so we expect that init_sched_clock() will have been
called by this point - and given that it's already been used, this is
not an unreasonable assumption.  This is fine as we expect that the
counter backing the sched_clock() implementation will not wrap between
these two calls - and to make sure we kick off an update at this point.

So, as a platform, there are two places where init_sched_clock() is
callable - either .init_early (preferred) or the sys_timer .init method
(if it must be late).

If sched_clock() support is enabled, then init_sched_clock() must have
been called no later than the return of sys_timer .init method otherwise
you will get an oops (which is what is happening) when the first update
cycle is kicked off.
--
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: State of LDP3430 platform

2011-01-15 Thread Paul Walmsley 
On Sat, 15 Jan 2011, Woodruff, Richard wrote:

 Recurring breaks  fixes happened to out of trees as owners changed.  

If a change breaks something in out-of-tree code, and a patch can be 
created that is valid and correct for the mainline tree, then patches are 
certainly welcomed on the public mailing lists.


- 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: State of LDP3430 platform

2011-01-15 Thread Paul Walmsley 
On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:

 On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
  On Fri, 14 Jan 2011, Tony Lindgren wrote:
  
   * Paul Walmsley p...@pwsan.com [101207 19:30]:
On Tue, 7 Dec 2010, Paul Walmsley wrote:

Regarding the watchdog problem, unfortunately, I can't reproduce on the 
BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
.config, one of us can try to reproduce the problem with it.  Do the 
2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
   
   I've been seeing this on my omap4 panda. While debugging it, I left
   u-boot console only running for a few minutes to see if that stays up.
   It did.. And after doing that somehow now my panda boots all the way
   and stays up. Weird.
  
  Hmmm, do you think the watchdog is what's killing it?  I don't think 
  leaving u-boot running would affect that?
 
 Right, well, the LDP3430 (and probably all OMAP) is broken by my
 init_sched_clock() changes because I gave up with testing on OMAP
 platforms.
 
 Why does OMAP initialize its clock sources soo late, outside of
 the timer initialization?  This means you have no counter in place
 (except for the jiffies counter) during early boot.
 
 Is there a reason why OMAP uniquely does this?

I don't think so.

Patch attached.


- Paul


[PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

Linus's master branch, currently at commit
1b59be2a6cdcb5a12e18d8315c07c94a624de48f (Merge branch 'slab/urgent'
of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6),
crashes during boot on OMAP4430 ES2.0 Panda:

[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.00] pgd = c0004000
[0.00] [] *pgd=
[0.00] Internal error: Oops: 8005 [#1] SMP
[0.00] last sysfs file:
[0.00] Modules linked in:
[0.00] CPU: 0Tainted: GW(2.6.37-07734-g2467802 #7)
[0.00] PC is at 0x0
[0.00] LR is at sched_clock_poll+0x2c/0x3c
[0.00] pc : []lr : [c0060b74]psr: 61d3
[0.00] sp : c058bfd0  ip : c058a000  fp : 
[0.00] r10:   r9 : 411fc092  r8 : 800330c8
[0.00] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
[0.00] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 
[0.00] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.00] Control: 10c53c7f  Table: 8000404a  DAC: 0017

This is due to the recent ARM init_sched_clock() changes and the late
initialization of the counter_32k clock source:

   http://marc.info/?l=linux-omapm=129513468605208w=2

Fix by initializing the counter_32k clocksource during the machine timer
initialization.

Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Paul Walmsley p...@pwsan.com

---
 arch/arm/mach-omap1/time.c   |7 +++
 arch/arm/mach-omap2/timer-gp.c   |   10 --
 arch/arm/plat-omap/counter_32k.c |3 +--
 arch/arm/plat-omap/include/plat/common.h |1 +
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
 
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
+   /*
+* XXX Since this file seems to deal mostly with the MPU timer,
+* this doesn't seem like the correct place for the sync timer
+* clocksource init.
+*/
+   if (!cpu_is_omap7xx()  !cpu_is_omap15xx())
+   omap_init_clocksource_32k();
 }
 
 struct sys_timer omap_timer = {
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -42,6 +42,8 @@
 
 #include timer-gp.h
 
+#include plat/common.h
+
 /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
 #define MAX_GPTIMER_ID 12
 
@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
 /* 
  * When 32k-timer is enabled, don't use GPTimer for clocksource
  * instead, just leave default clocksource which uses the 32k
- * sync counter.  See clocksource setup in see plat-omap/common.c. 
+ * sync counter.  See clocksource setup in plat-omap/timer-32k.c
  */
 
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+   omap_init_clocksource_32k();
+}
+
 #else
 /*
  * clocksource
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
---

Re: State of LDP3430 platform

2011-01-14 Thread Tony Lindgren 
* Paul Walmsley p...@pwsan.com [101207 19:30]:
 On Tue, 7 Dec 2010, Paul Walmsley wrote:
 
 Regarding the watchdog problem, unfortunately, I can't reproduce on the 
 BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
 omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
 .config, one of us can try to reproduce the problem with it.  Do the 
 2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?

I've been seeing this on my omap4 panda. While debugging it, I left
u-boot console only running for a few minutes to see if that stays up.
It did.. And after doing that somehow now my panda boots all the way
and stays up. Weird.

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: State of LDP3430 platform

2010-12-07 Thread Russell King - ARM Linux 
On Mon, Dec 06, 2010 at 11:27:45AM -0700, Paul Walmsley wrote:
 On Mon, 6 Dec 2010, Tony Lindgren wrote:
 
  * Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:
  
   NET: Registered protocol family 16
   [ cut here ]
   WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
   _omap_hwmod_enable+0x34/0x114()
   omap_hwmod: wd_timer2: enabled state can only be entered from 
   initialized, idle, or disabled state
   Modules linked in:
   ---[ end trace 1b75b31a2719ed1c ]---
   wd_timer2: Could not enable clocks for omap2_disable_wdt
  
  Can you check if these patches posted by Paul earlier help?
  
  OMAP: wd_timer: update integration code to use new hwmod change
  https://patchwork.kernel.org/patch/327472/
  
  OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
  https://patchwork.kernel.org/patch/327492/
  
  OMAP: wd_timer: remove old, dead probing code
  https://patchwork.kernel.org/patch/327482/
 
 Just FYI, those will need this series (OMAP2+: hwmod core upgrades 
 for 2.6.38: first set) applied first:
 
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38632.html

So LDP will remain unusable until after the 2.6.38 merge window?
--
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: State of LDP3430 platform

2010-12-07 Thread Paul Walmsley 
On Tue, 7 Dec 2010, Russell King - ARM Linux wrote:

 So LDP will remain unusable until after the 2.6.38 merge window?

I don't think that Tony or I realized that LDP3430 was broken until your 
E-mail.  Usually I use a BeagleBoard 35xx for OMAP3430 testing, and I 
think Tony uses an Overo.  The BeagleBoard boots cleanly with v2.6.37-rc5.

I do have a LDP3430 here though.  It doesn't boot past:

[0.00] Linux version 2.6.37-rc5 (p...@twilight) (gcc version 4.3.2 
(Sourcery G++ Lite 2008q3-72) ) #68 SMP Tue Dec 7 17:42:20
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction 
cache
[0.00] Machine: OMAP Zoom2 board
[0.00] debug: ignoring loglevel setting.
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1

Looking into it now.


- 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: State of LDP3430 platform

2010-12-07 Thread Paul Walmsley 
On Tue, 7 Dec 2010, Paul Walmsley wrote:

 I do have a LDP3430 here though.  It doesn't boot past:
 
 [0.00] Linux version 2.6.37-rc5 (p...@twilight) (gcc version 4.3.2 
 (Sourcery G++ Lite 2008q3-72) ) #68 SMP Tue Dec 7 17:42:20
 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
 [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction 
 cache
 [0.00] Machine: OMAP Zoom2 board
 [0.00] debug: ignoring loglevel setting.
 [0.00] bootconsole [earlycon0] enabled
 [0.00] Memory policy: ECC disabled, Data cache writeback
 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
 [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1
 
 Looking into it now.

My Zoom2 dies in the memset() in omap2_map_sram().  Not sure why, since 
yours seems to make it quite a bit further.  It dies in the same place 
with 2.6.36.  The Zoom2 here may be broken; it does not receive regular 
use.

Regarding the watchdog problem, unfortunately, I can't reproduce on the 
BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or 
omap2plus_defconfig without CONFIG_WATCHDOG.  If you send along your 
.config, one of us can try to reproduce the problem with it.  Do the 
2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?


- 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: State of LDP3430 platform

2010-12-06 Thread Tony Lindgren 
* Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:

 [ cut here ]
 WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
 _omap_hwmod_enable+0x34/0x114()
 omap_hwmod: wd_timer2: enabled state can only be entered from initialized, 
 idle, or disabled state
 Modules linked in:
 ---[ end trace 1b75b31a2719ed1c ]---
 wd_timer2: Could not enable clocks for omap2_disable_wdt

It seems like there's a problem handling a watchdog that's enabled
in the bootloader.. But that's not the only problem, looks like I'm
getting this on overo:

omap_device: omap_wdt.-1: new worst case activate latency 0: 122070
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
omap_device: omap_wdt.-1: new worst case deactivate latency 0: 30517
twl4030_wdt twl4030_wdt: Failed to register misc device
twl4030_wdt: probe of twl4030_wdt failed with error -16

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: State of LDP3430 platform

2010-12-06 Thread Russell King - ARM Linux 
On Mon, Dec 06, 2010 at 07:59:59AM -0800, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:
 
  [ cut here ]
  WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
  _omap_hwmod_enable+0x34/0x114()
  omap_hwmod: wd_timer2: enabled state can only be entered from initialized, 
  idle, or disabled state
  Modules linked in:
  ---[ end trace 1b75b31a2719ed1c ]---
  wd_timer2: Could not enable clocks for omap2_disable_wdt
 
 It seems like there's a problem handling a watchdog that's enabled
 in the bootloader.. But that's not the only problem, looks like I'm
 getting this on overo:
 
 omap_device: omap_wdt.-1: new worst case activate latency 0: 122070
 OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
 omap_device: omap_wdt.-1: new worst case deactivate latency 0: 30517
 twl4030_wdt twl4030_wdt: Failed to register misc device
 twl4030_wdt: probe of twl4030_wdt failed with error -16

-16 = -EBUSY, which is probably because you have two watchdogs.  The
watchdog subsystem has one minor device number, so you can only have
one watchdog registered.
--
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: State of LDP3430 platform

2010-12-06 Thread Tony Lindgren 
* Russell King - ARM Linux li...@arm.linux.org.uk [101206 09:12]:
 On Mon, Dec 06, 2010 at 07:59:59AM -0800, Tony Lindgren wrote:
  * Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:
  
   [ cut here ]
   WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
   _omap_hwmod_enable+0x34/0x114()
   omap_hwmod: wd_timer2: enabled state can only be entered from 
   initialized, idle, or disabled state
   Modules linked in:
   ---[ end trace 1b75b31a2719ed1c ]---
   wd_timer2: Could not enable clocks for omap2_disable_wdt
  
  It seems like there's a problem handling a watchdog that's enabled
  in the bootloader.. But that's not the only problem, looks like I'm
  getting this on overo:
  
  omap_device: omap_wdt.-1: new worst case activate latency 0: 122070
  OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
  omap_device: omap_wdt.-1: new worst case deactivate latency 0: 30517
  twl4030_wdt twl4030_wdt: Failed to register misc device
  twl4030_wdt: probe of twl4030_wdt failed with error -16
 
 -16 = -EBUSY, which is probably because you have two watchdogs.  The
 watchdog subsystem has one minor device number, so you can only have
 one watchdog registered.

Yeah that's it. Looks like omap2plus_defconfig has:

CONFIG_WATCHDOG=y
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y

Any external watchdog(s) should be set up to be secondary watchdogs
kicked by the omap watchdog as discussed earlier.

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: State of LDP3430 platform

2010-12-06 Thread Tony Lindgren 
* Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:

 NET: Registered protocol family 16
 [ cut here ]
 WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
 _omap_hwmod_enable+0x34/0x114()
 omap_hwmod: wd_timer2: enabled state can only be entered from initialized, 
 idle, or disabled state
 Modules linked in:
 ---[ end trace 1b75b31a2719ed1c ]---
 wd_timer2: Could not enable clocks for omap2_disable_wdt

Can you check if these patches posted by Paul earlier help?

OMAP: wd_timer: update integration code to use new hwmod change
https://patchwork.kernel.org/patch/327472/

OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
https://patchwork.kernel.org/patch/327492/

OMAP: wd_timer: remove old, dead probing code
https://patchwork.kernel.org/patch/327482/

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: State of LDP3430 platform

2010-12-06 Thread Paul Walmsley 
On Mon, 6 Dec 2010, Tony Lindgren wrote:

 * Russell King - ARM Linux li...@arm.linux.org.uk [101206 04:45]:
 
  NET: Registered protocol family 16
  [ cut here ]
  WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185 
  _omap_hwmod_enable+0x34/0x114()
  omap_hwmod: wd_timer2: enabled state can only be entered from initialized, 
  idle, or disabled state
  Modules linked in:
  ---[ end trace 1b75b31a2719ed1c ]---
  wd_timer2: Could not enable clocks for omap2_disable_wdt
 
 Can you check if these patches posted by Paul earlier help?
 
 OMAP: wd_timer: update integration code to use new hwmod change
 https://patchwork.kernel.org/patch/327472/
 
 OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
 https://patchwork.kernel.org/patch/327492/
 
 OMAP: wd_timer: remove old, dead probing code
 https://patchwork.kernel.org/patch/327482/

Just FYI, those will need this series (OMAP2+: hwmod core upgrades 
for 2.6.38: first set) applied first:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38632.html


- 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