From: Yakir <ykk@rock-chips.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
alsa-devel@alsa-project.org, David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org, Mark Brown <broonie@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()
Date: Wed, 01 Apr 2015 09:31:43 +0800 [thread overview]
Message-ID: <551B4A7F.30700@rock-chips.com> (raw)
In-Reply-To: <20150331115718.GS24899@n2100.arm.linux.org.uk>
Hi Russell,
在 2015/3/31 19:57, Russell King - ARM Linux 写道:
> On Tue, Mar 31, 2015 at 05:02:20AM -0400, Yang Kuankuan wrote:
>> Besides, as you are going an dw_hdmi cleanups, I want to point another bugs
>> that relate to the HDMI CTS test. There are somethings wrong with General
>> Control Pack, as for now the encoder color depth is 8-bit packing mode,
>> so the color depth only support 24 bits per pixel video, In this case the
>> CD filed in GCP should set to "Color Depth Not indicated".
> I'm not sure I follow.
>
> According to the iMX6 documentation, setting the CD field to either 0000
> or 0100 indicates that the color depth is 24 bits per pixel, 8 bits per
> component, 8 bit packing mode - there's no documented difference between
> these.
Yeah, that is the point. Though there's no designedware datasheet
difference between
"0000b" & 0100b" in vp_pr_cd, but I think the color_depth in vp_pr_cd
register are
mapping to CD0-CD3 filed in GCP packet, and acutally "0000b" & "0100b"
are differnent
in CD filed ("0000b Color Depth not indicated" & "0100b 24 bit per pixel").
If the CD filed is non-zero, that indicate we are support depth color
mode(but I think
the depth color mode need at least 36bpp). Besides as the HDMI
Specification descripte,
"/If the Sink dose not receive a GCP with non-zero CD from more than 4
consecutive video//
//fields, it should exit deep color mode and reverting to 24-bit
color/"(24-bit color is default).
In the end I think if we only output 24-bit color, we should make the CD
field to zero :)
> Are you saying that you wish to pass something other than 24 bpp video
> to your HDMI encoder?
>
>> In the end we should keep the *csc_color_depth(HDMI_CSC_SCALE)* &
>> *color_depth(HDMI_VP_PR_CD)* to zero, code should modify like this GCP
>> would test pass:
> >From what you're describing, you want CD field = 0 and CSC_SCALE = 0.
> It looks like hdmi_video_packetize() will set the CD field to zero if
> hdmi_data.enc_color_depth = 0, but that would cause hdmi_video_sample()
> and hdmi_video_csc() to fail. Maybe those two functions should be fixed
> to accept a color depth of zero, and maybe you need to set
> enc_color_depth to 0?
>
> Interestingly, HDMI_CSC_SCALE_CSC_COLORDE_PTH_24BPP is defined to be
> zero, but again, in the iMX6 data, it could take a value of either
> 0x00 or 0x40. I think hdmi_video_csc() should set this to 0x40 if
> hdmi_data.enc_color_depth = 0, and 0x40 for hdmi_data.enc_color_depth = 8.
Agree! If we only output 24-bit color, we should let the
hdmi_data.enc_color_depth = 0,
and hdmi_video_csc() & hdmi_video_packetize() should handle the
"enc_color_depth = 0".
Best regards.
Yakir Yang
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2015-04-01 1:31 UTC|newest]
Thread overview: 30+ 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
2015-03-30 19:40 ` [PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode() Russell King
2015-03-31 9:02 ` Yang Kuankuan
2015-03-31 11:57 ` Russell King - ARM Linux
2015-04-01 1:31 ` Yakir [this message]
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=551B4A7F.30700@rock-chips.com \
--to=ykk@rock-chips.com \
--cc=airlied@linux.ie \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabio.estevam@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).