On Sat, Sep 05, 2015 at 06:46:04AM -0700, Doug Anderson wrote:
> Russell,
>
> On Sat, Sep 5, 2015 at 1:31 AM, Russell King - ARM Linux
> wrote:
> > On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> >> AKA: just replace your entire "compute_n" function with:
> >>
> >> return (128 *
Hi,
On Sat, Sep 5, 2015 at 7:01 AM, Russell King - ARM Linux
wrote:
>> If you know the answer, just tell me. If you're talking about 74.25
>> vs. 32 kHz it is further evidence of what I'm saying. Note that
>> picking only one of the two listed CTS values again puts you in a
>> worse position fo
On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> Then perhaps you shouldn't be using a switch statement. You won't
> catch all values that are within .05% of (25.2 / 1.001).
No.
The clock rates you get ultimately come from the EDID via either the
detailed timing modes or from the
On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> AKA: just replace your entire "compute_n" function with:
>
> return (128 * freq) / 1000;
>
> ...and it's 100% simpler _and_ gets you a (marginally) better rate
> (assuming you really have 22.175000). If it was just about a
> 32000.
Russell,
On Sat, Sep 5, 2015 at 1:34 AM, Russell King - ARM Linux
wrote:
> On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
>> Then perhaps you shouldn't be using a switch statement. You won't
>> catch all values that are within .05% of (25.2 / 1.001).
>
> No.
>
> The clock rates y
Russell,
On Sat, Sep 5, 2015 at 1:31 AM, Russell King - ARM Linux
wrote:
> On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
>> AKA: just replace your entire "compute_n" function with:
>>
>> return (128 * freq) / 1000;
>>
>> ...and it's 100% simpler _and_ gets you a (marginally) bett
On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
> Russell,
>
> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
> wrote:
> >> In your case you're probably making the value that Linux
> >> asked you to make, AKA 25.175000 MHz.
> >
> > ... which is the spec value.
>
> This i
On Fri, Sep 04, 2015 at 12:48:02PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson
> wrote:
> > Russell,
> >
> > On Sat, Aug 8, 2015 at 9:10 AM, Russell King
> > wrote:
> >> Adjust the pixel clock values in the N calculation to match the more
> >> accurate c
Russell,
On Fri, Sep 4, 2015 at 5:27 PM, Russell King - ARM Linux
wrote:
> On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
>> wrote:
>> >> In your case you're probably making the value that Linux
>> >> aske
Russell,
On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
wrote:
>> Basically the spec is saying that you want both N and CTS to be
>> integral. ...as you say you really want:
>> CTS = (TMDS * N) / (128 * audio_freq)
>
> In the case of software-programmed CTS and N values, they have to
Hi,
On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson wrote:
> Russell,
>
> On Sat, Aug 8, 2015 at 9:10 AM, Russell King
> wrote:
>> Adjust the pixel clock values in the N calculation to match the more
>> accurate clock values we're given by the DRM subsystem, which are the
>> kHz pixel rate, with
Russell,
On Sat, Aug 8, 2015 at 9:10 AM, Russell King
wrote:
> Adjust the pixel clock values in the N calculation to match the more
> accurate clock values we're given by the DRM subsystem, which are the
> kHz pixel rate, with any fractional kHz rounded down in the case of
> the non-240, non-480
Adjust the pixel clock values in the N calculation to match the more
accurate clock values we're given by the DRM subsystem, which are the
kHz pixel rate, with any fractional kHz rounded down in the case of
the non-240, non-480 line modes, or rounded up for the others. So,
25.20 / 1.001
13 matches
Mail list logo
