Re: [Intel-gfx] [PATCH] Fix GM965 TV out regression

[Robert Lowery]

> On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote:
>> I recently upgraded to ubuntu 12.04 and noticed the TV out no longer
>> works
>> with kernel 3.2.0.
>>
>> Tracing back through old kernels, I found the last working kernel was
>> 2.6.35.
>>
>> Now 4 years ago I fixed a similar issue in the user space intel driver
>> by
>> waiting for vblank after writing to the TV_CTL register via
>> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275
>>
>> Low and behold, it appears 2 years later this same issue was
>> reintroduced
>> in kernel 2.6.36 and has led to some very unhappy users eg
>> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
>>
>> Could someone please apply the following which I have confirmed re-fixes
>> the issue for my TV output via component video connection.
>
> Nice piece of diggin through code! A few minor nitpicks on the patch:
> - sob-line is missing (see Documentation/SubmittingPatches)
> - are there any other people who have tested this patch? If so, please
>   include them in the patch with a
>
>   Tested-by: Name 

Signed-off-by: Robert Lowery 

I'm not aware of anyone else that has tested this patch as yet.

>
> Rodrigo, can you please check this patch with the docs and maybe quickly
> run it?
>
> Thanks, Daniel
> --
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 57 48
>


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fixup infoframe support for sdvo

[Daniel Vetter]

On Sat, May 12, 2012 at 08:22:00PM +0200, Daniel Vetter wrote:
> At least the worst offenders:
> - SDVO specifies that the encoder should compute the ecc. Testing also
>   shows that we must not send the ecc field, so copy the dip_infoframe
>   struct to a temporay place and avoid the ecc field. This way the avi
>   infoframe is exactly 17 bytes long, which agrees with what the spec
>   mandates as a minimal storage capacity (with the ecc field it would
>   be 18 bytes).
> - Only 17 when sending the avi infoframe. The SDVO spec explicitly
>   says that sending more data than what the device announces results
>   in undefined behaviour.
> - Add __attribute__((packed)) to the avi and spd infoframes, for
>   otherwise they're wrongly aligned. Noticed because the avi infoframe
>   ended up being 18 bytes large instead of 17. We haven't noticed this
>   yet because we don't use the uint16_t fields yet (which are the only
>   ones that would be wrongly aligned).
> 
> This regression has been introduce by
> 
> 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit
> commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647
> Author: David Härdeman 
> Date:   Fri Sep 24 21:44:32 2010 +0200
> 
> i915: enable AVI infoframe for intel_hdmi.c [v4]
> 
> Patch tested on my g33 with a sdvo hdmi adaptor.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
> Signed-Off-by: Daniel Vetter 

Forwarded from the bug entry:

Tested-by: Peter Ross  (G35 SDVO-HDMI)
> ---
>  drivers/gpu/drm/i915/intel_drv.h  |4 ++--
>  drivers/gpu/drm/i915/intel_sdvo.c |   11 +--
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d51f27f..3e09188 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -280,12 +280,12 @@ struct dip_infoframe {
>   uint16_t bottom_bar_start;
>   uint16_t left_bar_end;
>   uint16_t right_bar_start;
> - } avi;
> + } __attribute__ ((packed)) avi;
>   struct {
>   uint8_t vn[8];
>   uint8_t pd[16];
>   uint8_t sdi;
> - } spd;
> + } __attribute__ ((packed)) spd;
>   uint8_t payload[27];
>   } __attribute__ ((packed)) body;
>  } __attribute__((packed));
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 7d3f238..125228e 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -887,17 +887,24 @@ static bool intel_sdvo_set_avi_infoframe(struct 
> intel_sdvo *intel_sdvo)
>   };
>   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
>   uint8_t set_buf_index[2] = { 1, 0 };
> - uint64_t *data = (uint64_t *)&avi_if;
> + uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
> + uint64_t *data = (uint64_t *)sdvo_data;
>   unsigned i;
>  
>   intel_dip_infoframe_csum(&avi_if);
>  
> + /* sdvo spec says that the ecc is handled by the hw, and it looks like
> +  * we must not send the ecc field, either. */
> + memcpy(sdvo_data, &avi_if, 3);
> + sdvo_data[3] = avi_if.checksum;
> + memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
> +
>   if (!intel_sdvo_set_value(intel_sdvo,
> SDVO_CMD_SET_HBUF_INDEX,
> set_buf_index, 2))
>   return false;
>  
> - for (i = 0; i < sizeof(avi_if); i += 8) {
> + for (i = 0; i < sizeof(sdvo_data); i += 8) {
>   if (!intel_sdvo_set_value(intel_sdvo,
> SDVO_CMD_SET_HBUF_DATA,
> data, 8))
> -- 
> 1.7.8.3
> 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN

[Daniel Vetter]

On Sun, May 13, 2012 at 09:15:51PM +0100, Chris Wilson wrote:
> On Sun, 13 May 2012 22:08:10 +0200, Daniel Vetter  wrote:
> > On Sun, May 13, 2012 at 08:16:12PM +0100, Chris Wilson wrote:
> > > Turn a fatal lockup into a merely blank display with lots of shouty
> > > messages.
> > > 
> > > v2: Whilst in the area, convert the other BUG_ON into less fatal errors.
> > > In particular, note that we may be called on a PCH platform not using
> > > PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll)
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > Ok, I guess you want me to drop v1 of this again. I'll wait for a bit of
> > feedback on these two then (and the tested-by from qa on the 2nd one).
> 
> Up to you, I thought that the original patch was overshadowed by the
> your change request and little reason for it to be split. It would be
> good to get QA's tested-by on the second patch at any rate.

Ok, I've picked up v2 of patch 1 and the 2nd patch. Looks like we still
have an issue somewhere in that code that makes ilk unhappy :(
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN

[Daniel Vetter]

On Sun, May 13, 2012 at 08:51:41PM -0300, Eugeni Dodonov wrote:
> On Sun, May 13, 2012 at 4:16 PM, Chris Wilson  
> wrote:
> > Turn a fatal lockup into a merely blank display with lots of shouty
> > messages.
> >
> > v2: Whilst in the area, convert the other BUG_ON into less fatal errors.
> > In particular, note that we may be called on a PCH platform not using
> > PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll)
> 
> I think that we need to keep in mind that we can have Haswell+PPT
> combination, but I don't know what will happen in this case yet.
> 
> So I'd suggest adding a:
> 
> WARN_ON(pll == NULL && !HAS_PCH_LPT(dev));
> 
> as well somewhere in the checks. What do you think?

Sounds sensible. Care to stitch together that patch?
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: don't clobber the pipe param in sanitize_modesetting

[Daniel Vetter]

On Sun, May 13, 2012 at 09:33:42PM +0100, Chris Wilson wrote:
> On Sun, 13 May 2012 22:29:25 +0200, Daniel Vetter  
> wrote:
> > ... we need it later on in the function to clean up pipe <-> plane
> > associations. This regression has been introduced in
> > 
> > commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
> > Author: Chris Wilson 
> > Date:   Thu Mar 22 15:00:50 2012 +
> > 
> > drm/i915: Sanitize BIOS debugging bits from PIPECONF
> > 
> > Spotted by staring at debug output of an (as it turns out) totally
> > unrelated bug.
> > 
> > v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
> > Chris Wilson.
> > 
> > Cc: Chris Wilson 
> > Cc: sta...@kernel.org (the regression was Cc: stable, too)
> > Signed-Off-by: Daniel Vetter 
> Reviewed-by: Chris Wilson 
Queued for -next, thanks for the review.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] OpenGL sampler objects on sandybridge with Ubuntu Linux 12.04

[Daniel Vetter]

Hi,

Please file a bug report with the below details on bugs.freedesktop.org
against "Mesa" -> "DRI/Intel(i965)".

Thanks, Daniel

On Wed, May 16, 2012 at 09:58:45AM +, Mark Newiger wrote:
> Hello,
> 
> We are using an MiniPC with the following configuration:
> 
> -  Intel SandyBridge PC Mainboard DH61AG and integrated Intel HD 
> Graphics 3000
> 
> -  Dual OS: Windows 7 32bit and Ubuntu 12.04 32bit
> 
> When using OpenGL sampler objects for configuring textures, on Ubuntu I have 
> to create a mipmap chain by calling "glGenerateMipmap()". Otherwise the 
> texture sampling will not work (e.g. returns black).
> Take the following example:
> // Init
> int texture;
> glGenTextures(1, &texture);
> glBindTexture(GL_TEXTURE_2D, texture);
> glTexImage2D(...);
> 
> int sampler;
> glGenSamplers(1, &sampler);
> glSamplerParameteri(sampler, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> glSamplerParameteri(sampler, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> 
> // Render loop
> glActiveTexture(GL_TEXTURE0);
> glBindTexture(GL_TEXTURE_2D, texture);
> glBindSampler(0, sampler);
> ...
> 
> This works perfectly on Windows but not on Ubuntu. For Ubuntu Linux I have to 
> add the following:
> //Init
> ...
> glTexImage2D(...);
> glGenerateMipmap(GL_TEXTURE_2D);
> 
> Without the mipmap the texture sampling does not work, although I am not 
> using any mipmaps.
> When using the traditional texture filter configuration, this problem does 
> not occur and the code behaves the same on Windows and Linux:
> // Render loop
> glActiveTexture(GL_TEXTURE0);
> glBindTexture(GL_TEXTURE_2D, texture);
> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> 
> Seems to be a driver bug for me. Or did I oversee something ?
> 
> Thanks and best regards
> Mark
> 
> 
> Best regards,
> Mark Newiger | Senior Software Engineer
> SeeFront GmbH
> Esplanade 41 | D-20354 Hamburg, Germany
> Office: +49 40 416 22 64-83
> mark.newi...@seefront.com | 
> www.seefront.com
> 
> Managing Director: Christoph Grossmann
> Registered seat of the company: Hamburg
> Register Court: Amtsgericht Hamburg HRB 98205 VAT-ID-No. DE248406189
> 

> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: unlock mutex before intel_modeset_init_hw

[Daniel Vetter]

On Fri, May 18, 2012 at 10:22:32PM +0100, Chris Wilson wrote:
> On Fri, 18 May 2012 17:57:13 -0300, Paulo Zanoni  wrote:
> > From: Paulo Zanoni 
> > 
> > Because on IVB, intel_modeset_init_hw calls gen6_enable_rps with locks
> > the mutex. This problem broke suspend on my machine. It was introduced
> > in the following commit:
> > 
> > commit 2e1352cf196094f44e73776f41087f4c489ab936
> > Author: Chris Wilson 
> > Date:   Wed May 9 11:56:28 2012 +0100
> > 
> > drm/i915: gen6_enable_rps() wants to be called after ring initialisation
> > 
> > This fix was actually suggested by Chris Wilson on a conversation, so
> > the credit goes to him. I just bisected the problem, reported to him
> > and tested his idea.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Paulo Zanoni 
> 
> My mistake, I thought I was being consistent with the other callsites,
> when in fact it was the exact opposite.
> 
> Daniel, do you mind erasing the mistake from history and crediting Paulo
> for v3? :)
History rectified, thanks for the fix.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: don't return -ENXIO from gmbus xfer

[Daniel Vetter]

... too much risk for flaky edid transfers.

This regression has been introduced in

commit e646d5773572bf52017983d758bdf05777dc5600
Author: Daniel Kurtz 
Date:   Fri Mar 30 19:46:38 2012 +0800

drm/i915/intel_i2c: always wait for IDLE before clearing NAK

This patch keeps the improved NAK handling on the hw side, but reverts
the change to return -ENXIO in case the gmbus controller reports a
NAK.

Cc: Daniel Kurtz 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
Reported-and-Tested-by: Julian Simioni 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_i2c.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e04255e..0588d8e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -418,10 +418,11 @@ clear_err:
 * If no ACK is received during the address phase of a transaction,
 * the adapter must report -ENXIO.
 * It is not clear what to return if no ACK is received at other times.
-* So, we always return -ENXIO in all NAK cases, to ensure we send
-* it at least during the one case that is specified.
+*
+* Unfortunately we can't afford false positives in returning -ENXIO,
+* hence never return -ENXIO.
 */
-   ret = -ENXIO;
+   ret = i;
goto out;
 
 timeout:
-- 
1.7.10

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Fix GM965 TV out regression

[Chris Wilson]

On Sat, 19 May 2012 20:38:20 +0200, Daniel Vetter  wrote:
> On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote:
> > Could someone please apply the following which I have confirmed re-fixes
> > the issue for my TV output via component video connection.

> Rodrigo, can you please check this patch with the docs and maybe quickly
> run it?

The patch looks reasonable (just lacking a POSTING_READ prior to the
wait as that is not guaranteed by the wait). My guess would be that we
need a vblank to be sure that the writes latched and we indeed switched
off the detection mode prior to turning the pipe off. Not sure how that
results in ghost TV detection, and so it would be good to capture any
final explanation as a code comment to make sure that the wait isn't
deleted again in future.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [REVERT] - drm/i915: Removing TV Out modes

[Daniel Vetter]

On Sat, May 19, 2012 at 09:41:00PM +1000, Robert Lowery wrote:
> Further to my previous post regarding getting TV Out working on recent
> kernels, I see a recent check in to the mainline kernel source removed
> support for 576p TV output which I use.
> 
> Could someone please revert
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9
> or at least reinstate the 576p mode that I use.
> 
> I think 480p@59.94Hz is also a valid mode (though I don't use it) and
> should be left in and perhaps be renamed to just 480p since there is now
> no need to differentiate frequencies.
> 
> Something like this?

Hm, I have no idea whether we should just revert the entire commit.
Rodrigo, your commit

commit 55a6713b3f30a5024056027e9dbf03ac8f13bfc9
Author: Rodrigo Vivi 
Date:   Thu Dec 15 14:47:33 2011 -0200

drm/i915: Removing TV Out modes.

is a bit thin on justification as to why we need that. Can you please
explain?

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Fix GM965 TV out regression

[Daniel Vetter]

On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote:
> I recently upgraded to ubuntu 12.04 and noticed the TV out no longer works
> with kernel 3.2.0.
> 
> Tracing back through old kernels, I found the last working kernel was 2.6.35.
> 
> Now 4 years ago I fixed a similar issue in the user space intel driver by
> waiting for vblank after writing to the TV_CTL register via
> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275
> 
> Low and behold, it appears 2 years later this same issue was reintroduced
> in kernel 2.6.36 and has led to some very unhappy users eg
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
> 
> Could someone please apply the following which I have confirmed re-fixes
> the issue for my TV output via component video connection.

Nice piece of diggin through code! A few minor nitpicks on the patch:
- sob-line is missing (see Documentation/SubmittingPatches)
- are there any other people who have tested this patch? If so, please
  include them in the patch with a

  Tested-by: Name 

Rodrigo, can you please check this patch with the docs and maybe quickly
run it?

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/edid: adjust double-clocked cea modes

[Daniel Vetter]

On Tue, May 15, 2012 at 11:33:43AM -0400, Adam Jackson wrote:
> On 5/14/12 3:43 PM, Paulo Zanoni wrote:
> 
> >Also, I think flag DRM_MODE_FLAG_DBLCLK does not sound correct for
> >them, so we would need to create flags:
> >- DRM_MODE_FLAG_PR_1_to_10
> >- DRM_MODE_FLAG_PR_1_or_2
> >- DRM_MODE_FLAG_PR_1_or_2_or_4
> >
> >Or any other more creative names. And then we should cross our fingers
> >in the hope that they don't start creating modes with other possible
> >variations of PR :)
> >Anyway, how will the user be able to choose the wanted PR? What about
> >the aspect ratio? Yet Another Connector Property?
> 
> Well, one thing at a time.
> 
> Right now we don't have the concept of a mode property.  Therefore,
> modes exposed to userspace should all be unique.  Exposing the pixel
> repeat to userspace as a connector property is wrong because it
> doesn't apply to all modes for a connector.
> 
> So my initial inclination would be to do something like this in the
> flags field:
> 
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -58,6 +58,9 @@
>  #define DRM_MODE_FLAG_PIXMUX   (1<<11)
>  #define DRM_MODE_FLAG_DBLCLK   (1<<12)
>  #define DRM_MODE_FLAG_CLKDIV2  (1<<13)
> +/* begin non-xorg definitions */
> +#define DRM_PIXREP_MASK(15 << 14)
> +#define DRM_MODE_FLAG_PIXREP(x) (((x) << 14) & DRM_PIXMULT_MASK)
> 
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> 
> The timings for the variably-repeated modes won't change (right?) so
> this is the only way to get the desired pixel repeat passed into the
> modesettinng path.  And then the "one to ten" and "one two or four"
> modes simply need to be added to the list multiple times, once for
> each possible pixel replication, and with varying names depending on
> the effective framebuffer size.
> 
> Problems with this approach are that it means rewriting the CEA mode
> list or the VIC table walk or both, and that it means creating a
> class of modes that userspace can set but not create (which means,
> if your X driver is parsing EDID itself instead of just using the
> damn kernel mode list, that many of the modes will be inaccessible
> to X).  Neither is insoluble, just nngh.

For the variable pixel-repeat modes I'd propose that we mark them up with
a flag and flat-out reject them int the cea edid parser. All these modes
are super-low-res interlaced things likely only good to upscale sdtv
material. At least on Intel we might as well use the hw scaler for them.

The double-clocked ones look slightly more sane, so I guess we could keep
these. If I manage to get them to work anywhere else than on my machine
here :(

> The dual-aspect-ratio modes are, well, ugly.  Ideally we'd have
> scaler hardware on all digital output routes so we could just make
> that a connector property, and then hide the choice of mechanism
> inside the drm (either in the monitor if the infoframe says so / if
> it's controllable with DDC/CI or something, or in the GPU if not).
> I don't know if all the digital outputs in the world live up to that
> lofty goal.  Failing that we could encode the widescreen-ness in the
> mode name?  All quite horrible.  TVs really are the worst thing.

tbh our current avi infoframe support is ridiculously lacking - we don't
even properly work the overscan properties, set the VIC number and all
kinds of stuff. I think we can defer worrying about these multi-aspect
ratio modes until everything else works somewhat.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [REVERT] - drm/i915: Removing TV Out modes

[Robert Lowery]

Further to my previous post regarding getting TV Out working on recent
kernels, I see a recent check in to the mainline kernel source removed
support for 576p TV output which I use.

Could someone please revert
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9
or at least reinstate the 576p mode that I use.

I think 480p@59.94Hz is also a valid mode (though I don't use it) and
should be left in and perhaps be renamed to just 480p since there is now
no need to differentiate frequencies.

Something like this?

--- intel_tv.c.orig 2012-05-19 17:06:11.0 +1000
+++ intel_tv.c  2012-05-19 17:19:52.0 +1000
@@ -674,6 +674,54 @@ static const struct tv_mode tv_modes[] =
.filter_table = filter_table,
},
{
+   .name   = "480p",
+   .clock  = 107520,
+   .refresh= 59940,
+   .oversample = TV_OVERSAMPLE_4X,
+   .component_only = 1,
+
+   .hsync_end  = 64,   .hblank_end = 122,
+   .hblank_start   = 842,  .htotal = 857,
+
+   .progressive= true, .trilevel_sync = false,
+
+   .vsync_start_f1 = 12,   .vsync_start_f2 = 12,
+   .vsync_len  = 12,
+
+   .veq_ena= false,
+
+   .vi_end_f1  = 44,   .vi_end_f2  = 44,
+   .nbr_end= 479,
+
+   .burst_ena  = false,
+
+   .filter_table = filter_table,
+   },
+   {
+   .name   = "576p",
+   .clock  = 107520,
+   .refresh= 5,
+   .oversample = TV_OVERSAMPLE_4X,
+   .component_only = 1,
+
+   .hsync_end  = 64,   .hblank_end = 139,
+   .hblank_start   = 859,  .htotal = 863,
+
+   .progressive= true, .trilevel_sync = false,
+
+   .vsync_start_f1 = 10,   .vsync_start_f2 = 10,
+   .vsync_len  = 10,
+
+   .veq_ena= false,
+
+   .vi_end_f1  = 48,   .vi_end_f2  = 48,
+   .nbr_end= 575,
+
+   .burst_ena  = false,
+
+   .filter_table = filter_table,
+   },
+   {
.name   = "720p@60Hz",
.clock  = 148800,
.refresh= 6,





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [REVERT] - drm/i915: Removing TV Out modes

[Robert Lowery]

Further to my previous post regarding getting TV Out working on recent
kernels, I see a recent check in to the mainline kernel source removed
support for 576p TV output which I use.

Could someone please revert
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9
or at least reinstate the 576p mode that I use.

I think 480p@59.94Hz is also a valid mode (though I don't use it) and
should be left in and perhaps be renamed to just 480p since there is now
no need to differentiate frequencies.

Something like this?

--- intel_tv.c.orig 2012-05-19 17:06:11.0 +1000
+++ intel_tv.c  2012-05-19 17:19:52.0 +1000
@@ -674,6 +674,54 @@ static const struct tv_mode tv_modes[] =
.filter_table = filter_table,
},
{
+   .name   = "480p",
+   .clock  = 107520,
+   .refresh= 59940,
+   .oversample = TV_OVERSAMPLE_4X,
+   .component_only = 1,
+
+   .hsync_end  = 64,   .hblank_end = 122,
+   .hblank_start   = 842,  .htotal = 857,
+
+   .progressive= true, .trilevel_sync = false,
+
+   .vsync_start_f1 = 12,   .vsync_start_f2 = 12,
+   .vsync_len  = 12,
+
+   .veq_ena= false,
+
+   .vi_end_f1  = 44,   .vi_end_f2  = 44,
+   .nbr_end= 479,
+
+   .burst_ena  = false,
+
+   .filter_table = filter_table,
+   },
+   {
+   .name   = "576p",
+   .clock  = 107520,
+   .refresh= 5,
+   .oversample = TV_OVERSAMPLE_4X,
+   .component_only = 1,
+
+   .hsync_end  = 64,   .hblank_end = 139,
+   .hblank_start   = 859,  .htotal = 863,
+
+   .progressive= true, .trilevel_sync = false,
+
+   .vsync_start_f1 = 10,   .vsync_start_f2 = 10,
+   .vsync_len  = 10,
+
+   .veq_ena= false,
+
+   .vi_end_f1  = 48,   .vi_end_f2  = 48,
+   .nbr_end= 575,
+
+   .burst_ena  = false,
+
+   .filter_table = filter_table,
+   },
+   {
.name   = "720p@60Hz",
.clock  = 148800,
.refresh= 6,





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Specific resolution without monitor

[paulo louro]

Hey Carl,
I had the same problem as you.
So i wanted my MediaCenter to start up at for example 15h just before i get 
home. But since my TV and my AV receiver where in standby the resolution 
detected by the drm driver as always wrong. So to by pass this i have changed a 
bit intel drm driver and hard coded my TV EDID data directly into the driver. 
This ways every time the MC starts up it thinks is connected to the PC and 
setups the right resolution. 
Now this is not a simple thing to do since you will need to compile the linux 
kernel, you can also only compile the drm driver/module for sure but i dont 
know how to do that 
So what i did was, with some linux software, named edid grab or read or 
something, i extracted my TV edid in HEX format. Then i changed the function 
"drm_do_get_edid" inside the drm_edid.c file located at the linux 
kernel/drivers/gpu/drm/  to ignore the i2c bus and to use the edid i defined 
inside my block1 byte array. Also needed to comment out some code, since EDID 
something comes in multiple messages. Below you can find my modifications.

I hope this help you out. Maybe this is not the right way of doing it, but it 
worked for me. I´m not and expert on DRM or I915 driver, just wanted to make it 
worked so i hard coded it all. You can always improve and maybe add the 
function of reading the EDID from a file like the NVIDIA driver has. 


static u8 *drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter 
*adapter){   int i, j = 0, valid_extensions = 0; u8 *block, *new;   
 u8 block1[256] = 
{0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x34,0xa9,0xa4,0xa0,0x01,0x01,0x01,0x01,
 
0x00,0x14,0x01,0x03,0x80,0x00,0x00,0x78,0x0a,0xda,0xff,0xa3,0x58,0x4a,0xa2,0x29,

0x17,0x49,0x4b,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,

0x01,0x01,0x01,0x01,0x01,0x01,0x02,0x3a,0x80,0xd0,0x72,0x38,0x2d,0x40,0x10,0x2c,

0x45,0x80,0xba,0x88,0x21,0x00,0x00,0x1e,0x02,0x3a,0x80,0x18,0x71,0x38,0x2d,0x40,

0x58,0x2c,0x45,0x00,0xba,0x88,0x21,0x00,0x00,0x1e,0x00,0x00,0x00,0xfc,0x00,0x50,

0x61,0x6e,0x61,0x73,0x6f,0x6e,0x69,0x63,0x2d,0x54,0x56,0x0a,0x00,0x00,0x00,0xfd,

0x00,0x17,0x3d,0x0f,0x44,0x0f,0x00,0x0a,0x20,0x20,0x20,0x20,0x20,0x20,0x01,0xd3,

0x02,0x03,0x36,0x72,0x50,0x9f,0x90,0x14,0x05,0x20,0x13,0x04,0x12,0x03,0x11,0x02,

0x16,0x07,0x15,0x06,0x01,0x23,0x09,0x07,0x01,0x78,0x03,0x0c,0x00,0x10,0x00,0xb8,

0x26,0x2f,0xc0,0x0a,0x81,0x49,0xff,0xfc,0x06,0x16,0x08,0x00,0x18,0x00,0x00,0x00,

0x00,0x00,0xe3,0x05,0x1f,0x01,0x01,0x1d,0x80,0xd0,0x72,0x1c,0x16,0x20,0x10,0x2c,

0x25,0x80,0xba,0x88,0x21,0x00,0x00,0x9e,0x01,0x1d,0x80,0x18,0x71,0x1c,0x16,0x20,

0x58,0x2c,0x25,0x00,0xba,0x88,0x21,0x00,0x00,0x9e,0x01,0x1d,0x00,0xbc,0x52,0xd0,

0x1e,0x20,0xb8,0x28,0x55,0x40,0xba,0x88,0x21,0x00,0x00,0x1e,0x01,0x1d,0x00,0x72,

0x51,0xd0,0x1e,0x20,0x6e,0x28,0x55,0x00,0xba,0x88,0x21,0x00,0x00,0x1e,0x00,0xb6};
//if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)   //  
return NULL;
if ((block = kmalloc(EDID_LENGTH*2, GFP_KERNEL)) == NULL)   
return NULL;
/* base block fetch */  //for (i = 0; i < 4; i++) { //  
if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))  //  
goto out;   //  if (drm_edid_block_valid(block))//  
break;  //  if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {   //  
connector->null_edid_counter++; //  goto carp;  //  
}   //} //if (i == 4)   //  goto carp;
//DRM_DEBUG_KMS("DUMP EDID START\n");   //for(i = 0 ; i < EDID_LENGTH; 
i += 16 )//  
DRM_DEBUG_KMS("0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x\n",block[i],block[i+1],block[i+2],block[i+3],block[i+4],block[i+5],block[i+6],block[i+7],block[i+8],block[i+9],block[i+10],block[i+11],block[i+12],block[i+13],block[i+14],block[i+15]);
 //DRM_DEBUG_KMS("\nDUMP EDID END\n");
DRM_DEBUG_KMS("Overwriting EDID\n");//DRM_DEBUG_KMS("EDID_LENGTH: 
%d\n",EDID_LENGTH);
for(i = 0; i < 256; i++)block[i]=block1[i]; 
return block;
/* if there's no extensions, we're done */  if (block[0x7e] == 0)   
return block;
new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL); 
if (!new)   goto out;   block = new;
for (j = 1; j <= block[0x7e]; j++) {for (i = 0; i < 4; i++) 
{   if (drm_do_probe_ddc_edid(adapter,  
  block + (valid_extensions + 1) * EDID_LENGTH, 
  j, EDID_LENGTH))  goto out;   
if (drm_edid_block_valid(block + 

[Intel-gfx] [PATCH] Fix GM965 TV out regression

[Robert Lowery]

I recently upgraded to ubuntu 12.04 and noticed the TV out no longer works
with kernel 3.2.0.

Tracing back through old kernels, I found the last working kernel was 2.6.35.

Now 4 years ago I fixed a similar issue in the user space intel driver by
waiting for vblank after writing to the TV_CTL register via
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275

Low and behold, it appears 2 years later this same issue was reintroduced
in kernel 2.6.36 and has led to some very unhappy users eg
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688

Could someone please apply the following which I have confirmed re-fixes
the issue for my TV output via component video connection.

--- intel_tv.c.orig 2012-05-19 16:32:21.0 +1000
+++ intel_tv.c  2012-05-19 16:33:23.0 +1000
@@ -1186,6 +1186,9 @@ intel_tv_detect_type(struct intel_tv *in
I915_WRITE(TV_DAC, save_tv_dac & ~TVDAC_STATE_CHG_EN);
I915_WRITE(TV_CTL, save_tv_ctl);

+   intel_wait_for_vblank(intel_tv->base.base.dev,
+ to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+
/* Restore interrupt config */
if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
spin_lock_irqsave(&dev_priv->irq_lock, irqflags);


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx