From: Thierry Reding <thierry.reding@avionic-design.de>
To: "Christian König" <deathsimple@vodafone.de>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
linux-tegra@vger.kernel.org, "Dave Airlie" <airlied@redhat.com>,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm: tegra: Add HDMI support
Date: Sat, 10 Nov 2012 22:01:18 +0100 [thread overview]
Message-ID: <20121110210118.GA26809@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <509D28B6.3060207@vodafone.de>
[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]
On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> On 09.11.2012 16:45, Rafał Miłecki wrote:
> >2012/11/9 Thierry Reding <thierry.reding@avionic-design.de>:
> >>+/* all fields little endian */
> >>+struct hdmi_audio_infoframe {
> >>+ /* PB0 */
> >>+ u8 csum;
> >>+
> >>+ /* PB1 */
> >>+ unsigned cc:3; /* channel count */
> >>+ unsigned res1:1;
> >>+ unsigned ct:4; /* coding type */
> >>+
> >>+ /* PB2 */
> >>+ unsigned ss:2; /* sample size */
> >>+ unsigned sf:3; /* sample frequency */
> >>+ unsigned res2:3;
> >>+
> >>+ /* PB3 */
> >>+ unsigned cxt:5; /* coding extention type */
> >>+ unsigned res3:3;
> >>+
> >>+ /* PB4 */
> >>+ u8 ca; /* channel/speaker allocation */
> >>+
> >>+ /* PB5 */
> >>+ unsigned res5:3;
> >>+ unsigned lsv:4; /* level shift value */
> >>+ unsigned dm_inh:1; /* downmix inhibit */
> >>+
> >>+ /* PB6-10 reserved */
> >>+ u8 res6;
> >>+ u8 res7;
> >>+ u8 res8;
> >>+ u8 res9;
> >>+ u8 res10;
> >>+} __packed;
> >I was told it won't work on different endian devices. See
> >[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> >http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html
>
> Yeah, that's indeed true. And honestly adding just another
> implementation of the HDMI info frames sounds like somebody should
> finally sit down and implement it in a common drm_hdmi.c
So I've been looking at what most other implementations do and it seems
a lot just fill the AVI infoframe with zeroes while only a few actually
try to put useful information in them. Still in order to plan for a
generic solution, I thought maybe something like the below set of
structures and functions could work:
/*
* Structure that contains the infoframe fields in a form that allows them to
* be easily accessed from C code.
*/
struct hdmi_avi_infoframe;
/*
* DRM helper to fill a struct hdmi_avi_infoframe with information taken from
* a struct drm_display_mode. Fields that cannot automatically be derived by
* looking at a struct drm_display_mode are set to the default values.
*/
int drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
struct drm_display_mode *mode);
/*
* Packs the struct hdmi_avi_infoframe into a binary buffer that can be
* programmed to the hardware-specific registers.
*/
ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
void *buffer, size_t size);
Such a scheme would allow DRM drivers to call the helper and tweak the
fields in the structure if the want or need to and call the packing
function to obtain a buffer that they can write to the controller.
Does that sound at all reasonable?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-11-10 21:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 13:59 [PATCH 0/2] NVIDIA Tegra DRM driver Thierry Reding
2012-11-09 13:59 ` [PATCH 1/2] drm: Add NVIDIA Tegra20 support Thierry Reding
2012-11-09 15:18 ` Rob Clark
2012-11-09 16:00 ` Thierry Reding
2012-11-09 16:26 ` Rob Clark
2012-11-09 21:03 ` Thierry Reding
2012-11-10 18:04 ` Terje Bergström
2012-11-09 22:27 ` Stephen Warren
2012-11-10 0:09 ` Stephen Warren
2012-11-10 9:11 ` Thierry Reding
2012-11-13 8:00 ` Terje Bergström
2012-11-13 8:03 ` Thierry Reding
2012-11-13 8:16 ` Terje Bergström
2012-11-09 13:59 ` [PATCH 2/2] drm: tegra: Add HDMI support Thierry Reding
2012-11-09 15:45 ` Rafał Miłecki
2012-11-09 16:00 ` Christian König
2012-11-09 16:04 ` Rafał Miłecki
2012-11-09 20:20 ` Thierry Reding
2012-11-10 21:01 ` Thierry Reding [this message]
2012-11-10 21:11 ` Thierry Reding
2012-11-11 14:46 ` Daniel Vetter
2012-11-12 7:24 ` Thierry Reding
2012-11-12 9:43 ` Daniel Vetter
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=20121110210118.GA26809@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.de \
--cc=airlied@redhat.com \
--cc=deathsimple@vodafone.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox