assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/e1bc0712/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/70f2bb4c/attachment-0001.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/a72704fe/attachment-0001.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/d7be36e6/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/da00c2c5/attachment-0001.html>
From: Colin Ian King
tdp_table is being leaked on an error exit return path,
fix this by kfree'ing it. Also swap comparison around to make the
patch warning free with checkpatch.
Leak found via static analysis with CoverityScan
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/84470f1a/attachment-0001.html>
To allow supporting displays that need some logic to enable power to the
display try to get a vcc-supply property from the device tree and drive
the resulting regulator accordingly.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 1
Some displays have a reset input. To assert that the display is
functional the reset gpio must be deasserted.
Teach the driver to get and drive such a gpio accordingly.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 10 ++
Some displays have a reset input and/or need a regulator to function
properly. Allow to specify them for panel-dpi devices.
Acked-by: Rob Herring
Reviewed-by: Tomi Valkeinen
Signed-off-by: Uwe Kleine-König
---
Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
1 file change
Hello,
the only change since v2 is that the patch now applies to the driver
after it was moved to drivers/gpu/drm.
Toni liked v2, only asked to fix the path and then add his review-by
tag. That's what I did.
Best regards
Uwe
Uwe Kleine-König (3):
devicetree/bindings: add reset-gpios and vcc-
Fix a copy/paste error introduced by commit feebe91a, which backported
a stability fix from gfx_v8, but incorrectly forgot to dereference
into the sync_seq array, causing hangs as soon as acceleration was
used. The wait can't finish without the correct seq value.
Signed-off-by: Grigori Goronzy
Cc
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/1146c381/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/5745b9bf/attachment-0001.html>
Hi Heiko,
On 03/21/2016 07:29 PM, Heiko Stübner wrote:
> Hi Yakir,
>
> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>> This patch set would add the RGA direct rendering based 2d graphics
>> acceleration module.
> very cool to see that.
;)
>> This patch set is based on git repository be
Hi Daniel, Jie,
Am Mittwoch, den 09.03.2016, 21:52 +0800 schrieb Daniel Kurtz:
> Hi Philipp & Jie,
>
> Sorry I only now had a chance to dig deeper and review the HDMI driver.
I wish you had had a chance to do this earlier, But better now than
after the merge. I'll split the HDMI patches from the
On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
>
On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter
> wrote:
> > Just a bit of wording polish plus mentioning that it can fail and must
> > be restarted.
> >
> > Requested by Sumit.
> >
> > v2: Fix them typos (Hans).
> >
> > Cc:
On Mon, Mar 21, 2016 at 11:02:21AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Sat, 2016-03-19 at 11:02 +0100, Daniel Vetter wrote:
> > On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 9fce91f..5eb4e97 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/
This patch add the RGA dt config of rk3288 SoC.
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3288.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 8ac49f3..af948b9 100644
--- a/arch/arm/boot/dts/rk328
Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
The RGA driver is based on Exynos G2D driver, it is performed by two
tasks simply.
1. Configu
Introduce a common subdrv register/unregister interfaces, help
external driver to hook the drm open/close event.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 49 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 15 +
2 files chang
but I'm afraid to do wrong and I'm not much
of an expert.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/9304ab6c/attachment-0001.html>
Hi, Mark and all.
This patch set would add the RGA direct rendering based 2d graphics
acceleration module.
This patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux drm-next
commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
And the RGA driver is based on Exy
From: Gustavo Padovan
virtio_gpu was failing to send vblank events when using the atomic IOCTL
with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
enables atomic pageflips updates.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 9 -
1 file
From: Gustavo Padovan
Simplify code by using the new vblank crtc helpers.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_d
On 19 March 2016 at 02:15, Mark yao wrote:
> On 2016å¹´03æ18æ¥ 19:22, Tomeu Vizoso wrote:
>>
>> When the VOP is re-enabled, it will start scanning right away the
>> framebuffers that were configured from the last time, even if those have
>> been destroyed already. To prevent the VOP from trying
On Mon, Mar 21, 2016 at 12:30:54PM +0200, Jani Nikula wrote:
> On Fri, 18 Mar 2016, Ville Syrjälä wrote:
> > On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> >> On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> >> > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyu
Hi Alexey,
Thank you for the patch.
On Monday 21 Mar 2016 15:28:38 Alexey Brodkin wrote:
> As a pair to already existing drm_connector_unregister_all() we're adding
> generic implementation of what is already done in some drivers.
>
> Once this helper is implemented we'll be ready to switch exis
We have allowed migration for only LRU pages until now and it was
enough to make high-order pages. But recently, embedded system(e.g.,
webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
so we have seen several reports about troubles of small high-order
allocation. For fixing the
Now when generic drm_connector_register_all() helper exists we may safely
substiture with it driver-specific implementation of connectors plugging in
sysfs.
Signed-off-by: Alexey Brodkin
Cc: Daniel Vetter
Cc: David Airlie
Cc: Laurent Pinchart
Cc: linux-renesas-soc at vger.kernel.org
---
No ch
This driver used to have its own implementation of connector_register_all()
which actually was taken as a prototype of drm_connector_register_all().
Now when drm_connector_register_all() exists reusing it here.
And while at it replace atmel_hlcdc_dc_connector_unplug_all()
with generic drm_connect
As a pair to already existing drm_connector_unregister_all() we're adding
generic implementation of what is already done in some drivers.
Once this helper is implemented we'll be ready to switch existing
driver-specific implementations with the generic one.
Signed-off-by: Alexey Brodkin
Cc: Dani
Current name is a bit misleading because what that helper function
really does it calls drm_connector_unregister() for all connectors.
This all has nothing to do with hotplugging so let's name things
properly.
And while at it remove potentially dangerous locking around
drm_connector_unregister()
As a pair to already existing drm_connector_unplug_all()
(which we'll rename in this series to drm_connector_unregister_all())
we're adding generic implementation of what is already done in some drivers
for registering all connectors.
After implementation of that new helper we're updating 2 driver
Hi Alexey,
Thank you for the patch.
On Monday 21 Mar 2016 15:28:40 Alexey Brodkin wrote:
> Now when generic drm_connector_register_all() helper exists we may safely
s/Now when/Now that a/
> substiture with it driver-specific implementation of connectors plugging in
s/substiture with it/substit
Hi Alexey,
Thank you for the patch.
On Monday 21 Mar 2016 15:28:37 Alexey Brodkin wrote:
> Current name is a bit misleading because what that helper function
> really does it calls drm_connector_unregister() for all connectors.
>
> This all has nothing to do with hotplugging so let's name things
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impo
https://bugzilla.kernel.org/show_bug.cgi?id=114991
--- Comment #2 from Alex Deucher ---
Please also attach your xorg log.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=114991
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
On Mon, 21 Mar 2016 15:28:39 +0300
Alexey Brodkin wrote:
> This driver used to have its own implementation of connector_register_all()
> which actually was taken as a prototype of drm_connector_register_all().
>
> Now when drm_connector_register_all() exists reusing it here.
>
> And while at it
The members child_list and active_list were added to the fence struct
without descriptions for the Documentation. Adding these.
Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
Signed-off-by: Luis de Bethencourt
Reviewed-by: Javier Martinez Canillas
---
Hi,
This second version fix
Hi
On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter
wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
>
x27; bitset
in evergreen_hpd_fini() respectively.
Signed-off-by: Nicolai Stange
---
Applicable to linux-next-20160321.
Changes to v1:
- Turn commit message's impact part into a non-impact part.
drivers/gpu/drm/radeon/evergreen.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff -
On 21 March 2016 at 13:00, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> C
https://bugzilla.kernel.org/show_bug.cgi?id=115051
Bug ID: 115051
Summary: HD 5870, GPU lockup
Product: Drivers
Version: 2.5
Kernel Version: 4.4;4.5-rc7
Hardware: All
OS: Linux
Tree: Mainline
Statu
On Fri, 2016-03-18 at 20:05 +0200, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 07:00:29PM +0100, Daniel Vetter wrote:
> >
> > On Fri, Mar 18, 2016 at 06:41:40PM +0200, Ville Syrjälä wrote:
> > >
> > > On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> > > >
> > > > On Fri,
Thanks for the patch, Gustavo!
On 18 March 2016 at 19:49, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
I think it is worthwhile to add relevant bits to the Documentation as
wel
On Fri, 18 Mar 2016, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
>> On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
>> > > -drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer,
Hi Yakir,
Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
> This patch set would add the RGA direct rendering based 2d graphics
> acceleration module.
very cool to see that.
> This patch set is based on git repository below:
> git://people.freedesktop.org/~airlied/linux drm-next
> commit
osmetic one.
>
> All of the above applies analogously to evergreen_hpd_fini().
>
> Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it
> into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset
> in evergreen_hpd_fini() r
https://bugzilla.kernel.org/show_bug.cgi?id=105711
Lars W. changed:
What|Removed |Added
Kernel Version|4.3-rc4 |4.5
--
You are receiving this mail because:
Y
On Fri, Mar 18, 2016 at 2:29 PM, Christian König
wrote:
> From: Christian König
>
> Otherwise we can run into problems with the writeback code.
>
> Signed-off-by: Christian König
Applied the series.
Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 98
> +
On Fri, Mar 18, 2016 at 12:44 PM, Christian König
wrote:
> Am 18.03.2016 um 16:58 schrieb Jérôme Glisse:
>>
>> From: Jérome Glisse
>>
>> This match the exact same control flow as existing code. It just
>> use goto instead of multiple levels of if/else. It also clarify
>> early initialization
On 19 March 2016 at 15:39, Daniel Vetter wrote:
> On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
>> Drivers, especially i915.ko, can fail during the initial migration of a
>> dma-buf for CPU access. However, the error code from the driver was not
>> being propagated back to ioctl an
Hi Daniel,
On Sat, 2016-03-19 at 11:02 +0100, Daniel Vetter wrote:
> On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> >
> > Hi Daniel,
> >
> > On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
> > >
> > > On Fri, Mar 18, 2016 at 01:01:42PM +0300, Alexey Brodkin wrote:
> >
https://bugzilla.kernel.org/show_bug.cgi?id=106901
--- Comment #31 from Roman Gruber ---
Do you guys need any additional data?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=106901
--- Comment #30 from Roman Gruber ---
Updated kernel, same behaviour
[ 256.292089] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[ 256.292190] ACPI Warning
https://bugzilla.kernel.org/show_bug.cgi?id=106901
Roman Gruber changed:
What|Removed |Added
Kernel Version|Linux ASUS-G75VW|4.5.0
|4.4.4-gentoo_03/
On 03/21/2016 04:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit Semwa
On 03/18/2016 05:02 PM, Chris Wilson wrote:
> Drivers, especially i915.ko, can fail during the initial migration of a
> dma-buf for CPU access. However, the error code from the driver was not
> being propagated back to ioctl and so userspace was blissfully ignorant
> of the failure. Rendering corru
On 03/19/16 08:39, Jean-Francois Moine wrote:
> On Thu, 17 Mar 2016 14:22:34 +0200
> Jyri Sarha wrote:
>
>> @@ -76,16 +87,22 @@
>> };
>>
>> &i2c0 {
>> -tda19988 {
>> +tda19988: tda19988 {
>> compatible = "nxp,tda998x";
>> reg = <0x70>;
>> +
>> pi
On 19.03.2016 17:15, Hans Verkuil wrote:
> On 03/19/2016 03:50 AM, Krzysztof Kozlowski wrote:
>> On Fri, Mar 18, 2016 at 03:07:00PM +0100, Hans Verkuil wrote:
>>> From: Kamil Debski
>>>
>>> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
>>> Exynos4x12 SoCs. These are required by t
Nicolai Stange writes:
> The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
> enum transform 1:1 into bit positions within the 'enabled' bitset as
> assembled by evergreen_hpd_init():
>
> enabled |= 1 << radeon_connector->hpd.hpd;
>
> However, if ->hpd.hpd happens to equal R
On 03/21/2016 08:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit Se
Just a bit of wording polish plus mentioning that it can fail and must
be restarted.
Requested by Sumit.
v2: Fix them typos (Hans).
Cc: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-media at vger.kernel.org
Cc: dri-d
On Mon, Mar 21, 2016 at 8:40 AM, Hans Verkuil wrote:
>> +For correctness and optimal performance, it is always required to use
>> +SYNC_START and SYNC_END before and after, respectively, when accessing
>> the
>> +mapped address. Userspace cannot on coherent access, even when there are
Hi Daniel,
Two small comments:
On 03/21/2016 08:30 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit S
Just a bit of wording polish plus mentioning that it can fail and must
be restarted.
Requested by Sumit.
Cc: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.or
On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: David Airlie
> Cc: dri-devel
On Fri, Mar 18, 2016 at 07:42:45PM -0700, Eric Anholt wrote:
> The DPI interface involves taking a ton of our GPIOs to be used as
> outputs, and routing display signals over them in parallel.
>
> Signed-off-by: Eric Anholt
> ---
> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 67 +++
> d
On Fri, Mar 18, 2016 at 07:42:43PM -0700, Eric Anholt wrote:
> This is a basic TFT panel with a 40-pin FPC connector on it. The
> specification doesn't define timings, but the Adafruit instructions
> were setting up 800x480 CVT.
>
> Signed-off-by: Eric Anholt
> ---
> .../bindings/display/panel/
On Fri, Mar 18, 2016 at 07:42:42PM -0700, Eric Anholt wrote:
> This is the vendor for a 7" DPI panel sold by Adafruit which I'd like
> to describe in DT.
>
> Signed-off-by: Eric Anholt
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by
Hi Linus,
This is the main drm pull request for 4.6 kernel.
The highlights are below, and there are a few merge conflicts,
but I think they should all be simple enough for you to take
care off. At least at the moment they are just the writecombine
interface changes.
Overall the coolest thing her
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/d87e7f97/attachment.html>
76 matches
Mail list logo
