:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/6d866181/attachment.html>
148.3 ref: 10, post 10
--
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/20140407/0cb70327/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/11241980/attachment.html>
dri-devel/attachments/20140407/f5088968/attachment.html>
nts/20140407/e421b552/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/a3eb6b8a/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/019f76dd/attachment.html>
t part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/00603251/attachment.html>
_resources=lax (not sure what this does)
--
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/20140407/b01cd2eb/attachment.html>
esn't work with UEFI.
--
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/20140407/bb010062/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #11 from Alex Deucher ---
Created attachment 131601
--> https://bugzilla.kernel.org/attachment.cgi?id=131601&action=edit
possible fix
Does the attached kernel patch help?
--
You are receiving this mail because:
You are watching th
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/6d2ef470/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/d567254b/attachment.html>
||3.14
--
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/20140407/0322e218/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/4d2d7094/attachment.html>
On Son, 2014-04-06 at 15:26 +0300, Lauri Kasanen wrote:
> Hi,
>
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
>
> For example, a new 64-bit mesa+libdr
On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter wrote:
> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote:
> > This is related to my memory management work. As the VRAM queue is
> > global, it cannot be determined on a per-app basis. If at least one
> > client is running old userspace, the ne
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/2b202f99/attachment.html>
||
--
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/20140407/a898bb47/attachment-0001.html>
||
--
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/20140407/dc6a2703/attachment.html>
||
--
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/20140407/be9a600b/attachment.html>
||
--
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/20140407/0650a137/attachment.html>
-
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/20140407/0b493b9e/attachment.html>
a comment that documents these assumptions, I don't see a reason
for these assumptions in the first place.
I'd prefer if we simply provided the complete message rather than rely
on drivers not to touch anything but the reply field.
Thierry
-- next part --
A non-text
On Fri, 04 Apr 2014, Alex Deucher wrote:
> Needed for proper i2c over aux handling for certain
> monitors and configurations (e.g., dp bridges or
> adapters).
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
> 1 file changed, 11 insertions(+), 4
t causing any harm on actual hardware, is it?
In that case I'll queue this up for 3.16.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/c6c11806/attachment-0001.sig>
The decoder mux id is equal to the port id of the encoder's input port
that is connected to the given crtc, not to the endpoint id (which is
arbitrary and usually zero).
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 05.04.2014 01:31, Stephen Warren wrote:
> From: Stephen Warren
>
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index db9017adfe2b..498b37e39058 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -47,7 +47,7 @@ static
On 07.04.2014 11:18, Thierry Reding wrote:
> If I understand correctly there's no immediate need for this to go to
> stable kernels, nor for it to be queued for 3.15, right? That is the
> potential extra write isn't causing any harm on actual hardware, is it?
>
> In that case I'll queue this up fo
From: Thierry Reding
Certain types of I2C-over-AUX transactions require that only the address
is transferred. Detect this by looking at the AUX message's size and set
the address-only bit appropriately.
Signed-off-by: Thierry Reding
---
Hi Alex,
This patch is required to make eDP work properly
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/77c9b71b/attachment.sig>
hierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/eb0a812c/attachment.sig>
On 07.04.2014 11:41, Thierry Reding wrote:
> On Mon, Apr 07, 2014 at 11:34:22AM +0300, Terje Bergstr?m wrote:
>> On 07.04.2014 11:18, Thierry Reding wrote:
>>> If I understand correctly there's no immediate need for this to go to
>>> stable kernels, nor for it to be queued for 3.15, right? That is
On Mon, Apr 07, 2014 at 12:23:37PM +0800, Shawn Guo wrote:
> And I see another HDMI regression with my testing on mainline kernel. I
> can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> probes 1024x768 with the mainline today.
Works for me here.
> [20.606] (II) LoadModul
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula
---
Hi Alex, similar to Thierry's patch for i915.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
On Apr-07-2014 3:33 PM, Kannan, Vandana wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-devel at lists.freedesktop.org
> ---
This patch series is be
Hi Shawn,
Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > I just came across a couple problems when testing the series on
> > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > using Russell's bran
---
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/a9808a95/attachment.sig>
rry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/ae3b2dc3/attachment.sig>
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9 +++--
1 file changed,
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_cr
Hi, Lauri.
On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I'd like to know if this is going in the right direction.
This looks fine with me.
However, if possible I'd like the drivers to enable both alloc_threshold
and priority queue on a per-memory-type basis.
That would me
Am Montag, den 07.04.2014, 12:05 +0200 schrieb Philipp Zabel:
> Hi Shawn,
>
> Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> > On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > > I just came across a couple problems when testing the series on
> > > my imx6dl-sabresd board
On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> I just came across a couple problems when testing the series on
> my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> using Russell's branch below, which I believe has all the pieces put
> together.
>
> git://ftp
Loading cursors to the LCD controller's SRAM can be corrupted when the
configured pixel clock is relatively slow. This seems to be caused
when we write back-to-back to the SRAM registers.
There doesn't appear to be any status register we can read to check
when an access has completed.
Inserting
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v9->v10:
- Rebased on top of:
"211e7f2 [media]
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
ChangeLog v7->v8:
- Shrinked even more the Cc list.
Change
According to the datasheet, setting the di0_polarity_disp_clk
field in the GENERAL di register sets the output clock polarity
to active high.
Signed-off-by: Denis Carikli
---
ChangeLog v9->v10:
- New patch that is now needed by the
"staging: imx-drm: Use de-active and pixelclk-active" patch.
--
Signed-off-by: Denis Carikli
---
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"staging: imx-drm: Use de-active and pixelclk-active display-timing
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off
Signed-off-by: Denis Carikli
---
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zabel's Ack.
- Included Lothar Wa?mann's suggestion about imx-l
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v10->v11:
- Now uses the drm-panel instead of the display-timings.
This is to get regulator support, which is lacking in
the imx-drm driver when using the display-timings.
ChangeLog v9->v10:
- Rebased
-
On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:
> On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas
> wrote:
>> Plane rotation with omapdrm is currently broken.
>> It seems omap_plane_mode_set() expects width and height in screen
>> coordinates, so pass it like that.
>>
>> Cc: Rob Clark
>> Si
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: This patch now applies against drm_modes.h
- Rebased: It now uses the new
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: It now uses the following new flags defines names:
CLK_POL, ENABLE_POL
- The inversions in ipuv3-crtc.c are now fixed.
- ipuv3-crtc.c was still using mode->private_
Signed-off-by: Denis Carikli
---
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
---
.../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt |7 ++
.../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt |7 ++
.../bindin
The DRM_PANEL_SIMPLE is needed by the eukrea
mbimxsd51's displays.
Signed-off-by: Denis Carikli
---
ChangeLog v10->v11:
- New patch, splitting it would be overkill.
---
arch/arm/configs/imx_v6_v7_defconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defcon
On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula
wrote:
> On Fri, 04 Apr 2014, Alex Deucher wrote:
>> Needed for proper i2c over aux handling for certain
>> monitors and configurations (e.g., dp bridges or
>> adapters).
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/atombios_dp.
On Mon, Apr 7, 2014 at 9:24 AM, Alex Deucher wrote:
> On Mon, Apr 7, 2014 at 3:57 AM, Jani Nikula
> wrote:
>> On Fri, 04 Apr 2014, Alex Deucher wrote:
>>> Needed for proper i2c over aux handling for certain
>>> monitors and configurations (e.g., dp bridges or
>>> adapters).
>>>
>>> Signed-off-b
On Mon, Apr 7, 2014 at 3:49 AM, Thierry Reding
wrote:
> On Fri, Apr 04, 2014 at 03:58:37PM -0400, Alex Deucher wrote:
>> We need bare address packets at the start and end of
>> each i2c over aux transaction to properly reset the connection
>> between transactions. This mirrors what the existing
On Mon, Apr 07, 2014 at 10:22:36AM +0200, Philipp Zabel wrote:
> The decoder mux id is equal to the port id of the encoder's input port
> that is connected to the given crtc, not to the endpoint id (which is
> arbitrary and usually zero).
>
> Signed-off-by: Philipp Zabel
It fixes a color corrupt
move the retry
> logic into drm_dp_i2c_xfer()? Do you mind if we do that in a follow
> up patch so we can keep it separate from the addition of the bare
> address packets?
No, looking at the code again, I don't see how we can do much better
without sacrificing much of the clarity of the code.
But perhaps this could be documented somewhere else than the I2C
helpers. Perhaps the struct drm_dp_aux comment should be updated, which
would cause the DRM docbook to automatically pick up that change as
well.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/aa052f13/attachment-0001.sig>
Hi Inki and Tomasz,
On 04/06/2014 05:15 AM, Inki Dae wrote:
(...)
> The code creating the list of components to wait for
> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
> actually enabled in kernel config.
>
> Are you sure?
>
> exynos_drm_add_components() will try t
Hi Andrzej,
On 07.04.2014 16:18, Andrzej Hajda wrote:
> Hi Inki and Tomasz,
>
> On 04/06/2014 05:15 AM, Inki Dae wrote:
>
> (...)
>> The code creating the list of components to wait for
>> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
>> actually enabled in kernel co
Updated with Thierry's comments.
Alex Deucher (4):
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/dp/i2c: Update comments about common i2c over dp assumptions (v2)
drm/radeon/dp: switch to the commo
We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions. This mirrors what the existing dp i2c
over aux algo currently does.
This fixes EDID fetches on certain monitors especially with
dp bridges.
v2: update as per
Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).
v2: add comments clarifying tx_size setting.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 23 ++-
1 file changed, 18 insertions(+), 5 del
If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field. Doing so
breaks the logic in the common code.
v2: update struct drm_dp_aux comments about assumptions
Signed-off-by: Alex De
Provides a nice cleanup in radeon.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 117 +
drivers/gpu/drm/radeon/radeon_connectors.c | 44 ++-
drivers/gpu/drm/radeon/radeon_display.c| 11 ++-
drivers/gpu/drm/radeon/radeon_i2c
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
> To support bare address requests used by the drm dp helpers.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Hi Alex, similar to Thierry's patch for i915.
>
Looks good to me.
Reviewed-by: Alex Deucher
Do you want me to add this to the patch set?
On Mon, 07 Apr 2014 14:25:28 +0200
Thomas Hellstrom wrote:
> Hi, Lauri.
>
> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> > Hi list, Thomas,
> >
> > I'd like to know if this is going in the right direction.
>
> This looks fine with me.
>
> However, if possible I'd like the drivers to enable b
On 04/07/2014 04:39 PM, Lauri Kasanen wrote:
> On Mon, 07 Apr 2014 14:25:28 +0200
> Thomas Hellstrom wrote:
>
>> Hi, Lauri.
>>
>> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
>>> Hi list, Thomas,
>>>
>>> I'd like to know if this is going in the right direction.
>> This looks fine with me.
>>
>> Ho
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> ttm_bo_unref unconditionally calls kref_put on it's argument, so the
> thing can't be NULL without already causing Oopses.
Doesn't this mean the NULL check is in the wrong place (rather than the
NULL check should be removed)?
> Spotted by coverity.
>
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The ->gem_free_object never gets called with a NULL pointer, the check
> is redundant. Also checking after the upcast allows compilers to elide
> it anyway.
Right... because if obj was NULL, subtracting some offset from it won't
still be NULL.
> Spot
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The ->gem_free_object never gets called with a NULL pointer, the check
> is redundant. Also checking after the upcast allows compilers to elide
> it anyway.
>
> Spotted by coverity.
>
> Signed-off-by: Daniel Vetter
Same as MGA change.
Reviewed-by:
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The ->gem_free_object never gets called with a NULL pointer, the check
> is redundant. Also checking after the upcast allows compilers to elide
> it anyway.
>
> Spotted by coverity.
>
> Signed-off-by: Daniel Vetter
Same as MGA change.
Reviewed-by:
On 04/05/2014 02:44 AM, Daniel Vetter wrote:
> The outer if already checks for data != 0, so it can't really be
> 0. Hence remove it.
>
> Now I don't have specs or anything for this beast, so I have no
> idea whether this was actually intended or whether the logic
> should be different. At least t
On 04/05/2014 02:45 AM, Daniel Vetter wrote:
> The ->gem_free_object never gets called with a NULL pointer, the check
> is redundant. Also checking after the upcast allows compilers to elide
> it anyway.
>
> Noticed while chasing coverity reports, somehow this one here was not
> flagged.
>
> Sign
g/archives/dri-devel/attachments/20140407/256734dd/attachment.html>
On 04/05/2014 02:45 AM, Daniel Vetter wrote:
> This is C standard hair-splitting, but afaict
> - sum will be promoted to signed int in computation since
> uint8_t fits
> - signed overflow is undefined.
>
> No we need to add up an awful lot of bytes to actually make it
^^
Now
> overflow. But I
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/cb58ec57/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/15687069/attachment.html>
On 04/07/2014 02:18 AM, Thierry Reding wrote:
> On Fri, Apr 04, 2014 at 04:31:05PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> BIT_WORD() truncates rather than rounds, so the loops in
>> syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
>> rather than < in an at
On 07.04.2014 17:16, Inki Dae wrote:
> Hi Andrzej,
>
> 2014-04-07 23:18 GMT+09:00 Andrzej Hajda :
>> Hi Inki and Tomasz,
>>
>> On 04/06/2014 05:15 AM, Inki Dae wrote:
>>
>> (...)
>>> The code creating the list of components to wait for
>>> (exynos_drm_add_components()) doesn't seem to consider whic
y sys. :)
368 is much higher than 100. LMK if you need more. TIA.
--
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/20140407/6642275c/attachment-0001.html>
Hi
On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
wrote:
> The context_dtor callback is only called once we've successfully loaded
> the driver, which means dev->dev_private is set up. The check is hence
> pointless.
>
> Also dev->dev_private is deref already above, so compilers are free
> to el
Hi
On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
wrote:
> Hi all,
>
> Rainy w/e here and I got a bit bored, so looked at coverity again. I've closed
> all outstanding issues in drivers/gpu now either as false positives or fixed
> in
> this series expect for vmwgfx/ttm stuff (not enough clue) a
ot be garbled anymore, but scrolling in
Firefox (and possible other applications) is much slower/less smooth.
--
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/
||
--
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/20140407/523bd4d7/attachment.html>
On Mon, Apr 7, 2014 at 5:51 PM, David Herrmann wrote:
> On Sat, Apr 5, 2014 at 11:44 AM, Daniel Vetter
> wrote:
>> The context_dtor callback is only called once we've successfully loaded
>> the driver, which means dev->dev_private is set up. The check is hence
>> pointless.
>>
>> Also dev->dev_p
On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas wrote:
> On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:
>> On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas
>> wrote:
>>> Plane rotation with omapdrm is currently broken.
>>> It seems omap_plane_mode_set() expects width and height in screen
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/39973576/attachment-0001.html>
On Mon, Apr 7, 2014 at 6:05 AM, Thierry Reding
wrote:
> On Fri, Mar 28, 2014 at 10:04:09PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
>> > Add cursor plane as a parameter to drm_crtc_init() and update all
>> > existing DRM drivers to use a helper-pr
s.freedesktop.org/archives/dri-devel/attachments/20140407/ccb8f37f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #16 from Tom Yan ---
I tried to remove the DisplayPort-specific code in radeon_connector_hotplug()
of radeon_connector.c and everything seems to work like a charm. What is the
code supposed to do actually?
Though, btw, it seems that o
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/d684ac95/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #17 from Tom Yan ---
One thing to add, unplugging it physically in X still makes it blank. It
happens no matter the code is removed or not.
Also, HDMI doesn't work all time yet, seems that if the TV is powered off and
it goes into DPM
s 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/20140407/2bc40304/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140407/6377f175/attachment.html>
1 - 100 of 125 matches
Mail list logo
