Hi, Wangyan:
On Tue, 2019-04-09 at 11:07 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> This is the third step to make MT2701 HDMI stable.
> We should not change the rate of parent for hdmi phy when
> doing round_rate for this clock. The parent clock of hdmi
> phy must be the same as it.
Hi, Wangyan:
On Tue, 2019-04-09 at 11:07 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> Recalculate the rate of this clock, by querying hardware to
> make implementation of recalc_rate() to match the definition.
>
> Signed-off-by: Wangyan Wang
> ---
>
Hi, Wangyan:
On Tue, 2019-04-09 at 11:07 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> This is the first step to make MT2701 hdmi stable.
> The parent rate of hdmi phy had set by DPI driver.
> We should not set or change the parent rate of MT2701 hdmi phy,
> as a result we should remove
https://bugs.freedesktop.org/show_bug.cgi?id=110360
jian-h...@endlessm.com changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110360
Bug ID: 110360
Summary: AMD system hits AMD-Vi: Completion-Wait loop timed out
on Acer Squirtle_SR laptop
Product: DRI
Version: XOrg git
Hardware: Other
Hi, Wen:
On Thu, 2019-04-04 at 00:04 +0800, Wen Yang wrote:
> The call to of_parse_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
>
https://bugs.freedesktop.org/show_bug.cgi?id=110337
Berg changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
>
> On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> >
> > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > userspace.
It's been pointed out to me that disables
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #28 from mikhail.v.gavri...@gmail.com ---
And again deadlock occurred.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #27 from mikhail.v.gavri...@gmail.com ---
Created attachment 143904
--> https://bugs.freedesktop.org/attachment.cgi?id=143904=edit
dmesg from patched kernel [0001 + 0002 + 3]
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #26 from Andrey Grodzovsky ---
(In reply to Dieter Nützel from comment #25)
> (In reply to Andrey Grodzovsky from comment #24)
> > Created attachment 143898 [details] [review] [review]
> > [PATCH] drm_amd_display: wait for fence
https://bugzilla.kernel.org/show_bug.cgi?id=203111
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Thomas from comment #5)
> Thanks a lot for the detailed answer. I'm still not sure if I understand
> everything correctly (shouldn't the kernel driver validate the command
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/cirrus/cirrus_drv.h
drivers/gpu/drm/cirrus/cirrus_ttm.c
between commits:
aa8e2435b3d4 ("drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant")
7d1500f9fbfc ("drm/ttm: Remove file_page_offset
https://bugs.freedesktop.org/show_bug.cgi?id=110345
Timothy Arceri changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
Current implementation does not support MMU-less
plarforms.
Cc: Randy Dunlap
Cc: Neil Armstrong
Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git
To prevent build fail on some platform which does
not have it in the include file chain.
Cc: Neil Armstrong
Suggested-by: Randy Dunlap
Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_gem.c | 1 +
1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #25 from Dieter Nützel ---
(In reply to Andrey Grodzovsky from comment #24)
> Created attachment 143898 [details] [review]
> [PATCH] drm_amd_display: wait for fence without holding reservation
> lock.patch
>
> Reattaching.
Hello
On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>
> On 01/04/2019 08:47, Rob Herring wrote:
> > This adds the initial driver for panfrost which supports Arm Mali
> > Midgard and Bifrost family of GPUs. Currently, only the T860 and
> > T760 Midgard GPUs have been tested.
[...]
> > + case
On Monday, 2019-04-08 13:44:17 +, Ayan Halder wrote:
> Generated using make headers_install from the drm-next
> tree - git://anongit.freedesktop.org/drm/drm
> branch - drm-next
> commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
>
> The changes were as follows :-
>
> core: (drm.h,
https://bugs.freedesktop.org/show_bug.cgi?id=107559
Heiko Lechner changed:
What|Removed |Added
CC||Heiko.Lechner@ruhr-uni-boch
On Mon, Apr 1, 2019 at 10:43 AM Eric Anholt wrote:
>
> Chris Wilson writes:
>
> > Quoting Daniel Vetter (2019-04-01 14:06:48)
> >> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring wrote:
> >> > +{
> >> > + int i, ret = 0;
> >> > + struct drm_gem_object *obj;
> >> > +
> >> > +
On Sun, Apr 7, 2019 at 5:17 AM Neil Armstrong wrote:
>
> Hi Rob,
>
> Le 01/04/2019 13:24, Neil Armstrong a écrit :
> > On 01/04/2019 12:00, Steven Price wrote:
> >> On 01/04/2019 09:09, Neil Armstrong wrote:
> >>> Add the bindings for the Bifrost family of ARM Mali GPUs.
> >>>
> >>> The Bifrost
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #33 from Alex Deucher ---
(In reply to Talha Khan from comment #31)
> I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> still unable to boot any kernel newer 4.20. For me at least, I get a black
> screen
https://bugs.freedesktop.org/show_bug.cgi?id=110358
Bug ID: 110358
Summary: R
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=110339
--- Comment #3 from Pinky ---
* bugzilla-dae...@freedesktop.org [2019-04-08
13:10:29 +]:
>https://bugs.freedesktop.org/show_bug.cgi?id=110339
>
>--- Comment #2 from Nicholas Kazlauskas ---
>Thanks for the report, this is a kernel bug.
>
Also reject TDRs if another one already running.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94 +-
1 file changed, 67 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
For later driver's reference to see if the fence is signaled.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never destroy a job currently in timeout processing.
By this we avoid holding lock around ring mirror list in drm_sched_stop
which should solve a deadlock reported by a user.
Bugzilla:
On Mon, Apr 08, 2019 at 03:59:51PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Monday, April 8, 2019 9:15 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org;
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Monday, April 8, 2019 9:15 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org;
On Mon, Apr 08, 2019 at 03:40:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, April 8, 2019 8:27 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 8:27 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville
>; Lankhorst,
Hi,
On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko wrote:
>
> Hi,
>
> On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson wrote:
> >
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field. This
> > uses the standard
On Mon, Apr 08, 2019 at 02:40:51PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, April 8, 2019 6:01 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>
https://bugs.freedesktop.org/show_bug.cgi?id=110354
--- Comment #1 from Arek Hiler ---
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 266aa832..b235b18c 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -984,8 +984,11 @@ void igt_debug_wait_for_keypress(const char *var)
{
struct
>-Original Message-
>From: Sam Ravnborg [mailto:s...@ravnborg.org]
>Sent: Tuesday, April 2, 2019 12:07 AM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ;
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #8 from Diego Viola ---
Created attachment 143899
--> https://bugs.freedesktop.org/attachment.cgi?id=143899=edit
Xephyr.trace
To reproduce it:
$ apitrace replay Xephyr.trace -w
I used apitrace 7.1-3.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #24 from Andrey Grodzovsky ---
Created attachment 143898
--> https://bugs.freedesktop.org/attachment.cgi?id=143898=edit
[PATCH] drm_amd_display: wait for fence without holding reservation lock.patch
Reattaching.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #23 from Andrey Grodzovsky ---
Created attachment 143897
--> https://bugs.freedesktop.org/attachment.cgi?id=143897=edit
[PATCH] drm_amd_display: wait for fence without holding reservation lock.eml
This looks again like deadlock
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sam
>Ravnborg
>Sent: Tuesday, April 2, 2019 12:03 AM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com;
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 6:01 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville
>; Lankhorst,
Thierry,
On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding wrote:
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
>
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #7 from Michel Dänzer ---
(In reply to Diego Viola from comment #0)
> The issue goes away if I start the application with this variable:
> LIBGL_ALWAYS_SOFTWARE=1.
As discussed on IRC, presumably this would have to be set for the X
On Mon, Apr 8, 2019 at 9:45 PM Neil Armstrong wrote:
>
> Hi,
>
> On 08/04/2019 15:19, Qiang Yu wrote:
> > Oh, I'm really sorry if I did something wrong to use:
> > dim push-branch drm-misc-next
> > (Should the committer just use "git push" not the "dim push-branch
> > drm-misc-next"?)
>
> I can
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #6 from Diego Viola ---
System details:
Arch Linux (x86_64)
mesa 19.0.1-2
xorg-server 1.20.4-1
llvm7 7.0.1-1
i3-wm 4.16.1-1
xorg-server-xephyr 1.20.4-1
- I've downgraded llvm8 to llvm7 before I bisected because mesa-18.3.5
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #5 from Diego Viola ---
Created attachment 143896
--> https://bugs.freedesktop.org/attachment.cgi?id=143896=edit
Screnshot without the issue
GIMP started with LIBGL_ALWAYS_SOFTWARE=1 so it doesn't present the issue.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #4 from Diego Viola ---
Created attachment 143895
--> https://bugs.freedesktop.org/attachment.cgi?id=143895=edit
Screenshot showing the problem
Notice the lack of the "Help" menu item.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #3 from Diego Viola ---
Mesa was installed to /usr/local.
/usr/local/lib was added to /etc/ld.so.conf.d/mesa.conf.
libgbm, libEGL is being loaded from /usr/local/lib and radeonsi_dri.so is being
loaded from /usr/local/lib/dri.
On 2019-04-08 3:13 p.m., Christian König wrote:
> When ttm_put_pages() tries to figure out whether it's dealing with
> transparent hugepages, it just reads past the bounds of the pages array
> without a check.
>
> v2: simplify the test if enough pages are left in the array (Christian).
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #2 from Diego Viola ---
Created attachment 143894
--> https://bugs.freedesktop.org/attachment.cgi?id=143894=edit
bisect log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110355
--- Comment #1 from Diego Viola ---
I've bisected the issue, here is the bad commit:
[diego@archtest mesa]$ git bisect good
1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit
commit 1b25d340b791ad8350bdfb27f1a91ac79fa17748
https://bugs.freedesktop.org/show_bug.cgi?id=110355
Bug ID: 110355
Summary: radeonsi: GTK elements become invisible in some
applications (GIMP, LibreOffice)
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
Hi,
On 08/04/2019 15:19, Qiang Yu wrote:
> Oh, I'm really sorry if I did something wrong to use:
> dim push-branch drm-misc-next
> (Should the committer just use "git push" not the "dim push-branch
> drm-misc-next"?)
I can see your commit just fine on drm-misc-next :
commit
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct
https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #25 from Laurent ---
Lol and you use C11 (cpu) thread to load gpu thread even if gcc can't generate
byte code for a GPU ? I really doesn't understand what you're doing.
And for VBO you need to execute code with the GPU, not with
Oh, I'm really sorry if I did something wrong to use:
dim push-branch drm-misc-next
(Should the committer just use "git push" not the "dim push-branch
drm-misc-next"?)
Because I found the drm-tip repo has been updated also with
a few commits that I can't find similar ones in the history.
Could
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #32 from Talha Khan ---
Created attachment 143893
--> https://bugs.freedesktop.org/attachment.cgi?id=143893=edit
Journalctl output for kernel 5.0.5-200.fc29.x86_64
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #31 from Talha Khan ---
I moved the raven_dcmu.bin file to another directory, but unfortunately I am
still unable to boot any kernel newer 4.20. For me at least, I get a black
screen with a horizontal line near the bottom of orange
The first page entry is always the same with itself.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index
When ttm_put_pages() tries to figure out whether it's dealing with
transparent hugepages, it just reads past the bounds of the pages array
without a check.
v2: simplify the test if enough pages are left in the array (Christian).
Signed-off-by: Jann Horn
Signed-off-by: Christian König
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=110339
--- Comment #2 from Nicholas Kazlauskas ---
Thanks for the report, this is a kernel bug.
This was actually a regression caused from:
"drm/amd/display: PIP overlay corruption"
which was fixed by:
"drm/amd/display: Fix negative cursor pos
On Sat, Apr 6, 2019 at 1:45 AM wrote:
> From: Ondrej Jirman
>
> H6 has a different I/O voltage bias setting method than A80. Prepare
> existing code for using alternative bias voltage setting methods.
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
>
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 3:50 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>dcasta...@chromium.org; seanp...@chromium.org; Syrjala, Ville
>;
Here's a question first time I use command:
dim push-branch drm-misc-next
I see it updates both drm-misc-next and for-linux-next branch, is this
expected? What's the difference between drm-misc-next/drm-misc-next-fixes
and for-linux-next/for-linux-next-fixes?
Thanks,
Qiang
On Mon, Apr 8, 2019
On 08/04/2019 14:20, Qiang Yu wrote:
> On Mon, Apr 8, 2019 at 7:56 PM Neil Armstrong wrote:
>>
>> Hi,
>>
>> On 08/04/2019 13:26, Qiang Yu wrote:
>>> Feedback from kbuild robot:
>>> config: sh-allyesconfig (attached as .config)
>>> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>>
Patch has been applied to drm-misc-next branch.
Thanks,
Qiang
On Mon, Apr 8, 2019 at 3:12 AM Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Note that the lima mailing list is moderated.
>
> Signed-off-by: Randy Dunlap
> Cc: Qiang Yu
> Cc: dri-devel@lists.freedesktop.org
> Cc:
On Mon, Apr 08, 2019 at 12:26:23PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Friday, April 5, 2019 9:42 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org;
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, April 8, 2019 3:39 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ;
On Mon, Apr 8, 2019 at 8:00 PM Neil Armstrong wrote:
>
> On 08/04/2019 03:37, Qiang Yu wrote:
> > Looks good for me, patch is:
> > Reviewed-by: Qiang Yu
>
> Also:
> Reviewed-by: Neil Armstrong
>
> >
> > Should I apply this patch to drm-misc in this case? Or this patch will be
> > submitted in
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Friday, April 5, 2019 9:42 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org;
On Mon, Apr 8, 2019 at 7:56 PM Neil Armstrong wrote:
>
> Hi,
>
> On 08/04/2019 13:26, Qiang Yu wrote:
> > Feedback from kbuild robot:
> > config: sh-allyesconfig (attached as .config)
> > compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > lima_gem.c:(.text+0x6c): undefined reference to
On 08/04/2019 03:37, Qiang Yu wrote:
> Looks good for me, patch is:
> Reviewed-by: Qiang Yu
Also:
Reviewed-by: Neil Armstrong
>
> Should I apply this patch to drm-misc in this case? Or this patch will be
> submitted in other kernel tree and back merged to drm-misc?
You can push it yourself
Hi
Am 08.04.19 um 13:10 schrieb Koenig, Christian:
> Well first problem is I'm not sure if that is a good idea. Essentially
> we want to get rid of TTM in the long run.
>
> On the other hand this work might aid with that goal, so it might be
> worth a try.
I see. I'm actually interested in
Hi,
On 08/04/2019 13:26, Qiang Yu wrote:
> Feedback from kbuild robot:
> config: sh-allyesconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> lima_gem.c:(.text+0x6c): undefined reference to `vmf_insert_mixed'
>
> Cc: Randy Dunlap
> Signed-off-by: Qiang Yu
https://bugs.freedesktop.org/show_bug.cgi?id=110354
Bug ID: 110354
Summary: Confusing Junk in the results: Last errno: 25,
Inappropriate ioctl for device
Product: DRI
Version: unspecified
Hardware: Other
Feedback from kbuild robot:
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
lima_gem.c:(.text+0x6c): undefined reference to `vmf_insert_mixed'
Cc: Randy Dunlap
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Kconfig| 2 ++
https://bugs.freedesktop.org/show_bug.cgi?id=110290
Andre Klapper changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Well first problem is I'm not sure if that is a good idea. Essentially
we want to get rid of TTM in the long run.
On the other hand this work might aid with that goal, so it might be
worth a try.
Second is that this might actually not work of hand. The problem is here:
> + /* TODO: This
On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul
>
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
>
> Changes in v2:
> - Split out the binding into a new patch (Rob)
> -
On 2019-04-02 22:20, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data is received from
On Mon, Apr 01, 2019 at 11:00:09PM +0530, Uma Shankar wrote:
> Gen11 introduced a new gamma mode i.e, multi segmented
> gamma mode. Added support for the same.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 161
> -
>
On Mon, Apr 01, 2019 at 11:00:06PM +0530, Uma Shankar wrote:
> From: Ville Syrjälä
>
> This defines the color lut ranges for 10bit and multi
> segmented gamma range for ICL.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_color.c | 301
>
https://bugs.freedesktop.org/show_bug.cgi?id=110214
Diego Viola changed:
What|Removed |Added
Summary|radeonsi: xterm scrollback |radeonsi: xterm scrollback
Hello Uma,
V7 looks good to me, please feel free to use for the whole series:
Reviewed-by: Shashank Sharma
Regards
Shashank
On 4/3/2019 1:50 AM, Uma Shankar wrote:
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after
On Sat, Apr 06, 2019 at 01:45:07AM +0200, meg...@megous.com wrote:
> From: Icenowy Zheng
>
> The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY"
> on H6 is on a co-packaged AC200 chip, and it's not really internal (it's
> connected via RMII at PA GPIO bank).
>
> Add support
On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> transistors, before it can be used. Model this as a power supply for DDC
> (via regulator framework).
>
> Signed-off-by: Ondrej
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/Kconfig| 1 +
drivers/gpu/drm/bochs/bochs.h| 8 +-
drivers/gpu/drm/bochs/bochs_mm.c | 125 +++
3 files changed, 14 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/bochs/Kconfig
This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_ttm_object|. The only change in
semantics is that _bo_driver.verify_access() now does the actual
verification.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/Kconfig | 1
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Kconfig| 2 +-
drivers/gpu/drm/ast/ast_drv.c | 4 +-
drivers/gpu/drm/ast/ast_drv.h | 52 +-
drivers/gpu/drm/ast/ast_fb.c | 18 ++--
drivers/gpu/drm/ast/ast_main.c | 74 ++
drivers/gpu/drm/ast/ast_mode.c |
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/Kconfig | 1 +
drivers/gpu/drm/bochs/bochs.h | 34 +---
drivers/gpu/drm/bochs/bochs_drv.c | 4 +-
drivers/gpu/drm/bochs/bochs_kms.c | 18 +-
drivers/gpu/drm/bochs/bochs_mm.c | 269 +++---
5 files
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 19 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +--
The provided helpers can be used for the respective callback functions
in |struct drm_driver|.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 39
include/drm/drm_gem_ttm_helper.h | 10 +++
2 files changed, 49 insertions(+)
diff
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Kconfig | 1 +
drivers/gpu/drm/ast/ast_drv.h | 6 +-
drivers/gpu/drm/ast/ast_ttm.c | 120 ++
3 files changed, 11 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/ast/Kconfig
The helper function drm_gem_ttm_fill_create_dumb() implements most of
struct drm_driver.dumb_create() for GEM TTM buffer objects. It's not a
full implemenation of the callback, as several driver-specific parameters
are still required.
Signed-off-by: Thomas Zimmermann
---
Several simple framebuffer drivers copy most of the TTM code from each
other. The implementation is always the same; except for the name of
some data structures.
As recently discussed, this patch set provides generic TTM memory-
management code for framebuffers with dedicated video memory. It
The type |struct drm_gem_ttm_object| implements a TTM buffer object
for simple framebuffer devices with dedicated video memory. The BO
is either located in VRAM or system memory. The implementation has
been created from the respective code in ast, bochs and mgag200. These
drivers copy their
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/Kconfig| 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.h | 6 +-
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
3 files changed, 12 insertions(+), 118 deletions(-)
diff --git
The provided helpers can be used for the respective callback functions
in |struct ttm_bo_driver|.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 39
include/drm/drm_gem_ttm_helper.h | 10 +++
2 files changed, 49 insertions(+)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 3 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 124 ++
3 files changed, 13 insertions(+), 115 deletions(-)
diff --git
The Simple TTM memory manager is a helper library that manages dedicated
video memory of simple framebuffer devices. The implementation is based on
the respective code from ast, bochs, and mgag200. These drivers share the
exact same implementation execept for type names.
Signed-off-by: Thomas
1 - 100 of 187 matches
Mail list logo
