All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@avionic-design.de>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers
Date: Fri, 7 Dec 2012 08:28:10 +0100	[thread overview]
Message-ID: <20121207072810.GB3058@avionic-0098.adnet.avionic-design.de> (raw)
In-Reply-To: <CA+gsUGREMp9mH0ec4BWgf3wJ5oNGKT4aZeJ5BmLaMwZXHydGkg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2370 bytes --]

On Thu, Dec 06, 2012 at 02:55:23PM -0200, Paulo Zanoni wrote:
> Hi
> 
> 2012/12/6 Paulo Zanoni <przanoni@gmail.com>:
> > Hi
> >
> > 2012/12/5 Thierry Reding <thierry.reding@avionic-design.de>:
> >> Use the generic HDMI infoframe helpers to get rid of the duplicate
> >> implementation in the i915 driver.
> >
> > A few comments:
> >
> > - I've compiled your patches and now "intel_infoframes -d" tells my my
> > infoframes are full of zeroes. So there's a bug somewhere... I have to
> > say that the i915 infoframe registers are quite complicated and it
> > took me a long time to fix a lot of its problems, so please don't
> > break it and read below for a suggestion :)
> >
> > - Why do we need that kconfig stuff? Why not just put all the code
> > inside drivers/gpu/drm?
> >
> > - I really like having "common code between drivers merged", but I
> > really don't see how the i915 driver is benefiting from this change.
> > We're just basically complicating intel_hdmi.c to use a new struct
> > that doesn't fit our needs due to the lack of the ECC byte. My idea:
> > Instead of calling hdmi_avi_infoframe_pack, why don't we just
> > implement intel_hdmi_avi_infoframe_pack that converts a "struct
> > hdmi_avi_infoframe" into our own good-old "struct dip_infoframe" that
> > has the cool ECC value in the right place? This would probably
> > drastically reduce your chances of introducing bugs in our code :)
> 
> Just to be a little bit more clear about this paragraph since Daniel
> asked me a few questions:
> 
> For the changes inside intel_hdmi.c, I'd really like your patch to not
> touch any of the "write_infoframe" or "set_infoframes" callbacks. I
> think you can do everything by just patching intel_set_infoframe,
> intel_hdmi_set_avi_infoframe and intel_hdmi_set_spd_infoframe. In one
> of those functions you could call something like
> "intel_hdmi_infoframe_pack(struct hdmi_avi_infoframe, struct
> dip_infoframe)" and then proceed. This way you don 't need to touch
> the code that actually writes stuff to the hardware.

I think I already explained in my previous mail how IMO this completely
defeats the purpose of this patch series. Furthermore the functions that
write the infoframes to the hardware themselves could use some
refactoring of their own. There is a lot of duplication there.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2012-12-07  7:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05 16:45 [RFC v2 0/5] Add HDMI infoframe helpers Thierry Reding
2012-12-05 16:45 ` [RFC v2 1/5] drm: Add some missing forward declarations Thierry Reding
2012-12-05 16:45 ` [RFC v2 2/5] video: Add generic HDMI infoframe helpers Thierry Reding
2012-12-07 14:32   ` Paulo Zanoni
2012-12-11  7:58     ` Thierry Reding
2012-12-05 16:45 ` [RFC v2 3/5] drm: Add " Thierry Reding
2012-12-05 17:51   ` Lars-Peter Clausen
2012-12-06  7:28     ` Thierry Reding
2012-12-06  8:28       ` Lars-Peter Clausen
2012-12-06 14:09   ` Daniel Vetter
2012-12-06 14:28     ` Thierry Reding
2012-12-06 15:44       ` Daniel Vetter
2012-12-06 16:02         ` Thierry Reding
2012-12-07 19:00   ` Daniel Vetter
2012-12-05 16:45 ` [RFC v2 4/5] drm: tegra: Use generic " Thierry Reding
2012-12-05 16:45 ` [RFC v2 5/5] drm/i915: " Thierry Reding
2012-12-06 14:16   ` Daniel Vetter
2012-12-06 14:23     ` Thierry Reding
2012-12-06 15:57       ` Daniel Vetter
2012-12-06 16:02         ` Thierry Reding
2012-12-06 16:11   ` Paulo Zanoni
2012-12-06 16:55     ` Paulo Zanoni
2012-12-07  7:28       ` Thierry Reding [this message]
2012-12-07  8:30         ` Daniel Vetter
2012-12-07  8:49           ` Thierry Reding
2012-12-07  7:22     ` Thierry Reding
2012-12-07 15:11   ` [RFC] " Paulo Zanoni
2012-12-07 15:32     ` Daniel Vetter
2012-12-11 10:39       ` Daniel Vetter
2012-12-11  8:35     ` Thierry Reding

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=20121207072810.GB3058@avionic-0098.adnet.avionic-design.de \
    --to=thierry.reding@avionic-design.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=przanoni@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 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.