Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on ]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueab
Hi Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15-rc3 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15-rc3 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next
drm-intel/for-linux-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
https://bugzilla.kernel.org/show_bug.cgi?id=197925
--- Comment #9 from kwka...@gmx.com ---
#3 is fixed in both my monitor configurations.
#2 the behavior is still identical to Comment 5.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #8 from Deposite Pirate (dpir...@metalpunks.info) ---
Ok, I went through all the git bisect process. Here are the results:
git bisect start
# bad: [a638349bf6c29433b938141f99225b160551ff48] Merge branch 'for-4.15-fixes'
of git://git.k
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.16-wip
head: 8f003334f9f06d5a4c03c3d966ba258d770b97f4
commit: b8e7f06f8cc17c9f978987c9b98886f6e338a506 [105/117] drm/amdgpu: move
debugfs functions to their own file
reproduce:
# apt-get install sparse
git checkout
Hi Tomeu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to
Hi Tomeu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to
On Wed, Dec 13, 2017 at 03:00:56PM +0100, Christoph Fritz wrote:
> This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM
> simple panel driver.
>
> Signed-off-by: Christoph Fritz
> Signed-off-by: Stefan Riedmueller
> ---
> .../bindings/display/panel/auo,g104sn02.txt| 7
Hi Dave,
I forgot to include the DC fixes from Harry when I sent out
my fixes yesterday. This just adds them on top.
The following changes since commit 0507f438ea19d4280006467ba02956f6a693deca:
drm/amdgpu: fix MAP_QUEUES paramter (2017-12-12 15:40:11 -0500)
are available in the git repositor
https://bugzilla.kernel.org/show_bug.cgi?id=197925
--- Comment #8 from kwka...@gmx.com ---
As of 4.15.0-rc3-00086-g032b4cc8ff84:
#3 is fixed when in single internal monitor configuration. (Yes!)
I will, again, recheck #2 and #3 when I have an external monitor attached.
--
You are receiving thi
Hi,
On Fri, Dec 15, 2017 at 04:21:50PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
> picture. Some
> digging found that there is no check against the upper pixelclock limit of
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz,
On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
>
> * Lucas De Marchi wrote:
>
> > CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
> > allow the memory region to be stolen, otherwise we could have RAM being
> > arbitrarily overwritten if for example we keep u
To improve cpu read performance. This is implemented for APUs currently.
v2: Adapt to change
https://lists.freedesktop.org/archives/amd-gfx/2017-October/015174.html
v3: Adapt to change "forward begin_cpu_access callback to drivers"
Change-Id: I7a583e23a9ee706e0edd2a46f4e4186a609368e3
---
driver
On 15 December 2017 at 18:27, Andrey Grodzovsky
wrote:
> fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new
> suite/test disabling functionality.)
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280
Nit: remove the leading space.
>
> Signed-off-by: Andrey Grodzovsky
On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote:
> The acquire_ctx is special in that it needs to be released from the same
> thread as has been used to initialize it. This collides with the intention to
> extend the submit lifetime beyond the gem_submit function with potentially
> other threa
2017-12-15 11:30 GMT+01:00 Lucas Stach :
> Currently if the oldest BO in a bucket has different flags than what we
> look for we'll miss the cache.Fix this by iterating over the cached BOs
> until we find the oldest one with matching flags. This improves the hit
> ratio for some of the buckets.
>
>
Use the reservation wrapper for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
in
Use pr_debug instead of TTM_DEBUG, fix the lockdep assert and remove the
unused constant.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
ind
We only need to wait for the contended lock when the reservation object is
shared or when we want to remove everything. A trylock should be sufficient
in all other cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 +
1 file changed, 9 insertions(+), 4 deleti
Am 15.12.2017 um 19:27 schrieb Andrey Grodzovsky:
fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new
suite/test disabling functionality.)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
te
fixes: 806d080360faecb4025d8e9c7490cb097c25 (amdgpu: Use new suite/test
disabling functionality.)
bug: https://bugs.freedesktop.org/show_bug.cgi?id=104280
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/vcn_tests.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=104280
Andrey Grodzovsky changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |andrey.grodzov...@amd.com
On 10 November 2017 at 04:30, Andrey Grodzovsky
wrote:
> Switch from disabling tests during run to using the new disable
> API.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> tests/amdgpu/amdgpu_test.c| 14 ++--
> tests/amdgpu/amdgpu_test.h| 15
> tests/amdgpu/deadlock_tests.c
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo whic
Set dev->fb_helper even when fbdev emulation is compiled out,
so drivers can use it to free the structure.
Clear it for consistency.
Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
include/drm/drm_fb_helper.h | 7 ++
Promote new helpers for dealing with fbdev emulation.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm
Use the new setup/teardown helpers as well as drm_fb_helper_defio_init().
Wrap fb_deferred_io_mmap() in ifdef so we can make fbdev optional.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
I had to touch drm_fbdev_cma_fini() here, but that will be rebased away
Hi,
This is a new attempt at simplifying fbdev setup/teardown in drivers.
Only doc changes in this version based on feedback from Daniel.
Noralf.
Changes since version 1:
- Document a case where drm_fb_helper_fbdev_setup() can't be used:
connector hotplugging (e.g. dp mst).
- Document where d
Make it possible to opt out of fbdev emulation.
DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so
this doesn't change the default behaviour.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig | 5 +
1 file changed, 1
Add helpers to setup and teardown fbdev emulation.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 106
include/drm/drm_fb_helper.h | 25 ++
2 files changed, 131 insertions(+)
diff --git a/driv
Add entry for conversion of drivers to new helpers.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index f421a54527d2..1e59337
https://bugs.freedesktop.org/show_bug.cgi?id=104001
--- Comment #6 from mikhail.v.gavri...@gmail.com ---
Created attachment 136200
--> https://bugs.freedesktop.org/attachment.cgi?id=136200&action=edit
dmesg with 4.15.0-rc2 amd-staging-drm-next
--
You are receiving this mail because:
You are th
On Fri, Dec 15, 2017 at 05:46:19PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
> picture. Some
> digging found that there is no check against the upper pixelclock limit of
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz, which
From: Christian König
On CZ and newer APUs we can pin the fb into GART as well as VRAM.
v2: Don't enable gpu_vm_support for Raven yet since it leads to
a black screen. Need to debug this further before enabling.
Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
Signed-off-by: Christian K
When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
picture. Some
digging found that there is no check against the upper pixelclock limit of the
HDMI
output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.
The patch below adds a check for the upper bound
From: Christian König
Allow drivers to implement their own begin_cpu_access callback.
Change-Id: I97709b42b9351a04ee7e01106107a87bc56ea258
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 13 +
include/drm/drm_drv.h | 2 ++
2 files changed, 15 insertions(+)
On 2017-12-15 05:53 AM, Colin King wrote:
> From: Colin Ian King
>
> The null check on aconnector->base.edid_blob_ptr->data is redundant
> since data is an array and can never be null. Remove it.
>
> Detected by CoverityScan, CID#1460369 ("Array compared against 0")
>
> Signed-off-by: Colin Ia
Am 15.12.2017 um 17:33 schrieb Samuel Li:
To improve cpu read performance. This is implemented for APUs currently.
v2: Adapt to change
https://lists.freedesktop.org/archives/amd-gfx/2017-October/015174.html
v3: Adapt to change "forward begin_cpu_access callback to drivers"
Change-Id: I7a583e23
https://bugs.freedesktop.org/show_bug.cgi?id=104281
--- Comment #1 from Carlo Caione ---
The issue is not limited to this laptop model. We have at least 3 other ACER
models affected by this.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=104281
Bug ID: 104281
Summary: black / corrupted screen when resuming from S3
[AMDGPU]
Product: DRI
Version: XOrg git
Hardware: Other
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=104280
Bug ID: 104280
Summary: libdrm fails to build in open build service due to
no-return function
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
On Fri, Dec 15, 2017 at 04:21:50PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
> picture. Some
> digging found that there is no check against the upper pixelclock limit of
> the HDMI
> output, so X selects a 4kp60 format at 594 MHz, which
https://bugs.freedesktop.org/show_bug.cgi?id=104274
--- Comment #3 from Sverd Johnsen ---
Thanks for pointing me to that. Seems like it should have gone to stable
Alright. Here is what I do now:
boot with intel gpu, amdgpu is blacklisted in modules so it doesn't get
autoloaded
then i load amdgp
Den 15.12.2017 16.43, skrev Daniel Vetter:
On Fri, Dec 15, 2017 at 02:18:55PM +0100, Noralf Trønnes wrote:
Den 14.12.2017 21.25, skrev Daniel Vetter:
On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
Add helper for initializing fbdev deferred I/O.
The cleanup could have happene
On Fri, Dec 15, 2017 at 01:30:24PM +0100, Linus Walleij wrote:
> On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij
> wrote:
>
> > - The connector is apparently not the right abstraction to carry
> > the detailed timings specification between DRI drivers and bridge
> > drivers.
> >
> > - Instead
On Fri, Dec 15, 2017 at 02:18:55PM +0100, Noralf Trønnes wrote:
>
> Den 14.12.2017 21.25, skrev Daniel Vetter:
> > On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
> > > Add helper for initializing fbdev deferred I/O.
> > >
> > > The cleanup could have happened in drm_fb_helper_fin
On Fri, Dec 15, 2017 at 02:17:49PM +0100, Noralf Trønnes wrote:
>
> Den 14.12.2017 20.10, skrev Noralf Trønnes:
> > Promote new helpers for dealing with fbdev emulation.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 22 ++
> > 1 file c
On Fri, Dec 15, 2017 at 2:18 PM, Noralf Trønnes wrote:
>
> Den 14.12.2017 21.25, skrev Daniel Vetter:
>>
>> On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
>>>
>>> Add helper for initializing fbdev deferred I/O.
>>>
>>> The cleanup could have happened in drm_fb_helper_fini(), but t
On Thu, Dec 14, 2017 at 11:11:50AM +0530, Archit Taneja wrote:
> The msm/kms driver should work even if there is no GPU device specified
> in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
> since the driver assumes that priv->gpu_pdev is non-NULL.
>
> Perform an additional chec
When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
picture. Some
digging found that there is no check against the upper pixelclock limit of the
HDMI
output, so X selects a 4kp60 format at 594 MHz, which obviously won't work.
The patch below adds a check for the upper bound
Hi Jose,
On Wed, Dec 13, 2017 at 12:07:05PM +, Jose Abreu wrote:
> On 13-12-2017 11:05, Hans Verkuil wrote:
> > On 13/12/17 11:30, Maxime Ripard wrote:
> >> Hi Hans,
> >>
> >> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
> >>> When I connected my cubieboard running 4.15-rc1 to
On 15.12.2017 15:51, Arnd Bergmann wrote:
> The newly introduced driver has optional suspend/resume functions,
> causing a warning when CONFIG_PM is disabled:
>
> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined
> but not used [-Werror=unused-function]
> drivers/gpu/d
On 12/15/2017 01:05 PM, Christian König wrote:
I'm in favour of that. But I don't think what I proposed is a step
away from that direction. On the contrary. I've attached a POC patch
with the correctness checks stripped, not compile-tested. Much easier
to follow if you ask me, but if you fee
On Fri, Dec 15, 2017 at 2:33 PM, Thierry Reding
wrote:
> On Fri, Dec 15, 2017 at 01:51:52PM +0100, Arnd Bergmann wrote:
>> The newly introduced driver has optional suspend/resume functions,
>> causing a warning when CONFIG_PM is disabled:
>>
>> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_dis
On Fri, Dec 15, 2017 at 01:51:52PM +0100, Arnd Bergmann wrote:
> The newly introduced driver has optional suspend/resume functions,
> causing a warning when CONFIG_PM is disabled:
>
> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined
> but not used [-Werror=unused-func
On Fri, 2017-12-15 at 11:30 +0100, Lucas Stach wrote:
> Currently if the oldest BO in a bucket has different flags than what we
> look for we'll miss the cache.Fix this by iterating over the cached BOs
> until we find the oldest one with matching flags. This improves the hit
> ratio for some of the
Den 14.12.2017 21.19, skrev Daniel Vetter:
On Thu, Dec 14, 2017 at 08:10:03PM +0100, Noralf Trønnes wrote:
Add helpers to setup and teardown fbdev emulation.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 106
include/drm/drm_fb
https://bugs.freedesktop.org/show_bug.cgi?id=104043
frodz...@gmail.com changed:
What|Removed |Added
Attachment #136193|0 |1
is obsolete|
Den 14.12.2017 21.25, skrev Daniel Vetter:
On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of dri
On Fri, Dec 15, 2017 at 2:10 PM, Dmitry Osipenko wrote:
> On 15.12.2017 15:51, Arnd Bergmann wrote:
>> --- a/drivers/gpu/drm/tegra/hub.c
>> +++ b/drivers/gpu/drm/tegra/hub.c
>> @@ -730,7 +730,7 @@ static int tegra_display_hub_remove(struct
>> platform_device *pdev)
>> return err;
>> }
>>
>
Den 14.12.2017 20.10, skrev Noralf Trønnes:
Promote new helpers for dealing with fbdev emulation.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/
https://bugs.freedesktop.org/show_bug.cgi?id=104043
--- Comment #5 from frodz...@gmail.com ---
Created attachment 136193
--> https://bugs.freedesktop.org/attachment.cgi?id=136193&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
The newly introduced driver has optional suspend/resume functions,
causing a warning when CONFIG_PM is disabled:
drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined
but not used [-Werror=unused-function]
drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspe
https://bugs.freedesktop.org/show_bug.cgi?id=104043
--- Comment #4 from frodz...@gmail.com ---
Created attachment 136192
--> https://bugs.freedesktop.org/attachment.cgi?id=136192&action=edit
dmesg log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104043
--- Comment #3 from frodz...@gmail.com ---
Hi, thanks for the response and sorry for taking so long but the notification
went to spam folder. I will attach the Xorg log later today.
I actually tried to bisect already. The problem is that it does
On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij wrote:
> - The connector is apparently not the right abstraction to carry
> the detailed timings specification between DRI drivers and bridge
> drivers.
>
> - Instead put detailed timing data into the bridge itself as an
> optional information
Am 15.12.2017 um 11:53 schrieb Colin King:
From: Colin Ian King
The null check on aconnector->base.edid_blob_ptr->data is redundant
since data is an array and can never be null. Remove it.
Detected by CoverityScan, CID#1460369 ("Array compared against 0")
Signed-off-by: Colin Ian King
Ack
After some discussion and failed patch sets trying to convey
the right timing information between the display engine and
a bridge using the connector, I try instead to use an optional
timing information container in the bridge itself, so that
display engines can retrieve it from any bridge and use
This patch set is in response to Laurent's mail:
https://www.spinics.net/lists/dri-devel/msg155618.html
So in summary:
- The connector is apparently not the right abstraction to carry
the detailed timings specification between DRI drivers and bridge
drivers.
- Instead put detailed timing data
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
We assign the proper timing data to the pointer inside the
bridge struct so display controllers that need to align their
timings to the bridge can pick it up and work from there.
If the bridge has a too strict setup time for the incoming
signals, we may not be fast enough and then we need to
compensate by outputting the signal on the inverse clock
edge so it is for sure stable when the bridge samples it.
Since bridges in difference to panels does not expose their
connector
This adds device tree bindings for the Texas Instruments
THS8134, THS8134A and THS8134B VGA DACs by extending and
renaming the existing bindings for THS8135.
These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.
Cc: devicet...@vger.kernel
Am 15.12.2017 um 12:35 schrieb Thomas Hellstrom:
On 12/15/2017 10:53 AM, Christian König wrote:
Well this is more or less replicating what you are doing currently
but instead of spreading the checks and locking state all over the
code, both as local variables and parameters this is keeping it
On 12/15/2017 10:53 AM, Christian König wrote:
Well this is more or less replicating what you are doing currently
but instead of spreading the checks and locking state all over the
code, both as local variables and parameters this is keeping it in a
single place with correctness checks.
I d
From: Colin Ian King
The null check on aconnector->base.edid_blob_ptr->data is redundant
since data is an array and can never be null. Remove it.
Detected by CoverityScan, CID#1460369 ("Array compared against 0")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_
Currently if the oldest BO in a bucket has different flags than what we
look for we'll miss the cache.Fix this by iterating over the cached BOs
until we find the oldest one with matching flags. This improves the hit
ratio for some of the buckets.
Signed-off-by: Lucas Stach
---
etnaviv/etnaviv_bo
https://bugs.freedesktop.org/show_bug.cgi?id=104275
Michel Dänzer changed:
What|Removed |Added
CC||ckoenig.leichtzumerken@gmai
On Thu, Dec 14, 2017 at 09:11:01PM -0500, Alex Deucher wrote:
> On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 420025bd6a9b..cbba93483aec 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documen
Am Freitag, den 15.12.2017, 10:33 +0100 schrieb Lucas Stach:
> Am Freitag, den 15.12.2017, 08:43 +0100 schrieb Christian Gmeiner:
> > Add etna_cmd_stream_perf(..) to submit perform requests.
> > Userspace can submit pmrs via submit ioctl to sample perfmon
> > signals.
> >
> > v3:
> > - mark perfm
Hi Laurent,
On 03/12/17 10:57, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.
This could likely tag along with the preceding [PATCH 1/9] on it's short cut to
mainline before t
Hi Laurent,
As this is a prevents hardware hangs, and is a distinct patch on it's own - I
feel it should be on an accelerated path to integration, and should be merged
separately from the rest of the CRC feature series.
On 03/12/17 10:57, Laurent Pinchart wrote:
> Make sure we don't accept more i
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #5 from Kai-Heng Feng ---
Created attachment 136191
--> https://bugs.freedesktop.org/attachment.cgi?id=136191&action=edit
Garbled display.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #4 from Kai-Heng Feng ---
(In reply to Michel Dänzer from comment #3)
> The fundamental issue here is that only 32 MB of memory are reserved as VRAM
> for the GPU.
>
> https://patchwork.freedesktop.org/patch/192451/ should fix it (w
Am 15.12.2017 um 10:38 schrieb Thomas Hellstrom:
On 12/15/2017 10:13 AM, Christian König wrote:
Hi Thomas,
actually I was very happy to get rid of that stuff.
Yes, wrappers that don't do anything don't make much sense, but this
is a different story.
I was not talking about the wrappers, bu
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Gordon
commit 30b0da8d556e65ff935a56cd82c05ba0516d3e4a upstream.
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels s
On 12/15/2017 10:13 AM, Christian König wrote:
Hi Thomas,
actually I was very happy to get rid of that stuff.
Yes, wrappers that don't do anything don't make much sense, but this is
a different story.
In the long run I indeed wanted to replace ctx->resv with the
ww_acquire_ctx to enable
Am Freitag, den 15.12.2017, 08:43 +0100 schrieb Christian Gmeiner:
> Add etna_cmd_stream_perf(..) to submit perform requests.
> Userspace can submit pmrs via submit ioctl to sample perfmon
> signals.
>
> v3:
> - mark perfmon bos as RW
>
> Signed-off-by: Christian Gmeiner
> ---
[...]
> #endif
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #3 from Michel Dänzer ---
The fundamental issue here is that only 32 MB of memory are reserved as VRAM
for the GPU.
https://patchwork.freedesktop.org/patch/192451/ should fix it (with DC
enabled).
--
You are receiving this mail be
Am 15.12.2017 um 07:24 schrieb Thomas Hellstrom:
Hi.
On 12/14/2017 09:10 AM, Roger He wrote:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=104274
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Friday, December 15, 2017 2:25 PM
To: He, Roger ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian
Subject: Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO
Hi.
On 12/14/2
Hi Thomas,
actually I was very happy to get rid of that stuff.
In the long run I indeed wanted to replace ctx->resv with the
ww_acquire_ctx to enable eviction of even more things, but that is a
different story.
Recursive locking is usually something we should try to avoid.
Regards,
Christia
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #15 from Charly ---
Hi Andrew. X works all the time.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
Hi Morimoto-san,
On Fri, Dec 15, 2017 at 9:12 AM, Kuninori Morimoto
wrote:
>> > From: Kuninori Morimoto
>> > In general, PLL has VCO (= Voltage controlled oscillator),
>> > one of the very important electronic feature called as "jitter"
>> > is related to this VCO.
>> > In academic generalism, V
Hi Laurent, David
These are v3 of DPLLCR patch for rcar-du.
[1/2] is added
Kuninori Morimoto (2):
drm: rcar-du: use 1000 to avoid misunderstanding in rcar_du_dpll_divider()
drm: rcar-du: calculate DPLLCR to be more small jitter
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 60 ++
From: Kuninori Morimoto
It is difficult to understand its scale if number has many 0s.
This patch uses "* 1000" to avoid it in rcar_du_dpll_divider().
Signed-off-by: Kuninori Morimoto
---
v2 -> v3
- new patch
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Hi Geert, Laurent
> >> Yes, but compiled by 32bit too, right ?
> >> Without this "ll", 32bit compiler say
> >>
> >> warning: this decimal constant is unsigned only in ISO C90
> >
> > That's right. How about 409600UL then, to force unsigned integer types ?
> > Or possibly even better, 40
Hi Geert
> > From: Kuninori Morimoto
> > In general, PLL has VCO (= Voltage controlled oscillator),
> > one of the very important electronic feature called as "jitter"
> > is related to this VCO.
> > In academic generalism, VCO should be maximum to be more small jitter.
> > In high frequency clo
1 - 100 of 105 matches
Mail list logo
