From: ykk@rock-chips•com (Yakir)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RFC 01/11] drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()
Date: Wed, 01 Apr 2015 09:54:47 +0800 [thread overview]
Message-ID: <551B4FE7.3040804@rock-chips.com> (raw)
In-Reply-To: <20150331103519.GR24899@n2100.arm.linux.org.uk>
Hi Rusell,
? 2015/3/31 18:35, Russell King - ARM Linux ??:
> On Tue, Mar 31, 2015 at 02:55:53AM -0400, Yang Kuankuan wrote:
>> Hi Russell,
>>
>> I'm okay with this change, and also I am preparing that collect N/CTS
>> setting to an array, like this :
>>
>> struct n_cts {
>> unsigned int cts;
>> unsigned int n;
>> };
>>
>> struct tmds_n_cts {
>> unsigned long tmds;
>> /* 1 entry each for 32KHz, 44.1KHz, and 48KHz */
>> struct n_cts n_cts[3];
>> };
>>
>> static const struct tmds_n_cts n_cts_table[] = {
>> { 25175000, {{ 28125, 4576}, { 31250, 7007}, { 25175, 6144} } },
>> }
> I think this is something which should be a common helper rather than
> being specific to the driver. I believe these are the standard values
> for coherent audio/video clocks which can be found in the HDMI
> specifications. Such a helper should document that it is only for
> use when the audio and video clocks are coherent.
Yep, it will be logical to add the n/cts calcu to a common helper. And
actually
the HDMI specifications have give the Revommended N and Expected CTS
values for
several standard TMDS clock rates(25.2/1.001 ...).
>
> (The HDMI spec gives alternative N values for use with auto-CTS value
> generation for non-coherent clocks.)
>
> I'd also prefer the lookup to use the same units as the drm_display_mode
> video clock specification, which is kHz, so we can eventually kill the
> needless *1000 in dw_hdmi.
>
> One of the issues with using a common helper is that the common helper
> would include the 1.001 clocks, which are allegedly unsupported by the
> FSL iMX6 implementation, and, if proven that they don't work, we would
> need some way to disable audio for those devices.
Okay, but rockchip platform can handle the 1.001 clocks, so maybe we can
call
some valid function from dw_hdmi-imx & dw_hdmi-rockchip to mark the
effective
clock that platform support ?
>> But I am confused by the "hdmi->ratio", this variable was modify to
>> 100 in bind funciton, then nowhere would change it again. In this
>> case "hdmi->ratio" seems an unused variable, can we remove it ?
> I guess the FSL sources should be checked to find out what the intended
> use for that was, and we then need to decide whether to keep it (and
> implement it) or remove it.
Need FSL ack...
Best regards.
Yakir Yang
next prev parent reply other threads:[~2015-04-01 1:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 19:39 [RFC 0/11] dw_hdmi cleanups, audio preparation, helpers and ahb audio support Russell King - ARM Linux
2015-03-30 19:40 ` [PATCH RFC 01/11] drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator() Russell King
2015-03-31 6:55 ` Yang Kuankuan
2015-03-31 10:35 ` Russell King - ARM Linux
2015-04-01 1:54 ` Yakir [this message]
2015-03-30 19:40 ` [PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode() Russell King
[not found] ` <551A629C.5010306@rock-chips.com>
2015-03-31 11:57 ` Russell King - ARM Linux
2015-03-30 19:40 ` [PATCH RFC 03/11] drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little Russell King
2015-03-30 19:40 ` [PATCH RFC 04/11] drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced Russell King
2015-03-30 19:40 ` [PATCH RFC 05/11] drm: bridge/dw_hdmi: introduce interface to setting sample rate Russell King
2015-03-30 19:40 ` [PATCH RFC 06/11] drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio Russell King
2015-03-31 7:45 ` Yang Kuankuan
2015-03-31 9:15 ` Philipp Zabel
2015-03-30 19:40 ` [PATCH RFC 07/11] drm/edid: add function to help find SADs Russell King
2015-04-01 11:47 ` Jani Nikula
2015-04-01 11:56 ` Russell King - ARM Linux
2015-04-02 10:52 ` [PATCH] drm/edid: add #defines for ELD versions Jani Nikula
2015-03-30 19:40 ` [PATCH RFC 08/11] sound/core: add DRM ELD helper Russell King
2015-03-31 9:12 ` Philipp Zabel
2015-03-30 19:40 ` [PATCH RFC 09/11] sound/core: add IEC958 channel status helper Russell King
2015-03-31 8:30 ` Yang Kuankuan
2015-03-31 9:13 ` Russell King - ARM Linux
2015-04-01 2:04 ` Yakir
2015-04-01 7:58 ` Russell King - ARM Linux
2015-03-31 9:10 ` Philipp Zabel
2015-03-31 9:16 ` Russell King - ARM Linux
2015-03-30 19:40 ` [PATCH RFC 10/11] drm: bridge/dw_hdmi-ahb-audio: add audio driver Russell King
2015-03-30 19:40 ` [PATCH RFC 11/11] drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver Russell King
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=551B4FE7.3040804@rock-chips.com \
--to=ykk@rock-chips$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox