2016ë
05ì 30ì¼ 03:35ì Daniel Vetter ì´(ê°) ì´ ê¸:
> We want to hide drm_atomic_state internals better.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
> 1 file changed, 4 insertion
Picked it up.
Thanks,
Inki Dae
2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
>
> - Tobias
>
> Tobias Jakobi wrote:
>> The current bitwise AND should result in the same assembler
>> but this is what the code is actually supposed to do.
>>
>> Signed-off-by: Tobias Jakobi
>
Picked it up.
Thanks,
Inki Dae
2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> 3 files changed, 3 deletions(-)
Picked it up.
Thanks,
Inki Dae
2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
>
> - Tobias
>
> Tobias Jakobi wrote:
>> This makes the defines consistent with the rest.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
2016ë
06ì 10ì¼ 09:24ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
>
> On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae wrote:
>
> [snip]
>
>>> I know that removing .trg_type is enough but I also removed those lines
>>> because the fields are not used if .trg_type != I80_HW_TRG. So
On 10.06.2016 23:43, Daniel Vetter wrote:
> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> If userspace wants a page flip to take effect during vblank sequence n,
>> it has to wait for vblank seqno n-1 before calling the
>> DRM_IOCTL_MODE_PAGE_FLIP io
hing I can provide you with? Any specific test or steps?
--
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/20160613
Hi, YT:
Some comments inline.
On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6
> drivers/gpu/d
On Mon, Jun 13, 2016 at 3:34 AM, Inki Dae wrote:
> Picked it up.
Fyi it's already in drm-misc too.
-Daniel
>
> Thanks,
> Inki Dae
>
> 2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Ping!
>>
>> - Tobias
>>
>> Tobias Jakobi wrote:
>>> The current bitwise AND should result in the s
Hi, YT:
One comment inline.
On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> We need to acquire mutex before using the resources,
> and need to release it after finished.
> So we don't need to write registers in the blanking period.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediate
It seems pretty clear that bitwise OR was intended here and not logical
OR.
Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 8f96c40..3c1482b 100644
--- a/drivers
For the series:
Reviewed-by: Nicolai Hähnle
This patch is also:
Tested-by: Nicolai Hähnle
On 10.06.2016 16:13, Alex Deucher wrote:
> Align to the jump table offset. Fixes hangs on some
> systems with GFX PG enabled.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v
vel/attachments/20160613/c0e4c943/attachment.html>
op.org/archives/dri-devel/attachments/20160613/58137000/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=119991
--- Comment #3 from Jani-Markus Maunus ---
I did a bisect out of curiosity, and in my case the following commit fixes both
issues.
commit 274ad65c9d02bdcbee9bae045517864c3521d530
Author: Jérome Glisse
Date: Fri Mar 18 16:58:39 2016 +0100
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/04a8c3ba/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Lucas Stach changed:
What|Removed |Added
CC||dev at lynxeye.de
--- Comment #4 from Luca
On Sun, Jun 12, 2016 at 04:03:56PM +0100, Sudip Mukherjee wrote:
> We may have a situation that the memory allocation for fbdefio fails
> and then the allocation for fbops may succeed as some memory has been
> freed somewhere. Lets free fbops also to face these rare situtation.
> Since kfree can ha
On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
> wrote:
> > Drivers transitioning to atomic might not yet want to enable full
> > DRIVER_ATOMIC support when it's not entirely working. But using atomic
> > internally makes a lot more sense
On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote:
> On 10.06.2016 23:43, Daniel Vetter wrote:
> > On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote:
> >> From: Michel Dänzer
> >>
> >> If userspace wants a page flip to take effect during vblank sequence n,
> >> it has to
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/5b014ce7/attachment.html>
The lable fail_connector should placed before fail_encoder since
encoder was initialized before connector. which should also be
called after connector initialization failed.
Signed-off-by: Meng Yi
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
On Sat, Jun 11, 2016 at 01:50:17PM +, Grodzovsky, Andrey wrote:
> Hi.
>
> Just a reminder with regard to this patch. Please comment if any changes are
> required.
> Thanks.
When resubmitting please gather all the r-b you've collected and resubmitt
he entire patch using git send-email. If you
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/20160613/7ae8c5b5/attachment.html>
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/c5d62ced/attachment.html>
Hi Matthew,
sounds like the UVD block doesn't want to initialize. No idea off hand
why, could be anything. I would need the hardware here for a closer
inspection.
For a workaround you can try to disable the UVD blokc using the
ip_block_mask module parameter (it's a bitmask of enabled blocks e.
On 06/13/16 17:06, Daniel Vetter wrote:
> On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote:
>> On 10.06.2016 23:43, Daniel Vetter wrote:
>>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote:
From: Michel Dänzer
If userspace wants a page flip to take effe
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/183fd09d/attachment.html>
On Fr, 2016-06-10 at 17:20 +0200, Daniel Vetter wrote:
> On Fri, Jun 10, 2016 at 12:07:53AM +0200, Daniel Vetter wrote:
> > Now that the core helpers support nonblocking atomic commits there's
> > no need to invent that wheel separately (instead of fixing the bug in
> > the atomic implementation of
version 4:
make sure that normalized zpos value is stay in the defined property
range and warn user if not.
Fix NULL pointer bug in rcar-du while setting zpos value.
No changes in the other drivers.
version 3:
use kmalloc_array instead of kmalloc.
Correct normalize_zpos computation (comeback to M
version 4:
fix null pointer issue while setting zpos in plane reset function
This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.
Signed-off-by: Benjamin Gaignard
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Laurent Pinchart
Cc: Marek Szyprowsk
From: Marek Szyprowski
This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.
Signed-off-by: Marek Szyprowski
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: An
version 4:
- make sure that normalized zpos value is stay
in the defined property range and warn user if not
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzy
On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
> On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
>> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
>> wrote:
>> > Drivers transitioning to atomic might not yet want to enable full
>> > DRIVER_ATOMIC support when it's not entirely wo
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
---
Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description
.../bindings/display/rockchip/cdn-dp-rockchip.txt | 62 ++
1 file
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
Hi all
This series patch is for rockchip Type-C phy and DisplayPort controller
driver.
The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and H
Hi Dave,
please consider merging this tag, which contains the v16 MT8173 HDMI
patches I sent on 2016-05-26, rebased onto v4.7-rc2. There have been no
further comments.
regards
Philipp
The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
Linux 4.7-rc2 (2016-06-05 14:31:
On Tue, 31 May 2016, James Bottomley
wrote:
> On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
>> On Mon, 30 May 2016, James Bottomley <
>> James.Bottomley at HansenPartnership.com> wrote:
>> > I've tested a pristine 4.6.0 system, so it's definitely something
>> > that
>> > went in during th
Hi Guenter
Thanks for your comments
On 06/09/2016 06:13 AM, Guenter Roeck wrote:
>> +if (ret < 0) {
>> >+ dev_err(dp->dev, "failed to request firmware %d\n", ret);
>> >+ return ret;
>> >+ }
>> >+
>> >+ hdr = (struct cdn_firmware_header *)fw->data;
>> >+ if (fw->size
On 13/06/16 10:56, Shunqian Zheng wrote:
> Hi
>
> On 2016å¹´06æ10æ¥ 17:10, Tomasz Figa wrote:
>> Hi,
>>
>> On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
>> wrote:
>>> Use DMA API instead of architecture internal functions like
>>> __cpuc_flush_dcache_area() etc.
>>>
>>> To support the virtual
On 08/06/16 13:56, Liviu Dudau wrote:
> In hdlcd_drm_bind()/hdlcd_drm_unbind() we unwind the DRM setup in the
> wrong order (drm_mode_config_cleanup() before connector and encoder
> had a chance to cleanup their memory or before drm_dev_unregister()).
> The correct order should match in both functi
archives/dri-devel/attachments/20160613/be2ccb34/attachment.html>
e: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/8b823497/attachment.sig>
lid EDID or the DDC used to
get at the EDID might be broken (I've been told that it's fairly common
for OEMs to not wire through the DDC wires in cables to reduce costs).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/9e49e0f3/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=114711
--- Comment #2 from Peter Gerber ---
Yes, this fixes the issue.
--
You are receiving this mail because:
You are watching the assignee of the bug.
27;t give you all the information
that you need. I've never seen hardware that is programmed with the
physical size of the panel, so there's no way to read that back and
you'd still have to either parse EDID or use the value hard-coded in
the simple-panel driver if you want to compute the pixel density.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d4012955/attachment.sig>
--- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/4e412a35/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=119991
--- Comment #4 from Felix Schwarz ---
(In reply to Jani-Markus Maunus from comment #3)
> I might be just rambling at this point, but 4.6.1 stable was definitely
> bugged for me, yet this commit is dated well before 4.6.1 release - any idea
> what
gt; +
> + ret = devm_regulator_bulk_get(dev, num, s);
> + if (ret < 0) {
> + dev_err(dev, "%s: failed to init regulator, ret=%d\n",
> + __func__, ret);
> + return ret;
> + }
> +
> + jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(jdi->reset_gpio)) {
> + dev_err(dev, "cannot get reset-gpios %ld\n",
> + PTR_ERR(jdi->reset_gpio));
This is a third variant of error reporting. Please stick to one.
> + jdi->reset_gpio = NULL;
> + } else {
> + gpiod_direction_output(jdi->reset_gpio, 0);
> + }
> +
> + jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(jdi->enable_gpio)) {
> + dev_err(dev, "cannot get enable-gpio %ld\n",
> + PTR_ERR(jdi->enable_gpio));
> + jdi->enable_gpio = NULL;
> + } else {
> + gpiod_direction_output(jdi->enable_gpio, 0);
> + }
> +
> + jdi->backlight = drm_panel_create_dsi_backlight(jdi->dsi);
You should check for errors here.
> +MODULE_AUTHOR("Vinay Simha BN ");
> +MODULE_DESCRIPTION("JDI WUXGA LT070ME05000 DSI video mode panel driver");
The commit message names this "JDI LT070ME05000 WUXGA", please use the
same here.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/bbec2c12/attachment.sig>
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f313b4d..3099390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i9
The qemu stdvga can be configured with a wide range of video memory,
from 1 MB to 256 MB (default is 16 MB). In case it is configured
with only 1 or 2 MB it isn't really usable with bochsdrm, due to
depths other than 32bpp not being supported so that isn't enough
memory for a reasonable sized fram
On Mon, Jun 13, 2016 at 12:02:31PM +0100, Robin Murphy wrote:
> On 08/06/16 13:56, Liviu Dudau wrote:
> >In hdlcd_drm_bind()/hdlcd_drm_unbind() we unwind the DRM setup in the
> >wrong order (drm_mode_config_cleanup() before connector and encoder
> >had a chance to cleanup their memory or before drm
On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/32524460/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/3885c64a/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/e6dbb8e8/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/374c5a41/attachment.html>
From: Thierry Reding
Use a consistent name for the function that implements set_tear_scanline
and reword and reformat the kerneldoc slightly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_mipi_dsi.c | 16
include/drm/drm_mipi_dsi.h | 2 +-
2 files changed, 9 inser
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/07afb113/attachment-0001.html>
On Mon, Jun 13, 2016 at 11:20 AM, Gerd Hoffmann wrote:
> On Fr, 2016-06-10 at 17:20 +0200, Daniel Vetter wrote:
>> On Fri, Jun 10, 2016 at 12:07:53AM +0200, Daniel Vetter wrote:
>> > Now that the core helpers support nonblocking atomic commits there's
>> > no need to invent that wheel separately (
|Linux (All)
--
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/20160613/91d3ee3f/attachment.html>
On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote:
> There were a couple messed up things about this fail path.
> (1) it would drop object_name_lock twice
> (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles())
> needs to grab prime_lock
>
> Reported-by: Alex Deucher
> Signed-off-by:
On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote:
> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
> >> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
> >> wrote:
> >> > Drivers transitioning to atomic might not yet want
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/79824d28/attachment-0001.html>
On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote:
> On 06/13/16 17:06, Daniel Vetter wrote:
> > On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote:
> >> On 10.06.2016 23:43, Daniel Vetter wrote:
> >>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote:
> F
On Mon, Jun 13, 2016 at 12:47:33PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Fri, 2016-06-10 at 17:29 +0300, Alexey Brodkin wrote:
> > From: Ruud Derwig
> >
> > In case of simulation there's no real encoder/transmitter device
> > because in the model's virtual LCDÂ Â we're rendering whate
From: Christian König
Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
for working a lot with the PLLs and figuring this out.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -
From: Christian König
Drop the lock before calling cancel_delayed_work_sync().
Signed-off-by: Christian König
Tested-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
b/d
From: Christian König
A regular spin_lock/unlock should do here as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
b/driver
Add MAINTAINERS entry for ARM Mali-DP driver and update the
HDLCD file matching pattern to cover only HDLCD rather than
the whole drivers/gpu/drm/arm directory.
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/
Hello,
This is the fourth revision of the driver for the Mali Display Processors (Mali
DP).
Currently, the driver supports the Display Engine found in Mali DP500, DP550
and DP650, with up to 3 planes that can be rotated by the hardware. There are
features that the hardware supports that are not c
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/
On Mon, 13 Jun 2016, Jani Nikula wrote:
> On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Jani Nikula
And pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 --
>> 1 file changed,
On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote:
> There were a couple messed up things about this fail path.
> (1) it would drop object_name_lock twice
> (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles())
> needs to grab prime_lock
>
> Reported-by: Alex Deucher
> Signed-off-by:
yup, looks like we can drop the two pipe<0 checks. Care to send a patch?
BR,
-R
On Mon, Jun 13, 2016 at 10:51 AM, David Binderman
wrote:
> Hello there,
>
> 1.
>
> linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:545]: (style)
> Checking if unsigned variable 'pipe' is less than zero.
>
> So
On Mon, Jun 13, 2016 at 11:19:20AM -0400, Alex Deucher wrote:
> On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote:
> > There were a couple messed up things about this fail path.
> > (1) it would drop object_name_lock twice
> > (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles())
> > n
t;https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d0d700cf/attachment.html>
Fill set_busid field with drm_platform_set_busid helper function
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index b440617..98d67b4 100644
--- a/drivers/gpu/dr
On Mon, Jun 13, 2016 at 11:33 AM, Daniel Vetter wrote:
> On Mon, Jun 13, 2016 at 11:19:20AM -0400, Alex Deucher wrote:
>> On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote:
>> > There were a couple messed up things about this fail path.
>> > (1) it would drop object_name_lock twice
>> > (2) drm_gem
t attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/2ffa8a91/attachment.sig>
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/30c1c874/attachment.html>
On Mon, Jun 13, 2016 at 10:09 AM, Christian König
wrote:
> From: Christian König
>
> Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
> for working a lot with the PLLs and figuring this out.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Applied. Th
On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian König wrote:
> From: Christian König
>
> A regular spin_lock/unlock should do here as well.
>
> Signed-off-by: Christian König
Just drive-by comment, but you can't mix up irq spinlocks with normal
ones. And there's places where this is sti
Since d16e0faab91 (iommu: Allow selecting page sizes per domain) the
iommu core demands the page size to be set per domain, otherwise any
mapping attempts will be dropped. Make sure to set a valid page size
for the etnaviv iommu.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_iom
On Tue, Jun 07, 2016 at 11:08:02AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We don't need to use &radeon_crtc->base there as crtc is available
> in the function.
>
> Signed-off-by: Gustavo Padovan
All expect patch 5 merged, thanks.
-Daniel
> ---
> drivers/gpu/drm/radeon/rade
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Dmitrii Tcvetkov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am Donnerstag, den 02.06.2016, 22:28 +0200 schrieb Daniel Vetter:
> On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > in a modeset. (v2)"), the reference counts of all connectors in the
> > drm_mode_set gi
Yakir,
On Sat, Jun 11, 2016 at 7:56 PM, Yakir Yang wrote:
> The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
> connected using eDP interfaces.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v3:
> - Correct the size of panel_desc to active area 262mmx164mm (Emil, Stéphane
Am 13.06.2016 um 18:33 schrieb Daniel Vetter:
> On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian König wrote:
>> From: Christian König
>>
>> A regular spin_lock/unlock should do here as well.
>>
>> Signed-off-by: Christian König
> Just drive-by comment, but you can't mix up irq spinlocks wi
On Mon, Jun 13, 2016 at 06:49:57PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 02.06.2016, 22:28 +0200 schrieb Daniel Vetter:
> > On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > > in a modeset. (v2)
On Fri, Jun 10, 2016 at 04:16:33PM +0530, Archit Taneja wrote:
> MDP5:
> - Don't ask for source clock
>
> MDP4:
> - Give a better name for MDP_TV_CLK
> - Remove TV_SRC
> - Add MDP_AXI_CLK
This could use the explanation in the commit msg why it is okay you are
breaking compatibility.
With that,
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/695de130/attachment.html>
On Sat, Jun 11, 2016 at 4:02 AM, Christian König
wrote:
> Am 11.06.2016 um 08:51 schrieb Andres Rodriguez:
>>
>> When executing in a PCI passthrough based virtuzliation environemnt, the
>> hypervisor will usually attempt to send a PCIe bus reset signal to the
>> ASIC when the VM reboots. In this
When executing in a PCI passthrough based virtuzliation environment, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based
On Fri, Jun 10, 2016 at 04:16:37PM +0530, Archit Taneja wrote:
> The "qcom,data-lane-map" binding mentioned in the document is changed to
> the more generic "data-lanes" property specified in:
>
> Documentation/devicetree/bindings/media/video-interfaces.txt
>
> The previous binding expressed phys
On Mon, 13 Jun 2016 15:45:20 -0400
Alex Deucher wrote:
> When executing in a PCI passthrough based virtuzliation environment, the
> hypervisor will usually attempt to send a PCIe bus reset signal to the
> ASIC when the VM reboots. In this scenario, the card is not correctly
> initialized, but we
freedesktop.org/archives/dri-devel/attachments/20160613/d94c4308/attachment.html>
1 - 100 of 121 matches
Mail list logo