All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Yang Kuankuan <ykk@rock-chips.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
	Mark Brown <broonie@kernel.org>,
	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: Tue, 31 Mar 2015 12:57:18 +0100	[thread overview]
Message-ID: <20150331115718.GS24899@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <551A629C.5010306@rock-chips.com>

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.

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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()
Date: Tue, 31 Mar 2015 12:57:18 +0100	[thread overview]
Message-ID: <20150331115718.GS24899@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <551A629C.5010306@rock-chips.com>

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.

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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-03-31 11:57 UTC|newest]

Thread overview: 58+ 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:39 ` 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-30 19:40   ` Russell King
2015-03-31  6:55   ` Yang Kuankuan
2015-03-31  6:55     ` Yang Kuankuan
2015-03-31 10:35     ` Russell King - ARM Linux
2015-03-31 10:35       ` Russell King - ARM Linux
2015-04-01  1:54       ` Yakir
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-30 19:40   ` Russell King
2015-03-31  9:02   ` Yang Kuankuan
2015-03-31 11:57     ` Russell King - ARM Linux [this message]
2015-03-31 11:57       ` Russell King - ARM Linux
2015-04-01  1:31       ` Yakir
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   ` 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   ` 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   ` 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-30 19:40   ` Russell King
2015-03-31  7:45   ` Yang Kuankuan
2015-03-31  7:45     ` Yang Kuankuan
2015-03-31  9:15   ` Philipp Zabel
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-03-30 19:40   ` Russell King
2015-04-01 11:47   ` Jani Nikula
2015-04-01 11:47     ` Jani Nikula
2015-04-01 11:56     ` Russell King - ARM Linux
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-04-02 10:52         ` Jani Nikula
2015-03-30 19:40 ` [PATCH RFC 08/11] sound/core: add DRM ELD helper Russell King
2015-03-30 19:40   ` Russell King
2015-03-31  9:12   ` Philipp Zabel
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-30 19:40   ` Russell King
2015-03-31  8:30   ` Yang Kuankuan
2015-03-31  8:30     ` Yang Kuankuan
2015-03-31  9:13     ` Russell King - ARM Linux
2015-03-31  9:13       ` Russell King - ARM Linux
2015-04-01  2:04       ` Yakir
2015-04-01  2:04         ` Yakir
2015-04-01  7:58         ` Russell King - ARM Linux
2015-04-01  7:58           ` Russell King - ARM Linux
2015-03-31  9:10   ` Philipp Zabel
2015-03-31  9:10     ` Philipp Zabel
2015-03-31  9:16     ` Russell King - ARM Linux
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   ` Russell King
2015-03-30 19:40 ` [PATCH RFC 11/11] drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver Russell King
2015-03-30 19:40   ` 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=20150331115718.GS24899@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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=ykk@rock-chips.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.