On 5 February 2015 at 11:35, One Thousand Gnomes
wrote:
>> If I'm not mistaken, that would be as simple as adding
>>
>> #define VT_BUF_HAVE_RW.
>> #define scr_writew(val, addr) (*(addr) = (val))
>> #define scr_readw(addr) (*(addr))
>>
>> to arch/x86/include/asm/vga.h.
>
> and stick an
On 9 February 2015 at 10:49, Geert Uytterhoeven wrote:
> On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote:
>> On 5 February 2015 at 11:35, One Thousand Gnomes
>> wrote:
>>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>>
>>> #endif
>>>
&
ed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
Now we've unified all our backing storage handling around sg tables (even
for stolen memory), so maybe that's not useful for you guys. Just figured
I'll drop this here, it imo made our code look fairly tidy.
Che
ruct fb_info *info,
> *
> * Maps a virtual console @unit to a frame buffer device
> * @newidx.
> + *
> + * This should be called with the console lock held.
> */
> static int set_con2fb_map(int unit, int newidx, int user)
> {
What about throwing a WARN_CONSOLE_UNLOCKE
y contains
information after a crash, so you need to rehang your machine if you've
rebooted since then.
Thanks, Daniel
> Feb 28 11:42:47 mithrandir kernel: [15627.758428] [drm:i915_wait_request]
> *ERROR* i915_wait_request returns -11 (awaiting 7 at 4, next 8)
> Feb 28 11:42:47 mithr
While investigating Intel i5 Arrandale GPU lockups with -rc4, I
noticed a lock imbalance.
Signed-off-by: Daniel J Blueman
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc03537..f5fee1b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915
rather gross amount of fragile code duplication
between these two parts of the kernel intel graphics driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c |7 ---
drivers/gpu/drm/i915/i915_gem.c |8
include/drm/drmP.h |1 -
3 files
No caller (rightly) cares about it, so drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c |4 ++--
include/drm/drmP.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index
There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_agpsupport.c | 40 +++--
drivers/gpu/drm/drm_memory.c | 12 ++
include/drm/d
next on it (due to my make-gem-embeddable work).
Tested on my agp rv570 and my i945 with no ill effects.
Please review and merge.
Thanks, Daniel
Daniel Vetter (3):
drm: kill drm_agp_chipset_flush
drm: drop return value of drm_free_agp
drm: kill agp indirection mess
drivers/gpu/drm/drm_ag
On Mon, Apr 12, 2010 at 10:51:20AM -0700, Eric Anholt wrote:
> On Fri, 9 Apr 2010 21:05:03 +0200, Daniel Vetter
> wrote:
> > Daniel Vetter (6):
> > drm: extract drm_gem_object_init
> > drm: free core gem object from driver callbacks
> > drm/i915: introduce i
roduce it anymore and I currently don't yet have a clue about
what's wrong. Currently I'm suspecting a locking goof-up.
Is there a bugzilla entry to track this?
-Daniel
> > [ 1878.810147] PM: Syncing filesystems ... done.
> > [ 1878.903316] Freezing user space processe
Just embed it and adjust the pointers, No other changes (that's
for later patches).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 58 +++---
2 files changed, 30 insertions(+), 29 deletions(-)
Comments on the patches and my future plans highly welcome.
Yours, Daniel
Daniel Vetter (6):
drm: extract drm_gem_object_init
drm: free core gem object from driver callbacks
drm/i915: introduce i915_gem_alloc_object
drm/i915: embed the gem object into drm_i915_gem_object
drm/i915: don't
Thanks to the to_intel_bo helper, this change is rather trivial.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu
When drivers embed the core gem object into their own structures,
they'll have to do this. Temporarily this results in an ugly
kfree(gem_obj);
in every gem driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 10 +++---
drivers/gpu/drm/i915/i915_
Luckily the change is quite a little bit less invasive than I've
feared.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 +++
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 21 ++---
driver
Just preparation, no functional change.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c | 12 +---
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_fb.c |2 +-
drivers/gpu/drm/i915
This function can be used by drivers who allocate the drm gem object
on their own. No functional change in here, just preparation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 39 +--
include/drm/drmP.h|2 ++
2 files changed, 31
See http://intellinuxgraphics.org/how_to_report_bug.html for the details
of what else is needed.
Yours, Daniel
On Sun, Mar 14, 2010 at 01:19:10AM +0100, Martin Fahr wrote:
> Hi,
>
> Linux v2.6.32-rc1 introduced a bug for me, which gives me a black screen
> on my laptop when bootin
serve as a warning sign that there's likely a
layering violation ahead. After all, generic code should not muck around
in the asic private stuff.
Unconditionally including radeon_asic.h therefore runs counter to the
bigger idea behind my patches.
Cheers, Daniel
--
Dan
With these static structs gone, radeon_asic.h is a real header file
and can be used as such.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.c | 487 +
drivers/gpu/drm/radeon/radeon_asic.h | 489 --
2 files
And move asic init plus a few related functions from radeon_device.c
to it. This file will hold all the asic structures in the future,
but atm they're still stuck in radeon_asic.h.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/Makefile|2 +-
drivers/gpu/drm/radeon/rad
This just an example to show what radeon_asic.h might be good for.
Before Jerome kills it ;)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 47 --
drivers/gpu/drm/radeon/radeon_asic.h | 52 +++--
2 files
is is just an example
to convince Jerome that radeon_asic.h might not be totally useless ;)
Again, comments higly welcome.
Yours, Daniel
Daniel Vetter (5):
drm/radeon: create radeon_asic.c
drm/radeon: move asic structs to radeon_asic.c
drm/radeon: unconfuse return value of radeon
No one cares about it, so set it to void.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon
In essence this creates a home for all asic specific declarations in
radeon_asic.h
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/evergreen.c |1 +
drivers/gpu/drm/radeon/r100.c |1 +
drivers/gpu/drm/radeon/r200.c |1 +
drivers/gpu/drm/radeon/r300.c |1
s to diverge by accident.
Well, this is exactly what I'm trying to fix here. atm radeon_asic.h
contains static struct definitions (i.e. should be a C file) and is
therefore included only exactly _once_. And contains tons of declarations
for the functions it uses. Which are actually in one case n
Ok, convinced. I'll respin the patch series along your idea (creating
radeon_asic.c) and resend.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
Download Intel® Parallel Studio Eval
Try
On Thu, Mar 11, 2010 at 04:46:01PM +0100, Jerome Glisse wrote:
> On Thu, Mar 11, 2010 at 02:06:02PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > This patch pile moves the "static struct radeon_asic " definitions
> > form radeon_asic.h into the asic-spec
is makes code-reading easier. Of
course, as someone who has just started to look at the radeon drm, I'm
biased ;)
- there was no .c file around where they'd fit.
Creating a new radeon_asic.c file would be another option of course. If
you think that's much better, I could respin
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h | 38 +-
drivers/gpu/drm/radeon/rs400.c | 72 ++
2 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r420.c| 75 ++
drivers/gpu/drm/radeon/radeon_asic.h | 39 +-
2 files changed, 77 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r420.c b
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h | 38 +-
drivers/gpu/drm/radeon/rv515.c | 72 ++
2 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/evergreen.c | 43 ++
drivers/gpu/drm/radeon/radeon_asic.h | 35 +--
2 files changed, 44 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r300.c| 105 ++
drivers/gpu/drm/radeon/radeon_asic.h | 76 +
2 files changed, 107 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h | 39 +
drivers/gpu/drm/radeon/rs600.c | 63 ++
2 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/radeon
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h | 37 +---
drivers/gpu/drm/radeon/rv770.c | 65 ++
2 files changed, 66 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
And kill the temporary function declarations. Also drop a few
unnecessary forward declarations.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/evergreen.c | 12 +-
drivers/gpu/drm/radeon/r100.c|1 +
drivers/gpu/drm/radeon/r200.c| 35
70.
Comments higly welcome.
Yours, Daniel
Daniel Vetter (14):
drm/radoen: move r100 asic struct to r100.c
drm/radoen: move r200 asic struct to r200.c
drm/radeon: move r300 asic structs to r300.c
drm/radeon: move r420 asic struct to r420.c
drm/radoen: move rs400 asic struct to rs400.c
drm
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r600.c| 43 ++
drivers/gpu/drm/radeon/radeon_asic.h | 37 +
2 files changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600
.c
To accomplish this, the declarations for a few shared functions had to
be moved from radeon_asic.h to radeon.h. They'll move back when this
cleanup is complete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r100.c| 38
drivers/gpu/drm/r
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_asic.h | 38 +-
drivers/gpu/drm/radeon/rs690.c | 72 ++
2 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
No one cares about it, so set it to void.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon
Like for r200.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/r520.c| 77 ++
drivers/gpu/drm/radeon/radeon_asic.h | 40 +-
2 files changed, 79 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r520.c b
Like for the r100.
Because radeon_asic.h is not yet usable as a header file, I had to
copy a few shared function declarations into r200.c. Yes, this is
ugly but not actually worse than current state. And it'll all be
gone when this header untangling is done.
Signed-off-by: Daniel V
On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Daniel Stone wrote:
> > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
> > the usual approach is to install your new server + drivers into a
> > separate pref
Oh, dang. Thanks for catching this. Eric, please merge.
Cc: sta...@kernel.org (for .33)
Reviewed-by: Daniel Vetter
On Sat, Mar 06, 2010 at 02:05:39PM +0300, Dan Carpenter wrote:
> We should free "params" before returning.
>
> Signed-off-by: Dan Carpenter
>
> diff --g
less do this;
the usual approach is to install your new server + drivers into a
separate prefix.
Cheers,
Daniel
pgpnHb05h5vaf.pgp
Description: PGP signature
--
Download Intel® Parallel Studio Eval
Try the new software tools fo
On Fri, Mar 05, 2010 at 07:49:32AM -0800, David Miller wrote:
> From: Daniel Stone
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
>
> You have to s
On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote:
> From: Daniel Stone
> > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> >> In fact, I argue that the moment nouveau went into Fedora and
> >> was turned on by default, the int
to
> us.
Maybe the lesson to be learned from all this is, 'if the developers
don't want something merged because they're not ready and forsee huge
problems in the future, actually listen to them instead of blindly
ramming it in regardless'? But maybe that's just me.
Chee
ew years. But we don't have enough
people (or at least enough people who aren't busy with the other parts
of their day jobs, or kids, or burnout, or whatever) to do it.
I understand that you guys are upset about this, so maybe you'd like to
donate, say, 10% of your developer ba
Hi,
On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> From: Daniel Stone
> > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> >> If it effects such a large number of people, which this noveau thing
> >> does, it's entirely relevan
t's not a friendly place. :)
>
> Heh, I guess you've never had to debug libtool then. mklib is a walk
> in the park by comparison.
In fairness though, I haven't had to debug libtool for several years
now, because it always seems to work, whereas mklib seems to encounter
new an
Fix the following compile time error:
drivers/built-in.o: In function `nouveau_connector_detect':
/home/daniel/src/linux/jup/linux-2.6/drivers/gpu/drm/nouveau/nouveau_connector.c:243:
undefined reference to `acpi_lid_open'
Signed-off-by: Daniel Mack
Cc: David Airlie
Cc: Ben
> kfree(params);
Just move the drm_gem_object_unreference before the mutex_unlock calls,
make more sense that way, IMHO.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
The Planet:
d calls the new
> ->gem_free_object_unlocked entry point if available, and
> otherwise just takes struct_mutex and just calls ->gem_free_object
Why not add a BUG_ON(!mutex_is_locked(&dev->struct_mutex)) to
drm_gem_object_unreference to catch wrong api by occasional drm hackers
like me?
-
crashes again.
> c05422d52ee6b is not the culprit. Sorry Daniel for blaming your patch.
No problem. Looks like your hunting a pretty ugly Heisenbug. There's quite
a interesting blog post by Paul McKenney, esp. the solution to "Quick Quiz 1"
might be usefull in your case:
http://pa
On Sun, Nov 29, 2009 at 05:03:51PM -0800, vehemens wrote:
> You missing the point as is rnoland. Just because the linux DRM developers
> stopped using a centralized repository, didn't mean FreeBSD shouldn't as the
> intial integration work would be still shared reducing the burden on any one
>
e hands of
> > someone besides yourself it is irrelevant.
>
> Thats the whole point of having a public respository. How else can one
> publish?
gitorious, github, people.fd.o, freebsd.org public_html, etc, etc.
Cheers,
Daniel
Compilation will otherwise break, due to using uint32_t types without
having include stdint.h.
Signed-off-by: Daniel Stone
---
shared-core/drm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/shared-core/drm.h b/shared-core/drm.h
index d97844f..9674072 100644
--- a
On Thu, Oct 08, 2009 at 10:11:40AM -0700, Eric Anholt wrote:
> On Sun, 2009-10-04 at 15:00 +0200, Daniel Vetter wrote:
> > I've simply overlooked one case in the conversion to interruptible
> > sleeps. Rectify this.
> >
> > Also delete a leftover debug printk.
I've simply overlooked one case in the conversion to interruptible
sleeps. Rectify this.
Also delete a leftover debug printk.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_overlay.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/dr
On Fri, Oct 02, 2009 at 02:38:46PM -0700, Eric Anholt wrote:
> On Tue, 2009-09-15 at 22:57 +0200, Daniel Vetter wrote:
> OK, I've finally pulled this for -next, with a bit of hand resolving of
> conflicts. I debated, because of the somewhat unusual series of adding
> the ring s
Now that the cache flushing of the memory based overlay regs works,
we can safely switch off the overlay. Beforehand it was only disabled
(like in userspace).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_overlay.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff
.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm
As long as the gpu can keep up, neither the cpu (waiting for gpu)
nore the gpu (waiting for vblank to do an overlay flip) stalls.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_gem.c |4 +-
drivers/gpu/drm/i915/intel_drv.h
It's not needed anymore.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 18 --
2 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
It is identical to I85X. Use that one instead.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
's just an unkillable X in addition to a black screen.
BUG() about it and explain in the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 17 +++-
drivers/gpu/drm/i915/intel_drv.h |9 ++-
drivers/gpu/drm/i915/intel_overlay.c | 167 +++-
e...@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_dma.c |7 +
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers
Hi all,
Latest version of my overlay kms work. I've added the new stuff as separated
patches for easier testing in case something blows up.
Please review.
Thanks, Daniel
Daniel Vetter (8):
[drm]: make drm_mode_object_find typesafe
[drm/i915]: add i915_lp_ring_sync helper
[drm/i915]:
he overlay. Looks like I've missed yet another cache flush. I've hacked
up a fix which seems to work, here, but I'd like to give it some more
testing.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mo
.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm
It is identical to I85X. Use that one instead.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
my side. This fixes fullscreen
playback.
Changes since v2:
- add underrun detection as spec'ed for i965.
- flush caches properly, fixing visual corruptions.
Tested-By: diego.abele...@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile|1 +
driver
I've tried to summarize the outcomes of various discussion in the changelog.
Please review and consider for .32.
Thanks, Daniel
Daniel Vetter (5):
[drm]: make drm_mode_object_find typesafe
[drm/i915]: require_pipe_a helper functions
[drm/i915]: add i915_lp_ring_sync helper
[drm/i9
These will be used to ensure that the clock of pipe a is running
when the overlay is switched on. Programming logic more or less
directly ported over from userspace.
Also export the already existing helper function drm_encoder_crtc_ok.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
On Fri, Sep 11, 2009 at 05:48:18AM +0200, Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
> > On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> > >
> > > And why did you suddenly start to care, while you pretty mu
de it to the
> kernel?
>
> > > No version was bumped, because i believe these are against the kernel
> > > copy of the drm, because for some reason the kernel copy never saw
> > > commit 659e9a091d3.
>
> And why did you suddenly start to care, while you p
ng DMA/whater that's efficient).
> > ...
> >Fine. I'll just push this then as a device ioctl to bring usable video on
> >8xx to kms.
>
> OK,
> Thanks,
>
> Thomas
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
much code, if anything at all. And instead I'd have
an interface in command buffer submission that looks an awfull lot like an
very special purpose ioctl in disguise. So I went down that road and
created a _real_ ioctl with well-defined semantics.
> ~ C.
Yours, Daniel
btw: intel hw has
is a delicate dance is needed,
carefully sync with the crtc output state.
So at least on intel, some overlay support on the kernel side is needed to
at least prevent race conditions that may hang the chip.
> Alex
Yours, Daniel
--
Daniel Vetter
Mail: dan..
er on
gallium thing work we probably need to extend the DRI2 proto such that X
can work as an arbiter for the overlay.
> > ...
> >btw: I don't think we can sketch out a common interface before we have a
> >second
> >implementation to go pattern hunting.
> OK. We&#
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
> 2009/8/31 Thomas Hellström :
> > Daniel Vetter wrote:
> >
> > ...
> >> In conclusion I don't think a common ioctl is worth it. But sharing some
> >> code and infrastructure
ther chipset. But I don't really
count on that, because at least radeon has textured video for all it's
chips.
> /Thomas
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
Let
let's leave it at this
for the moment. I left some dummy functions as infrastructure.
Changes since v1:
- fix off-by-one misconception on my side. This fixes fullscreen
playback.
Tested-By: diego.abele...@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Mak
On Mon, Aug 24, 2009 at 09:22:58PM -0400, squirrl wrote:
> Linus needs to rip out the GEM subsystem. Xorg needs to remove your
> contributions.
>
> Mesa should seriously consider stepping back their code base.
>
> Honestly it'll be 2011 before we got anything usable the way it is now.
>
> Inte
On Wed, Aug 19, 2009 at 01:31:06AM +0200, Luc Verhaegen wrote:
> Dave,
>
> Ask yourself whether your statement, the one i replied to, was a
> technical contribution, or something else?
Luc,
Just ... stop. This is embarassing.
Daniel
pgp6apJk0Gjf4.pgp
Description: P
.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm
And clean up a small whitespace goof-up in the same function, while
I was looking at it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b
... by moving the assignment up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bb59356..818c703 100644
--- a
ger
than 1024.
- patches 1, 4, 5 change drm-generic code.
- the ioctl interface is intel-only. Anyone (radeon devs?) working on another
overlay implementation/interested in sharing code?
Yours, Daniel
PS: I'll post the ddx part shortly to intel-gfx.
Daniel Vetter (6):
[drm]: make drm_m
ns as infrastructure.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_dma.c |7 +
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
driver
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
These will be used to ensure that the clock of pipe a is running
when the overlay is switched on. Programming logic more or less
directly ported over from userspace.
Also export the already existing helper function drm_encoder_crtc_ok.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm
On Wed, Jul 01, 2009 at 09:39:17PM -0400, Kristian Høgsberg wrote:
> If we want to do better (and if we care about security enhanced X in a
> [... snipped for brevity ...]
> session server is a client of a system display server. Which is why
... ? :)
Cheers,
Daniel
signature.asc
De
1 - 100 of 279 matches
Mail list logo
