If fbdev registration fails for whatever reason, the error path of
bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev
initialization error is not fatal to the probe function, a subsequent
device removal will try to call bochs_fbdev_fini() again, hitting the
Oops below.
This was de
On 2017.03.23 14:43:44 +0100, Frans Klaver wrote:
> On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check, leading to a potential null
> > pointer derefere
On 03/23/2017 02:26 PM, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling
On Wed, Mar 15, 2017 at 06:02:09PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre
> ---
> .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/am
Hi Linus,
This is the fixes pull request for rc4.
It contains one core drm/fbdev regression fix.
A set of i915 fixes including a few GVT related fixes, along with
some reset fixes.
One new PCI id for amdgpu, and some minor workaround regression fixes.
A set of exynos fixes, dropping support for a
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #26 from Christian Birchinger (jo...@netswarm.net) ---
Haven't used HDMI for almost a year now. The issue is still present and this
time changing prealloc fixes nothing. 2048 used to work, but now all values
i've tried from 64 to 4096 d
The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.
Signed-off-by: Chris Zhong
Reviewed-by: Brian Norris
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../bindings/display/panel/innolux,p079zca.txt | 23 +
Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
Tested-by: Brian Norris
---
Changes in v4:
- remove backlight check after probe
- add bpc info
Changes in v3:
- printk err after regulator_disable(innolux->supply)
On 2017-03-23 01:53, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.
When changing resolution a regular fbdev driver also changes display
timing accordingly (
Hi Ville,
On 23-03-2017 18:14, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 17:42, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:43, S
On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from someone who doesn't know meson
yet) would
Hi Ville,
On 23-03-2017 19:00, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:16, Ville Syrjälä wrote:
>>> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
Add the HDMI 2.0 aspect ratio flags (64:27 and 256
Looks like in Linux next we can now get an oops when unloading omapdrm:
Unable to handle kernel NULL pointer dereference at virtual address
...
LR is at omap_drm_irq_uninstall+0xb0/0xe0 [omapdrm]
...
[] (omap_drm_irq_uninstall [omapdrm]) from []
(pdev_remove+0x50/0x88 [omapdrm])
[] (pdev_
Hi Andrzej,
On 23-03-2017 11:17, Andrzej Hajda wrote:
> On 23.03.2017 12:04, Jose Abreu wrote:
>> Hi Andrzej,
>>
>>
>> Thanks for the feedback!
>>
>> On 23-03-2017 08:11, Andrzej Hajda wrote:
>>> On 22.03.2017 18:35, Jose Abreu wrote:
This patch completes CEA table of video modes so that VIC
On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote:
> Hm, I certainly want it... but it would be unreasonable of me to expect
> Eric to cold-code a big upfront design for systems he can't even test
> this on.
>
> What I would request would rather be: please do not put in any
> immediate
Hi Daniel,
Thanks for the feedback!
On 23-03-2017 07:25, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote:
>> Perform sanity checks so that HDMI 2.0+ modes are not exported to
>> drivers or userspace unless asked to.
> Why? They're just normal modes, this doesn'
FYI, we noticed the following commit:
commit: f04f7e3e041aab12abbf3ed7b854446af5a624a9 ("drm: bochs: Don't remove
uninitialized fbdev framebuffer")
url:
https://github.com/0day-ci/linux/commits/Gabriel-Krisman-Bertazi/drm-bochs-Don-t-remove-uninitialized-fbdev-framebuffer/20170318-164722
base:
On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote:
> From: Colin Ian King
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference. If info is null, then the error message being
> printed
Hi Ville,
On 23-03-2017 15:16, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
>> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
>> flag which will signal userspace that this is a HDMI 2.0+ mode. It
>> is expected that these new flags will not
Hi Shashank,
On 23-03-2017 16:08, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:57 PM, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:45, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-
Hi Ville,
On 23-03-2017 15:36, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>> For any other mode, the VIC filed in AVI infoframes should be 0.
>> HDMI 2.0 sinks, support vide
Hi Shashank,
On 23-03-2017 15:14, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 15:14, Shashank Sharma wrote:
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>>> For any other mode, the VIC fi
Hi Shashank,
On 23-03-2017 16:43, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 6:33 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:08, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On Wed, Mar 22, 2017 at 08:26:07AM -0500, Rob Herring wrote:
> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
>
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no co
On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
>> >>>
>> >>> Quoting Rob Clark (
Hi Michel,
When it happens, the main thread of our gl based app is stuck on a
ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same
thing happens if true. Other threads are only si_shader:0,1,2,3 and are
doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof
X
Hi Shashank,
On 22-03-2017 18:57, Sharma, Shashank wrote:
> Hi Jose,
> I can't find the other patches of this series in dri patchwork, am I missing
> something ?
You can find them now in patchwork (I don't know what happened).
>
> Also, I am planning to publish a series for YUV 420 handling,
Hi Ville,
On 23-03-2017 17:42, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:43, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 6:33 PM, Jose Abreu wrote:
Hi Shashank,
Hi Andrzej,
Thanks for the feedback!
On 23-03-2017 08:11, Andrzej Hajda wrote:
> On 22.03.2017 18:35, Jose Abreu wrote:
>> This patch completes CEA table of video modes so that VIC 1-107
>> are now available. Use the HDMI 2.0+ flag to signal these are
>> modes for HDMI 2.0 onwards.
> edid_cea_mo
Hi Daniel,
On 23-03-2017 07:22, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
>> We can't expect userspace to have full support for all HDMI 2.0+
>> features. Instead of expecting/waiting for userspace to support
>> the new features add a knob, much like the s
Hi,
On 03/15/2017 06:02 PM, Yannick Fertre wrote:
Signed-off-by: Yannick Fertre
---
Same remarks than patch7
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 9c6ba54e..f7ddf29b 1
Hi
On 03/15/2017 06:02 PM, Yannick Fertre wrote:
Signed-off-by: Yannick Fertre
---
Can you change commit header by:" ARM: config: stm32: Add LTDC support"
and can you fill a commit message please ?
arch/arm/configs/stm32_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/ar
Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
>
> I guess an interesting que
https://bugs.freedesktop.org/show_bug.cgi?id=100364
John Brooks changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=90320
John Brooks changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=100364
--- Comment #1 from John Brooks ---
Created attachment 130407
--> https://bugs.freedesktop.org/attachment.cgi?id=130407&action=edit
Fix for display not waking
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100364
Bug ID: 100364
Summary: DisplayPort hotplug warning and monitor sometimes
stays blank
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All
On 03/22/2017 02:48 PM, Rob Clark wrote:
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, whi
On Sat, Mar 18, 2017 at 12:09 AM, Russell King - ARM Linux
wrote:
> On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
>> This is a modesetting driver for the pl111 CLCD display controller
>> found on various ARM platforms such as the Versatile Express. The
>> driver has only been tested
can you add bps here too?
On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Chris Zhong
> Reviewed-by: Sean Paul
> Tested-by: Brian Norris
> ---
>
> Changes in v3:
> - printk err after regula
https://bugs.freedesktop.org/show_bug.cgi?id=79431
Jan Vesely changed:
What|Removed |Added
Resolution|NOTABUG |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on|79431 |
Referenced Bugs:
https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #6 from omegap...@startmail.com ---
Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow
I'm sure ;)
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #5 from omegap...@startmail.com ---
Ah, happened again after leaving it off for ~2 hours...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 23-03-2017 15:16, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> >> flag which will signal userspace that
https://bugs.freedesktop.org/show_bug.cgi?id=100304
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 21 March 2017 at 05:00, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> > > wrote:
>> > > > Seems
On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 23-03-2017 17:42, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:43, Sharma, Shashank wrote:
> >>> Regards
> >>>
> >>> Shashank
https://bugs.freedesktop.org/show_bug.cgi?id=100067
--- Comment #6 from Vedran Miletić ---
(In reply to Mig from comment #5)
> minimal.cpp compiled with
>
> gcc -c minimal.cpp -g -o minimal.o
>
> [miguel@antergos-mig extra]$ gdb
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Founda
Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker wrote:
>
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
Sure, but if it's easier to get right (which I'm asserting it is),
On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 16:43, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/23/2017 6:33 PM, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:08, Sharma, Shashank wrote:
> >>> Regard
On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:52 PM, Jose Abreu wrote:
> > Hi Ville,
> >
> >
> > On 23-03-2017 15:36, Ville Syrjälä wrote:
> >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> >>> HDMI 1.4b support
>
> No, I've requested reverting the patch for now because it causes an
> obviously and rather severe problem. If you guys can quickly find how to
> fix it feel free to use that instead.
>
> My mistake! That makes sense. Thanks again.
___
dri-devel mailin
Regards
Shashank
On 3/23/2017 6:33 PM, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:08, Sharma, Shashank wrote:
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Regards
Shashank
On 3/23/2017 5:28 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
1-64).
Regards
Shashank
On 3/23/2017 5:52 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:36, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 15:14, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861
Understood -- I thought you might not want to take this patch, but I
went ahead and sent it out because Christian requested it, and it
seems like he doesn't think VRAM bos should ever evict back to VRAM at
all?
No, I've requested reverting the patch for now because it causes an
obviously and ra
Christian,
- Are we going to support resizing BAR when kernel
modesetting is not enabled and we are running in console
under VBIOS control (VESA/VGA)?
- Should we restore PCI configuration if amdgpu
will be unloaded?
- In function amdgpu_resize_bar0():
If resizing for "max" size failed sho
- Are we going to support resizing BAR when kernel
modesetting is not enabled and we are running in console
under VBIOS control (VESA/VGA)?
No, initial I've tried to resize the PCI BAR during probing without the
help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able
to handle a
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #12 from pablow.1...@gmail.com ---
(In reply to Vedran Miletić from comment #11)
> Is this still an issue?
Hi! I no longer have that video card, so no idea if it's still an issue.
--
You are receiving this mail because:
You are the
Hi Dave,
drm-misc-fixes-2017-03-23:
One fbdev regression fix from Michel
Cheers, Daniel
The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:
Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-mi
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #4 from omegap...@startmail.com ---
Just 'Invalid argument' currently.
I just did 10 tests turning the monitor off for just over 30 seconds, and on
turning it back on, the display layout did not break (but I got the usual flip
queue
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 15:14, Shashank Sharma wrote:
> > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> > For any other mode, the VIC filed in AVI infoframes should be 0.
> > HDMI 2.0 sinks, sup
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
>
> Was userspace maybe performing concurrent CPU access to the BOs in
> question?
As far as I know Julien has demonstrated that this is not the case.
> I hope we can find a better solution.
Understood -- I thought you might not want to take this patch, but I went
ahead and sent it out becaus
https://bugs.freedesktop.org/show_bug.cgi?id=100304
--- Comment #6 from Mike Lothian ---
Thanks, that's working great for me
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedeskto
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>> wrote:
>>>
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
>>> 1-64).
>>> For any other mode, the VIC filed in A
You guys might wanna use this series, to solve this problem.
https://patchwork.freedesktop.org/series/21773/
Patch 1: completes the CEA modes 1-107
Patch 2: Protects HDMI 1.4 monitors from HDMI 2.0 VICs
Regards
Shashank
On 3/23/2017 1:07 PM, Sharma, Shashank wrote:
Regards
Shashank
On 3/2
Regards
Shashank
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1
On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> flag which will signal userspace that this is a HDMI 2.0+ mode. It
> is expected that these new flags will not be exported to userspace
> unless client asks to.
W.r.t.
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
Hi Laurent,
On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> +{
> + struct rcar_du_device *rcdu = vsp->dev;
> + struct platfor
https://bugs.freedesktop.org/show_bug.cgi?id=100304
--- Comment #5 from Alex Deucher ---
Created attachment 130399
--> https://bugs.freedesktop.org/attachment.cgi?id=130399&action=edit
possible fix
This should fix the issue.
--
You are receiving this mail because:
You are the assignee for th
On 23.03.2017 12:35, Jose Abreu wrote:
> Hi Andrzej,
>
>
> On 23-03-2017 11:17, Andrzej Hajda wrote:
>> On 23.03.2017 12:04, Jose Abreu wrote:
>>> Hi Andrzej,
>>>
>>>
>>> Thanks for the feedback!
>>>
>>> On 23-03-2017 08:11, Andrzej Hajda wrote:
On 22.03.2017 18:35, Jose Abreu wrote:
> Thi
On stih407-410 chip family the GDP layers are able to support up to UHD
resolution (3840 x 2160).
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_gdp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/s
Make sure the GPU lock is taken, so that fence completion order matches
seqno order.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index
The fence allocation needs to be protected by the GPU mutex, otherwise
the fence seqnos of concurrent submits might not match the insertion order
of the jobs in the kernel ring. This breaks the assumption that jobs
complete with monotonically increasing fence seqnos.
Fixes: d9853490176c (drm/etnav
Hi Ville,
On 21 March 2017 at 18:12, wrote:
> Another iteration of the i915 CCS support. Main change is lifting the
> fb dimensions hsub/vsub alignment restrictions from the core. Without that
> userspace would have to align the fb size be a multiple of 8x16 pixels
> which isn't something they a
On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote:
> Hi Michel,
>
> On 23 March 2017 at 08:53, Michel Dänzer wrote:
> > Otherwise this can also prevent modesets e.g. for switching VTs, when
> > multiple monitors with different native resolutions are connected.
> >
> > The depths must m
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the s
On Wed, 22 Mar 2017, "Sharma, Shashank" wrote:
> Thanks for this patch, Jani.
>
> Reviewed-by: Shashank Sharma
And pushed to drm-misc-next, thanks for the review.
BR,
Jani.
>
>
> Regards
> Shashank
> On 3/22/2017 4:33 PM, Jani Nikula wrote:
>> Fix sparse warning:
>>
>> drivers/gpu/drm/drm_scd
On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote:
> On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
> >> Hi, Daniel,
> >>
> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> >>> On Thu, Mar 23, 2017 at 08:28:32AM +01
On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> From: Colin Ian King
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference. If info is null, then the error message being
>
On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> >
> >
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
> > > >
From: Colin Ian King
info is being checked to see if it is a null pointer, however, vpgu is
dereferencing info before this check, leading to a potential null
pointer dereference. If info is null, then the error message being
printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
u
Hi Michel,
On 23 March 2017 at 08:53, Michel Dänzer wrote:
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.
>
> The depths must match though, so keep the != test for that.
>
> Also update the DRM_DEBUG out
On 22 March 2017 at 20:10, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson. It doesn't
>> seem so bad with a quick look and I think I
On 23.03.2017 12:04, Jose Abreu wrote:
> Hi Andrzej,
>
>
> Thanks for the feedback!
>
> On 23-03-2017 08:11, Andrzej Hajda wrote:
>> On 22.03.2017 18:35, Jose Abreu wrote:
>>> This patch completes CEA table of video modes so that VIC 1-107
>>> are now available. Use the HDMI 2.0+ flag to signal the
Regards
Shashank
On 3/23/2017 10:11 AM, Andrzej Hajda wrote:
On 22.03.2017 18:35, Jose Abreu wrote:
This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.
edid_cea_modes array is used in differ
On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
> Hi Daniel,
>
>
> On 23-03-2017 07:22, Daniel Vetter wrote:
> > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
> >> We can't expect userspace to have full support for all HDMI 2.0+
> >> features. Instead of expecting/waitin
I realized it was too early to search that in dri-devel last night, I
guess it takes some time to sync.
Now I can see them all :)
On 3/23/2017 12:37 PM, Jose Abreu wrote:
Hi Shashank,
On 22-03-2017 18:57, Sharma, Shashank wrote:
Hi Jose,
I can't find the other patches of this series in dri
On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
>> Hi, Daniel,
>>
>> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
>>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas
Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
isn't used by our CTL instance anymore.
Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
instances. The ones that need to be configured are conf
Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.
Firstly, we need to identify whether we need a right mixer or not.
3D mux is a small block placed after the DSPPs in MDP5. It can merge
2 LM/DSPP outputs and feed it to a single interface.
Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
will need to be made more specific later when we add Dual DSI
support with source split enabled. In that use cas
Now that we have a right hwpipe in mdp5_plane_state, configure it
mdp5_plane_mode_set(). The only parameters that vary between the
left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
as we just even chop the fb into left and right halves.
Add a mdp5_plane_right_pipe() which will be u
1 - 100 of 136 matches
Mail list logo
