.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140910/9eb67514/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140910/d1b162c1/attachment.html>
HDMI currently stops working after a system suspend/resume cycle. The
cause is that the mode setting states in hardware gets lost and isn't
restored across the suspend/resume cycle.
The patch adds a very basic suspend/resume support to imx-drm driver,
and calls drm_helper_resume_force_mode() in .
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #8 from Alex Deucher ---
to be clear, are you saying that it's working again with 3.16? E.g.,
3.13 -> works
3.14 -> doesn't work
3.16 -> works
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #7 from Javier Fernandez ---
Hello again,
i have been able to boot correctly with the open source driver using the Ubuntu
specific kernel 3.16.0-14-lowlatency
should i try with upstream 3.16.2 ?
--
You are receiving this mail becau
All those ipu_*_put() calls in ipu_plane_dpms() are unnecessary,
because the only occurrence of ipu_plane_dpms() with 'mode' not being
DRM_MODE_DPMS_ON is in function ipu_disable_plane(), which already
has a ipu_plane_put_resources() call to put those ipu resources right
after ipu_plane_dpms().
So
On Wed, Sep 10, 2014 at 09:25:29PM +0300, Ville Syrj?l? wrote:
> On Wed, Sep 10, 2014 at 12:04:18PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Fold intel_pipe_set_base() in the update primary plane path merging
> > pieces of code that are common to both paths.
> >
> > Basica
On Wed, Sep 10, 2014 at 12:04:18PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Fold intel_pipe_set_base() in the update primary plane path merging
> pieces of code that are common to both paths.
>
> Basically the the pin/unpin procedures are the same for both paths
> and some check
On Wed, 2014-09-10 at 17:54 +0200, David Herrmann wrote:
> * User-space currently has a hard-time figuring out which backlight device to
>use, and which backlight device belongs to which display. So far, most
>systems only provide backlight-devices for internal displays, so figuring
> ou
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140910/6a692d02/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140910/eb63de16/attachment.html>
On Wed, Sep 10, 2014 at 12:04:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Factor out a piece of code from intel_pipe_set_base() that updates
> the pipe size and adjust fitter.
>
> This will help refactor the update primary plane path.
>
> v2: use struct intel_crtc as argument
On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Optimize code avoiding helding dev mutex if old fb and current fb
> are the same.
>
> v2: take Ville's comments
> - move comment along with the pin_and_fence call
> - check for error before c
On Wed, Sep 10, 2014 at 07:26:53PM +0300, Ville Syrj?l? wrote:
> On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Optimize code avoiding helding dev mutex if old fb and current fb
> > are the same.
> >
> > v2: take Ville's comments
> > - move
ping.
On Wed, Aug 27, 2014 at 7:59 PM, Ajay Kumar wrote:
> This series is based on master branch of Linus tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> I have tested this after adding few DT changes for exynos5250-snow and
> exynos5420-peach-pit boards.
>
> The V
Hi
On Tue, Sep 9, 2014 at 10:16 AM, Ville Syrj?l?
wrote:
> On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> From my POV I don't think the modesetting interface needs to take
>> crtcs, just connectors and modes,
>> so I'm wondering going forward for atomic should we even accept crtc
From: Dave Airlie
Just move this into a separate header file, and make the
two users use it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ati_pcigart.c | 2 ++
drivers/gpu/drm/r128/r128_drv.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.h | 1 +
include/drm/ati_pcigart.h |
From: Dave Airlie
This moves the drm_dma and drm_bufs stuff out of drmP.h as
much as possible and hides it in drm_legacy.h.
It built.
Signed-off-by-: Dave Airlie
---
drivers/gpu/drm/drm_bufs.c| 2 +-
drivers/gpu/drm/drm_dma.c | 10 ++---
drivers/gpu/drm/drm_fops.c
Backlight devices have always been managed independently of display
controllers. They're often controlled via different hardware interfaces
and their relationship to display-controllers varies vastly between
different boards. However, display brightness is obviously a property of
a display, and thu
So far backlights have only been controlled via sysfs. However, sysfs is
not a proper user-space API for runtime modifications, and never was
intended to provide such. The DRM drivers are now prepared to provide
such a backlight link so user-space can control backlight via DRM
connector properties.
There is really no reason to use a mutex to protect a simple list. Convert
the list-lock to a simple spinlock instead.
The spin-locks prepare for a backlight_find() helper, which should
preferably be usable from atomic context. A mutex would prevent that, so
use an irq-save spinlock instead.
Sign
Use static initializers instead of setting up global variables during
runtime. This reduces code size and execution time.
Signed-off-by: David Herrmann
---
drivers/video/backlight/backlight.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/bac
Hi
This series introduces a link between DRM connectors and backlight-class
devices. It tries to solve some long standing issues:
* User-space currently has a hard-time figuring out which backlight device to
use, and which backlight device belongs to which display. So far, most
systems onl
On Wed, Sep 10, 2014 at 5:29 PM, Daniel Vetter
wrote:
> On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
> wrote:
>> Hmm, not quite an ack from my side for the pull in its current form. I
>> said if the two remaining issues i mentioned are addressed, then i'm
>> happy with it and can have my revie
I've read INVBL as "invalid backlight" and got mightly confused.
The #defines are already fairly long and we can afford to extend
them a bit more without resulting in ugly code all over.
I'm not sure how useful the complicated bitmask return value of these
functions really are since no one checks
Imo u32 hints at a register value, but in reality all callers only
care whether the sampled timestamp is precise or not. So give them
just a bool.
Also move the declaration out of drmP.h, it's only used in drm_irq.c.
Cc: Mario Kleiner
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
drivers
Drivers without a hardware vblank counter simply can't account for the
vblanks that happened while the vblank interrupt was off. To check
this grab a vblank timestamp and if the result is dubious follow the
normal save-and-disable logic.
Drivers should prevent this by setting vblank_disable_allowe
With the new support for immediate vblank disabling we always disabled
the vblank interrupt right away, irrespective of the vblank offdelay
setting.
But being able to let vblanks run forever is fairly useful for
debugging, so restore that behaviour.
Suggested-by: Mario Kleiner
Cc: Mario Kleiner
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
wrote:
> Hmm, not quite an ack from my side for the pull in its current form. I
> said if the two remaining issues i mentioned are addressed, then i'm
> happy with it and can have my reviewed/acked-by. Looking at the code
> they haven't been adressed.
Hi
On Wed, Sep 10, 2014 at 10:10 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves the drm_dma and drm_bufs stuff out of drmP.h as
> much as possible and hides it in drm_legacy.h.
>
> It built.
I guess this is now obsolete with Daniel's series? I prefer his way
(using a global drm_legac
Hi
On Wed, Sep 10, 2014 at 12:43 PM, Daniel Vetter
wrote:
> Also sprinkle the drm_legacy_ prefix where missing.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> drivers/gpu/drm/drm_legacy.h | 7 +++
> drivers/gpu/drm/drm_scatter.c | 8
> include/
Hi
On Wed, Sep 10, 2014 at 12:43 PM, Daniel Vetter
wrote:
> Also drop the unneeded EXPORT_SYMBOL and sprinkle drm_legacy_ prefixes
> where missing.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_bufs.c | 2 +-
> drivers/gpu/drm/drm_dma.c| 10 --
> drivers/gpu/drm/d
Hi Dave,
A few more radeon patches for 3.18. This patch set gives us more
flexibility with respect to buffer placement in vram with respect
to CPU access. E.g., if you know you will not need CPU access, we can
now pin outside of the CPU window, reducing contention for the
CPU window space.
We a
e-mail snafu, sent it too early by accident, and from a gmail web
interface which i'm apparently incapable of using properly...
The second fix should look like this:
> A simple fix in static void vblank_disable_and_save() would be to
> replace the new...
>
> if (!vblank->enabled) {
>
> ... check
Hmm, not quite an ack from my side for the pull in its current form. I
said if the two remaining issues i mentioned are addressed, then i'm
happy with it and can have my reviewed/acked-by. Looking at the code
they haven't been adressed.
However, this is easily fixable on top of the current patches
Hi Dave, more fixes for 3.17, almost all Cc: stable material.
BR,
Jani.
The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd:
Linux 3.17-rc4 (2014-09-07 16:09:43 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-f
Dave any opinion on this patch set? Are you ok with me including it
in my next drm-next pull request? It'd be nice to get some additional
review on the ttm changes, but it shouldn't really affect any other
drivers unless they enable shared fences for concurrent buffer reads.
We'd like to get this
On Wed, Sep 10, 2014 at 05:36:08PM +0200, Daniel Vetter wrote:
> With the new support for immediate vblank disabling we always disabled
> the vblank interrupt right away, irrespective of the vblank offdelay
> setting.
>
> But being able to let vblanks run forever is fairly useful for
> debugging,
Quoting Stephen Boyd (2014-09-05 17:00:00)
> On 09/04, Stephen Boyd wrote:
> >
> > I don't understand why we need to hold the prepare lock around
> > the kref_put(), so I changed the flow so that we don't do this
> > when we unregister a clock.
>
> Ok we hold the prepare mutex to make sure get an
Hi Dave,
So here's the final bits of Ville's vblank rework with a bit of cleanup
from Mario on top.
The neat thing this finally allows is to immediately disable the vblank
interrupt on the last drm_vblank_put if the hardware has perfectly
accurate vblank counter and timestamp readout support. On
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
During testing your compone
On Mon, Sep 8, 2014 at 8:43 PM, Dave Airlie wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor co
patch didn't handle max_offset == 0 correctly. Attaching a fixed v2
patch and your patch rebased on top of that.
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
-- next part -
On Wed, Sep 10, 2014 at 06:23:07PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just move this into a separate header file, and make the
> two users use it.
>
> Signed-off-by: Dave Airlie
I've shuffled this into the new include/drm/drm_legacy.h I'm creating, but
this makes more sense. Can
Only used in one place ever, so put it right next to that.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 2 ++
include/drm/drmP.h| 8
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index fcc9d7d
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 2 ++
include/drm/drmP.h | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index d6dc75534304..7e459bf38c26 100644
--- a/drivers/gpu/d
Unfortunately we can't move struct drm_lock_data easily since
it's embedded into struct drm_master. And figuring out where exactly
this struct should be allocated isn't that simple ...
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 17 -
include/drm/drm_legacy.h | 17
A few odd cases:
- mgag200 someho had a totally unused drm_dma_handle_t. Remove it.
- i915 still uses the legacy pci dma alloc api, so grows an include.
Everything else fairly standard.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 1 +
drivers/gpu/drm/drm_info.c
And replace the drm_core_ prefix with drm_legacy_ since really, this
isn't core stuff.
Also drop drm_core_dropmap since it's unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c| 12 ++--
drivers/gpu/drm/i810/i810_dma.c | 8
drivers/gpu/drm/mga/mga
If we push down the ioctl table in drm_ioctl.c they're not required
any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 230 ++--
include/drm/drmP.h | 22 +
2 files changed, 118 insertions(+), 134 deletions(-)
diff --git
Drivers really, really have no business even looking at this lock. And
thankfully they don't.
So unexport it and move the declaration to drm_internal.h.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 1 -
drivers/gpu/drm/drm_internal.h | 1 +
drivers/gpu/drm/drm_lock.c |
This way drivers can't grow crazy ideas any more, and it also
helps a bit in reviewing EXPORT_SYMBOLS.
v2: Even more stuff. Unfortunately we can't move drm_vm_open_locked
because exynos does some horrible stuff with it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 1 +
dri
No user at all.
My guess is that this is a leftover from ttm before it used
the more abstract helpers to register/unregister its sysfs
objects (see drm_sysfs.h). At least in the existing history
it was never used.
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 1 -
1 file changed, 1 dele
Also sprinkle the customary legacy_ prefix.
Unfortunately we can't move the other functions since i915 is still
using them. Shame on me for that one :(
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 2 +-
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_vm.c | 2 +-
inc
Only used by radeon/ati ums drivers, so let's hide it better.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ati_pcigart.c | 1 +
include/drm/drmP.h| 25 -
include/drm/drm_legacy.h | 24
3 files changed, 25 insertions(+), 25 de
And move a few legayc functions to start things over there.
It compiles ...
Inspired by a patch from Dave Airlie, but with a split between drm.ko
private legacy functions and stuff used by drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_legacy.h| 1 +
drivers/gpu/drm/i81
---
drivers/gpu/drm/drm_legacy.h | 2 ++
include/drm/drmP.h | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index d8bc895bc376..fd69263cbcca 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/
Also sprinkle the drm_legacy_ prefix where missing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
drivers/gpu/drm/drm_legacy.h | 7 +++
drivers/gpu/drm/drm_scatter.c | 8
include/drm/drmP.h| 7 ---
4 files changed, 13 insertions(+), 13 del
Also drop the unneeded EXPORT_SYMBOL and sprinkle drm_legacy_ prefixes
where missing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 2 +-
drivers/gpu/drm/drm_dma.c| 10 --
drivers/gpu/drm/drm_fops.c | 2 +-
drivers/gpu/drm/drm_legacy.h | 8
include/drm
Hi all,
Motivated by some irc discussions and a quick patch from Dave I've decided to
clean up drmP.h. This series creates two new header files:
- "drm_internal.h" for stuff private to drm.ko
- for declaratations which are only used by non-kms legacy
drivers.
Result is a net reduction of drmP.
Hi Inki,
To test it properly I have to fix init/remove bugs [1].
Of course these bugs were not introduced by this patch,
but they prevented some basic tests.
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
I have tested successfully your patch with trats and universal_c210 b
From: "Y.C. Chen"
Type error and cause AST2000 cannot be detected correctly
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index b027e33..b792194 100
From: "Y.C. Chen"
Some config settings like 3rd TX chips will not get correctly
if the extended reg is protected
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Vi
From: Gustavo Padovan
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use struct intel_crtc as argument to intel_update_pipe_size()
v3: use 'crtc' as argument name
Signed-off-by: Gus
From: Gustavo Padovan
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
v2: take Ville's comments
- move comment along with the pin_and_fence call
- check for error before calling i915_gem_track_fb
- move old_obj != obj to an upper if conditi
Hi Dave,
Just a few fixes for radeon for 3.17.
The following changes since commit 68c78bd67bd6f868474ac75d98ea7d6ebf28d2e7:
Merge branch 'linux-3.17' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2014-09-05
09:27:33 +1000)
are available in the git repository at:
On Tue, Sep 09, 2014 at 05:49:46PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Optimize code avoiding helding dev mutex if old fb and current fb
> are the same.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> 1 file c
Hi Dave,
Could you pull in Steve Longerbeam's preparation series for capture
support? The first two patches change the ipu_cpmem API. They need to be
kept together and touch the staging driver, so I have prepared a tag
containing just the two of them for Greg to pull.
The following changes since
This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF inputs.
It maintains the audio format and rate constraints according
to the HDMI device parameters (EDID) and does dynamic input
switch in the TDA998x I2C driver on start/stop audio streamin
On Thu, Sep 4, 2014 at 2:01 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_
On Thu, Sep 4, 2014 at 2:01 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This patch adds a new flag to the ttm_validate_buffer list to
> add the fence as shared to the reservation object.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/qxl/qxl_
Hi Dave, main pull for 3.18:
1) add LVDS support for mdp4 (tested with auo B101XTN01.0 panel)
2) add B101XTN01.0 panel
3) bit of gpu refactoring to prepare for addition of addition gpu
generations beyond just a3xx
Thierry, I wasn't quite sure if I should include the panel patch or if
you were
On Tue, Sep 09, 2014 at 07:22:49PM -0400, Rob Clark wrote:
> On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrj?l?
> wrote:
> > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
> >> Hi,
> >>
> >> So I've been attempting to hide the 30" Dell MST monitors in the
> >> kernel, and ran into a numbe
On Thu, Sep 4, 2014 at 2:01 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This allows us to specify if we want to sync to
> the shared fences of a reservation object or not.
>
> Signed-off-by: Christian K?nig
Just one minor copy/paste typo in the comments below. With that fixed:
Rev
A couple more little fixes:
1) fix from llvm/clang folks
2) fix build if common clock framework is not used
3) if vram carveout is used, have default size for vram carveout
---
The following changes since commit fdcaa1dbb7c6ed419b10fb8cdb5001ab0a00538f:
Merge tag 'ipu-3.18' of git://git.peng
ou are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140910/9075debc/attachment-0001.html>
Ok I've stumbled over the exynos mmap stuff again while cleaning up
drm legacy cruft and I just don't get what you're doing and why
exactly exynos needs to be special.
_All_ other drm drivers happily get along with the vma offset manger
stuff to handle mmaps, but somehow exynos does something real
Y.C. Chen writes:
> From: "Y.C. Chen"
>
> Type error and cause AST2000 cannot be detected correctly
>
> Signed-off-by: Y.C. Chen
> ---
> drivers/gpu/drm/ast/ast_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/g
Y.C. Chen writes:
> From: "Y.C. Chen"
>
> Some config settings like 3rd TX chips will not get correctly
> if the extended reg is protected
>
> Signed-off-by: Y.C. Chen
> ---
> drivers/gpu/drm/ast/ast_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/as
On Wed, Sep 10, 2014 at 4:23 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Just move this into a separate header file, and make the
> two users use it.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/ati_pcigart.c | 2 ++
> drivers/gpu/drm/r128/r128_
On Wed, Sep 10, 2014 at 12:03 AM, Michel D?nzer wrote:
> On 10.09.2014 01:28, Alex Deucher wrote:
>>
>> On Mon, Sep 8, 2014 at 9:15 PM, Michel D?nzer wrote:
>>>
>>> On 09.09.2014 09:47, Michel D?nzer wrote:
On 09.09.2014 02:36, Alex Deucher wrote:
>
>
> Updated version with
On Wed, Sep 10, 2014 at 4:20 AM, Ville Syrj?l?
wrote:
> On Tue, Sep 09, 2014 at 07:22:49PM -0400, Rob Clark wrote:
>> On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrj?l?
>> wrote:
>> > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> >> Hi,
>> >>
>> >> So I've been attempting to hide the
On Tue, Sep 09, 2014 at 06:58:47PM +0300, Ville Syrj?l? wrote:
> On Tue, Sep 09, 2014 at 11:43:19AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > The !crtc->enabled case will now be handled by the !visible code,
> > since the handling is basically the same.
> >
> > Signed-off-b
On Tue, Sep 09, 2014 at 02:43:14PM -0300, Gustavo Padovan wrote:
> 2014-09-09 Ville Syrj?l? :
>
> > On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Factor out a piece of code from intel_pipe_set_base() that updates
> > > the pipe size and
This allows us to drop 2 header declarations from drmP.h. The 3rd one
is also used in drm_ioctl.c, so for that create a new drm_internal.h
header for non-legacy non-kms (since we have internal headers for
those parts already) declarations private to drm.ko.
Signed-off-by: Daniel Vetter
---
drive
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140910/3cf12cd2/attachment-0001.html>
iable suffice?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140910/67e08cb1/attachment.html>
88 matches
Mail list logo
