All of lore.kernel.org
 help / color / mirror / Atom feed
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only
Date: Wed, 14 Jan 2015 14:16:15 -0800	[thread overview]
Message-ID: <20150114221615.22722.24878@quantum> (raw)
In-Reply-To: <3353483.Eif0pChkY5@phil>

Quoting Heiko St?bner (2015-01-08 14:30:01)
> Hi Kever,
> 
> Am Montag, 17. November 2014, 22:55:36 schrieb Kever Yang:
> > To support all kinds of frequency requirement for HDMI on rk3288,
> > we need a PLL that can change rate at run time.
> > 
> > There are some discussion before at [0], I think we can just leave
> > the npll for HDMI(DCLK_VOP0) used to make it simple.
> > 
> > Comments are welcome.
> 
> I think I said it in private somewhere already, but just so it's also 
> available publically:
> 
> I don't think customizing/limiting the clock usage like this will fly, 
> especially as this would require each and every rk3288 board to use vop0 for 
> hdmi and vop1 for other stuff.
> 
> With the new rk3288 Firefly devboard this concern already becomes reality. 
> There a vga converter is connected to VOP0, which leaves only vop1 for hdmi if 
> one wants to support the vga connection.
> 
> 
> From our discussion about this problem I remember that the missing clock 
> frequencies only affected more esotheric screen resolutions, so personally I'm 
> not this much concerned an would like to wait till we find a better solution to 
> the problem.

Ack. We shouldn't have to limit the possible hardware configurations in
software just to keep things simple. This points to a deficiency in the
clock framework. This is a common concern: how to change a clock
frequency for one user without exploding all of the other users.

Do you think Tomeu's constraints API[0] might be a step in the right
direction for you?

[0] http://lkml.kernel.org/r/<1421071809-17402-3-git-send-email-tomeu.vizoso@collabora.com>

Regards,
Mike

> 
> 
> Heiko

WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Kever Yang" <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
Cc: sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	dkl-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org,
	sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Dmitry Torokhov <dtor-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Jianqun <jay.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Chris Zhong <zyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only
Date: Wed, 14 Jan 2015 14:16:15 -0800	[thread overview]
Message-ID: <20150114221615.22722.24878@quantum> (raw)
In-Reply-To: <3353483.Eif0pChkY5@phil>

Quoting Heiko Stübner (2015-01-08 14:30:01)
> Hi Kever,
> 
> Am Montag, 17. November 2014, 22:55:36 schrieb Kever Yang:
> > To support all kinds of frequency requirement for HDMI on rk3288,
> > we need a PLL that can change rate at run time.
> > 
> > There are some discussion before at [0], I think we can just leave
> > the npll for HDMI(DCLK_VOP0) used to make it simple.
> > 
> > Comments are welcome.
> 
> I think I said it in private somewhere already, but just so it's also 
> available publically:
> 
> I don't think customizing/limiting the clock usage like this will fly, 
> especially as this would require each and every rk3288 board to use vop0 for 
> hdmi and vop1 for other stuff.
> 
> With the new rk3288 Firefly devboard this concern already becomes reality. 
> There a vga converter is connected to VOP0, which leaves only vop1 for hdmi if 
> one wants to support the vga connection.
> 
> 
> From our discussion about this problem I remember that the missing clock 
> frequencies only affected more esotheric screen resolutions, so personally I'm 
> not this much concerned an would like to wait till we find a better solution to 
> the problem.

Ack. We shouldn't have to limit the possible hardware configurations in
software just to keep things simple. This points to a deficiency in the
clock framework. This is a common concern: how to change a clock
frequency for one user without exploding all of the other users.

Do you think Tomeu's constraints API[0] might be a step in the right
direction for you?

[0] http://lkml.kernel.org/r/<1421071809-17402-3-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

Regards,
Mike

> 
> 
> Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette@linaro.org>
To: "Heiko Stübner" <heiko@sntech.de>,
	"Kever Yang" <kever.yang@rock-chips.com>,
	dianders@chromium.org
Cc: sonnyrao@chromium.org, addy.ke@rock-chips.com, cf@rock-chips.com,
	dkl@rock-chips.com, huangtao@rock-chips.com,
	linux-rockchip@lists.infradead.org, tomeu.vizoso@collabora.com,
	sboyd@codeaurora.org,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	devicetree@vger.kernel.org, "Dmitry Torokhov" <dtor@chromium.org>,
	linux-kernel@vger.kernel.org, "Kumar Gala" <galak@codeaurora.org>,
	"Jianqun" <jay.xu@rock-chips.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Chris Zhong" <zyw@rock-chips.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Russell King" <linux@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only
Date: Wed, 14 Jan 2015 14:16:15 -0800	[thread overview]
Message-ID: <20150114221615.22722.24878@quantum> (raw)
In-Reply-To: <3353483.Eif0pChkY5@phil>

Quoting Heiko Stübner (2015-01-08 14:30:01)
> Hi Kever,
> 
> Am Montag, 17. November 2014, 22:55:36 schrieb Kever Yang:
> > To support all kinds of frequency requirement for HDMI on rk3288,
> > we need a PLL that can change rate at run time.
> > 
> > There are some discussion before at [0], I think we can just leave
> > the npll for HDMI(DCLK_VOP0) used to make it simple.
> > 
> > Comments are welcome.
> 
> I think I said it in private somewhere already, but just so it's also 
> available publically:
> 
> I don't think customizing/limiting the clock usage like this will fly, 
> especially as this would require each and every rk3288 board to use vop0 for 
> hdmi and vop1 for other stuff.
> 
> With the new rk3288 Firefly devboard this concern already becomes reality. 
> There a vga converter is connected to VOP0, which leaves only vop1 for hdmi if 
> one wants to support the vga connection.
> 
> 
> From our discussion about this problem I remember that the missing clock 
> frequencies only affected more esotheric screen resolutions, so personally I'm 
> not this much concerned an would like to wait till we find a better solution to 
> the problem.

Ack. We shouldn't have to limit the possible hardware configurations in
software just to keep things simple. This points to a deficiency in the
clock framework. This is a common concern: how to change a clock
frequency for one user without exploding all of the other users.

Do you think Tomeu's constraints API[0] might be a step in the right
direction for you?

[0] http://lkml.kernel.org/r/<1421071809-17402-3-git-send-email-tomeu.vizoso@collabora.com>

Regards,
Mike

> 
> 
> Heiko

  reply	other threads:[~2015-01-14 22:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 14:55 [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only Kever Yang
2014-11-17 14:55 ` Kever Yang
2014-11-17 14:55 ` Kever Yang
2014-11-17 14:55 ` [RFC PATCH 1/2] clk: rockchip: leave npll for VOP0 only Kever Yang
2014-11-17 14:55   ` Kever Yang
2014-11-17 14:55 ` [RFC PATCH 2/2] arm: dts: rockchip: select npll as parent of DCLK_VOP0 Kever Yang
2014-11-17 14:55   ` Kever Yang
2015-01-08 22:30 ` [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only Heiko Stübner
2015-01-08 22:30   ` Heiko Stübner
2015-01-08 22:30   ` Heiko Stübner
2015-01-14 22:16   ` Mike Turquette [this message]
2015-01-14 22:16     ` Mike Turquette
2015-01-14 22:16     ` Mike Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150114221615.22722.24878@quantum \
    --to=mturquette@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.