Konrad,
I'm really sorry for taking so long to review this.
I'd like to go through a couple of high-level things first before
reviewing the coding itself.
The page_alloc_func structure looks nice, but I'd like to have it per
ttm backend,
we would just need to make sure that the backend is al
On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH wrote:
> Are these really all -stable material?
I think just the sequence that actually makes the machine work; the
scarier patches are those which reduce the mode setting time from 5-10s
down to .7s.
Is this stretching the bounds of what is acceptabl
> I don't think that matters for this driver, its totally not for
> acceleration, write a real driver if you have some case where copying
> algorithms are going to matter.
It will matter if you want a generic dumb server that can handle stuff
like PCI cards as well, but in fact it may well be bes
On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox wrote:
>> I don't think that matters for this driver, its totally not for
>> acceleration, write a real driver if you have some case where copying
>> algorithms are going to matter.
>
>
> It will matter if you want a generic dumb server that can handle st
Hi, Dave.
I am sending a mail I wonder where are we on this. I had sent DRM Driver
patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any
comments from you.
You can refer to these patches I sent from links below.
v1: < https://lwn.net/Articles/454380/ >
v2: < http://www.
I am sorry for missed title.
From: Inki Dae [mailto:inki@samsung.com]
Sent: Friday, September 30, 2011 6:39 PM
To: 'airl...@linux.ie'; 'Dave Airlie'
Cc: 'dri-devel@lists.freedesktop.org'; 'kyungmin.p...@samsung.com'
Subject:
Hi, Dave.
I am sending a mail I wonder where are we on t
On Thu, 29 Sep 2011 18:09:50 -0700, Keith Packard wrote:
> +static void ironlake_panel_vdd_work(struct work_struct *__work)
> +{
> + struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
> + struct intel_dp,
> panel_vdd_work);
> + s
On Don, 2011-09-29 at 19:07 -0700, Nicholas Miell wrote:
> The mouse cursor hotspot calculation when the cursor is partially off the
> top or left side of the screen was off by one.
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158
>
> Signed-off-by: Nicholas Miell
> ---
> drivers/g
On Fri, Sep 30, 2011 at 01:58:29AM -0700, Keith Packard wrote:
> On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH wrote:
>
> > Are these really all -stable material?
>
> I think just the sequence that actually makes the machine work; the
> scarier patches are those which reduce the mode setting time
On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> I'm really sorry for taking so long to review this.
That is OK. We all are busy - and it gave me some time to pretty
up the code even more.
>
> I'd like to go through a couple of high-level things first before
> rev
While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
potential bug fixed by patch 3) and opportunities for cleanup.
Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch
along
From: Michel Dänzer
Apart from the obvious cleanup, this should make the line
cursor_end = x - xorigin + w;
correct now.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletion
From: Michel Dänzer
Fixes cursor disappearing prematurely when moving off a top/left edge which
is not located at the desktop top/left edge.
Signed-off-by: Michel Dänzer
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_cursor.c | 12 +++-
1 files changed, 7 insertions(+), 5 de
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index c495575..bac8ee7 100644
--- a/drive
On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote:
> We were relying on the BIOS to set these bits, which doesn't always
> happen.
>
> Signed-off-by: Keith Packard
Ok, I'll try to increase our review-bandwidth for modesetting stuff by
jumping into this maze myself. For the moment I'l
On Thu, Sep 29, 2011 at 06:09:34PM -0700, Keith Packard wrote:
> This masks out all interrupts and ack's any pending ones at IRQ
> uninstall time to make sure we don't receive any unexpected interrupts
> later on.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/i915_irq.c |4 ++
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Michel Dänzer changed:
What|Removed |Added
Attachment #51779|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Michel Dänzer changed:
What|Removed |Added
Attachment #51780|application/octet-stream|text/plain
mime type|
On Thu, Sep 29, 2011 at 06:09:35PM -0700, Keith Packard wrote:
> There's no reason to enforce a 300ms delay during eDP mode setting.
>
> Signed-off-by: Keith Packard
Can you elaborate a bit why this is no longer needed? Jesse seems to have
introduced this spefically for edp panels in d209848d617
On Thu, Sep 29, 2011 at 06:09:36PM -0700, Keith Packard wrote:
> We're going to assume that EDID is more reliable than the VBT tables
> for eDP panels, which is notably true on MacBook machines where the
> VBT contains completely bogus data.
>
> Signed-off-by: Keith Packard
Ok, this is way over m
On Thu, Sep 29, 2011 at 06:09:37PM -0700, Keith Packard wrote:
> Verify that the eDP VDD is on, either with the panel being on or with
> the VDD force-on bit being set.
>
> This demonstrates that in many instances, VDD is not on when needed,
> which leads to failed EDID communications.
>
> Signed
On Thu, Sep 29, 2011 at 06:09:38PM -0700, Keith Packard wrote:
> Avoid any question about locked registers by just writing the unlock
> pattern with every write to the register.
>
> Signed-off-by: Keith Packard
grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
dpms functions
https://bugs.freedesktop.org/show_bug.cgi?id=41366
Summary: HDMI on a Fusion board only comes up when LVDS is
already enabled
Product: DRI
Version: XOrg CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=41366
--- Comment #1 from Simon Farnsworth 2011-09-30
10:13:00 PDT ---
Created an attachment (id=51804)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51804)
dmesg showing the modeset that results in HDMI being off unexpectedly
--
Configure bu
On Thu, Sep 29, 2011 at 06:09:39PM -0700, Keith Packard wrote:
> Cleans up code dealing with eDP VDD a bit. Remove redundant checks in
> callers
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 20 ++--
> 1 files changed, 10 insertions(+), 10 deletion
https://bugs.freedesktop.org/show_bug.cgi?id=41366
--- Comment #2 from Simon Farnsworth 2011-09-30
10:13:24 PDT ---
Created an attachment (id=51805)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51805)
dmesg showing the modeset that results in HDMI working
--
Configure bugmail: https://
https://bugs.freedesktop.org/show_bug.cgi?id=41366
Simon Farnsworth changed:
What|Removed |Added
Summary|HDMI on a Fusion board only |[r600 KMS] HDMI on a Fusion
On Thu, Sep 29, 2011 at 06:09:40PM -0700, Keith Packard wrote:
> The VDD force bit is turned on before touching the panel, but if it
> was enabled, there was no call to turn it back off. Add a call.
>
> Signed-off-by: Keith Packard
Nice catch of in inbalanced on/off.
Reviewed-by: Daniel Vetter
-
On Thu, Sep 29, 2011 at 06:09:41PM -0700, Keith Packard wrote:
> On eDP, DDC requires panel power, but turning that on uses the panel
> power sequencing timing values fetch from the DPCD data.
>
> Signed-off-by: Keith Packard
Can't really check more than what the patch does what it claims to do,
On Thu, Sep 29, 2011 at 06:09:43PM -0700, Keith Packard wrote:
> The DP i2c initialization code does a couple of i2c transactions,
> which means that an eDP panel must be powered up.
>
> Signed-off-by: Keith Packard
Ah, here's the code I've been looking for when reviewing patch 9.
Reviewed-by: D
On Thu, Sep 29, 2011 at 06:09:42PM -0700, Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Dan
On Fri, 30 Sep 2011 18:20:48 +0200, Daniel Vetter wrote:
> Shouldn't we mask/ack south DE irqs before before we mask DE irqs to avoid
> races, i.e. move this new code up?
I don't know. What about the GT interrupts? I just stuck stuff at the
bottom, figuring it would do the least harm...
--
ke
On Thu, Sep 29, 2011 at 06:09:44PM -0700, Keith Packard wrote:
> Any call to intel_dp_sink_dpms must ensure that the panel has power so
> that the DP_SET_POWER operation will be correctly received. The only
> one missing this was in intel_dp_prepare.
>
> Signed-off-by: Keith Packard
If I understa
On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter wrote:
> Can you elaborate a bit why this is no longer needed? Jesse seems to have
> introduced this spefically for edp panels in d209848d61794968. If this
> becomes rendundant due to your panel power sequencing fixes, maybe move it
> down the ser
On Fri, Sep 30, 2011 at 10:44:22AM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 18:20:48 +0200, Daniel Vetter wrote:
>
> > Shouldn't we mask/ack south DE irqs before before we mask DE irqs to avoid
> > races, i.e. move this new code up?
>
> I don't know. What about the GT interrupts? I jus
On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter wrote:
>
> > Can you elaborate a bit why this is no longer needed? Jesse seems to have
> > introduced this spefically for edp panels in d209848d61794968. If this
> > becomes rendunda
https://bugs.freedesktop.org/show_bug.cgi?id=41367
Summary: [r300g, bisected] WebGL test runner regression
Product: Mesa
Version: git
Platform: Other
URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi
c/webgl/sd
On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter wrote:
> Ok, this is way over my head, just checked whether the patch does what it
> claims to - nice exercise in reading dp modeset code ;-)
Yeah, it's purely heuristic -- the VBT contains a mode which was
originally for the LVDS. It's unclear w
On Thu, Sep 29, 2011 at 06:09:45PM -0700, Keith Packard wrote:
> This ensures that the panel power sequencing is complete before
> attempting to communicate over the aux channel.
>
> Signed-off-by: Keith Packard
Looks like a patch useful for fixing up this mess, but I don't quite see
the point of
On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote:
> Use pp_control instead of re-reading?
Could, but you'll note a later patch eliminates both pp_status and
pp_control local variables, so I didn't bother to clean this up when
refactoring.
> dp_aux_ch does the low-level io for the below,
On Fri, 30 Sep 2011 19:09:46 +0200, Daniel Vetter wrote:
> grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
> dpms functions - any reasons these two writes are left out?
Nope, I just didn't look there. I'll fix that. Locking registers with
magic patterns is just crazy these
On Fri, 30 Sep 2011 19:13:55 +0200, Daniel Vetter wrote:
> Why not also move the id_edp check into edp_panel_on|off like for the vdd
> functions? This way it looks a bit inconsistent ...
Yeah, I can do that. May mean a few redundant checks, but they're cheap.
--
keith.pack...@intel.com
pgp2O
On Fri, 30 Sep 2011 11:31:45 +0100, Chris Wilson
wrote:
> I think you want the dev->mode_config.mutex here.
oops. good catch.
--
keith.pack...@intel.com
pgp5yI304Zoht.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freede
On Fri, Sep 30, 2011 at 07:58:21PM +0200, Daniel Vetter wrote:
> On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote:
> > On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter wrote:
> >
> > > Can you elaborate a bit why this is no longer needed? Jesse seems to have
> > > introduced this sp
On Fri, 30 Sep 2011 06:57:05 -0700, Greg KH wrote:
> No, actually this makes it easier for -stable as each individual patch
> fixes a problem, so in re-reading them, I have no objection for them to
> go into -stable.
Ok, cool. Splitting these up was a pain.
> Would these also work on 3.0?
They
On Fri, Sep 30, 2011 at 11:01:06AM -0700, Keith Packard wrote:
> Should I bother to include this patch in the series at all? It's purely
> for diagnostics to make sure the panel is powered during all aux channel
> transactions.
I'd say yes, imo paranoia in modesetting code is justified ;-)
-Daniel
On Thu, Sep 29, 2011 at 06:09:46PM -0700, Keith Packard wrote:
> Store the panel power sequencing delays in the dp private structure,
> rather than the global device structure. Who knows, maybe we'll get
> more than one eDP device in the future.
>
> Look at both the current hardware register setti
On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o wrote:
> What kind of battery life do you get with these patches applied, out
> of curiosity?
4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
same as people are getting under Mac OS.
--
keith.pack...@intel.com
pgpczbMwrKpO6.
On Thu, Sep 29, 2011 at 06:09:47PM -0700, Keith Packard wrote:
> This value doesn't come directly from the VBT, and so is rather
> specific to the particular DP output.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 4
On Thu, Sep 29, 2011 at 06:09:48PM -0700, Keith Packard wrote:
> The return value was unused, so just stop doing that.
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
On Fri, 30 Sep 2011 11:01:06 -0700, Keith Packard wrote:
Non-text part: multipart/signed
> On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote:
>
> > Use pp_control instead of re-reading?
>
> Could, but you'll note a later patch eliminates both pp_status and
> pp_control local variables, so
On Thu, Sep 29, 2011 at 06:09:49PM -0700, Keith Packard wrote:
> We need to check eDP VDD force and panel on in several places, so
> create some simple helper functions to avoid duplicating code.
>
> Signed-off-by: Keith Packard
Ah, here's the code that kills my "... instead of re-reading PP_CON
On Fri, 30 Sep 2011 20:09:59 +0200, Daniel Vetter wrote:
> On further strolling through bspec to review later patches I've noticed
> that PCH_PP_ON_DELAYS and PCH_PP_OFF_DELAYS seem to have values for
> power on->backlight on and backlight off->panel off delays. Maybe we
> should use these?
Yeah
On Fri, 30 Sep 2011 19:45:02 +0200, Daniel Vetter wrote:
> If I understand things correctly we don't need the vdd_on/off on dpms off
> because the panel is running and has power.
Yes, that's correct; the aux channel works with either full power or
with the force VDD bit turned on.
--
keith.pac
On Fri, 30 Sep 2011 20:01:11 +0200, Daniel Vetter wrote:
> Looks like a patch useful for fixing up this mess, but I don't quite see
> the point of merging this given that you fix things for real in the next
> one ...
Good point. In the development process, this was the patch which made
things wo
On Fri, 30 Sep 2011 20:16:44 +0200, Daniel Vetter wrote:
> Awesome patch description and the code agrees with what I've cross-checked
> on bspec. The only fear I have is that we currently ignore the backlight
> on/off timings and some panel probably relies on use waiting for backlight
> on/off +
On Thu, Sep 29, 2011 at 06:09:50PM -0700, Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then re
On Thu, Sep 29, 2011 at 06:09:51PM -0700, Keith Packard wrote:
> Using the same basic plan as the VDD force delayed power off, make
> turning the panel power off asynchronous.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 71
> +
On Thu, Sep 29, 2011 at 06:09:52PM -0700, Keith Packard wrote:
> This eliminates a fairly long delay when power sequencing newer
> hardware
>
> Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
On Thu, Sep 29, 2011 at 06:09:53PM -0700, Keith Packard wrote:
> If the panel is powered up, there's no need to delay for the 'off'
> interval when turning the panel on.
>
> Signed-off-by: Keith Packard
I'll hold off carefully checking this one until the previous patches
settle. Especially when
https://bugs.freedesktop.org/show_bug.cgi?id=41248
Leann Ogasawara changed:
What|Removed |Added
CC||leann.ogasawara@canonical.c
On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter wrote:
> A cancel_work might be good here, not point in waking up the cpu for no
> reason. And can you add "panel off timer: " to the deboug output?
No, that's not correct, this is run before turning the panel back on and
must check that enough t
On Fri, 30 Sep 2011 20:55:24 +0200, Daniel Vetter wrote:
> If it's not too annoying to do, can you move this to the previous patch?
> Dito for the s/panel_vdd_work/panel_work/.
Yeah, that was a bit of sloppy patch mangling.
> Same comment as in the previous patch: I think the
> intel_dp->want_p
https://bugs.freedesktop.org/show_bug.cgi?id=39897
--- Comment #22 from chrisdh...@googlemail.com 2011-09-30 14:41:56 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > Does:
> >
> > Option "ColorTiling" "false"
> >
> > in the device section of your xorg.conf help? If so, you may
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #5 from Gustav Näslund 2011-09-30 14:45:03
PDT ---
Success! it works as it should
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
On Fri, Sep 30, 2011 at 01:56:09PM -0700, Keith Packard wrote:
> On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter wrote:
>
> > A cancel_work might be good here, not point in waking up the cpu for no
> > reason. And can you add "panel off timer: " to the deboug output?
>
> No, that's not correct
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #11 from Martin Stolpe 2011-09-30 15:57:21
PDT ---
Created an attachment (id=51815)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51815)
Screenshot of Firefox when 2d acceleration is disabled
--
Configure bugmail: https://bu
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #12 from Martin Stolpe 2011-09-30 15:57:48
PDT ---
Created an attachment (id=51816)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51816)
Screenshot of Firefox when 2d acceleration is enabled
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #13 from Martin Stolpe 2011-09-30 15:58:30
PDT ---
Created an attachment (id=51817)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51817)
Configuration for r600 card
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #14 from Martin Stolpe 2011-09-30 15:59:24
PDT ---
Created an attachment (id=51818)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51818)
Xorg configuration for r300 card
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #15 from Martin Stolpe 2011-09-30 16:00:06
PDT ---
Created an attachment (id=51819)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51819)
Xorg log file for r300 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #16 from Martin Stolpe 2011-09-30 16:00:31
PDT ---
Created an attachment (id=51820)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51820)
Xorg log file for r300 card when 2d acceleration is enabled
--
Configure bugmail: https
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Martin Stolpe changed:
What|Removed |Added
Attachment #51820|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #17 from Martin Stolpe 2011-09-30 16:01:36
PDT ---
Created an attachment (id=51821)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51821)
Xorg log file for r600 card when 2d acceleration is disabled
--
Configure bugmail: http
https://bugs.freedesktop.org/show_bug.cgi?id=41373
Summary: memory leak when drmModeRes is freed.
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #18 from Martin Stolpe 2011-09-30 16:07:30
PDT ---
Hello,
I've found the problem why it didn't work. I didn't know that the entry funtion
(or whatever it is called) has to have the same name as the driver. After
creating a xorg.conf
On Fri, 30 Sep 2011 19:09:46 +0200, Daniel Vetter wrote:
> grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
> dpms functions - any reasons these two writes are left out?
Upon a bit of review:
The bspec makes it clear that this write protect key only needs to
be written
On 09/30/2011 08:16 AM, Michel Dänzer wrote:
> While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image
> off-by-one error', I noticed at least one other bug (fixed by patch 2, and one
> potential bug fixed by patch 3) and opportunities for cleanup.
>
> Patch 1 is based on Nicholas
https://bugs.freedesktop.org/show_bug.cgi?id=41373
--- Comment #1 from Boram Park 2011-09-30 17:32:09
PDT ---
Created an attachment (id=51824)
View: https://bugs.freedesktop.org/attachment.cgi?id=51824
Review: https://bugs.freedesktop.org/review?bug=41373&attachment=51824
another patch for me
https://bugs.freedesktop.org/show_bug.cgi?id=41375
Summary: VDPAU not working on RS880
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #1 from Michael Lothian 2011-09-30 18:40:52
PDT ---
Created an attachment (id=51828)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51828)
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #2 from Michael Lothian 2011-09-30 18:41:17
PDT ---
Created an attachment (id=51829)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51829)
mplayer2 log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=emai
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #3 from Michael Lothian 2011-09-30 18:43:54
PDT ---
Created an attachment (id=51831)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51831)
Screen shot of garbled picture
--
Configure bugmail: https://bugs.freedesktop.org/user
https://bugs.freedesktop.org/show_bug.cgi?id=41375
--- Comment #4 from Michael Lothian 2011-09-30 18:49:01
PDT ---
I start smplayer with LD_LIBRARY_PATH=/usr/lib/vdpau VDPAU_DRIVER=r600 smplayer
If there is anything else I can provide to help debug this please let me know
the sample mpeg video
On Fri, 30 Sep 2011 20:16:44 +0200, Daniel Vetter wrote:
> Awesome patch description and the code agrees with what I've cross-checked
> on bspec. The only fear I have is that we currently ignore the backlight
> on/off timings and some panel probably relies on use waiting for backlight
> on/off +
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #21 from Nicholas Miell 2011-09-30 20:45:37 PDT
---
It isn't a bug, it is a perfectly valid and entirely safe optimization.
Valgrind supplies its own overrides for the string functions that don't do this
optimization specifically to
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #22 from Nicholas Miell 2011-09-30 21:08:50 PDT
---
Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
allocation size 2 bytes, which is broken.
--
Configure bugmail: https://bugs.freedesktop.org/userpre
https://bugs.freedesktop.org/show_bug.cgi?id=40423
--- Comment #23 from Benoit Jacob 2011-09-30 21:22:05 PDT
---
(In reply to comment #22)
> Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest
> allocation size 2 bytes, which is broken.
This sounds like something that
Hi, Dave.
I am very sorry for html type used before so I am re-sending this e-mail. I
wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC
Exynos4210 a week ago but we have not received any comments from you.
You can refer to these patches I sent from links below.
v1: < htt
>
> You can refer to these patches I sent from links below.
> v1: < https://lwn.net/Articles/454380/ >
> v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
> v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >
> v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >
>
Hi, Dave.
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Saturday, October 01, 2011 3:07 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> kyungmin.p...@samsung.com
> Subject: Re: [RESEND] An inquiry about DRM Driver for Samsung SoC E
On 29/09/11 23:21, Brad Campbell wrote:
> On 29/09/11 22:36, Alex Deucher wrote:
>> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
>> wrote:
>>> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
>>> the displayport AUX channel stopped re-trying commands that elicited
>>> a D
Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.
VBT doesn't provide any values for T1 or T2, so we'll alw
On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
wrote:
> On 29/09/11 23:21, Brad Campbell wrote:
>>
>> On 29/09/11 22:36, Alex Deucher wrote:
>>>
>>> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
>>> wrote:
This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
th
On 30/09/11 12:59, Alex Deucher wrote:
> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
>> Looking at it with a nights sleep, it's obvious the code path in
>> aux_native_write is ok. Is this a bit cleaner than the last patch?
>
> Looks pretty good. I was thinking of something more like this (sorr
On Fri, Sep 30, 2011 at 1:14 AM, Brad Campbell
wrote:
> On 30/09/11 12:59, Alex Deucher wrote:
>>
>> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
>
>>> Looking at it with a nights sleep, it's obvious the code path in
>>> aux_native_write is ok. Is this a bit cleaner than the last patch?
>>
>> Lo
Konrad,
I'm really sorry for taking so long to review this.
I'd like to go through a couple of high-level things first before
reviewing the coding itself.
The page_alloc_func structure looks nice, but I'd like to have it per
ttm backend,
we would just need to make sure that the backend is aliv
ackard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0da935b4/attachment-0001.pgp>
> I don't think that matters for this driver, its totally not for
> acceleration, write a real driver if you have some case where copying
> algorithms are going to matter.
It will matter if you want a generic dumb server that can handle stuff
like PCI cards as well, but in fact it may well be bes
On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox wrote:
>> I don't think that matters for this driver, its totally not for
>> acceleration, write a real driver if you have some case where copying
>> algorithms are going to matter.
>
>
> It will matter if you want a generic dumb server that can handle st
1 - 100 of 185 matches
Mail list logo
