https://bugs.freedesktop.org/show_bug.cgi?id=34457
reimth at gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
.
You can apply all these changes doing the follwing.
git commit --amend --author="Mathias Fr?hlich "
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120229/f780a326/attachment.pgp>
From: Mathias Fröhlich
Add an option to skip reading the mode entries from
the vbt bios tables.
This change enables the use of displays where the vbt table just
contains inappropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.
Rev
Hi,
On Wednesday, February 29, 2012 22:04:45 you wrote:
> thank you for your patch. Could you please resend it as [PATCH v2] with
> the following things addressed.
Will do. Thanks!
Mathias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
https://bugzilla.kernel.org/show_bug.cgi?id=42727
--- Comment #21 from Alex Deucher 2012-02-29
21:04:00 ---
Created an attachment (id=72501)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72501)
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugzilla.kernel.
On Mon, Feb 27, 2012 at 02:53:37PM -0300, Eugeni Dodonov wrote:
> On Tue, Feb 14, 2012 at 19:37, Daniel Vetter
> wrote:
>
> > This way we can free up the bus->adaptor.algo_data pointer and make it
> > available for use with the bitbanging fallback algo.
> >
> > Signed-Off-by: Daniel Vetter
> >
On Tue, Feb 28, 2012 at 09:08:17AM +0100, Jean Delvare wrote:
> On Tue, 28 Feb 2012 00:39:39 +0100, Daniel Vetter wrote:
> > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> > we need to be able to fall back to the bit-banging algo on gpio pins.
> >
> > The current code set
On Tue, Feb 28, 2012 at 12:42:19AM +0100, Daniel Vetter wrote:
> I'd like to export the corresponding functions from the i2c core
> so that I can use them in fallback bit-banging in i915.ko
>
> v2: Adapt to new i2c export patch.
>
> Cc: nouveau at lists.freedesktop.org
> Signed-off-by: Daniel Vet
Hi,
Attached is a small change to i915 that fixes a customer case that I had in my
day job.
The problem happens with an embedded board that contains vbt bios tables that
do not match the attached display.
Using this change and the apropriate kernel boot command line they are able to
use an ot
Add an option to skip reading the mode entries from
the vbt bios tables.
This change enables the use of displays where the vbt table just
contains inapropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.
Signed-off-by: Mathias Froehl
On Mon, Feb 20, 2012 at 07:22:00PM +0800, Daniel Kurtz wrote:
> On Feb 15, 2012 6:48 PM, "Daniel Vetter" wrote:
> >
> > On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> > > gmbus_xfer with a single message (particularly a single message write)
> > > would
> > > set Bus Cycle Select
https://bugs.freedesktop.org/show_bug.cgi?id=46802
--- Comment #2 from Pablo 2012-02-29 19:42:55 PST ---
Created attachment 57843
--> https://bugs.freedesktop.org/attachment.cgi?id=57843
static image in sm2
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=46802
Pablo changed:
What|Removed |Added
Priority|medium |low
--- Comment #1 from Pablo 2012-02-29 19:36:
https://bugs.freedesktop.org/show_bug.cgi?id=46802
Bug #: 46802
Summary: Regnum online dont run on Shader model 2
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=46802
Bug #: 46802
Summary: Regnum online dont run on Shader model 2
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
On Mon, Feb 27, 2012 at 16:43, Tomasz Stanislawski
wrote:
> The documentation of DMABUF says fallowing words about map_dma_buf callback.
>
> "It is one of the buffer operations that must be implemented by the
> exporter. It should return the sg_table containing scatterlist for this
> buffer, mappe
non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120229/e98a7f20/attachment.pgp>
On Thu, 1 Mar 2012 00:14:53 +0100
Daniel Vetter wrote:
> I'll redo this patch by adding _multipage versions of these 2 functions
> for i915.
OK, but I hope "for i915" doesn't mean "private to"! Put 'em in
pagemap.h, for maintenance reasons and because they are generic.
Making them inline is a
On Thu, 1 Mar 2012 00:14:53 +0100
Daniel Vetter wrote:
> I'll redo this patch by adding _multipage versions of these 2 functions
> for i915.
OK, but I hope "for i915" doesn't mean "private to"! Put 'em in
pagemap.h, for maintenance reasons and because they are generic.
Making them inline is a
On Wed, Feb 29, 2012 at 03:01:46PM -0800, Andrew Morton wrote:
> On Wed, 29 Feb 2012 15:03:31 +0100
> Daniel Vetter wrote:
>
> > drm/i915 wants to read/write more than one page in its fastpath
> > and hence needs to prefault more than PAGE_SIZE bytes.
> >
> > I've checked the callsites and they
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
On Wed, 29 Feb 2012 15:03:31 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for the
On Wed, 29 Feb 2012 15:03:31 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for the
https://bugs.freedesktop.org/show_bug.cgi?id=34457
rei...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Dear Mathias,
thank you for your patch. Could you please resend it as [PATCH v2] with
the following things addressed.
1. Please do not send attached patches. Just copy it into your message
compose window – make sure to turn off automatic line breaks – and adapt
the subject line and recipients or
https://bugzilla.kernel.org/show_bug.cgi?id=42727
--- Comment #21 from Alex Deucher 2012-02-29 21:04:00
---
Created an attachment (id=72501)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72501)
possible fix
Does this kernel patch help?
--
Configure bugmail: https://bugzilla.kernel.
> On Mon, 2012-02-27 at 10:44 +0800, Chen Jie wrote:
>> Hi,
>>
>> For this occasional GPU lockup when returns from STR/STD, I find
>> followings(when the problem happens):
>>
>> The value of SRBM_STATUS is whether 0x20002040 or 0x20003040.
>> Which means:
>> * HI_RQ_PENDING(There is a HI/BIF reques
On Wed, 2012-02-29 at 12:49 +0800, chenhc at lemote.com wrote:
> > On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> >> ? 2012?2?17? ??5:27?Chen Jie ???
> >> >> One good way to test gart is to go over GPU gart table and write a
> >> >> dword using the GPU at end of each page something like 0xCA
> On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
>> ? 2012?2?17? ??5:27?Chen Jie ???
>> >> One good way to test gart is to go over GPU gart table and write a
>> >> dword using the GPU at end of each page something like 0xCAFEDEAD
>> >> or somevalue that is unlikely to be already set. And then
On Wed, 2012-02-29 at 11:04 -0500, alexdeucher at gmail.com wrote:
> From: Sebastian Biemueller
>
> The bo is removed from the list at the top of
> radeon_vm_bo_rmv(), but then the list is used
> in radeon_vm_bo_update_pte() to look up the vm.
> remove the bo_list entry at the end of the
> functi
his is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120229/22808bf9/attachment.pgp>
On Mon, Feb 27, 2012 at 02:53:37PM -0300, Eugeni Dodonov wrote:
> On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote:
>
> > This way we can free up the bus->adaptor.algo_data pointer and make it
> > available for use with the bitbanging fallback algo.
> >
> > Signed-Off-by: Daniel Vetter
> >
>
On Tue, Feb 28, 2012 at 09:08:17AM +0100, Jean Delvare wrote:
> On Tue, 28 Feb 2012 00:39:39 +0100, Daniel Vetter wrote:
> > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> > we need to be able to fall back to the bit-banging algo on gpio pins.
> >
> > The current code set
On Tue, Feb 28, 2012 at 12:42:19AM +0100, Daniel Vetter wrote:
> I'd like to export the corresponding functions from the i2c core
> so that I can use them in fallback bit-banging in i915.ko
>
> v2: Adapt to new i2c export patch.
>
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter
On 29.02.2012 00:23, Jerome Glisse wrote:
> On Tue, 2012-02-28 at 23:19 +0100, Christian K?nig wrote:
>> Without this fix the driver randomly treats
>> textures as arrays and I'm really wondering
>> why gcc isn't complaining about it.
>>
>> Signed-off-by: Christian K?nig
>> ---
>> drivers/gpu/drm
Hi,
Attached is a small change to i915 that fixes a customer case that I had in my
day job.
The problem happens with an embedded board that contains vbt bios tables that
do not match the attached display.
Using this change and the apropriate kernel boot command line they are able to
use an ot
On Mon, Feb 20, 2012 at 07:22:00PM +0800, Daniel Kurtz wrote:
> On Feb 15, 2012 6:48 PM, "Daniel Vetter" wrote:
> >
> > On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> > > gmbus_xfer with a single message (particularly a single message write)
> > > would
> > > set Bus Cycle Select
From: Sebastian Biemueller
The bo is removed from the list at the top of
radeon_vm_bo_rmv(), but then the list is used
in radeon_vm_bo_update_pte() to look up the vm.
remove the bo_list entry at the end of the
function instead.
Signed-off-by: Alex Deucher
Cc: Jerome Glisse
---
drivers/gpu/drm
On Tue, Feb 28, 2012 at 3:06 PM, Felix Kuehling
wrote:
> On 12-02-28 09:40 AM, Mario Kleiner wrote:
>>
>> Ok, you had a larger test set of machines and more specific test cases
>> for this problem, i'm convinced. Thanks for all the testing.
>> You have my...
>>
>> Reviewed-by: Mario Kleiner
>
>
On Wed, 2012-02-29 at 12:49 +0800, che...@lemote.com wrote:
> > On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> >> 在 2012年2月17日 下午5:27，Chen Jie 写道：
> >> >> One good way to test gart is to go over GPU gart table and write a
> >> >> dword using the GPU at end of each page something like 0xCAFED
On Wed, 2012-02-29 at 11:04 -0500, alexdeuc...@gmail.com wrote:
> From: Sebastian Biemueller
>
> The bo is removed from the list at the top of
> radeon_vm_bo_rmv(), but then the list is used
> in radeon_vm_bo_update_pte() to look up the vm.
> remove the bo_list entry at the end of the
> function
Hi,
can you look at problem with setting display brightness on radeon 6470 card?
http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg02862.html
https://bugzilla.kernel.org/show_bug.cgi?id@862
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed
remove declared but unused functions from drmP.h, fix the comments
where necessary. Also, remove drm_mem_info which is unused.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_irq.c|4 ++--
drivers/gpu/drm/drm_memory.c | 19 ---
include/drm/drmP.h |9 --
From: Sebastian Biemueller
The bo is removed from the list at the top of
radeon_vm_bo_rmv(), but then the list is used
in radeon_vm_bo_update_pte() to look up the vm.
remove the bo_list entry at the end of the
function instead.
Signed-off-by: Alex Deucher
Cc: Jerome Glisse
---
drivers/gpu/drm
On Mon, Feb 27, 2012 at 16:43, Tomasz Stanislawski
wrote:
> The documentation of DMABUF says fallowing words about map_dma_buf callback.
>
> "It is one of the buffer operations that must be implemented by the
> exporter. It should return the sg_table containing scatterlist for this
> buffer, mappe
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
Am Mittwoch, den 29.02.2012, 10:36 + schrieb Dave Airlie:
> On Tue, Feb 28, 2012 at 3:06 PM, Felix Kuehling
> wrote:
> > On 12-02-28 09:40 AM, Mario Kleiner wrote:
> >>
> >> Ok, you had a larger test set of machines and more specific test cases
> >> for this problem, i'm convinced. Thanks for
On 29.02.2012 00:23, Jerome Glisse wrote:
On Tue, 2012-02-28 at 23:19 +0100, Christian König wrote:
Without this fix the driver randomly treats
textures as arrays and I'm really wondering
why gcc isn't complaining about it.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r600_cs.c |
On Tue, Feb 28, 2012 at 3:06 PM, Felix Kuehling wrote:
> On 12-02-28 09:40 AM, Mario Kleiner wrote:
>>
>> Ok, you had a larger test set of machines and more specific test cases
>> for this problem, i'm convinced. Thanks for all the testing.
>> You have my...
>>
>> Reviewed-by: Mario Kleiner
>
> T
remove declared but unused functions from drmP.h, fix the comments
where necessary. Also, remove drm_mem_info which is unused.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_irq.c|4 ++--
drivers/gpu/drm/drm_memory.c | 19 ---
include/drm/drmP.h |9 --
50 matches
Mail list logo
