https://bugs.freedesktop.org/show_bug.cgi?id=110850
Bug ID: 110850
Summary: Vlc fails to decode video using vaapi
Product: Mesa
Version: 19.1
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hey Linus,
A small bit more lively this week but not majorly so. I'm away in
Japan next week for family holiday, so I'll be pretty disconnected,
I've asked Daniel to do fixes for the week while I'm out.
I sent this out earlier, but I forgot the subject, and then Ben asked
about some nouveau firmw
The "num_lanes" variable needs to be signed for the error handling to
work. The "i" variable can be a regular int as well.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/bridge/sii902x.c | 2 +-
1 file changed, 1 insert
Hello Jyri Sarha,
The patch ff5781634c41: "drm/bridge: sii902x: Implement HDMI audio
support" from May 27, 2019, leads to the following static checker
warning:
drivers/gpu/drm/bridge/sii902x.c:753 sii902x_audio_codec_init()
warn: 'sii902x->audio.mclk' isn't an ERR_PTR
drivers/gpu
This should check that "i" is within bounds before checking reading from
the array.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/bridge/sii902x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
On Wed, May 22, 2019 at 04:47:01PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
>
> Cc: intel-...@lists.freedesktop.org
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
> ---
> drivers/gp
On Thu, Jun 06, 2019 at 07:40:38PM -0300, Rodrigo Siqueira wrote:
> When vkms calls drm_universal_plane_init(), it sets 0 for the
> possible_crtcs parameter which works well for a single encoder and
> connector; however, this approach is not flexible and does not fit well
> for vkms. This commit ad
From: Jason Gunthorpe
So we can check locking at runtime.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
---
v2
- Fix missing & in lockdeps (Jason)
---
mm/hmm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f67ba32983d9f1..c702cd7
From: Jason Gunthorpe
Ralph observes that hmm_range_register() can only be called by a driver
while a mirror is registered. Make this clear in the API by passing in the
mirror structure as a parameter.
This also simplifies understanding the lifetime model for struct hmm, as
the hmm pointer must
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
> and poison bytes to detect this condition.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
> ---
> v2
> - Keep range start/end val
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> So long a a struct hmm pointer exists, so should the struct mm it is
> linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
> once the hmm refcount goes to zero.
>
> Since mmdrop() (ie a 0 kref on struct
From: Jason Gunthorpe
So long a a struct hmm pointer exists, so should the struct mm it is
linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
once the hmm refcount goes to zero.
Since mmdrop() (ie a 0 kref on struct mm) is now impossible with a !NULL
mm->hmm delete the hm
From: Jason Gunthorpe
No other register/unregister kernel API attempts to provide this kind of
protection as it is inherently racy, so just drop it.
Callers should provide their own protection, it appears nouveau already
does, but just in case drop a debugging POISON.
Signed-off-by: Jason Gunth
On Thu, Jun 06, 2019 at 07:04:46PM +, Kuehling, Felix wrote:
> On 2019-06-06 11:11 a.m., Jason Gunthorpe wrote:
> > On Fri, May 10, 2019 at 07:53:21PM +, Kuehling, Felix wrote:
> >> These problems were found in AMD-internal testing as we're working on
> >> adopting HMM. They are rebased aga
On Mon, Jun 3, 2019 at 6:56 PM Andrey Konovalov wrote:
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> tee_shm_register()->optee_shm_unregister()->check_
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_release() is called exactly once per hmm. ops->release() cannot
> accidentally trigger any action that would recurse back onto
> hmm->mirrors_sem.
>
> This fixes a use after-free race of the form:
>
>CPU0
Hi,
We observed the following error on an i.MX6D+ CPU during start of X. As a result, the screen goes blank.
---
[ 3599.200886] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:30:crtc-0] flip_done timed out
[ 3610.080885] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> As coded this function can false-fail in various racy situations. Make it
> reliable by running only under the write side of the mmap_sem and avoiding
> the false-failing compare/exchange pattern.
>
> Also make the locking ve
From: Jason Gunthorpe
Range functions like hmm_range_snapshot() and hmm_range_fault() call
find_vma, which requires hodling the mmget() and the mmap_sem for the mm.
Make this simpler for the callers by holding the mmget() inside the range
for the lifetime of the range. Other functions that accep
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This list is always read and written while holding hmm->lock so there is
> no need for the confusing _rcu annotations.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
> ---
> mm/hmm.c | 4 ++--
> 1 file cha
From: Jason Gunthorpe
hmm_release() is called exactly once per hmm. ops->release() cannot
accidentally trigger any action that would recurse back onto
hmm->mirrors_sem.
This fixes a use after-free race of the form:
CPU0 CPU1
Simplify AUX data read by removing index arithmetic and shifting with
a helper function that does two things:
1. Fetch data from up to 4 32-bit registers from the chip
2. Copy read data into user provided array.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
On Fri, May 10, 2019 at 07:53:21PM +, Kuehling, Felix wrote:
> These problems were found in AMD-internal testing as we're working on
> adopting HMM. They are rebased against glisse/hmm-5.2-v3. We'd like to get
> them applied to a mainline Linux kernel as well as drm-next and
> amd-staging-drm-n
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> So we can check locking at runtime.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
> ---
> v2
> - Fix missing & in lockdeps (Jason)
> ---
> mm/hmm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions
Hi,
We observed the following error on an i.MX6D+ CPU during start of X. As a
result, the screen goes blank.
---
[ 3599.200886] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
[CRTC:30:crtc-0] flip_done timed out
[ 3610.080885] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
[CRTC
From: Jason Gunthorpe
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code another version of this, all
that does is skip the might_sleep() debugging in common cases, which is
not helpful.
Further, based on prior patches, we can no simp
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Ralph observes that hmm_range_register() can only be called by a driver
> while a mirror is registered. Make this clear in the API by passing in the
> mirror structure as a parameter.
>
> This also simplifies understanding th
From: Jason Gunthorpe
This list is always read and written while holding hmm->lock so there is
no need for the confusing _rcu annotations.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
---
mm/hmm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/
We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be
enough. This also gets rid of a magic number as a bonus.
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
From: Jason Gunthorpe
Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
and poison bytes to detect this condition.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
---
v2
- Keep range start/end valid after unregistration (Jerome)
---
mm/hmm.c | 7 +--
1 f
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The wait_event_timeout macro already tests the condition as its first
> action, so there is no reason to open code another version of this, all
> that does is skip the might_sleep() debugging in common cases, which is
> not he
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() is not a fence and the mmu_notifier
system will continue to reference hmm->mn until the srcu grace period
expires.
Resulting in use after free races like this:
CPU0 CPU1
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
...
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 8e7403f081f44a..547002f56a163d 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
...
> @@ -125,7 +130,7 @@ static void hmm_free(struct kref *kref)
> mm->hmm = NULL;
> spin_u
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Range functions like hmm_range_snapshot() and hmm_range_fault() call
> find_vma, which requires hodling the mmget() and the mmap_sem for the mm.
>
> Make this simpler for the callers by holding the mmget() inside the range
>
From: Jason Gunthorpe
For hmm.git:
This patch series arised out of discussions with Jerome when looking at the
ODP changes, particularly informed by use after free races we have already
found and fixed in the ODP code (thanks to syzkaller) working with mmu
notifiers, and the discussion with Ralp
On Thu, Jun 6, 2019 at 3:59 AM Andrzej Hajda wrote:
>
> On 05.06.2019 09:04, Andrey Smirnov wrote:
> > Simplify AUX data read by removing index arithmetic and shifting with
> > a helper functions that does three things:
> >
> > 1. Fetch data from up to 4 32-bit registers from the chip
> >
From: Jason Gunthorpe
As coded this function can false-fail in various racy situations. Make it
reliable by running only under the write side of the mmap_sem and avoiding
the false-failing compare/exchange pattern.
Also make the locking very easy to understand by only ever reading or
writing mm-
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> No other register/unregister kernel API attempts to provide this kind of
> protection as it is inherently racy, so just drop it.
>
> Callers should provide their own protection, it appears nouveau already
> does, but just in
Am 07.06.2019 09:27, schrieb Dan Carpenter:
> This should check that "i" is within bounds before checking reading from
> the array.
>
> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/bridge/sii902x.c | 4 ++--
>
On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don’t
> have hardware with writeback support.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> d
On Fri, Jun 07, 2019 at 09:48:08AM +0200, Daniel Vetter wrote:
> On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don’t
> > have hardware w
On Thu, Jun 06, 2019 at 11:47:12AM +0200, Anders Roxell wrote:
> When building with CONFIG_DRM_MXSFB and CONFIG_FB_MXS enabled as
> loadable modules, we see the following warning:
>
> warning: same module names found:
> drivers/video/fbdev/mxsfb.ko
> drivers/gpu/drm/mxsfb/mxsfb.ko
>
> Rework
On Fri, Jun 07, 2019 at 09:39:57AM +0200, walter harms wrote:
>
>
> Am 07.06.2019 09:27, schrieb Dan Carpenter:
> > This should check that "i" is within bounds before checking reading from
> > the array.
> >
> > Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> > Signed
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #47 from Rui Salvaterra ---
(In reply to Marek Olšák from comment #45)
> Yeah that looks good.
Great! In that case, I'm going to do a proper version and send it. I don't like
the fact that I'm doing chip_families[r300screen->caps.fa
On 06/06/2019 19:30, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> The G12A Primary plane was disabled by writing in the OSD1 configuration
>> registers, but this caused the plane blender to stall instead of continuing
>> blended only the overlay plane.
>
> grammar nit: "...instead of contin
On 06/06/2019 19:25, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> The primary plane disable logic is flawed, when the primary plane is
>> disabled, it is re-enabled in the vsync irq when another plane is updated.
>>
>> Handle the plane disabling correctly by handling the primary plane
>> ena
On 06/06/2019 18:30, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> The Amlogic G12A HDMI PLL needs some specific settings to lock with
>> different fractional values for the 5,4GHz mode.
>>
>> Handle the 1000/1001 variation fractional case here to avoid having
>> the PLL in an non lockable st
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #48 from Rui Salvaterra ---
(In reply to Rui Salvaterra from comment #43)
> Compiz feels much snappier, indeed.
To be 100 % honest, the difference is noticeable, but my laptop has one big
problem: as if the Xpress 200M wasn't slow e
https://bugs.freedesktop.org/show_bug.cgi?id=108381
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #49 from Richard Thier ---
> as if the Xpress 200M wasn't slow enough, the screen has
> a resolution of > 1680x1050 when the typical resolution,
> at the time, was 1280x800.
I don't get it. Is there no supported resolution below tha
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #50 from Rui Salvaterra ---
(In reply to Richard Thier from comment #49)
> I don't get it. Is there no supported resolution below that big one? That is
> quite hard to believe. Mine is 1024x768 when maxed, but sometimes I reverse
> e
Hi Yannick,
Thank you for your patch
Acked-by: Philippe Cornu
Philippe :-)
On 6/3/19 10:31 AM, Yannick Fertré wrote:
> Print display controller hardware version in debug mode only.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/ltdc.c | 2 +-
> 1 file changed, 1 insertion(+
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #21 from tempel.jul...@gmail.com ---
I'm open to trying out other patches, e.g. concerning double buffering for the
cursor. :)
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Lowry,
On Thu, Jun 06, 2019 at 10:53:05AM +0100, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds iommu_connect and disconnect for SMMU support, and configures
> TBU translation once SMMU has been attached to the display device.
>
> Signed-off-by: Low
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #47 from Ondrej Lang ---
The patch is not part of the kernel package itself, it is part of the
linux-firmware package, there was no new release of linux-firmware since I
tested this.
I think the reason why you did not have to rebuld
On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >
> > If think valid compatible properties would be:
> > compatible = "innolux,n116bge", "simple-panel";
> > compatible = "edp-connector", "simple-panel";
>
> A connecto
On 03.06.2019 16:21, Colin King wrote:
> From: Colin Ian King
>
> The less than check for the variable num_lanes is always going to be
> false because the variable is a u32. Fix this by making num_lanes an
> int and also make loop index i an int too.
>
> Addresses-Coverity: ("Unsigned compared ag
On 07.06.2019 09:27, Dan Carpenter wrote:
> The "num_lanes" variable needs to be signed for the error handling to
> work. The "i" variable can be a regular int as well.
>
> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> Signed-off-by: Dan Carpenter
Colin send alread
On 07.06.2019 09:27, Dan Carpenter wrote:
> This should check that "i" is within bounds before checking reading from
> the array.
>
> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> Signed-off-by: Dan Carpenter
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
On 07/06/2019 10:41, Andrzej Hajda wrote:
> On 03.06.2019 16:21, Colin King wrote:
>> From: Colin Ian King
>>
>> The less than check for the variable num_lanes is always going to be
>> false because the variable is a u32. Fix this by making num_lanes an
>> int and also make loop index i an int to
Hi James,
On Mon, May 20, 2019 at 11:44:47AM +0100, james qian wang (Arm Technology
China) wrote:
> To achieve same caling effect compare with none split, the texel
> calculation need to use the same scaling ratio before split, so add
> "total_xxx" to pipeline to describe the hsize/vsize before s
On Tue, May 21, 2019 at 10:34:54AM +0100, james qian wang (Arm Technology
China) wrote:
> DRM_OBJECT_MAX_PROPERTY number 24 is not enough for komeda usage, increase
> it to 32 to fit komeda's requirement.
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
Reviewed-by: Liviu Dudau
Be
On 6/6/19 9:38 AM, Daniel Vetter wrote:
> Hi Bart,
Hi Daniel,
> On Tue, May 28, 2019 at 11:02:31AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> I think we're slowly getting there. Previous cover letters with more
>> context:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2019-May/218362
On Thu, 6 Jun 2019 at 22:15, Daniel Vetter wrote:
>
> I. was. blind.
>
> Caught with vkms, which has some really slow crc computation function.
>
> Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in
> drm_crtc_add_crc_entry")
> Cc: Rodrigo Siqueira
> Cc: Tomeu Vizoso
> Cc: Emil Vel
On Wed, 5 Jun 2019 at 13:08, Daniel Vetter wrote:
>
> This completes Emil's series of removing DRM_UNLOCKED from modern
> drivers. It's entirely cargo-culted since we ignore it on
> non-DRIVER_LEGACY drivers since:
>
> commit ea487835e8876abf7ad909636e308c801a2bcda6
> Author: Daniel Vetter
> Date
https://bugs.freedesktop.org/show_bug.cgi?id=110725
--- Comment #10 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- CML ICL:
igt@kms_big_fb@(linear|x-tiled|y-tiled)-(16|32|64)bpp-rotate-(90|270) - skip -
unsupported configuration, SKIP -}
{+ CML ICL:
igt@kms_b
With reference to mainline commit (1ff494813bafa127ecba1160262ba39b2fdde7ba),
DRIVER_IRQ_SHARED is to be used only by legacy drivers. Further,
drm_irq_install() ignores this flag altogether.
One needs to use devm_request_irq() instead, with IRQF_SHARED to create a shared
interrupt handler.
Signed-
Hi John,
I think it's looking good. I spotted a couple of error paths which I
think are missing cleanup, no complaints about the API though.
On Fri, Jun 07, 2019 at 03:07:15AM +, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
Abstract the debugfs override and the firmware EDID retrieval
function. We'll be needing it in the follow-up. No functional changes.
Cc: Daniel Vetter
Cc: Harish Chegondi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 17 insertions(+),
We've moved the override and firmware EDID (simply "override EDID" from
now on) handling to the low level drm_do_get_edid() function in order to
transparently use the override throughout the stack. The idea is that
you get the override EDID via the ->get_modes() hook.
Unfortunately, there are scen
https://bugs.freedesktop.org/show_bug.cgi?id=110313
--- Comment #5 from Mika Kahola ---
It seems that we haven't seen this bug for a while now. Can we close this one?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-dev
On Tue, 04 Jun 2019, Ilpo Järvinen wrote:
> Yes, if it applies fine to 5.1. ...Also, it will take a week or so.
Please try these two patches instead:
https://patchwork.freedesktop.org/series/61764/
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
V3:
* add bindings documentation (suggested by s...@ravnborg.org)
V2 2019-06-05 07:07:05:
* fix typo in 99dtc panel compatible string (reported by imir...@alum.mit.edu)
V1 2019-06-04 14:53:00:
Since v5.2-rc1 OMAP is no longer using a special display driver architecture
for DPI panels, but uses t
Signed-off-by: H. Nikolaus Schaller
---
.../display/panel/ortustech,com37h3m99dtc.txt| 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt
diff --git
a/Documentation/devicetree/bindings/displa
Signed-off-by: H. Nikolaus Schaller
---
.../display/panel/ortustech,com37h3m05dtc.txt| 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt
diff --git
a/Documentation/devicetree/bindings/displa
Signed-off-by: H. Nikolaus Schaller
---
.../bindings/display/panel/sharp,lq070y3dg3b.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt
diff --git
a/Documentation/devicetree/bindings/display/pane
The change adds support for the Ortustech COM37H3M05DTC/99DTC 3.7" TFT LCD
panel.
Tested on Letux3704.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/panel/panel-simple.c | 33
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simp
The change adds support for the Sharp LQ070Y3DG3B 7.0" TFT LCD panel.
Tested on Letux7004.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/panel/panel-simple.c | 30
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drive
Le ven. 7 juin 2019 à 12:07, Emil Velikov a écrit :
>
> On Thu, 6 Jun 2019 at 22:15, Daniel Vetter wrote:
> >
> > I. was. blind.
> >
> > Caught with vkms, which has some really slow crc computation function.
> >
> > Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in
> > drm_crtc_add
Hi John,
On Fri, Jun 07, 2019 at 03:07:16AM +, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and
Hi Yannick,
Thank you for your patch
Acked-by: Philippe Cornu
Philippe :-)
On 6/3/19 10:32 AM, Yannick Fertré wrote:
> This patch enables runtime power management (runtime PM) support for
> the display controller. pm_runtime_enable() and pm_runtime_disable()
> are added during ltdc load and un
Hi,
On Fri, Jun 07, 2019 at 03:07:17AM +, John Stultz wrote:
> This patch adds system heap to the dma-buf heaps framework.
>
> This allows applications to get a page-allocator backed dma-buf
> for non-contiguous memory.
>
> This code is an evolution of the Android ION implementation, so
> th
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/intel_dpll_mgr.h
index 8835dd20f1d27e05..79a53c5439a8e6db 100644
--- a/drivers/gpu/drm/i915
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:14PM +0200, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> Each DU output channel is provided with a CMM unit to perform image
> enhancement and color correction.
I would say "On most G
Hi Geert,
On Thu, Jun 06, 2019 at 10:00:23PM +0200, Geert Uytterhoeven wrote:
> On Thu, Jun 6, 2019 at 8:50 PM Laurent Pinchart wrote:
> > On Thu, Jun 06, 2019 at 04:22:03PM +0200, Jacopo Mondi wrote:
> >> Update the 'vsps' property structure in the documentation example to
> >> reflect what's act
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:15PM +0200, Jacopo Mondi wrote:
> Add CMM to the list of supported features for Gen3 SoCs that provide it:
> - R8A7795
> - R8A7796
> - R8A77965
> - R8A7799x
>
> Leave R8A77970 out as V3M and V3H are the only Gen3 SoCs that do not
On Mon, Jun 3, 2019 at 7:06 AM Damian Kos wrote:
>
> This patch updates mhdp8546 firmware from v1.2.12 to v1.2.15.
>
> Added support for performing arbitrary I2C-over-AUX transactions.
> Corrected handling of erroneous requests for reading/writing 0 bytes over
> DPCD.
> Add mailbox message to for
Hi Jacopo,
On Fri, Jun 07, 2019 at 02:35:40PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thu, Jun 06, 2019 at 04:22:14PM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > Each DU output channel is provide
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:16PM +0200, Jacopo Mondi wrote:
> Implement device tree parsing to collect the available CMM instances
> described by the 'cmms' property. Associate CMMs with CRTCs and store a
> mask of active CMMs in the DU group for later enable
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:17PM +0200, Jacopo Mondi wrote:
> Enable/disable the CMM associated with a CRTC at
> atomic_enable()/atomic_disable() time.
I would squash this patch with the next 3. It's hard to review them
independently.
> Signed-off-by: Jacop
On 5/20/19 3:43 PM, Marek Vasut wrote:
> On 5/20/19 3:06 PM, Fabio Estevam wrote:
>> There is a DRM version of the mxsfb driver for quite some time
>> at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
>> the fbdev version any longer.
>>
>> Remove the fbdev mxsfb driver in favour o
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:18PM +0200, Jacopo Mondi wrote:
> Enable the CMM units through the display unit extensional function control
> group register DEFR7.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 8
>
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:19PM +0200, Jacopo Mondi wrote:
> Enable the GAMMA_LUT KMS property using the framework helpers to
> register the proeprty and the associated gamma table size maximum size.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm
On 6/7/19 9:57 AM, Daniel Vetter wrote:
> On Thu, Jun 06, 2019 at 11:47:12AM +0200, Anders Roxell wrote:
>> When building with CONFIG_DRM_MXSFB and CONFIG_FB_MXS enabled as
>> loadable modules, we see the following warning:
>>
>> warning: same module names found:
>> drivers/video/fbdev/mxsfb.ko
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:20PM +0200, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
>
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> Signed-off-by: Jacopo Mon
Hi Jacopo,
Now that I've read the whole series, here are a few comments.
On Fri, Jun 07, 2019 at 02:35:40PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thu, Jun 06, 2019 at 04:22:14PM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Colo
On 5/21/19 4:12 PM, Geert Uytterhoeven wrote:
> On Tue, May 21, 2019 at 4:02 PM Bartlomiej Zolnierkiewicz
> wrote:
>> No need for them.
>>
>> Cc: Geert Uytterhoeven
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>
> Reviewed-by: Geert Uytterhoeven
Thanks, I queued the patch for v5.3.
Best reg
On 6/1/19 11:06 PM, Alexandre Belloni wrote:
> On 30/05/2019 14:30:19+0200, Bartlomiej Zolnierkiewicz wrote:
>> Add COMPILE_TEST support to atmel_lcdfb driver for better compile
>> testing coverage.
>>
>> While at it fix improper use of UL (to silence build warnings on
>> x86_64).
>>
>> Cc: Alexan
On 5/21/19 12:47 PM, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to imxfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Elec
On 5/21/19 12:49 PM, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to pxa168fb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung E
1 - 100 of 205 matches
Mail list logo
