On 07/02/13 03:57, Daniel Drake wrote:
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. Yo
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
On 07/01/2013 10:30 PM, Daniel Drake wrote:
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On 07/02/13 03:57, Daniel Drake wrote:
> On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
> wrote:
>> I prefer not to try to find the best clock (source) at all. Let the
>> user pass the clock name by e.g. platform_data (or DT) and just try to
>> get the requested pixclk or a integer multiple
On 07/01/2013 10:30 PM, Daniel Drake wrote:
> Here is a new patch which should incorporate all your previous feedback.
> Now each variant passes clock info to the main driver via a new
> armada_clk_info structure.
>
> A helper function in the core lets each variant find the best clock.
> As you sug
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
> On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
>> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>>>wrote:
Sure... lets add some background info firs
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
>>> completely different registe
On 06/29/2013 05:06 PM, Daniel Drake wrote:
> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
> wrote:
>> Sure... lets add some background info first: the big problem here is the
>> completely different register layouts for the clock register:
>>
>> On Armada 510:
>> 31:30 - select the
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big pr
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big problem here is the
completely different register layouts for the clock register:
On Armada 510:
31:30 - select the clock input fro
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
>>> completely different registe
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
> > + /* check if any clock can meet this r
On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks for pointing me to the most recent version of your driver.
> Can you comment on the below patch for improved clock handling?
Sure... lets add some background info first: the big problem here is the
completely d
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
> > + /* check if any clock can meet this r
On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks for pointing me to the most recent version of your driver.
> Can you comment on the below patch for improved clock handling?
Sure... lets add some background info first: the big problem here is the
completely d
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
26 matches
Mail list logo
