Hi Alexey,
On 03-03-2017 19:24, Alexey Brodkin wrote:
>
> Correct. Otherwise we'll get some modes and devices that
> don't work.
>
> Remember our saga with 74.25 vs 74.40 MHz?
>
> With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock
> which satisfy some monitors especially those w
On Fri, Mar 03, 2017 at 06:05:15PM +, Jose Abreu wrote:
> Hi Alexey,
>
>
> On 03-03-2017 13:27, Alexey Brodkin wrote:
> >
> > So if I understood you correct here what I really need is just to get rid
> > of existing check,
> > right? I.e. the following is to be in v2 respin:
> >
Hi Jose,
On Fri, 2017-03-03 at 18:05 +, Jose Abreu wrote:
> Hi Alexey,
>
>
> On 03-03-2017 13:27, Alexey Brodkin wrote:
> >
> >
> > So if I understood you correct here what I really need is just to get rid
> > of existing check,
> > right? I.e. the following is to be in v2 respin:
> > ---
Hi Alexey,
On 03-03-2017 13:27, Alexey Brodkin wrote:
>
> So if I understood you correct here what I really need is just to get rid of
> existing check,
> right? I.e. the following is to be in v2 respin:
> --->8---
> diff --git a/drivers/gp
Hi Daniel,
On Thu, 2017-03-02 at 20:54 +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote:
> >
> > Since we cannot always generate exactly requested pixel clock
> > there's not much sense in checking requested_clock == clk_round_rate().
> > In that case f
On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote:
> Since we cannot always generate exactly requested pixel clock
> there's not much sense in checking requested_clock == clk_round_rate().
> In that case for quite some modes we'll be getting -EINVAL and no video
> output at all.
>
> B
Since we cannot always generate exactly requested pixel clock
there's not much sense in checking requested_clock == clk_round_rate().
In that case for quite some modes we'll be getting -EINVAL and no video
output at all.
But given there's some tolerance to real pixel clock in TVs/monitors
we may s
7 matches
Mail list logo
