In order to ease up on the logic, break the current code to gather the
dssdevs:
first get all available dssdevs, then call connect on each dssdev. As the
last step remove the dssdevs which failed to connect from the available
dssdev list.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapd
Instead of reaching back to DSS to iterate through the dss_devices every
time, use an internal array where we store the available and usable
dss_devices.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 95 +++---
drivers/gpu/drm/omapdrm/oma
Hi
The series adds support for changing the order of the displays defined by DT
display aliases.
The motivation to do such a thing is that for example the fb emulation is
treating the first display/crtc as the 'main' display and will create the
fb emulation based on the first display's propertie
It makes the cleanup paths a bit cleaner.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 9b3c36b48356..90
Sort the dssdev array based on DT aliases.
With this change we can remove the panel ordering from dss/display.c and
have all sorting related to dssdevs in one place.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 22 ++
1 file changed, 22 insertions(
omapdrm.displays (int array) can be used to reorder the displays by id if
needed. It can be also used to disable display.
If the board have two active displays:
0 - LCD
1 - HDMI
then:
omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
omapdrm.displays=1,0 - represents reverse order
The previous patch implements the ordering of the dss_devices based on DT
aliases in omap_drm.c, so there is no need to do the ordering in
dss/display.c anymore.
At the same time remove the alias member of the omap_dss_device struct
since it is no longer needed. The only place it was used is in t
If we allocate the drm_device earlier we can just return the error code
without the need to use goto.
Do the unref of the drm_device as a last step when cleaning up. This will
make the drm_device available longer for us and makes sure that we only
free up the memory when all other cleanups have be
On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote:
> Hi Dave,
> One fix for next.
> Sorry for late pull request. If it can't catch this round, will resend
> on next round.
drm-misc is always open for features, which makes this a lot simpler. Just
in case you want to reconsider moving hi
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #38 from Ethan Hsieh ---
Created attachment 133861
--> https://bugs.freedesktop.org/attachment.cgi?id=133861&action=edit
Xorg.0.log (ubuntu 17.04 + modeset)
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #39 from Ethan Hsieh ---
Created attachment 133862
--> https://bugs.freedesktop.org/attachment.cgi?id=133862&action=edit
Xorg.0.log (ubuntu 17.04 + intel&amdgpu)
I install Ubuntu 17.4 and can reproduce corruption issue in AC/DC mo
On Fri, Aug 25, 2017 at 10:14:03AM +0200, Hans Verkuil wrote:
On 24/08/17 14:26, Brian Starkey wrote:
On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:
On 08/24/17 13:14, Brian Starkey wrote:
Hi Hans,
On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
On 08/21/2017 06:
https://bugs.freedesktop.org/show_bug.cgi?id=102300
--- Comment #9 from f...@mt2015.com ---
I updated bunch of packages today (linux-amd-staging,mesa etc) and now DVI-I-1
is not recognized but it is shown as DVI-D-1. This also brought new problem:
monitors 'blink' randomly, about every ten seconds
https://bugs.freedesktop.org/show_bug.cgi?id=102300
--- Comment #10 from f...@mt2015.com ---
By the way refresh rate 60.00 is used since DVI-I-1 -> DVI-D-1 change.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne wrote:
Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit :
> What I mean was: an application can use the modifier to give buffers from
> one device to another without ne
Hi Dave,
On 29 August 2017 at 16:32, Daniel Vetter wrote:
> On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote:
>> Hi Dave,
>> One fix for next.
>> Sorry for late pull request. If it can't catch this round, will resend
>> on next round.
>
> drm-misc is always open for features, which ma
On 2017年08月23日 14:26, Sandy Huang wrote:
This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.
Signed-off-by: Sandy Huang
Signed-off-by: Mark yao
Signed-off-by: Heiko Stuebner
---
Looks good for me:
Reviewed-by: Mark Yao
Changes
Am Dienstag, 29. August 2017, 18:17:11 CEST schrieb Mark yao:
> On 2017年08月23日 14:26, Sandy Huang wrote:
> > This patch add Document for Rockchip Soc RK3288 LVDS,
> > This based on the patches from Mark yao and Heiko Stuebner.
> >
> > Signed-off-by: Sandy Huang
> > Signed-off-by: Mark yao
> > Sig
https://bugzilla.kernel.org/show_bug.cgi?id=196791
--- Comment #6 from Walther Pelser (w.pel...@web.de) ---
Created attachment 258143
--> https://bugzilla.kernel.org/attachment.cgi?id=258143&action=edit
lsinitrd kernel 4.13.0-rc6 parts
the firmware is there
--
You are receiving this mail beca
https://bugzilla.kernel.org/show_bug.cgi?id=196791
--- Comment #7 from Walther Pelser (w.pel...@web.de) ---
(In reply to Takashi Iwai from comment #5)
> It doesn't matter what zypper says. Simply check initrd content via
> lsinitrd.
> If the target firmware file is found there, it's OK. If not,
Am 29.08.2017 um 15:21 schrieb Himanshu Jha:
Kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr
On Fri, Jul 28, 2017 at 04:58:27PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote:
> > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote:
> > > > Some ARM
On Tue, Aug 29, 2017 at 11:54 AM, Xinliang Liu wrote:
> Hi Dave,
>
> On 29 August 2017 at 16:32, Daniel Vetter wrote:
>> On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote:
>>> Hi Dave,
>>> One fix for next.
>>> Sorry for late pull request. If it can't catch this round, will resend
>>>
Most code only cares about the current commit or previous commit.
Fortunately we already have a place to track those. Move it to
drm_crtc_state where it belongs. :)
The per-crtc commit_list is kept for places where we have to look
deeper than the current or previous commit for checking whether to
Currently we neatly track the crtc state, but forget to look at
plane/connector state.
When doing a nonblocking modeset, immediately followed by a setprop
before the modeset completes, the setprop will see the modesets new
state as the old state and free it.
This has to be solved by waiting for h
https://bugzilla.kernel.org/show_bug.cgi?id=196791
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=102013
Amr Ibrahim changed:
What|Removed |Added
Summary|GTK3 tooltips are corrupted |GTK3 tooltips are corrupted
Am 29.08.2017 um 15:12 schrieb Himanshu Jha:
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c
On 2017-08-29 09:12 AM, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
>
> Signed-off-by: Himanshu Jha
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
> .../gpu/drm/amd/powerplay/hwmgr/processp
https://bugzilla.kernel.org/show_bug.cgi?id=196791
--- Comment #9 from Takashi Iwai (ti...@suse.de) ---
I guess it's module since Walther is using SUSE kernels.
Could you give the full dmesg output from 4.13.0-rc6-vanilla you've installed
recently? That has the firmware file in initrd as in comm
On Fri, Aug 25, 2017 at 03:34:33PM +0200, Daniel Vetter wrote:
On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
Hi,
Thanks for the CC.
On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf Tr??nnes wrote:
> (cc affected parties)
>
>
> Den 18.08.2017 09.46, skrev Daniel Vetter:
> > On
Den 28.08.2017 23.41, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:44PM +0200, Noralf Trønnes wrote:
Support device unplug by introducing a new initialization function:
drm_fb_helper_simple_init() which together with
drm_fb_helper_dev_unplug() and drm_fb_helper_fb_destroy() handles open
f
https://bugzilla.kernel.org/show_bug.cgi?id=196791
--- Comment #10 from Walther Pelser (w.pel...@web.de) ---
(In reply to Alex Deucher from comment #8)
> The only reason the firmware would fail to load is if it's not available.
> From the log, it shows direct fw loading failed. Did you build rad
https://bugs.freedesktop.org/show_bug.cgi?id=102468
Bug ID: 102468
Summary: RX470 powerplay issues on hybrid laptop system (dGPU
does not power down)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=102468
--- Comment #1 from Alex Deucher ---
(In reply to taijian from comment #0)
> If I blacklist amdgpu in the kcl and then force the dGPU to off with
> acpi_call, the reported power consumption in powertop drops to ~12 W, with a
> corresponding incr
On Wed, Aug 23, 2017 at 02:26:59PM +0800, Sandy Huang wrote:
> This patch add Document for Rockchip Soc RK3288 LVDS,
> This based on the patches from Mark yao and Heiko Stuebner.
>
> Signed-off-by: Sandy Huang
> Signed-off-by: Mark yao
> Signed-off-by: Heiko Stuebner
> ---
>
> Changes accordin
Den 28.08.2017 23.46, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:45PM +0200, Noralf Trønnes wrote:
Add drm_fbdev_cma_dev_unplug() and use the drm_fb_helper device unplug
support. Pin driver module on fb_open().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/
Hi Thierry,
On Fri, Aug 18, 2017 at 12:08 PM, Thierry Reding
wrote:
> I've applied, though somewhat reluctantly, this to drm-misc-next without
> Rob's Acked-by, but the device tree bindings look trivial enough.
Was it really applied? I am not able to find this patch in linux-next.
Thanks
_
Daniel Vetter writes:
> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes wrote:
>> Hi,
>>
>> Currently I'm using the cma library with tinydrm because it was so
>> simple to use even though I have to work around the fact that reads are
>> uncached. A bigger problem that I have become aware of, is
Den 28.08.2017 23.58, skrev Daniel Vetter:
Hi Noralf,
On Mon, Aug 28, 2017 at 07:17:42PM +0200, Noralf Trønnes wrote:
This adds device unplug support to drm_fb_helper, drm_fb_cma_helper
(fbdev) and tinydrm.
My motivation for doing this is to make tinydrm useable with USB
devices. This discuss
https://bugs.freedesktop.org/show_bug.cgi?id=102468
--- Comment #2 from taij...@posteo.de ---
I followed the recommendations of this page:
https://wiki.archlinux.org/index.php/Hybrid_graphics
The call working on my system is: echo "\\_SB.PCI0.PEG0.PEGP._OFF" >
/proc/acpi/call
If I use this comma
https://bugzilla.kernel.org/show_bug.cgi?id=196791
Walther Pelser (w.pel...@web.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On 08/28/2017 12:17 PM, Noralf Trønnes wrote:
Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
Acked-By: David
Hi Dave,
A few fixes for drm-next for 4.14. Nothing too major. I'll check in
again in a week or so.
The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f:
Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next
(2017-08-23 05:32:26 +1000)
are availa
Reviewed-by: Rex Zhu mailto:rex@amd.com>>
Best Regards
Rex
From: Wentland, Harry
Sent: Tuesday, August 29, 2017 9:34:01 PM
To: Himanshu Jha; airl...@linux.ie
Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org;
On Tue, Aug 29, 2017 at 9:28 AM, Christian König
wrote:
> Am 29.08.2017 um 15:21 schrieb Himanshu Jha:
>>
>> Kfree on NULL pointer is a no-op and therefore checking is redundant.
>>
>> Signed-off-by: Himanshu Jha
>
>
> Reviewed-by: Christian König
>
Applied. thanks!
Alex
>
>> ---
>> drive
On Tue, Aug 29, 2017 at 9:34 AM, Harry Wentland wrote:
> On 2017-08-29 09:12 AM, Himanshu Jha wrote:
>> kfree on NULL pointer is a no-op and therefore checking is redundant.
>>
>> Signed-off-by: Himanshu Jha
>
> Reviewed-by: Harry Wentland
Applied. thanks!
Alex
>
> Harry
>
>> ---
>> drivers
Hi Dave,
The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98:
Linux 4.13-rc7 (2017-08-27 17:20:40 -0700)
are available in the git repository at:
git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-fixes
for you to fetch changes up to 021aba761f2a6c12158afb9993
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: ff14f0dca1f23b2cff41e43440c7952965e5fc1b
commit: 9b37a9b8f6464e3ce1ce59eda1ec7053c8e77ca3 [68/819] drm/amd/dc: Add dc
display driver (v2)
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC
I've send a related kernel crash log to amd-devel some days ago without
any answer, yet...
Was:
[amd-staging-drm-next] kernel crash with amdgpu on RX580 in
'drm_object_property_get_value'
I get this in _all_ current 'amd-staging-drm-next' versions. ;-(
[16301.515079] [ cut here ]
(Sorry for so many list cross-posting and big cc)
Please help testing !
The invalidate_page callback suffered from 2 pitfalls. First it used to
happen after page table lock was release and thus a new page might have
been setup for the virtual address before the call to invalidate_page().
This is
On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote:
>
> Note this is barely tested. I intend to do more testing of next few days
> but i do not have access to all hardware that make use of the mmu_notifier
> API.
Thanks for doing this.
> First 2 patches convert existing call of mmu_notifier_in
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96 --
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 5
calling memcpy immediately after memset with the same region of memory
makes memset redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drive
Kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drive
On Tue, Aug 29, 2017 at 4:52 AM, Hoegeun Kwon wrote:
> Hi Krzysztof,
>
> The driver has been merged into exynos-drm-misc.
> Could you please check this patch(3/3).
Hi, OK, no problems for me but it is too late for current cycle so it
will go in for v4.15.
Best regards,
Krzysztof
>
> Best regard
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi_phy.c | 5 +
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 5 +
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 5 +
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 5 +
3 files changed, 3 insertions(+), 12 dele
On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote:
> I've worked with Vladimir Murzin inside ARM to try to sort out problems
> on the board like the one that you have. He's got to a point where the HDLCD
> starts correctly after adding a non-fixed pxlclk source, but then the rest of
> the
On Tue, Aug 29, 2017 at 05:11:24PM -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote:
> >
> > Note this is barely tested. I intend to do more testing of next few days
> > but i do not have access to all hardware that make use of the mmu_notifier
> > API.
>
> Than
Hi, all,
I recently bough a bunch of udl-compatible DisplayLink adapters and
have been trying to use them in Linux, but have been running into some
issues:
- Output is limited to 16-bit color, but the device is capable of 24-bit color.
- X providers (not sure if that's the right term--it's the ou
On Tue, Aug 29, 2017 at 6:39 PM, Dieter Nützel wrote:
> I've send a related kernel crash log to amd-devel some days ago without any
> answer, yet...
>
> Was:
> [amd-staging-drm-next] kernel crash with amdgpu on RX580 in
> 'drm_object_property_get_value'
>
> I get this in _all_ current 'amd-staging
https://bugs.freedesktop.org/show_bug.cgi?id=102013
--- Comment #16 from Michel Dänzer ---
Does the bug summary change mean you've confirmed that the problem doesn't
happen with an older version of Mesa? If so, which version?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102391
Matt Turner changed:
What|Removed |Added
QA Contact||dri-devel@lists.freedesktop
On 29 August 2017 at 21:57, Daniel Vetter wrote:
> On Tue, Aug 29, 2017 at 11:54 AM, Xinliang Liu
> wrote:
>> Hi Dave,
>>
>> On 29 August 2017 at 16:32, Daniel Vetter wrote:
>>> On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote:
Hi Dave,
One fix for next.
Sorry for lat
65 matches
Mail list logo
