On Wed, 1 Feb 2012 18:42:52 +
Dave Airlie wrote:
> On Tue, Jan 24, 2012 at 2:10 PM, Alex Deucher wrote:
> > On Sun, Jan 22, 2012 at 9:43 AM, Igor Murzov
> > wrote:
> >> From 77c912ea1eca50a93a34d5be69f9dc96a8bef0d8 Mon Sep 17 00:00:00 2001
> >> From: Igor Murzov
> >> Date: Sun, 22 Jan 2012
On Feb 1, 2012, at 1:56 PM, Julien Cristau wrote:
> On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote:
>
>> yeah, that's probably cleaner (I guess it'll avoid the -*), but it should
>> have the same effect.
>>
> I get host_os=linux-gnu here afaict, so not really the same effect,
yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have
the same effect.
I'll make the change.
On Feb 1, 2012, at 12:43 PM, Julien Cristau wrote:
> On Mon, Jan 30, 2012 at 15:25:20 -0800, Jeremy Huddleston wrote:
>
>> This fixes a failure in 'make check' found by the tin
Following up on my message from Jan 19, now with a lot more hard data
and a less intrusive modification. Still a prototype though. CC-ing
DRI-devel and Mario Kleiner for a larger audience.
To recap, I was seeing consistent flickering with Mesa/KMS on Android on
my Iconia Tab W500 tablet with an AM
Hi Alex,
We don't have the documentation that contains this register definition.
We try to use the Linux 3.0.0 on our PowerPC board and M96 GPU (RV730):
it doesn't work as is. We need to revert this definition like it was
before 2.6.39.4
(http://lists.freedesktop.org/archives/dri-devel/2011-J
On Mit, 2012-02-01 at 17:07 -0500, Ilija Hadzic wrote:
>
> diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
> b/drivers/gpu/drm/radeon/r600_blit_kms.c
> index d996f43..32dcc95 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
> @@ -468,27 +46
On Don, 2012-02-02 at 09:42 +0100, Cédric Cano wrote:
>
> We try to use the Linux 3.0.0 on our PowerPC board and M96 GPU (RV730):
> it doesn't work as is. We need to revert this definition like it was
> before 2.6.39.4
> (http://lists.freedesktop.org/archives/dri-devel/2011-July/012811.html).
Dear Ilija,
Am Mittwoch, den 01.02.2012, 17:07 -0500 schrieb Ilija Hadzic:
[…]
> +#define I2F_MAX_BITS 15
> +#define I2F_MAX_INPUT ((2 << I2F_MAX_BITS) - 1)
> +#define I2F_SHIFT (24 - I2F_MAX_BITS)
> +
> +/*
> + * converts unsigned integer into 32-bit IEEE floating point representation;
> + *
Hi Daniel,
On Tuesday 31 January 2012 11:36:02 Daniel Vetter wrote:
> On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
> > Hi Sumit,
> >
> > > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
> > [snip]
> >
> > > static inline void dma_buf_unmap_attachment(struct dma_buf_
The non modesetting drm drivers currently use a handcrafted pci probe
function. This requires the drm core to keep a list of registered devices
for each driver. This series adds a probe function for the non modesetting
drivers and removes the legacy probe code. The USB and platform drivers
use the
drm_platform_init is modelled after the legacy pci probe
support. It initializes a device_list, but this list will
only ever have a single entry as it is specific to a single
platform device instance. Simplify this by calling
drm_get_platform_dev directly from the driver.
Signed-off-by: Sascha Hau
The driver core is better at tracking the devices
associated to a device, no need to do this ourselves.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c |1 -
include/drm/drmP.h|3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_usb.c | 43 ++-
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index dd154d4..b741b54 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c | 45 +++--
1 files changed, 3 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index c0d47ab..2407a1d 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b
pci, usb and platform support all duplicate the same code. Provide
a common function for this.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_stub.c | 56
include/drm/drmP.h |2 +
2 files changed, 58 insertions(+), 0 deletions(-)
d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_platform.c | 51 ++-
1 files changed, 3 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 7153508..5d5e388 100644
--- a/drivers/gpu/drm/drm_pl
Usb drivers can register themselves and call drm_get_usb_dev
in their probe function. We don't need a drm specific wrapper
function for this. As there are currently no users, none a
touched here.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_usb.c | 26 --
include
struct drm_device has a struct usbdevice * and a
struct platform_device *. This is unused, so remove it.
If the platform_device or usbdevice is needed, we can
always get it using to_usb_device or to to_platform_device.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_platform.c|
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f390f5f..8c7ac41 100644
--- a
struct drm_driver has a union containing the different drivers.
This field is unused in case of a usb or platform device. For
pci devices it is only used in drm_pci_get_name() which uses
the pci_driver to return the pci driver name. For all existing
drm drivers this driver name matches the struct d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c |1 -
drivers/gpu/drm/drm_platform.c |1 -
drivers/gpu/drm/drm_usb.c |1 -
include/drm/drmP.h |5 -
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/driver
This way we do not need the legacy handcrafted probe mechanism
anymore and can remove it.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c | 41 +-
drivers/gpu/drm/i810/i810_drv.c | 16 +
drivers/gpu/drm/mga/mga_drv.c |
https://bugzilla.kernel.org/show_bug.cgi?id=42716
--- Comment #1 from Michel Dänzer 2012-02-02 11:59:30 ---
(In reply to comment #0)
> Any idea what's going on here?
Given your mixed testing results, I suspect the bisect result is bogus; you
probably need to at least test each kernel a coup
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #47 from Michel Dänzer 2012-02-02 04:04:31 PST
---
How are the LVDS and DVI displays arranged in the session? Can you attach the
output of xrandr?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Y
- Original Message -
> From: "Sascha Hauer"
> To: dri-devel@lists.freedesktop.org
> Cc: "Inki Dae" , ker...@pengutronix.de
> Sent: Thursday, 2 February, 2012 11:57:52 AM
> Subject: [PATCH] drm: cleanup device registration
>
> The non modesetting drm drivers currently use a handcrafted pci
On Thu, 2 Feb 2012, Paul Menzel wrote:
+ * I2F_MAX_BITS can be increased, but that will add to loop iterations
should that be t*w*o?
No, it's not "two" like the number but "to" like in "add to the group" or
"add to the pile".
___
dri-devel mail
On Thu, Feb 02, 2012 at 07:05:00AM -0500, David Airlie wrote:
> - Original Message -
> > From: "Sascha Hauer"
> > To: dri-devel@lists.freedesktop.org
> > Cc: "Inki Dae" , ker...@pengutronix.de
> > Sent: Thursday, 2 February, 2012 11:57:52 AM
> > Subject: [PATCH] drm: cleanup device registr
- Original Message -
> From: "Sascha Hauer"
> To: "David Airlie"
> Cc: "Inki Dae" , ker...@pengutronix.de,
> dri-devel@lists.freedesktop.org
> Sent: Thursday, 2 February, 2012 12:34:02 PM
> Subject: Re: [PATCH] drm: cleanup device registration
>
> On Thu, Feb 02, 2012 at 07:05:00AM -0
On Thu, 2 Feb 2012, Michel [ISO-8859-1] D�nzer wrote:
+#define I2F_MAX_BITS 15
+#define I2F_MAX_INPUT ((2 << I2F_MAX_BITS) - 1)
Should be ((1 << I2F_MAX_BITS) - 1): 2^n == (1 << n)
Right. I'll fix it.
Use WARN_ON_ONCE here to avoid spamming the kernel output. If this is
ever hit again
Hi David,
On Wed, Feb 01, 2012 at 11:38:18AM +0100, Sascha Hauer wrote:
> The following patches contain some fixes and cleanups for the drm
> core.
>
> - fix memory holes
> - make some initialization / deinitialization more symmetric
> - add convenience functions for creating properties
> - remov
https://bugs.freedesktop.org/show_bug.cgi?id=45503
--- Comment #10 from mlam...@gmail.com 2012-02-02 06:20:36 PST ---
I just found the solution:
diff -ur a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.
https://bugs.freedesktop.org/show_bug.cgi?id=45503
--- Comment #11 from mlam...@gmail.com 2012-02-02 06:22:03 PST ---
Created attachment 56517
--> https://bugs.freedesktop.org/attachment.cgi?id=56517
dmesg with my patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #48 from Camaleón 2012-02-02 06:23:13 PST ---
Created attachment 56518
--> https://bugs.freedesktop.org/attachment.cgi?id=56518
Output of "xrandr"
In reply to comment #47, I'm attaching the output of "xrandr".
--
Configure bugmai
> I see. For example the i810 also has a framebuffer driver. Do you see
> a way to fix this except writing a kms driver for all legacy devices?
> Otherwise I would leave the pci part untouched and only keep the
> platform/USB pieces which I'm admittedly more interested in.
Which is obsolete and un
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #49 from Michel Dänzer 2012-02-02 06:36:30 PST
---
The kernel DESKTOP_HEIGHT fix from bug 43835 might help for the GPU lockups.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #50 from Michel Dänzer 2012-02-02 06:36:59 PST
---
Argh, I mean bug 45329.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=45503
--- Comment #12 from Dave Airlie 2012-02-02 06:59:30
PST ---
arrgh good catch, I'll send a patch with that fix now,
thanks for tracking that down.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
From: Alan Cox
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 791c0ef..97d5b80 100644
--- a/drivers/gpu/drm/g
(Resending in two bits to avoid stgit breakage)
From: Alan Cox
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |1 +
1 files changed, 1 insertions(+), 0 d
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 791c0ef..97d5b80 100644
--- a/drivers/gpu/drm/g
From: Alan Cox
Some this is Medfield stuff that may reappear in some form later, other
bits are just dead stuff
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_crtc.c |3 -
drivers/gpu/drm/gma500/psb_drv.h | 94 +---
2 files changed, 2 inser
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 27 ++-
drivers/gpu/drm/gma500/cdv_intel_lvds.c|6 -
drivers/gpu/drm/gma500/oaktrail_device.c | 204 +
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 72 +
drive
From: Alan Cox
Update this to better reflect the status
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Kconfig |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 754e14b..f92a7f4 100644
--- a/dr
From: Jesper Juhl
In psb_intel_lvds_init(), if we fail to allocate memory for
'psb_intel_connector' we free the memory we previously allocated for
'psb_intel_encoder', but we then proceed to use that free'd pointer
when we do 'psb_intel_encoder->dev_priv = lvds_priv;'.
We may also leak the memor
From: Alex Deucher
Previous patch only updates r3xx+. It's not likely
anyone will use this on r1xx/r2xx, but add it for consistency.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 46 +++-
drivers/gpu/drm/radeon/r200.c | 17 +---
From: Alex Deucher
Not likely this will be implemented anytime soon, but for
completeness...
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 12 +++-
drivers/gpu/drm/radeon/r200.c | 12 +++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/dri
From: Alex Deucher
Different versions of the DP to LVDS bridge chip
need different panel mode settings depending on
the chip version used.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_dp.c
https://bugs.freedesktop.org/show_bug.cgi?id=34155
--- Comment #5 from Marco Albanese 2012-02-02 07:26:00 PST
---
Created attachment 56520
--> https://bugs.freedesktop.org/attachment.cgi?id=56520
Dmesg with "failed to reserve"
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?
https://bugs.freedesktop.org/show_bug.cgi?id=34155
--- Comment #6 from Marco Albanese 2012-02-02 07:26:13 PST
---
(In reply to comment #4)
> Are there also 'reserve failed' messages before the messages referenced in the
> original report?
No, there aren't. Is the only type of "reserve failed" I
Evergreen and NI blit copy was broken if the buffer maps to a rectangle
whose one dimension is 16384 (max dimension allowed by these chips).
In the mainline kernel, the problem is exposed only when buffers are
very large (1G), but it's still a problem. The problem could be exposed
for smaller buffe
On Thu, Feb 2, 2012 at 10:26 AM, Ilija Hadzic
wrote:
> Evergreen and NI blit copy was broken if the buffer maps to a rectangle
> whose one dimension is 16384 (max dimension allowed by these chips).
> In the mainline kernel, the problem is exposed only when buffers are
> very large (1G), but it's s
On Don, 2012-02-02 at 10:26 -0500, Ilija Hadzic wrote:
> Evergreen and NI blit copy was broken if the buffer maps to a rectangle
> whose one dimension is 16384 (max dimension allowed by these chips).
> In the mainline kernel, the problem is exposed only when buffers are
> very large (1G), but it's
On Thu, 2 Feb 2012, Alex Deucher wrote:
Should probably CC stable as well.
I was thinking of that, but decided not to because it's in the gray area
of this rule per Documentation/stable_kernel_rules.txt
- It must fix a real bug that bothers people (not a, "This could be a
problem...
https://bugs.freedesktop.org/show_bug.cgi?id=34155
--- Comment #7 from Michel Dänzer 2012-02-02 07:56:37 PST
---
Created attachment 56529
--> https://bugs.freedesktop.org/attachment.cgi?id=56529
Add return value to error message
Please apply this debugging patch and post the value(s) of r whe
Hi Linus,
A set of fixes from nouveau and radeon, one reported regression about
reading BIOS roms on certain dual-gpu laptops is fixed (use after free),
along with a s/r black screen fix, and a GPU hang fix.
Dave.
The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #51 from Camaleón 2012-02-02 08:34:48 PST ---
(In reply to comment #50)
> Argh, I mean bug 45329.
Thank you, we can do try... what would be the "easy peasy" way to go for it?
Mainline kernel 3.3-rc2 contains the mentioned patches? Ar
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #52 from Michel Dänzer 2012-02-02 08:57:40 PST
---
(In reply to comment #51)
> Mainline kernel 3.3-rc2 contains the mentioned patches?
No. You can try the drm-fixes branch of
git://people.freedesktop.org/~airlied/linux.git, but it s
On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> Hi,
>
> I plan to do a libdrm release on friday because ddx/mesa work i have
> been doing depends on thing i added to libdrm/radeon. Is anybody else
> working on some libdrm related code that would need a release ?
AFAICS these neve
On Thu, Feb 2, 2012 at 5:38 PM, Paul Berry wrote:
> On 1 February 2012 20:55, Alan Coopersmith
> wrote:
>>
>> On 02/ 1/12 08:52 PM, Alexandre Demers wrote:
>>>
>>> Hi,
>>>
>>> I've been trying all day to sync sources from anongit.freedesktop.org
>>> (dri and mesa) and it always ends up by a time
https://bugs.freedesktop.org/show_bug.cgi?id=45558
Bug #: 45558
Summary: cannot render on a drawable of size equal the max
framebuffer size
Classification: Unclassified
Product: Mesa
Version: git
Platform: All
https://bugs.freedesktop.org/show_bug.cgi?id=45558
--- Comment #1 from Alban Browaeys 2012-02-02 10:40:03 PST
---
Created attachment 56551
--> https://bugs.freedesktop.org/attachment.cgi?id=56551
testcase for max not rendering
This testcase is made from a mesa demo. The issue is that with Win
https://bugs.freedesktop.org/show_bug.cgi?id=45558
Alban Browaeys changed:
What|Removed |Added
Attachment #56550|application/octet-stream|text/plain
mime type|
On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> > Hi,
> >
> > I plan to do a libdrm release on friday because ddx/mesa work i have
> > been doing depends on thing i added to libdrm/radeon. Is anybody else
> > working
On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> > Hi,
> >
> > I plan to do a libdrm release on friday because ddx/mesa work i have
> > been doing depends on thing i added to libdrm/radeon. Is anybody else
> > working
On Thu, Feb 02, 2012 at 02:55:22PM -0500, Jerome Glisse wrote:
> On Thu, Feb 02, 2012 at 07:13:21PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2012 at 07:10:10PM -0500, Jerome Glisse wrote:
> > > Hi,
> > >
> > > I plan to do a libdrm release on friday because ddx/mesa work i have
> > > been d
This return statement got dropped while fixing the conflicts introduced
in 7a7e8734ac3.
---
drivers/gpu/drm/radeon/evergreen.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Note that I've not actually tested this change, I just noticed when
reviewing the mentioned merge commit. If th
https://bugs.freedesktop.org/show_bug.cgi?id=30151
--- Comment #1 from pitam...@free.fr 2012-02-02 12:47:26 PST ---
I can confirm this.
linux 3.2
graphic board hd4870
HDMI audio device seen and unmuted
set in the grub kernel boot command radeon.audio=1
but when playing, no sound and no error
t
On Thu, Feb 2, 2012 at 3:23 PM, Matthijs Kooijman wrote:
> This return statement got dropped while fixing the conflicts introduced
> in 7a7e8734ac3.
> ---
> drivers/gpu/drm/radeon/evergreen.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> Note that I've not actually tested this
On Thu, Feb 02, 2012 at 02:27:18PM +, Alan Cox wrote:
> > I see. For example the i810 also has a framebuffer driver. Do you see
> > a way to fix this except writing a kms driver for all legacy devices?
> > Otherwise I would leave the pci part untouched and only keep the
> > platform/USB pieces
Signed-off-by: Alan Coopersmith
---
include/drm/drm_fourcc.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b1107cb..85facb0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -24,10 +24,
unable to have a working radeon kms framebuffer with linux-3.2.2 on ppc
video card: Radeon 9250 PCI
here the boot log:
U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)
CPU: AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
No Security/Kasumi support
Bootstrap Option H
unable to have a working radeon kms framebuffer with linux-3.2.2 on ppc
video card: Radeon X1650PRO PCIE
here the boot log:
U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)
CPU: AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
No Security/Kasumi support
Bootstrap O
On 1 February 2012 20:55, Alan Coopersmith wrote:
> On 02/ 1/12 08:52 PM, Alexandre Demers wrote:
>
>> Hi,
>>
>> I've been trying all day to sync sources from anongit.freedesktop.org
>> (dri and mesa) and it always ends up by a time out. Is there a problem
>> with the server or the address?
>>
>
>
> -Original Message-
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Wednesday, February 01, 2012 7:39 PM
> To: dri-devel at lists.freedesktop.org
> Cc: kernel at pengutronix.de; Sascha Hauer; Inki Dae
> Subject: [PATCH 19/20] drm exynos: use drm_fb_helper_set_par directly
https://bugzilla.kernel.org/show_bug.cgi?id=42716
Summary: Boot failure with KMS enabled (radeon)
Product: Drivers
Version: 2.5
Kernel Version: 3.2.x
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
On Wed, 1 Feb 2012 18:42:52 +
Dave Airlie wrote:
> On Tue, Jan 24, 2012 at 2:10 PM, Alex Deucher
> wrote:
> > On Sun, Jan 22, 2012 at 9:43 AM, Igor Murzov
> > wrote:
> >> From 77c912ea1eca50a93a34d5be69f9dc96a8bef0d8 Mon Sep 17 00:00:00 2001
> >> From: Igor Murzov
> >> Date: Sun, 22 Jan 2
Hi Alex,
We don't have the documentation that contains this register definition.
We try to use the Linux 3.0.0 on our PowerPC board and M96 GPU (RV730):
it doesn't work as is. We need to revert this definition like it was
before 2.6.39.4
(http://lists.freedesktop.org/archives/dri-devel/2011-Ju
On Mit, 2012-02-01 at 17:07 -0500, Ilija Hadzic wrote:
>
> diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
> b/drivers/gpu/drm/radeon/r600_blit_kms.c
> index d996f43..32dcc95 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_kms.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
> @@ -468,27 +46
On Don, 2012-02-02 at 09:42 +0100, C?dric Cano wrote:
>
> We try to use the Linux 3.0.0 on our PowerPC board and M96 GPU (RV730):
> it doesn't work as is. We need to revert this definition like it was
> before 2.6.39.4
> (http://lists.freedesktop.org/archives/dri-devel/2011-July/012811.html).
re
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120202/439fa938/attachment.pgp>
Hi Daniel,
On Tuesday 31 January 2012 11:36:02 Daniel Vetter wrote:
> On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
> > Hi Sumit,
> >
> > > On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
> > [snip]
> >
> > > static inline void dma_buf_unmap_attachment(struct dma_buf_
The non modesetting drm drivers currently use a handcrafted pci probe
function. This requires the drm core to keep a list of registered devices
for each driver. This series adds a probe function for the non modesetting
drivers and removes the legacy probe code. The USB and platform drivers
use the
drm_platform_init is modelled after the legacy pci probe
support. It initializes a device_list, but this list will
only ever have a single entry as it is specific to a single
platform device instance. Simplify this by calling
drm_get_platform_dev directly from the driver.
Signed-off-by: Sascha Hau
The driver core is better at tracking the devices
associated to a device, no need to do this ourselves.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c |1 -
include/drm/drmP.h|3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_usb.c | 43 ++-
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index dd154d4..b741b54 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c | 45 +++--
1 files changed, 3 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index c0d47ab..2407a1d 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b
pci, usb and platform support all duplicate the same code. Provide
a common function for this.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_stub.c | 56
include/drm/drmP.h |2 +
2 files changed, 58 insertions(+), 0 deletions(-)
d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_platform.c | 51 ++-
1 files changed, 3 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 7153508..5d5e388 100644
--- a/drivers/gpu/drm/drm_pl
Usb drivers can register themselves and call drm_get_usb_dev
in their probe function. We don't need a drm specific wrapper
function for this. As there are currently no users, none a
touched here.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_usb.c | 26 --
include
struct drm_device has a struct usbdevice * and a
struct platform_device *. This is unused, so remove it.
If the platform_device or usbdevice is needed, we can
always get it using to_usb_device or to to_platform_device.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_platform.c|
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f390f5f..8c7ac41 100644
--- a
struct drm_driver has a union containing the different drivers.
This field is unused in case of a usb or platform device. For
pci devices it is only used in drm_pci_get_name() which uses
the pci_driver to return the pci driver name. For all existing
drm drivers this driver name matches the struct d
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c |1 -
drivers/gpu/drm/drm_platform.c |1 -
drivers/gpu/drm/drm_usb.c |1 -
include/drm/drmP.h |5 -
4 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/driver
This way we do not need the legacy handcrafted probe mechanism
anymore and can remove it.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_pci.c | 41 +-
drivers/gpu/drm/i810/i810_drv.c | 16 +
drivers/gpu/drm/mga/mga_drv.c |
https://bugzilla.kernel.org/show_bug.cgi?id=42716
--- Comment #1 from Michel D?nzer 2012-02-02 11:59:30
---
(In reply to comment #0)
> Any idea what's going on here?
Given your mixed testing results, I suspect the bisect result is bogus; you
probably need to at least test each kernel a cou
https://bugs.freedesktop.org/show_bug.cgi?id=43835
--- Comment #47 from Michel D?nzer 2012-02-02 04:04:31
PST ---
How are the LVDS and DVI displays arranged in the session? Can you attach the
output of xrandr?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Y
- Original Message -
> From: "Sascha Hauer"
> To: dri-devel at lists.freedesktop.org
> Cc: "Inki Dae" , kernel at pengutronix.de
> Sent: Thursday, 2 February, 2012 11:57:52 AM
> Subject: [PATCH] drm: cleanup device registration
>
> The non modesetting drm drivers currently use a handcraft
On Thu, 2 Feb 2012, Paul Menzel wrote:
>> + * I2F_MAX_BITS can be increased, but that will add to loop iterations
>
> should that be t*w*o?
>
No, it's not "two" like the number but "to" like in "add to the group" or
"add to the pile".
On Thu, Feb 02, 2012 at 07:05:00AM -0500, David Airlie wrote:
> - Original Message -
> > From: "Sascha Hauer"
> > To: dri-devel at lists.freedesktop.org
> > Cc: "Inki Dae" , kernel at pengutronix.de
> > Sent: Thursday, 2 February, 2012 11:57:52 AM
> > Subject: [PATCH] drm: cleanup device r
1 - 100 of 145 matches
Mail list logo
