|RESOLVED
--
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/20160829/039bef3e/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/22518200/attachment-0001.html>
Just tried it and the system didn't freeze. However it will freeze
after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
> On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
>> Hi B
Hi Emil,
On 08/29/2016 07:41 PM, Emil Velikov wrote:
> Hi all,
>
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
> wrote:
>
>> MODULE_AUTHOR("Sascha Hauer ");
>> MODULE_AUTHOR("Andy Yan ");
>> MODULE_AUTHOR("Yakir Yang ");
>> +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant to start a fla
We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous
prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but ca
We get 2 warnings when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:75:1: warning: no previous
prototype for 'nvkm_perfsig_find' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:703:1: warning: no previous
prototype for 'nvkm_perfsrc_new' [-Wmissing-pro
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
CC'ed Martin who filed the bz, he can reproduce too
https://bugzilla
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and
to obtain the GPU power state.
Obtaining the GPU state immediately after starting the graphical user
session freezes the system.
This code triggers something, which is responsible for the freeze.
---
// Returns 1 if the
known about it... ;-).
The base OS was Fedora 24/x86_64 with LLVM 3.8.0.
--
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/20160829/1e187f11/attachment.html>
We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c:312:1: warning: no previous
prototype for 'gm107_gr_init' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static
We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous
prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can
We get 2 warnings when build kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous
prototype for 'nv50_grctx_fill' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1: warning: no previous
prototype for 'nv50_grctx_init' [-Wmissing
If we being polled with a timeout of zero, a nonblocking busy query,
we don't need to install any fence callbacks as we will not be waiting.
As we only install the callback once, the overhead comes from the atomic
bit test that also causes serialisation between threads.
Signed-off-by: Chris Wilson
We get 1 warning when build kernel with W=1:
drivers/gpu/drm/nouveau/dispnv04/overlay.c:496:1: warning: no previous
prototype for 'nouveau_overlay_init' [-Wmissing-prototypes]
In fact, this function is declared in disp.h, so this patch
add missing header dependencies
Signed-off-by: Baoyou Xie
-
https://bugzilla.kernel.org/show_bug.cgi?id=117581
--- Comment #7 from Elmar Stellnberger ---
I guess it would already be resolved but Bug 155511 inhibits me from testing
that out correctly.
--
You are receiving this mail because:
You are watching the assignee of the bug.
We get 1 warning when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous
prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can
Am 29.08.2016 um 18:57 schrieb Chris Wilson:
> The ttm_mem_type_manager.move tracks the fence for the last migration on
> the memory manager. Currently it is accessed under its own spinlock to
> ensure that the fence doesn't disappear from underneath it. We can
> translate the reader to acquire a r
We get 1 warning when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous
prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but ca
On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
> Just tried it and the system didn't freeze. However it will freeze
> after some time (few minutes while working).
>
> Seams to be pci_read_config_dword. Where is this exactly defined?
pci_read_config_dword() is defined in include/li
On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> - remove kerneldoc for drm-internal functions
> - drm_property_replace_global_blob isn't actually atomic, and doesn't
>need to be. Update docs&comments to match
> - document all the types and try to link things a bit better
> - nits all over
>
R
We get 2 warnings when biuld kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:75:1: warning: no previous
prototype for 'nvkm_perfsig_find' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:703:1: warning: no previous
prototype for 'nvkm_perfsrc_new' [-Wmissing-pro
On Mon, 29 Aug 2016, Lyude wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actua
On Mon, 29 Aug 2016, Andrea Arcangeli wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> What I should
On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel
wrote:
> Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
>> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
>> wrote:
>> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> >> According to basic tests, it looks there is no issue
The ttm_mem_type_manager.move tracks the fence for the last migration on
the memory manager. Currently it is accessed under its own spinlock to
ensure that the fence doesn't disappear from underneath it. We can
translate the reader to acquire a reference to the fence using
fence_get_rcu_safe() whic
The atomic conversion lost the notification to let the DRM core
know about the current state of the CRTC vblank interrupts. This
regressed the ability of the core to reject page flip attempts
on currently disabled CRTCs. Add back the notifications.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/
On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel
wrote:
> Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
>> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> > This patch adds active plane reconfiguration support for imx-drm.
>> > This may fixes some mode setting failure i
dri-devel/attachments/20160829/11ad4aef/attachment-0001.html>
Hi all,
On 24 August 2016 at 06:46, Vladimir Zapolskiy
wrote:
> MODULE_AUTHOR("Sascha Hauer ");
> MODULE_AUTHOR("Andy Yan ");
> MODULE_AUTHOR("Yakir Yang ");
> +MODULE_AUTHOR("Vladimir Zapolskiy ");
Don't meant to start a flame-war or alike but to educate myself:
Where does one draw the line
On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
wrote:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> According to basic tests, it looks there is no issue if we don't wait for
>> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that,
>> either. This patch is nee
drm/i915/vlv: Make intel_crt_reset() per-encoder:
4570d833390b10043d082fe535375d4a0e071d9c
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init():
4c732e6ee9e71903934d75b12a021eb3520b6197
drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug():
21842ea84f161ae37ba25f0250c377fd19c5b307
d
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a
Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> > This patch adds active plane reconfiguration support for imx-drm.
> > This may fixes some mode setting failure issues which were introduced
> > by imx-drm atomic conversion
On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter wrote:
> On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
>> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
>> of the helper drm_atomic_helper_commit_planes() if the relevant display
>> controllers(e.g., IPUv3 for
From: Andy Green
Set the initial audio packet settings to allow the audio
driver to work.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy Green
Cc: Dave Long
Cc: Guodong Xu
Cc: Zhangfei
From: Srinivas Kandagatla
This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy
This patch adds support to Audio for both adv7511 and adv7533
bridge chips.
This patch was originally from [1] by Lars-Peter Clausen
and was adapted by Archit Taneja and
Srinivas Kandagatla .
Then I heavily reworked it to use the hdmi-codec driver. So credit
to them, but blame to me.
[1]
http
From: Archit Taneja
This patch moves the adv7511 data structure to header file so that the
audio driver file could use it.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy Green
Cc: Dave Lo
This is another swing at getting the adv7511 hdmi bridge
audio support reviewed.
I've taken the core audio work done by Lars-Peter Clausen, and
adapted by Srinivas Kandagatla and Archit Taneja, and tried to
rework it to use the hdmi-codec sound driver.
This patchset, along with the i2s driver and
On 08/29/16 15:58, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only sche
On Mon, Aug 29, 2016 at 06:44:46PM +0530, Archit Taneja wrote:
>
>
> On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> > - remove kerneldoc for drm-internal functions
> > - drm_property_replace_global_blob isn't actually atomic, and doesn't
> >need to be. Update docs&comments to match
> > - docu
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
What I should look for when trying those two settings? Will they
suc
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://github.com/anholt/linux tags/drm-vc4-next-2016-08-29
for you to fetch changes up to 67f13690f447841fb3d2f952a6e49b2b28ae379b:
drm/vc4: Don't force new binner overflow allocation per draw. (2016-08-19
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://github.com/anholt/linux drm-vc4-fixes-2016-08-29
for you to fetch changes up to 552416c146fadc67cd9b53ef7adf88d3381c43a6:
drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39
-07
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/78c15ac6/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/aab84dbb/attachment.html>
dri-devel/attachments/20160829/14bd2532/attachment.html>
dri-devel/attachments/20160829/5e8abd78/attachment.html>
dri-devel/attachments/20160829/8138f61a/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/4fec402d/attachment.html>
rg/archives/dri-devel/attachments/20160829/ff05218c/attachment.html>
On 2016-08-29 03:37, Michel Dänzer wrote:
> On 26/08/16 06:16 PM, Michal Marek wrote:
>> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
>> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.
>
> Thanks for the clarification.
>
> The radeon driver prob
On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
>
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CON
Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep
hint so that userspace knows that each of them needs amdkfd in the
initrd.
Reported-and-tested-by: Martin Jambor [amdgpu]
Reported-by: Michel Dänzer [radeon]
Signed-off-by: Michal Marek
---
v2: Also patch radeon
drivers/g
On Mon, Aug 29, 2016 at 05:12:03PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC
On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote:
> When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
> in which some DRM drivers are built-in, but the framebuffer core is a
> loadable module. This results in a link error, such as:
>
> drivers/gpu/drm/radeon/radeo
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
in which some DRM drivers are built-in, but the framebuffer core is a
loadable module. This results in a link error, such as:
drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
radeon_kfd.c:(.text.radeon_pci_probe
Hi Chris,
2016-08-29 Chris Wilson :
> If we being polled with a timeout of zero, a nonblocking busy query,
> we don't need to install any fence callbacks as we will not be waiting.
> As we only install the callback once, the overhead comes from the atomic
> bit test that also causes serialisation
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
> Hi Bjorn,
>
> I am using the bbswitch kernel module to switch off/on the GPU and
> to obtain the GPU power state.
> Obtaining the GPU state immediately after starting the graphical user
> session freezes the system.
>
> This code tr
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/2216ebd8/attachment.html>
> -Original Message-
> From: Michel Dänzer [mailto:michel at daenzer.net]
> Sent: Sunday, August 28, 2016 11:17 PM
> To: Mario Kleiner
> Cc: dri-devel at lists.freedesktop.org; jglisse at redhat.com;
> bskeggs at redhat.com; Deucher, Alexander; airlied at redhat.com
> Subject: Re: "Fixes"
Am Donnerstag, den 11.08.2016, 11:18 +0200 schrieb Lucas Stach:
> When the destroy path is called the plane should already be
> disabled. If not, this is a core bug and should not be worked
> around in the driver.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
>
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> This patch adds active plane reconfiguration support for imx-drm.
> This may fixes some mode setting failure issues which were introduced
> by imx-drm atomic conversion patch set. The main idea is to disable the
> plane in question in CRT
drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.
Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_
Am Freitag, den 26.08.2016, 17:10 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> > The devicetree documentation states that those are required properties,
> > so the driver should refuse to probe if those are absent to be
> > consistent. Thi
from Vedran MiletiÄ ---
Can you try a newer kernel? 4.7 at least.
--
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/20160
Tried 4.8-rc4 on my i5-2400 PC, got this warning:
[ 14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[ 15.847321] [ cut here ]
[ 15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866
sandybridge_pcode_write+0x109/0x1f0 [i915]
[
On Sunday, August 28, 2016 1:02:52 PM CEST Baoyou Xie wrote:
> We get 1 warning when build kernel with W=1:
> drivers/gpu/drm/nouveau/dispnv04/overlay.c:496:1: warning: no previous
> prototype for 'nouveau_overlay_init' [-Wmissing-prototypes]
>
> In fact, this function is declared in disp.h, so t
Hi Thorsten,
On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis
wrote:
> Lo! Dave, below report made it to the list of regression for 4.8, but
> afaics nothing happened after the initial report. Was it discussed (and
> maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
> be on
Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel
> wrote:
> > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
> >> wrote:
> >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb
Reset the write FIFO memories after disabling the DMFC
to make sure no stale data is kept around.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
in
Add defines for the memory reset bits and export the memory reset
function to IPU modules.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 17 +
drivers/gpu/ipu-v3/ipu-prv.h| 24
2 files changed, 37 insertions(+), 4 deletions(-)
di
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
On 27/08/16 04:57 AM, Mario Kleiner wrote:
> On 08/18/2016 04:23 AM, Michel Dänzer wrote:
>> On 18/08/16 01:12 AM, Mario Kleiner wrote:
>
> One thing that confuses me so far is that visual results and measurment
> suggest it works nicely, properly serializing the rendering/detiling
> blit and the
On 27/08/16 05:07 AM, Mario Kleiner wrote:
> On 08/18/2016 04:32 AM, Michel Dänzer wrote:
>> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>>>
>>> and the offload gpu imports those and renders into them. That saves
>>> one extra copy, so should be somewhat more efficient.
>>
>> Using two shared buffe
On Mon, Aug 29, 2016 at 9:02 AM, Baoyou Xie wrote:
> We get 1 warning when build kernel with W=1:
> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous
> prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file
On Mon, Aug 29, 2016 at 12:47:20PM +0200, Lucas Stach wrote:
> Core, bus and shader are all module input clocks. If the SoC integration
> provides the same clock for all inputs, the DT should reflect this by
> supplying the same clock for all 3 inputs.
You're making an assertion that we don't know
Don't leave any bridge or panel attached to a stale driver instance
when unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/driver
Don't leave the bridge attached to a stale driver instance when
unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 3
On 26/08/16 11:52 PM, Alex Deucher wrote:
> From: satsahu
>
> Signed-off-by: Alex Deucher
> ---
> tests/util/kms.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 650b23b..c20134e 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@
Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
> wrote:
> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> According to basic tests, it looks there is no issue if we don't wait for
> >> DMFC FIFO to clear when disabling DM
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something
that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> Hi,
>
> hope somebody can help me fix this kernel problem which affect
The pixel clock "polarity" is set for tilcdc panels with
the invert-pxl-clk property. But if we have several display-timings
with different pixel clock setups we need to set the values depending
on the selected display-timing. Check for the pixelclk-active property
and invert the value if invert-px
On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI m
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> According to basic tests, it looks there is no issue if we don't wait for
> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that,
> either. This patch is needed to avoid the annoying warning caused by a
> timeout on wa
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC
On 26/08/16 06:16 PM, Michal Marek wrote:
> On 2016-08-26 04:20, Michel Dänzer wrote:
>> On 26/08/16 02:10 AM, Michal Marek wrote:
>>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>>> userspace knows that amdgpu needs amdkfd in the initrd.
>>>
>>> Reported-and-tested-by: Ma
- remove kerneldoc for drm-internal functions
- drm_property_replace_global_blob isn't actually atomic, and doesn't
need to be. Update docs&comments to match
- document all the types and try to link things a bit better
- nits all over
v2: Appease checkpatch in the moved code (Archit)
Reviewed-b
They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_property.c | 23 +--
1
This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.
v2: resurrect misplaced hunk (Daniel Stone)
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Si
It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.
Cc: Laurent Pinchart
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 43 ---
drivers/gpu/drm/drm_fourcc.c | 43 +++
I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.
v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mo
It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 31 ---
include/drm/drm_mode_object.h | 2 +-
2 f
Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.
v2:
- Also move the generic get/set property ioctls. At first this seemed
like a bad idea since it requires making drm_mode_crtc_set_obj_prop
non-static. But even
- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.
v2: Review from Archit:
- Appease checkpatch in the moved code.
- Make it clea
Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.
On 29-08-2016 10:21, Russell King - ARM Linux wrote:
> On Mon, Aug 29, 2016 at 10:17:04AM +0100, Jose Abreu wrote:
>> Colorspace and scan information values were being written in wrong
>> offsets. This patch corrects this and writes the values at the
>> offsets specified in the databook.
>>
>> Si
On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC
On Sun, 28 Aug 2016, Andrea Arcangeli wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
That's a merge commit, the real one is
commit a05
1 - 100 of 128 matches
Mail list logo
