COMMON_CLK has been a bool value, selected by the platforms who need
common clock framework. If a CCF driver is needed on an add-on device
such as PCIe card, COMMON_CLK can be selected individually as a
tristate value.
Signed-off-by: York Sun <[email protected]>
CC: Paul Bolle <[email protected]>
CC: Mike Turquette <[email protected]>
---
drivers/clk/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 32b2219..07f0b2f 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -10,7 +10,7 @@ config HAVE_MACH_CLKDEV
bool
config COMMON_CLK
- bool
+ tristate "Common Clock"
select HAVE_CLK_PREPARE
select CLKDEV_LOOKUP
select SRCU
--
1.7.9.5
On Wed, Jun 17, 2015 at 12:01:47PM -0700, York Sun wrote:
> COMMON_CLK has been a bool value, selected by the platforms who need
> common clock framework. If a CCF driver is needed on an add-on device
> such as PCIe card, COMMON_CLK can be selected individually as a
> tristate value.
>
> Signed-off-by: York Sun <[email protected]>
> CC: Paul Bolle <[email protected]>
> CC: Mike Turquette <[email protected]>
Why do you CC the I2C list for clk patches??
On 06/17/2015 12:05 PM, Wolfram Sang wrote:
> On Wed, Jun 17, 2015 at 12:01:47PM -0700, York Sun wrote:
>> COMMON_CLK has been a bool value, selected by the platforms who need
>> common clock framework. If a CCF driver is needed on an add-on device
>> such as PCIe card, COMMON_CLK can be selected individually as a
>> tristate value.
>>
>> Signed-off-by: York Sun <[email protected]>
>> CC: Paul Bolle <[email protected]>
>> CC: Mike Turquette <[email protected]>
>
> Why do you CC the I2C list for clk patches??
>
My apology for CC the wrong list.
It was firstly introduced in this patch http://patchwork.ozlabs.org/patch/485088/.
York
Drop linux-i2c mailing list.
Michael/Paul,
Please review and tell me if this is a bad idea. I am working on a platform
COMMON_CLK is not enabled. The clock I need is on a PCIe card. I don't think
modify platform Kconfig is right. So modifying drivers/clk/Kconfig seems
reasonable to me.
York
On 06/17/2015 12:01 PM, York Sun wrote:
> COMMON_CLK has been a bool value, selected by the platforms who need
> common clock framework. If a CCF driver is needed on an add-on device
> such as PCIe card, COMMON_CLK can be selected individually as a
> tristate value.
>
> Signed-off-by: York Sun <[email protected]>
> CC: Paul Bolle <[email protected]>
> CC: Mike Turquette <[email protected]>
> ---
> drivers/clk/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 32b2219..07f0b2f 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -10,7 +10,7 @@ config HAVE_MACH_CLKDEV
> bool
>
> config COMMON_CLK
> - bool
> + tristate "Common Clock"
> select HAVE_CLK_PREPARE
> select CLKDEV_LOOKUP
> select SRCU
>
York,
On Wed, 2015-06-17 at 14:20 -0700, York Sun wrote:
> Drop linux-i2c mailing list.
(Looking at MAINTAINERS suggests that, besides Michael, Stephen Boyd and
the linux-clk mailing list actually care about the COMMON CLK
FRAMEWORK.)
> Please review and tell me if this is a bad idea.
You waited less than three hours to ping us. That alone would be enough
for most people to ignore your message.
> I am working on a platform
> COMMON_CLK is not enabled. The clock I need is on a PCIe card. I don't think
> modify platform Kconfig is right. So modifying drivers/clk/Kconfig seems
> reasonable to me.
I have no idea what the problem is with COMMON_CLK for your driver. I
found a long thread (about three weeks ago) concerning this problem.
Apparently no solution was found. That's something you have to figure
out with the people involved with the CCF, I can't help you there.
What I do know is that I told you already, yesterday, that changing
COMMON_CLK to tristate is not needed for what it appears you want to do.
And, more importantly, that it will likely break stuff left and right
without additional changes (which this patch lacks).
Perhaps I was unclear. Ask for clarification if so. Perhaps I was wrong.
Then you're free to correct me. But, please, rate limit your patch
versions. You've sent a version on Monday, Tuesday, and Wednesday. That
mainly will make people to filter out your patches. I won't be looking
at a new version for another week now, sorry.
Thanks,
Paul Bolle
Paul,
Your review comments are very appreciated.
On 06/18/2015 02:18 AM, Paul Bolle wrote:
> York,
>
> On Wed, 2015-06-17 at 14:20 -0700, York Sun wrote:
>> Drop linux-i2c mailing list.
>
> (Looking at MAINTAINERS suggests that, besides Michael, Stephen Boyd and
> the linux-clk mailing list actually care about the COMMON CLK
> FRAMEWORK.)
Great! Thanks for the pointer.
>
>> Please review and tell me if this is a bad idea.
>
> You waited less than three hours to ping us. That alone would be enough
> for most people to ignore your message.
>
>> I am working on a platform
>> COMMON_CLK is not enabled. The clock I need is on a PCIe card. I don't think
>> modify platform Kconfig is right. So modifying drivers/clk/Kconfig seems
>> reasonable to me.
>
> I have no idea what the problem is with COMMON_CLK for your driver. I
> found a long thread (about three weeks ago) concerning this problem.
> Apparently no solution was found. That's something you have to figure
> out with the people involved with the CCF, I can't help you there.
>
> What I do know is that I told you already, yesterday, that changing
> COMMON_CLK to tristate is not needed for what it appears you want to do.
> And, more importantly, that it will likely break stuff left and right
> without additional changes (which this patch lacks).
I will follow up with the right crowd.
>
> Perhaps I was unclear. Ask for clarification if so. Perhaps I was wrong.
> Then you're free to correct me. But, please, rate limit your patch
> versions. You've sent a version on Monday, Tuesday, and Wednesday. That
> mainly will make people to filter out your patches. I won't be looking
> at a new version for another week now, sorry.
That's exactly the reason I separated the Kconfig. This is more generic than the
clock driver I proposed.
Thanks again.
York