On 08/28/2012 05:41 PM, Sachin Kamat wrote:
Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
symbol 'g2d_pm_ops' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
1 files changed, 1 in
On Tue, Aug 28, 2012 at 11:18:24PM -0500, Ian Pilcher wrote:
> On 08/28/2012 07:13 PM, Adam Jackson wrote:
> > On 8/28/12 7:33 PM, Ian Pilcher wrote:
> >> Actually, I believe that the error is probably in the Intel driver. As
> >> I understand it, it shouldn't be sending audio InfoFrames to a non-
Per usual, I've forgotten all the cc's ... I really need to script this,
I'm too dumb to remember.
-Daniel
On Wed, Aug 29, 2012 at 10:29:43AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Just a few smaller things:
> - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression
> from
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: [PATCH v2] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd75
On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from th
radeon_ring_restore is freeing the memory for the saved
ring data. We need to remember that, otherwise we try to
restore the ring data again on the next try. Additional
to that it shouldn't try the reset infinitely if we have
saved ring data.
Signed-off-by: Christian König
---
drivers/gpu/drm/ra
On Wed, Aug 29, 2012 at 4:08 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do th
On Wed, Aug 29, 2012 at 7:24 AM, Christian König
wrote:
> radeon_ring_restore is freeing the memory for the saved
> ring data. We need to remember that, otherwise we try to
> restore the ring data again on the next try. Additional
> to that it shouldn't try the reset infinitely if we have
> saved
On 29 August 2012 12:32, Joonyoung Shim wrote:
> On 08/28/2012 05:41 PM, Sachin Kamat wrote:
>>
>> Fixes the following warning:
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
>> symbol 'g2d_pm_ops' was not declared. Should it be static?
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> dr
On 27/08/12 21:04, Hausensteiner Keg wrote:
On 27/08/12 20:29, Jerome Glisse wrote:
On Sun, Aug 26, 2012 at 8:34 PM, Hausensteiner Keg
wrote:
...
Does patch
http://people.freedesktop.org/~glisse/0001-drm-radeon-extra-type-safe-for-fence-emission.patch
Helps ?
Thanks Jerome. Will try pa
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V4:
Fix review comments about space and comment indentation.
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edi
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
Hi all,
Sorry for breaking message threading but I was not included in
iterations 3 and 4 of this patch.
Random comments about v4:
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned
> char *b
On Wed, Aug 29, 2012 at 4:46 PM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selecte
https://bugzilla.kernel.org/show_bug.cgi?id=18872
Alan changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
--
Configure bugmail: https://bugzil
https://bugzilla.kernel.org/show_bug.cgi?id=29512
Alan changed:
What|Removed |Added
Component|Video(AGP) |Video(DRI - non Intel)
AssignedTo|airl...
From: Alex Deucher
Hi Dave,
This is the current set of radeon fixes for 3.6. Nothing too major.
Highlights:
- fix a gart regression on older IGP chips
- more MSAA fixes
- fix a double free in gpu reset code
- modesetting fixes
The following changes since commit 84f720ecba6716d198b21936d1bf625
On 08/29/2012 02:56 AM, Daniel Vetter wrote:
Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
We've fixed quite a few bugs for our infoframe support recently ...
Tested just now. The behavior has changed. I now need to use *both*
flags to make my display work with an I
https://bugs.freedesktop.org/show_bug.cgi?id=54230
Bug #: 54230
Summary: r600-llvm-compiler completely broken at CAYMAN
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #1 from Thomas Rohloff 2012-08-29 20:49:21 UTC
---
Created attachment 66295
--> https://bugs.freedesktop.org/attachment.cgi?id=66295
Minecrafts main menue.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #2 from Thomas Rohloff 2012-08-29 20:54:31 UTC
---
Created attachment 66296
--> https://bugs.freedesktop.org/attachment.cgi?id=66296
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #3 from Thomas Rohloff 2012-08-29 20:55:07 UTC
---
Created attachment 66297
--> https://bugs.freedesktop.org/attachment.cgi?id=66297
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
On 8/29/12 3:53 PM, Ian Pilcher wrote:
Thinking a bit more about this, I'm starting to rethink my assertion
that the Intel driver is at fault here. On one hand, it doesn't make
any sense to send audio InfoFrames to a non-HDMI display. (BTW, I'm
assuming that a display with a DisplayPort port w
a pedantic observation, you can do with it what you wish (i'm not a
list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629):
#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
Thanks for the comments Daniel and Jean
I will upload patch set 6.
This shall include Jean's review coments.
And i will tag Daniel,Jean and Ville as reviewed.
Regards,
Shirish S
On Wed, Aug 29, 2012 at 9:12 AM, Daniel Vetter wrote:
> On Wed, Aug 29, 2012 at 4:46 PM, Shirish S wrote:
> > The cu
From: Alex Deucher
Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c | 31 +++
1 files changed, 26 insertions(+), 5 delet
I just pushed one more important fix:
commit 41fa54377057ab38bc3e08ebb46168a7daf2e63b
Author: Alex Deucher
Date: Wed Aug 29 19:48:26 2012 -0400
drm/radeon: fix dig encoder selection on DCE61
Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity syst
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #8 from Alex Deucher 2012-08-30 00:13:43 UTC ---
Should be fixed in my drm-next-3.6 branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6
there are several patches required. The patches should show up in stable
kernel
Hi Jean,
On Wed, Aug 29, 2012 at 6:44 AM, Jean Delvare wrote:
> Hi all,
>
> Sorry for breaking message threading but I was not included in
> iterations 3 and 4 of this patch.
>
> Random comments about v4:
>
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #9 from LRN 2012-08-30 01:40:44 UTC ---
Pulled your drm-next-3.6 branch, and merged with current linux master.
Display now works!
There are font rendering problems with X server, but that's another issue.
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #34 from Anonymous Helper 2012-08-30
01:48:07 UTC ---
Created attachment 66308
--> https://bugs.freedesktop.org/attachment.cgi?id=66308
DSDT table from Macbook Pro 8,2 (EFI boot)
Alex,
Please see the DSDT table from a Macbook Pro
On 08/29/2012 04:38 PM, Adam Jackson wrote:
> So to me, that says that drivers need to ask _both_ whether the monitor
> supports audio and whether it's HDMI before sending HDMI-specific audio
> signalling.
OK, so the burden is on the individual drivers.
In terms of moving forward with the rest of
Hi Linus,
a bunch of scattered fixes ati/intel/nouveau, couple of core ones,
nothing too shocking or different.
Dave.
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
are available in the git repository at:
git://peopl
Hi,
On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst
wrote:
[Snip]
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> new file mode 100644
> index 000..e0ceddd
> --- /dev/null
> +++ b/include/linux/dma-fence.h
> @@ -0,0 +1,124 @@
> +/*
> + * Fence mechanism for dma-buf
From: Shirish S
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]
Changes from V2:
Add switch for DDC and E-DDC
Ch
From: Shirish S
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]
Changes from V2:
Add switch for DDC and E-DDC
Ch
From: Shirish S
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the reg
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]
Changes from V2:
Add switch for DDC and E-DDC
Changes from V3:
Rem
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
From: Shirish S
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the reg
On Mit, 2012-08-29 at 20:02 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Was using the DCE41 code which was wrong. Fixes
> blank displays on a number of Trinity systems.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/atombios_encode
On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote:
>
> a pedantic observation, you can do with it what you wish (i'm not a
> list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629):
>
> #if !defined(__arm__)
> if (io_remap_pfn_range(vma, vma->vm_start,
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #15 from Joseph Spiros 2012-08-29
05:36:56 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > I'm running into this bug as well, with an iMac G5 containing a Radeon 9600
> > (rv350) chip. It's been a few months since t
On 08/28/2012 05:41 PM, Sachin Kamat wrote:
> Fixes the following warning:
> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
> symbol 'g2d_pm_ops' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
> 1 files
On Tue, Aug 28, 2012 at 11:18:24PM -0500, Ian Pilcher wrote:
> On 08/28/2012 07:13 PM, Adam Jackson wrote:
> > On 8/28/12 7:33 PM, Ian Pilcher wrote:
> >> Actually, I believe that the error is probably in the Intel driver. As
> >> I understand it, it shouldn't be sending audio InfoFrames to a non-
Per usual, I've forgotten all the cc's ... I really need to script this,
I'm too dumb to remember.
-Daniel
On Wed, Aug 29, 2012 at 10:29:43AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Just a few smaller things:
> - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression
> from
signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120829/04fa94eb/attachment.pgp>
On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from th
radeon_ring_restore is freeing the memory for the saved
ring data. We need to remember that, otherwise we try to
restore the ring data again on the next try. Additional
to that it shouldn't try the reset infinitely if we have
saved ring data.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/ra
s have uploaded patch set 5 incorporating your comments.
> Otherwise looks OK to me.
>
> --
> Ville Syrj?l?
> Intel OTC
>
- Shirish
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120829/59cf9d49/attachment.html>
On Wed, Aug 29, 2012 at 7:24 AM, Christian K?nig
wrote:
> radeon_ring_restore is freeing the memory for the saved
> ring data. We need to remember that, otherwise we try to
> restore the ring data again on the next try. Additional
> to that it shouldn't try the reset infinitely if we have
> saved
On 29 August 2012 12:32, Joonyoung Shim wrote:
> On 08/28/2012 05:41 PM, Sachin Kamat wrote:
>>
>> Fixes the following warning:
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
>> symbol 'g2d_pm_ops' was not declared. Should it be static?
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> dr
On 27/08/12 21:04, Hausensteiner Keg wrote:
> On 27/08/12 20:29, Jerome Glisse wrote:
>> On Sun, Aug 26, 2012 at 8:34 PM, Hausensteiner Keg
>> wrote:
>>> ...
>> Does patch
>>
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-extra-type-safe-for-fence-emission.patch
>>
>>
>>
>> Helps ?
>
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.
Changes from V4:
Fix review comments about space and comment indentation.
Based on drm-next branch
Shirish S (1):
drm: edid: add support for E-DDC
drivers/gpu/drm/drm_edi
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address
Hi all,
Sorry for breaking message threading but I was not included in
iterations 3 and 4 of this patch.
Random comments about v4:
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned
> char *b
On Wed, Aug 29, 2012 at 4:46 PM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selecte
https://bugzilla.kernel.org/show_bug.cgi?id=18872
Alan changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
--
Configure bugmail: https://bugzil
https://bugzilla.kernel.org/show_bug.cgi?id=29512
Alan changed:
What|Removed |Added
Component|Video(AGP) |Video(DRI - non Intel)
AssignedTo|airlied
From: Alex Deucher
Hi Dave,
This is the current set of radeon fixes for 3.6. Nothing too major.
Highlights:
- fix a gart regression on older IGP chips
- more MSAA fixes
- fix a double free in gpu reset code
- modesetting fixes
The following changes since commit 84f720ecba6716d198b21936d1bf625
On 08/29/2012 02:56 AM, Daniel Vetter wrote:
> Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
> We've fixed quite a few bugs for our infoframe support recently ...
Tested just now. The behavior has changed. I now need to use *both*
flags to make my display work with an
https://bugs.freedesktop.org/show_bug.cgi?id=54230
Bug #: 54230
Summary: r600-llvm-compiler completely broken at CAYMAN
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #1 from Thomas Rohloff 2012-08-29 20:49:21
UTC ---
Created attachment 66295
--> https://bugs.freedesktop.org/attachment.cgi?id=66295
Minecrafts main menue.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #2 from Thomas Rohloff 2012-08-29 20:54:31
UTC ---
Created attachment 66296
--> https://bugs.freedesktop.org/attachment.cgi?id=66296
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=54230
--- Comment #3 from Thomas Rohloff 2012-08-29 20:55:07
UTC ---
Created attachment 66297
--> https://bugs.freedesktop.org/attachment.cgi?id=66297
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
On 8/29/12 3:53 PM, Ian Pilcher wrote:
> Thinking a bit more about this, I'm starting to rethink my assertion
> that the Intel driver is at fault here. On one hand, it doesn't make
> any sense to send audio InfoFrames to a non-HDMI display. (BTW, I'm
> assuming that a display with a DisplayPort
a pedantic observation, you can do with it what you wish (i'm not a
list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629):
#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120829/9ab4b82b/attachment-0001.html>
From: Alex Deucher
Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c | 31 +++
1 files changed, 26 insertions(+), 5 de
I just pushed one more important fix:
commit 41fa54377057ab38bc3e08ebb46168a7daf2e63b
Author: Alex Deucher
Date: Wed Aug 29 19:48:26 2012 -0400
drm/radeon: fix dig encoder selection on DCE61
Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity syst
ith
> real hardware while I couldn't.
>
> Your patch never checked for the 3 message transfer complete, it checked
only 2.
With the changes above applied, you can add:
>
> Reviewed-by: Jean Delvare
>
> Will add your review comments in patch set 5 and your reviewed tag.
Thanks & Regards,
Shirish S
> --
> Jean Delvare
> Suse L3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120829/5b818ed7/attachment.html>
Hi,
On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst
wrote:
[Snip]
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> new file mode 100644
> index 000..e0ceddd
> --- /dev/null
> +++ b/include/linux/dma-fence.h
> @@ -0,0 +1,124 @@
> +/*
> + * Fence mechanism for dma-buf
72 matches
Mail list logo
