RE: [PATCH v5 0/12] dmtimer adaptation to platform_driver

2010-12-14 Thread DebBarma, Tarun Kanti
Kevin,
 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Wednesday, December 15, 2010 7:37 AM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH v5 0/12] dmtimer adaptation to platform_driver
 
 Tarun Kanti DebBarma tarun.ka...@ti.com writes:
 
  dmtimer adaptation to platform_driver.
 
  This patch series is adaptation of dmtimer code to platform driver
  using omap_device and omap_hwmod abstraction.
 
  Tested on following platforms:
  OMAP4430, OMAP3430, OMAP3630, OMAP2430
  OMAP2420 -- Image with omap2plus_defconfig in too large to download on
 N800.
 
 And OMAP1?
BTW, I have posted v6 yesterday and in that for testing on N800
I have removed OMAP3 and OMAP4 options and I was able to download.

Coming to OMAP1, I am getting Bad Magic Number while download.
Looks like there is problem in selecting the right platform info.
I am trying to resolve this and test.
--
Tarun

 
 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 v5 0/12] dmtimer adaptation to platform_driver

2010-12-13 Thread Kevin Hilman
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

 On Tue, Dec 07, 2010 at 05:14:07AM +0530, Tarun Kanti DebBarma wrote:
  dmtimer adaptation to platform_driver.
 
  This patch series is adaptation of dmtimer code to platform driver
  using omap_device and omap_hwmod abstraction.
 
  Tested on following platforms:
  OMAP4430, OMAP3430, OMAP3630, OMAP2430
  OMAP2420 -- Image with omap2plus_defconfig in too large to download on
 N800.
 
 How about omap1? The mainline code happily compiles and boots on osk5912
 but this series is going to break omap1 build.

 I have built and booted on OMAP1 during v3. This time I could not because
 My OMAP1710 has gone bad. I am looking for one to test.
 That's precisely the reason I have not mentioned OMAP1. 

Rather than not mentioning OMAP1, you should state whether (or not) it
was tested on OMAP1.   As build/boot testing on OMAP1 is a requirement
for merge, this information is crucial.

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 v5 0/12] dmtimer adaptation to platform_driver

2010-12-13 Thread Paul Walmsley
On Tue, 7 Dec 2010, Tarun Kanti DebBarma wrote:

 Tested on following platforms:
 OMAP4430, OMAP3430, OMAP3630, OMAP2430
 OMAP2420 -- Image with omap2plus_defconfig in too large to download on N800.

Just build a minimal N800 config for testing.  It's really quite easy.  
Use 'make menuconfig' and then you can remove lots of unnecessary stuff.


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


[PATCH v5 0/12] dmtimer adaptation to platform_driver

2010-12-06 Thread Tarun Kanti DebBarma
dmtimer adaptation to platform_driver.

This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.

Tested on following platforms:
OMAP4430, OMAP3430, OMAP3630, OMAP2430
OMAP2420 -- Image with omap2plus_defconfig in too large to download on N800.

Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

v5:
(1) In mach-omap2/dmtimer.c the two different init functions are merged
into a single one, viz: omap_timer_init(*oh, *user). Now this function is
used both during early init and later. The distinction between the two is
made by the *user field.

(2) Added timeout to low-level access routines in place of infinite while
loop which waits on write-pend register bit.

(3) Modified devices names from omap-timer.x to omap_timer.x

(4) Modified module description from OMAP DUAL MODE TIMER DRIVER to:
MODULE_DESCRIPTION(OMAP Dual-Mode Timer Driver);

(5) Use well-defined constants for new IP revision register constants instead
of hard-coded values.

(6) Use consistent naming mechanism by using _dm_timer_ instead of _dmtimer_
wherever applicable.

(7) Removed id field from omap_dm_timer{} since the same can be obtained from
pdev.

(8) clk_get() and clk_put() moved from probe() and remove() functions.
Now clk_get() is called when timer is acquired in the omap_dm_timer_prepare()
and clk_put() is called in omap_dm_timer_free().

(9) Modified the device name in mach-omap1/dmtimer.c to omap_timer

(10) Incorporated general comments:
(i) Redundant Copyright information.
(ii) Typos in comments.
(iii) Modify subjects for hwmod database related patches.
(iv) Remove redundant comments from hwmod database as they would be lost during
auto-generation in the future.
(v) replaced dev_dbg() with dev_err() wherever error condition is printed.

TODO:
(1) OFF Mode support

(2) Upgrade timeout implementation in low-level read/write access to return
error condition to EXPORT APIs. This is re-frained in the present implementation
because that would involve change to EXPORTED APIs. Besides, there is no clear
design as yet which is agreed upon by the community.

(3) Try to get rid of dmtimer list maintained separately in the driver. Instead
use the device list maintained by the device model. The devices can be accessed
using available API driver_find_device().

At present we are unable to use driver_find_device() because it does not look
into device list which is created during early boot.
Therefore, until suitable solutions are found we have to wait.

v4:
(1) clock aliases are renamed as 32k_ck, sys_ck and alt_ck
(2) incorporate missing clk_put() for corresponding clk_get()
(3) modified clk_get()/clk_put() to be called once once in platform driver.
(4) consistent header for new files
(5) check return value of omap_hwmod_for_each_by_class() in device init
routines.
(6) remove is_abe_timer field in dmtimer_platform_data structure. this is
no longer needed with new input clock source aliasing.
(7) proper splitting of patch series
(8) remove register map from hwmod database.
(9) remove clock source strings array from hwmod database and associated
structure declaration from plat/dmtimer.h. this is no longer needed.
(10) remove dev_attr from hwmod database. this is no longer needed.
(11) use register offsets to identify OMAP 4 registers instead of register map.
(12) remove clock source name strings from hwmod database.
(13) introduce new mechanism for getting struct clk associated with clock source
names. this is achieved by adding clock alisases for all supported clock 
sources.
(14) remove clock setup functions in mach-omap2 for populating struct clk
associated with all input clock sources because this is no longer needed with
above implementation.
(15) device names changed from dmtimer to omap-timer
(16) device index starts from 1 instead of 0
(17) remove .init_name from hwmod database. this is not needed.
(18) introduce separate functions for reading/writing interrupt registers 
instead of
doing all operations within a single function.

v3:
(1) multi-line comment error correction
(2) provision to allow any of the available dmtimers as early timers
instead of restricting them to millisecond timers only.
(3) in 'struct omap_dmtimer{}' is_initialized flag is redundant and
so must be removed. if the element is found in the list it is already
initialized.
(4) remove 'found' flag in omap_dm_timer_request() and
omap_dm_timer_request_specific() functions.
this is not needed with alternate implementation.
(5) use .init_name to initialize device names so that it can be identified
during early boot as well. This is to avoid duplicate functions for clock
manipulations during early boot and later.
(6) remove redundant functions from mach-omap2 which are created just to
call pm functions like: pm_runtime_get_sync(),pm_runtime_put_sync(),..
and instead call them directly from plat-omap function api's.
(7) timer clock source names made part of hwmod database. source_clock[]
of 

Re: [PATCH v5 0/12] dmtimer adaptation to platform_driver

2010-12-06 Thread G, Manjunath Kondaiah
On Tue, Dec 07, 2010 at 05:14:07AM +0530, Tarun Kanti DebBarma wrote:
 dmtimer adaptation to platform_driver.
 
 This patch series is adaptation of dmtimer code to platform driver
 using omap_device and omap_hwmod abstraction.
 
 Tested on following platforms:
 OMAP4430, OMAP3430, OMAP3630, OMAP2430
 OMAP2420 -- Image with omap2plus_defconfig in too large to download on N800.

How about omap1? The mainline code happily compiles and boots on osk5912
but this series is going to break omap1 build.

As per Tony's comments for GPIO and DMA hwmod, the changes should build and
boot for omap1 also.

-Manjunath

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


RE: [PATCH v5 0/12] dmtimer adaptation to platform_driver

2010-12-06 Thread DebBarma, Tarun Kanti
 -Original Message-
 From: G, Manjunath Kondaiah [mailto:manj...@ti.com]
 Sent: Monday, December 06, 2010 9:59 PM
 To: DebBarma, Tarun Kanti
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH v5 0/12] dmtimer adaptation to platform_driver
 
 On Tue, Dec 07, 2010 at 05:14:07AM +0530, Tarun Kanti DebBarma wrote:
  dmtimer adaptation to platform_driver.
 
  This patch series is adaptation of dmtimer code to platform driver
  using omap_device and omap_hwmod abstraction.
 
  Tested on following platforms:
  OMAP4430, OMAP3430, OMAP3630, OMAP2430
  OMAP2420 -- Image with omap2plus_defconfig in too large to download on
 N800.
 
 How about omap1? The mainline code happily compiles and boots on osk5912
 but this series is going to break omap1 build.
I have built and booted on OMAP1 during v3. This time I could not because
My OMAP1710 has gone bad. I am looking for one to test.
That's precisely the reason I have not mentioned OMAP1. 

 
 As per Tony's comments for GPIO and DMA hwmod, the changes should build
 and
 boot for omap1 also.
Yes, I guess this is quite understood. Thanks anyways.

--
Tarun

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