Tomeu,
On Wed, Jan 27, 2016 at 2:20 AM, Tomeu Vizoso wrote:
> On 26 January 2016 at 17:32, Doug Anderson wrote:
>> Tomeu,
>>
>> On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
>>> On 22 January 2016 at 18:07, Doug Anderson wrote:
Tomeu,
On Fri, Jan 22, 2016 at 6:00 AM,
On 26 January 2016 at 17:32, Doug Anderson wrote:
> Tomeu,
>
> On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
>> On 22 January 2016 at 18:07, Doug Anderson wrote:
>>> Tomeu,
>>>
>>> On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
On 21 January 2016 at 21:11, Doug Anderson
Tomeu,
On Wed, Jan 27, 2016 at 2:20 AM, Tomeu Vizoso wrote:
> On 26 January 2016 at 17:32, Doug Anderson wrote:
>> Tomeu,
>>
>> On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
>>> On 22 January 2016 at 18:07, Doug
On 26 January 2016 at 17:32, Doug Anderson wrote:
> Tomeu,
>
> On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
>> On 22 January 2016 at 18:07, Doug Anderson wrote:
>>> Tomeu,
>>>
>>> On Fri, Jan 22, 2016 at 6:00 AM,
Tomeu,
On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
> On 22 January 2016 at 18:07, Doug Anderson wrote:
>> Tomeu,
>>
>> On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
>>> On 21 January 2016 at 21:11, Doug Anderson wrote:
Hi,
On Thu, Jan 21, 2016 at 1:03 AM, Tomeu
On 22 January 2016 at 18:07, Doug Anderson wrote:
> Tomeu,
>
> On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
>> On 21 January 2016 at 21:11, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
So we have a mechanism for detecting a conflict in
On 22 January 2016 at 18:07, Doug Anderson wrote:
> Tomeu,
>
> On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
>> On 21 January 2016 at 21:11, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu
Tomeu,
On Tue, Jan 26, 2016 at 12:28 AM, Tomeu Vizoso wrote:
> On 22 January 2016 at 18:07, Doug Anderson wrote:
>> Tomeu,
>>
>> On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
>>> On 21 January 2016 at 21:11, Doug
Tomeu,
On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
> On 21 January 2016 at 21:11, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
>>> So we have a mechanism for detecting a conflict in the clock
>>> hierarchy, and a mechanism to solve it, but we
On 21 January 2016 at 21:11, Doug Anderson wrote:
> Hi,
>
> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
>> So we have a mechanism for detecting a conflict in the clock
>> hierarchy, and a mechanism to solve it, but we are missing a way for
>> userspace to communicate policy regarding
Tomeu,
On Fri, Jan 22, 2016 at 6:00 AM, Tomeu Vizoso wrote:
> On 21 January 2016 at 21:11, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
>>> So we have a mechanism for detecting a
On 21 January 2016 at 21:11, Doug Anderson wrote:
> Hi,
>
> On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
>> So we have a mechanism for detecting a conflict in the clock
>> hierarchy, and a mechanism to solve it, but we are missing a way for
Hi,
On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
> So we have a mechanism for detecting a conflict in the clock
> hierarchy, and a mechanism to solve it, but we are missing a way for
> userspace to communicate policy regarding which clocks should be given
> priority when solving such a
On 20 January 2016 at 17:50, Doug Anderson wrote:
> Tomeu,
>
> On Tue, Jan 19, 2016 at 4:02 AM, Tomeu Vizoso wrote:
>> On 13 November 2014 at 23:59, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang
>>> wrote:
Hi Heiko,
On 11/07/2014 05:06 AM,
On 20 January 2016 at 17:50, Doug Anderson wrote:
> Tomeu,
>
> On Tue, Jan 19, 2016 at 4:02 AM, Tomeu Vizoso wrote:
>> On 13 November 2014 at 23:59, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Nov 13, 2014 at 12:52 AM, Kever
Hi,
On Thu, Jan 21, 2016 at 1:03 AM, Tomeu Vizoso wrote:
> So we have a mechanism for detecting a conflict in the clock
> hierarchy, and a mechanism to solve it, but we are missing a way for
> userspace to communicate policy regarding which clocks should be given
>
Tomeu,
On Tue, Jan 19, 2016 at 4:02 AM, Tomeu Vizoso wrote:
> On 13 November 2014 at 23:59, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang
>> wrote:
>>> Hi Heiko,
>>>
>>> On 11/07/2014 05:06 AM, Heiko Stübner wrote:
Hi Kever,
Am Dienstag, 4.
Tomeu,
On Tue, Jan 19, 2016 at 4:02 AM, Tomeu Vizoso wrote:
> On 13 November 2014 at 23:59, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang
>> wrote:
>>> Hi Heiko,
>>>
>>> On 11/07/2014
Hi
On 11/14/2014 09:46 AM, Mike Turquette wrote:
Looking through the clock-tree there are a lot more components possibly
> >>using
> >>(or wanting to use) the npll: of course the VOPs, the edp, hdmi, isp,
> >>hevc,
> >>gpu, tsp uart0 and gmac. So I'm slightly uncomfortable with somehow
>
Hi
On 11/14/2014 09:46 AM, Mike Turquette wrote:
Looking through the clock-tree there are a lot more components possibly
using
(or wanting to use) the npll: of course the VOPs, the edp, hdmi, isp,
hevc,
gpu, tsp uart0 and gmac. So I'm slightly uncomfortable with somehow
reserving
the npll
Hi,
On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang wrote:
> Hi Heiko,
>
> On 11/07/2014 05:06 AM, Heiko Stübner wrote:
>>
>> Hi Kever,
>>
>> Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
>>>
>>> we are going to make a clock usage solution for rk3288:
>>> 1. CPLL and GPLL always not
Hi Heiko,
On 11/07/2014 05:06 AM, Heiko Stübner wrote:
Hi Kever,
Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always not change after assign init;
2. NPLL default as 500MHz, may used for most scene;
3.
Hi Heiko,
On 11/07/2014 05:06 AM, Heiko Stübner wrote:
Hi Kever,
Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always not change after assign init;
2. NPLL default as 500MHz, may used for most scene;
3.
Hi,
On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang kever.y...@rock-chips.com wrote:
Hi Heiko,
On 11/07/2014 05:06 AM, Heiko Stübner wrote:
Hi Kever,
Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always
Hi Kever,
Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
> we are going to make a clock usage solution for rk3288:
> 1. CPLL and GPLL always not change after assign init;
> 2. NPLL default as 500MHz, may used for most scene;
> 3. NPLL may be changed by VOP(HDMI) clock for some
Hi Kever,
Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always not change after assign init;
2. NPLL default as 500MHz, may used for most scene;
3. NPLL may be changed by VOP(HDMI) clock for some special
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always not change after assign init;
2. NPLL default as 500MHz, may used for most scene;
3. NPLL may be changed by VOP(HDMI) clock for some special
frequency requirement.
I test it with rk3288 evb on top of Heiko's
we are going to make a clock usage solution for rk3288:
1. CPLL and GPLL always not change after assign init;
2. NPLL default as 500MHz, may used for most scene;
3. NPLL may be changed by VOP(HDMI) clock for some special
frequency requirement.
I test it with rk3288 evb on top of Heiko's
28 matches
Mail list logo