Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rajendra,

On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
> Hi,
> 
> This RFC series is based of Mikes' latest clk-next. I will
> rebase it once 3.5-rc1 is out and post with more testing thats
> in progress. Meanwhile, the RFC is for me to get some early
> feedback on the patches.
> 
> This series retains the static clock declarations and also
> all data and code in mach-omap folders and does not move
> it as yet to drivers/clk. I know its desierable that we move
> away from static declaration of data and move over to drivers/clk
> but thats not addressed by this series.
> Also the series moves over only OMAP2+ (OMAP2/3/4)
> to use COMMON clk and leaves OMAP1 still using OMAP
> clock framework.
> 
> The series does not break git-bisect at any point and to
> do so adds new data in completely different files and uses
> some ifdefferry in code too, and switches over in one
> patch to move from OMAP clock to COMMON clock. Then deletes
> all old data files and all the ifdeferrey around.
> 
> All of the new data for OMAP2/3/4 in the new COMMON clock
> format is autogenerated, OMAP4 by hacking the existing python
> scripts, and OMAP2/3 by converting the existing C99 structs
> to JSON format (Thanks to Paul Walmsley for this) and then having
> python to read the JSON format and generate the C99 structs
> back in the form COMMON clk expects.
> 
> The patches also depend on 2 of my patches posted here
> http://comments.gmane.org/gmane.linux.kernel/1298747
> I have not reposted them becasue one of them is already
> picked up by Mike, and the other is already under discussion.
> 
> The series with all dependent patches can be found here
> git://github.com/rrnayak/linux.git clk-next-omap
> 
> regards,
> Rajendra
> 
> Mike Turquette (1):
>   ARM: omap4: cm: add bitfield width values
> 
> Rajendra Nayak (23):
>   clk: Add CLK_IS_BASIC flag to identify basic clocks
>   ARM: omap: clk: convert all clk_enable to clk_prepare_enable
>   ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
>   ARM: omap: clk: Nuke plat clock.c & clock.h if CONFIG_COMMON_CLK
>   ARM: omap: clk: Remove all direct dereferncing of struct clk
>   ARM: omap: hwmod: Fix up hwmod based clkdm accesses
>   ARM: omap4: clk: Convert to common clk
>   ARM: omap3: clk: Convert to common clk
>   ARM: omap2: clk: Convert to common clk
>   ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle
>   ARM: omap: clk: Define a function to enable clocks at init
>   ARM: omap4: clk: Add 44xx data using common struct clk
>   ARM: omap3: clk: Add 3xxx data using common struct clk
>   ARM: omap2: clk: Add 24xx data using common struct clk
>   ARM: omap: clk: Switch to COMMON clk
>   ARM: omap: clk: Use plat clock.c & clock.h only for OMAP1

With regard to the above patch, I am not sure why it is necessary to
move the existing definitions out of plat-omap/clock.h to put in
mach-omap2/clock.h. Eventually, if we move omap1 to the common clock
framework, won't we need to move them back? It would seem to me that by
keeping them in plat clock.h it will be easier to migrate omap1 to the
common clock framework (assuming thats our goal). Also, by adding the
common clock definitions to the plat clock.h it will be easier for
migrating omap1 too.

Obviously, we would need to keep the #ifdef COMMON_CLK around this code
so it can compile for both omap1 and omap2+ today.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux