On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen
> wrote:
> > Hi,
> >
> > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
> >> Register OMAP DRM/KMS platform device. DMM is split into a
> >> separate device using hwmod.
> >>
> >> Signed
On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote:
> On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
> > On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen
> > wrote:
> > > Hi,
> > >
> > > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
> > >> Register OMAP DRM/KMS platform device.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 23 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 73 +
2 files changed, 85 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/ra
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +-
drivers/gpu/drm/radeon/r600.c |5 +-
drivers/gpu/drm/radeon/
It is a rw_semaphore now and only write locked
while changing the clock. Also the lock is renamed
to better reflect what it is protecting.
v2: Keep the ttm_vm_ops on IGPs
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|3 ++-
drivers/gpu/drm/radeon/radeon_device.c
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c|2 +-
drivers/gpu/drm/radeon/ni.c |2 +-
drivers/gpu/drm/rad
From: Christian Koenig
The spinlock was actually there to protect the
rptr, but rptr was read outside of the locked area.
Also we don't really need a spinlock here, an
atomic should to quite fine since we only need to
prevent it from being reentrant.
Signed-off-by: Christian Koenig
---
driver
From: Christian Koenig
The shader preemption on cayman doesn't work
correctly with multiple rings. So to be able to
still make use of the compute rings we use a
semaphore to make sure that only one IB can execute
at the same time.
This isn't as effective as shader preemption, but
also isn't as b
Try to remove or replace the cs_mutex with a
vm_mutex where it is still needed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c |7 ++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
From: Christian Koenig
Signed-off-by: Christian Koenig
---
drivers/gpu/drm/radeon/radeon.h |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3e83480..618df9a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/
From: Christian Koenig
1. It is really dangerous to have more than one
spinlock protecting the same information.
2. radeon_irq_set sometimes wasn't called with lock
protection, so it can happen that more than one
CPU would tamper with the irq regs at the same
time.
3. The pm.gui_idl
From: Christian Koenig
So we can skip the looking. Also renames sw_int to
ring_int, cause that better matches its purpose.
Signed-off-by: Christian Koenig
---
drivers/gpu/drm/radeon/evergreen.c | 32 -
drivers/gpu/drm/radeon/r100.c | 10 +++---
drivers/gpu/dr
On 23.05.2012 19:02, Jerome Glisse wrote:
On Wed, May 23, 2012 at 12:41 PM, Dave Airlie wrote:
On Wed, May 23, 2012 at 5:26 PM, Jerome Glisse wrote:
On Wed, May 23, 2012 at 12:08 PM, Dave Airlie wrote:
On Wed, May 23, 2012 at 3:48 PM, Jerome Glisse wrote:
On Wed, May 23, 2012 at 8:34 AM,
On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen wrote:
> On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
>> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen
>> wrote:
>> > Hi,
>> >
>> > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
>> >> Register OMAP DRM/KMS platform device. DMM is
On Thu, May 24, 2012 at 1:21 AM, Tomi Valkeinen wrote:
> On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote:
>> On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
>> > On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen
>> > wrote:
>> > > Hi,
>> > >
>> > > On Wed, 2012-05-23 at 15:08 -0500,
Hi,
I don't know if this patch got missed in the list traffic or if I did something
wrong but it doesn't appear to have been picked up. This is my first time
contributing so if I did anything wrong some pointers would be appreciated.
Thanks
Frank
> From: dri-devel-bounces+frank.binns=imgtec...
> + atomic_tring_int[RADEON_NUM_RINGS];
> boolcrtc_vblank_int[RADEON_MAX_CRTCS];
> - boolpflip[RADEON_MAX_CRTCS];
> - int pflip_refcount[RADEON_MAX_CRTCS];
> + atomic_t
On Thu, 2012-05-24 at 02:35 -0600, Rob Clark wrote:
> On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen wrote:
> > On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
> >> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, 2012-05-23 at 15:08 -0500, Andy
On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
> v4l2 camera working w/ tiler buffers on my pandaboard, for example.
>
> Maybe fbdev is an exception to the rule because it has no way for
> userspace to pass it a buffer t
>> Does the linux API mandates atomic_t to be a 32bits word?
>
> AFAIK it is, at least for the platforms we care about.
> ...
Then, the proper course of action would be to add to the linux API, sized
atomic operation first, wouldn't it?
--
Sylvain
___
On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND wrote:
>>> Does the linux API mandates atomic_t to be a 32bits word?
>>
>> AFAIK it is, at least for the platforms we care about.
>> ...
>
> Then, the proper course of action would be to add to the linux API, sized
> atomic operation first, wouldn'
On Thu, May 24, 2012 at 1:53 PM, Dave Airlie wrote:
> On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND wrote:
Does the linux API mandates atomic_t to be a 32bits word?
>>>
>>> AFAIK it is, at least for the platforms we care about.
>>> ...
>>
>> Then, the proper course of action would be to
On Thu, May 24, 2012 at 10:50 AM, Frank Binns wrote:
> Hi,
> I don't know if this patch got missed in the list traffic or if I did
> something wrong but it doesn't appear to have been picked up. This is my
> first time contributing so if I did anything wrong some pointers would be
> appreciated
The framebuffer helper panic notifier is unregistered, in drm_fb_helper_fini(),
when kernel_fb_helper_list goes from being non-empty to empty. However, in
drm_fb_helper_single_fb_probe(), it's possible for the panic notifier to be
registered without an element being added to this list if a drive
https://bugzilla.kernel.org/show_bug.cgi?id=12333
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=12333
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=12342
Alan changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=12342
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=12434
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=12434
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
> Does the linux API mandates atomic_t to be a 32bits word?
AFAIK it is, at least for the platforms we care about.
...
>>>
>>> Then, the proper course of action would be to add to the linux API, sized
>>> atomic operation first, wouldn't it?
>>
>> No, atomic is fine for this, I t
On Thu, May 24, 2012 at 1:01 AM, Tomi Valkeinen wrote:
>> +struct omap_drm_platform_data {
>> + struct omap_kms_platform_data *kms_pdata;
>> +};
>
> This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
> didn't just move the struct. Is that on purpose?
Good point. I can clean
https://bugs.freedesktop.org/show_bug.cgi?id=50230
--- Comment #9 from Vadim Girlin 2012-05-24 07:38:10 PDT ---
Created attachment 62057
--> https://bugs.freedesktop.org/attachment.cgi?id=62057
[PATCH] radeon/llvm: fix sampler index in llvm_emit_tex
Does this patch help?
--
Configure bugmail
On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen wrote:
> On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
>
>> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
>> v4l2 camera working w/ tiler buffers on my pandaboard, for example.
>>
>> Maybe fbdev is an exception to the ru
On Thu, 2012-05-24 at 10:09 -0500, Gross, Andy wrote:
> On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen wrote:
> > On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
> >
> >> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
> >> v4l2 camera working w/ tiler buffers on my pand
On Thu, May 24, 2012 at 3:49 AM, Christian König
wrote:
> From: Christian Koenig
>
> 1. It is really dangerous to have more than one
> spinlock protecting the same information.
>
> 2. radeon_irq_set sometimes wasn't called with lock
> protection, so it can happen that more than one
> CPU wo
https://bugs.freedesktop.org/show_bug.cgi?id=50232
--- Comment #1 from Vadim Girlin 2012-05-24 08:50:00 PDT ---
Please test with the first patch from bug 50230.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You ar
On Thu, May 24, 2012 at 11:35:15AM -0400, Alex Deucher wrote:
> On Thu, May 24, 2012 at 3:49 AM, Christian König
> wrote:
> > From: Christian Koenig
> >
> > 1. It is really dangerous to have more than one
> > spinlock protecting the same information.
> >
> > 2. radeon_irq_set sometimes wasn't c
On Thu, May 24, 2012 at 09:49:05AM +0200, Christian König wrote:
> It is completely unnecessary to create fences
> before they are emitted, so remove it and a bunch
> of checks if fences are emitted or not.
>
> Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/
Hi Dave,
A set of fixes for 3.5:
- Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload,
fix pch pll asserts.
- Fix up eDP panel power sequencing - turns out we need to keep vdd on
while switching everything off.
- Reject doubleclocked modes on dp.
- Fixup sdvo interlaced ha
On Thu, May 24, 2012 at 09:49:06AM +0200, Christian König wrote:
> Signed-off-by: Christian König
Need a small improvement see below, otherwise
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon.h | 23 ++-
> drivers/gpu/drm/radeon/radeon_fence.c | 73
> ++
On Thu, May 24, 2012 at 09:49:07AM +0200, Christian König wrote:
> Move inter ring syncing with semaphores into the
> existing ring allocations, with that we need to
> lock the ring mutex only once.
>
> Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/e
On Thu, May 24, 2012 at 09:49:08AM +0200, Christian König wrote:
> It is a rw_semaphore now and only write locked
> while changing the clock. Also the lock is renamed
> to better reflect what it is protecting.
>
> v2: Keep the ttm_vm_ops on IGPs
>
> Signed-off-by: Christian König
Reviewed-by: J
On Thu, May 24, 2012 at 09:49:09AM +0200, Christian König wrote:
> From: Christian Koenig
>
> Signed-off-by: Christian Koenig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon.h |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/dri
On Thu, May 24, 2012 at 09:49:10AM +0200, Christian König wrote:
> From: Christian Koenig
>
> The spinlock was actually there to protect the
> rptr, but rptr was read outside of the locked area.
>
> Also we don't really need a spinlock here, an
> atomic should to quite fine since we only need to
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: 21 May 2012 10:04
> To: Dave Airlie
> Cc: Tom Cooksey; linaro-mm-...@lists.linaro.org; xorg-
> de...@lists.x.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Linaro-mm-sig]
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #7 from Vladislav Tcendrovskii 2012-05-24 16:30:46
---
I have tested kernel 3.4.
Results look a bit strange:
When i use modprobe radeon, I have the same pixel noise, which I had before.
If I start X, I have screen with windows
During unload, don't cleanup the framebuffer if it is not valid.
Signed-off-by: Andy Gross
---
drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fbdev.c
b/drivers/staging/omapdrm/omap_fbdev.c
index
Failures during the dmm probe can cause the kernel to crash. Moved
the spinlock to a global and moved list initializations immediately
after the allocation of the dmm private structure.
Signed-off-by: Andy Gross
---
drivers/staging/omapdrm/omap_dmm_priv.h |1 -
drivers/staging/omapdrm/omap
Just a few small items caught in my net while trawling the code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Ville Syrjälä
The rest of the code uses stdint types, so use them in
drm_property_change_is_valid() as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
From: Ville Syrjälä
Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
UINT_MAX.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e1b53fb..5fc198d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/dr
From: Ville Syrjälä
Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
format).
Fix intel_init_framebuffer() to match hardware and driver limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 & co. are supported on Gen3 and earlier
* XRGB210101010 & co.
From: Ville Syrjälä
The framebuffer offset must be aligned to (macro)pixel size.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel
From: Ville Syrjälä
Take fb->offset[0] into account when calculating the linear and tile x/y
offsets.
For non-tiled surfaces fb->offset[0] is simply added to the linear
byte offset.
For tiled surfaces treat fb->offsets[0] as a byte offset into the
linearized view of the surface. So we end up co
From: Ville Syrjälä
MI display flips can't handle some changes in the framebuffer
format or layout. Return an error in such cases.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
Make sure the the framebuffer stride is smaller than the maximum
accepted by any plane.
Also when using a tiled memory make sure the object stride matches
the framebuffer stride.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +
Add all kinds of framebuffer layout sanity checks to the code.
Also the framebuffer offset wasn't properly handled, and code dealing
with the primary plane pixel format was quite broken.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://l
From: Ville Syrjälä
Zero initialize the mode_cmd structure when creating the kernel
framebuffer. Avoids having uninitialized data in offsets[0] for
instance.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
First add a bit of helper functions to aid in the clipping duties
(those patches were already posted a long time ago) and then utilize
them to properly clip the video sprites to the pipe dimensions.
I also threw in a few small cleanup patches dealing with the sprite code.
_
From: Ville Syrjälä
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to a best effort approach, where the
source coordinates are rounded to the nearest (macro)
From: Ville Syrjälä
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 19 +++
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers
From: Ville Syrjälä
The framebuffer pixel format is already checked by the common code.
So there's no way an invalid format could reach the driver. So instead
of falling back to a default format, call BUG().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c |8 ++--
From: Ville Syrjälä
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 155
include/drm/drm_crtc.h | 24 +++
2 files
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 102
include/drm/drm_crtc.h |4 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
ind
On Thu, May 24, 2012 at 1:53 PM, wrote:
> Just a few small items caught in my net while trawling the code.
for the series:
Reviewed-by: Alex Deucher
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mail
I can easily trigger a crash in nouveau interrupt handler by unbinding
and rebinding the GPU.
The command used:
echo $pci_device > nouveau/unbind && \
sleep 5 && \
echo $pci_device > nouveau/bind
Kernel is 3.4.0 with modular drm/nouveau.
GPU is NVidia nForce IGP (NV11)
Unbind
On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
> UINT_MAX.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 10 +-
> 1 files changed, 9 in
Currently the video sprites appear to get disabled on modeset more by
accient than by design.
With the current API that behaviour makes very little sense to me.
You first enable some plane, and then it can get disabled due to some
unrelated operation.
So these patches change the behaviour so that
From: Ville Syrjälä
If the update_plane() operation succeeds, make a copy of the requested
src and crtc coordinates, so that the the plane may be reclipped if the
display mode changed later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c |8
include/drm/drm_crtc.h
From: Ville Syrjälä
Add an optional driver specific restore_fbdev_mode() hook to
drm_fb_helper. If the driver doesn't provide the hook,
drm_fb_helper_restore_fbdev_mode() is called directly as before.
In this hook the driver can disable additional planes, cursors etc.
that shouldn't be visible w
From: Ville Syrjälä
When setting a display mode, disable all planes on the CRTC beforehand,
and re-enable them after the new mode has been set.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 48 ++
1 files changed, 48 insertions(+), 0
From: Ville Syrjälä
Convert intel_fb_restore_mode to be useable as the
drm_fb_helper.restore_fbdev_mode hook. This will cause all planes to be
disabled when swithing back to fbcon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |
On Thu, 24 May 2012 21:08:58 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Take fb->offset[0] into account when calculating the linear and tile x/y
> offsets.
>
> For non-tiled surfaces fb->offset[0] is simply added to the linear
> byte offset.
>
> For tiled surfaces tre
On Thu, 24 May 2012 21:29:46 +0300
ville.syrj...@linux.intel.com wrote:
> Currently the video sprites appear to get disabled on modeset more by
> accient than by design.
>
> With the current API that behaviour makes very little sense to me.
> You first enable some plane, and then it can get disab
On Thu, May 24, 2012 at 10:43 AM, Andy Gross wrote:
> Failures during the dmm probe can cause the kernel to crash. Moved
> the spinlock to a global and moved list initializations immediately
> after the allocation of the dmm private structure.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clar
On Thu, May 24, 2012 at 10:44 AM, Andy Gross wrote:
> During unload, don't cleanup the framebuffer if it is not valid.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> di
On Thu, May 24, 2012 at 10:44 AM, Andy Gross wrote:
> During unload, don't cleanup the framebuffer if it is not valid.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> di
On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:29:46 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > Currently the video sprites appear to get disabled on modeset more by
> > accient than by design.
> >
> > With the current API that behaviour makes very
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:08:58 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Take fb->offset[0] into account when calculating the linear and tile x/y
> > offsets.
> >
> > For non-tiled surfaces fb->of
On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
> > UINT_MAX.
> >
> > Signed-off-by: Ville Syrjälä
>
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > On Thu, 24 May 2012 21:08:58 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Take fb->offset[0] into account when calculatin
On Thu, May 24, 2012 at 09:54:37PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote:
> > On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Make sure 'width * cpp' and 'height * pitch
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #8 from Jérôme Glisse 2012-05-24 19:13:23
---
Created an attachment (id=73382)
--> (https://bugzilla.kernel.org/attachment.cgi?id=73382)
Fix backend map
This patch should fix your issue
--
Configure bugmail: https://bugzilla.
On Thu, May 24, 2012 at 08:49:53PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote:
> > On Thu, 24 May 2012 21:29:46 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > Currently the video sprites appear to get disabled on modeset more by
> > > accie
This is some very early demo code for the atomic modesetting feature.
According to my current plan there would be just one ioctl. You simply feed
it an arbitrary list of object properties and the implementation will decice
how it can apply those (for example, whether it can complete the operation
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c |8 +---
include/drm/drm_crtc.h |4
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6dafb99..ce0f446 100644
--- a/dri
From: Ville Syrjälä
Treat a range property as signed when the unsigned minimum value is
larger than the unsigned maximum value.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
From: Ville Syrjälä
Refactor the code to check whether an object has a specific property
to a new function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/driv
From: Ville Syrjälä
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crt
From: Ville Syrjälä
First draft.
The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.
Detailed error reporting is missing
From: Ville Syrjälä
Just a quick prototype to test the atomic modeset API. Implemented
via already existing non-atomic mechanisms internally.
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_atomic.c | 788 ++
drivers/gpu/drm/i915/in
https://bugs.freedesktop.org/show_bug.cgi?id=50230
--- Comment #10 from almos 2012-05-24 13:25:32 PDT ---
(In reply to comment #9)
> Created attachment 62057 [details] [review]
> [PATCH] radeon/llvm: fix sampler index in llvm_emit_tex
>
> Does this patch help?
Yes, the patch fixes it. I also tri
https://bugs.freedesktop.org/show_bug.cgi?id=50232
--- Comment #2 from almos 2012-05-24 13:25:38 PDT ---
(In reply to comment #1)
> Please test with the first patch from bug 50230.
The revert patch fixes the ghost image problem. The warning is still printed,
but the visuals seem to be good now.
Hi all,
I've got fed up with our sorry state of connector detection and rampant edid re
and rere-reading.
This patch series lays the groundwork in the drm helpers so that drivers can
avoid all this madness (at least on working hw) and properly cache the edid.
With the additional changes for drm/
Useful if drivers want to be slightly more clever about hotplug
handling.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
include/drm/drm_crtc_helper.h |1 +
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_c
Instead of reusing the polling code for hdp handling, split them up.
This has a few consequences:
- Don't touch HDP capable connectors in the poll loop.
- Only touch HDP capable connectors in drm_helper_hpd_irq_event.
- Run the HDP handling directly instead of going through a work item -
all call
Useful for ->detect functions that have different behaviour if force
is set. This way probe_single_connector can avoid to do the expensive
edid dance on connectors where this is not needed.
I've checked through all drivers and set this flag everywhere where
the connector->detect function has diffe
The detection function is simply too unreliable - it doesn't
properly pick up changes right away.
For now, just set the compat flag and ignore this, because on a
quick look fixing this properly is a very big fish to fry.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |2
1 - 100 of 240 matches
Mail list logo
