linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: "Christian König" <deathsimple@vodafone.de>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-tegra@vger.kernel.org, "Dave Airlie" <airlied@redhat.com>
Subject: Re: [PATCH 2/2] drm: tegra: Add HDMI support
Date: Sun, 11 Nov 2012 15:46:44 +0100	[thread overview]
Message-ID: <20121111144644.GK5854@phenom.ffwll.local> (raw)
In-Reply-To: <20121110210118.GA26809@avionic-0098.mockup.avionic-design.de>

On Sat, Nov 10, 2012 at 10:01:18PM +0100, Thierry Reding wrote:
> 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?

Sounds good, especially the disdinction between the infoframe creation and
packing. E.g. on intel sdvo outputs we may not put in one of the ECC bytes
(since the hw creates it), so we need our own packing code there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  parent reply	other threads:[~2012-11-11 14:45 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
2012-11-10 21:11         ` Thierry Reding
2012-11-11 14:46         ` Daniel Vetter [this message]
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=20121111144644.GK5854@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --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=thierry.reding@avionic-design.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).