Hi Sam
thanks for reviewing the patch set.
Am 20.02.20 um 19:56 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
>> The mgag200 driver uses an empty implementation for its encoder. Replace
>> the code with the generic simple encoder.
>>
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
Thanks, I will take a look.
Regards,
Kenny
On Wed, Feb 19, 2020 at 1:38 PM Johannes Weiner wrote:
>
> On Wed, Feb 19, 2020 at 11:28:48AM -0500, Kenny Ho wrote:
> > On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote:
> > >
> > > Yes, I'd go with absolute units when it comes to memory,
Hey Linus,
Varied PR for rc3, i915 is the largest, they are seeing some ACPI
problems with their CI which hopefully get solved soon. msm has a
bunch of fixes for new hw added in the merge, a bunch of amdgpu fixes,
and nouveau adds support for some new firmwares for turing tu11x GPUs
that were
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 12:51 PM
>
> (resend because gmail did not format to plain text...)
>
> On Thu, Feb 20, 2020 at 8:45 PM Chia-I Wu wrote:
> >
> >
> >
> > On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
> >>
> >> > From: Chia-I Wu
> >> > Sent: Friday,
Hi, Enric:
On Thu, 2020-02-20 at 18:21 +0100, Enric Balletbo i Serra wrote:
> In the actual implementation the same compatible string
> "mediatek,-mmsys" is used to bind the clock drivers
> (drivers/clk/mediatek) as well as to the gpu driver
> (drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends
(resend because gmail did not format to plain text...)
On Thu, Feb 20, 2020 at 8:45 PM Chia-I Wu wrote:
>
>
>
> On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
>>
>> > From: Chia-I Wu
>> > Sent: Friday, February 21, 2020 6:24 AM
>> >
>> > On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
> > From: Chia-I Wu
> > Sent: Friday, February 21, 2020 6:24 AM
> >
> > On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin
> wrote:
> > >
> > > > From: Tian, Kevin
> > > > Sent: Thursday, February 20, 2020 10:05 AM
> > > >
> > > > > From: Chia-I Wu
Hi, Enric:
On Thu, 2020-02-20 at 18:21 +0100, Enric Balletbo i Serra wrote:
> Dear all,
>
> Those patches are intended to solve an old standing issue on some
> Mediatek devices (mt8173, mt2701 and mt2712) in a slightly different way
> to the precedent series.
>
> Up to now both drivers, clock
On Fri, Feb 14, 2020 at 8:09 PM Maxime Ripard wrote:
>
> The A33 TCON supports LVDS, so we can toggle the support switch.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
The user manual doesn't list the bits for LVDS signal polarity though.
I assume this was verified with the BSP or
On 2020-02-19 08:53, Nirmoy Das wrote:
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6
On 2020-02-19 08:53, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16
On 2020-02-19 08:53, Nirmoy Das wrote:
> GPU address should belong to driver not in memory management.
> This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
>
> Signed-off-by: Nirmoy Das
> Acked-by: Huang Rui
> Reviewed-by: Christian König
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #11 from Thomas Frank (thfr...@e.mail.de) ---
I can confirm Noel's finding. Reverting
1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 brings back the screen output after
resume for me as well.
--
You are receiving this mail because:
You
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 6:24 AM
>
> On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
> >
> > > From: Tian, Kevin
> > > Sent: Thursday, February 20, 2020 10:05 AM
> > >
> > > > From: Chia-I Wu
> > > > Sent: Thursday, February 20, 2020 3:37 AM
> > > >
> > > > On
On Thu, Feb 20, 2020 at 10:27 AM Jordan Crouse wrote:
> When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of
> cache coherency issues because it is mapped as write-combine without clearing
> the cache after it was zeroed.
>
> Rather than duplicate the hacky workaround we
On Wed, Feb 19, 2020 at 6:13 PM Tian, Kevin wrote:
> > > Curious... How is such slot exposed to the guest? A reserved memory
> > > region? Is it static or might be dynamically added?
> > The plan is for virtio-gpu device to reserve a huge memory region in
> > the guest. Memslots may be added
On 2/20/20 9:08 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On
On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
>
> > From: Tian, Kevin
> > Sent: Thursday, February 20, 2020 10:05 AM
> >
> > > From: Chia-I Wu
> > > Sent: Thursday, February 20, 2020 3:37 AM
> > >
> > > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
> > > >
> > > > > From: Paolo
Hi Sebastian,
On Thu, Feb 20, 2020 at 10:39:38PM +0100, Sebastian Reichel wrote:
> On Sun, Feb 16, 2020 at 11:03:06PM +0200, Laurent Pinchart wrote:
> > The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
> > are not used anymore. Remove them.
> >
> > Signed-off-by: Laurent
Hi,
On Sun, Feb 16, 2020 at 11:03:06PM +0200, Laurent Pinchart wrote:
> The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
> are not used anymore. Remove them.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Tomi Valkeinen
> ---
Actually it would be good to postpone this
On Thu, Feb 20, 2020 at 6:17 AM Laurent Pinchart
wrote:
>
> Hi Vasily,
Hi Laurent,
> Thank you for the patch.
>
> On Thu, Feb 20, 2020 at 12:35:08AM -0800, Vasily Khoruzhick wrote:
> > From: Icenowy Zheng
> >
> > Pinebook has an ANX6345 bridge connected to the RGB666 LCD output and
> > eDP
On Thu, Feb 20, 2020 at 5:56 AM Laurent Pinchart
wrote:
>
> Hi Vasily,
Hi Laurent,
> Thank you for the patch.
>
> On Thu, Feb 20, 2020 at 12:35:05AM -0800, Vasily Khoruzhick wrote:
> > Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
> >
> > Signed-off-by: Vasily Khoruzhick
> >
On Thu, Feb 20, 2020 at 1:35 AM Sam Ravnborg wrote:
>
> Hi Vasily
>
> On Thu, Feb 20, 2020 at 12:35:05AM -0800, Vasily Khoruzhick wrote:
> > Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> >
On Thu, Feb 20, 2020 at 5:59 AM Laurent Pinchart
wrote:
>
> Hi Vasily,
Hi Laurent,
>
> Thank you for the patch.
>
> On Thu, Feb 20, 2020 at 12:35:07AM -0800, Vasily Khoruzhick wrote:
> > This commit adds support for the NewEast Optoelectronics CO., LTD
> > WJFH116008A 11.6" 1920x1080 TFT LCD
On Thu, Feb 20, 2020 at 5:53 AM Laurent Pinchart
wrote:
>
> Hi Vasily,
Hi Laurent,
> Thank you for the patch.
>
> On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> > devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> > we don't need to print scary
On Thu, Feb 20, 2020 at 1:21 PM Sam Ravnborg wrote:
>
> Hi Laurent.
>
> > > + "^neweast,.*":
> > > +description: Guangdong Neweast Optoelectronics CO., LT
> >
> > Google only returns two hits for this name, beside the ones related to
> > this patch series. Are you sure this is the correct
On 2020-02-20 12:14, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:45:57AM -0800, jsa...@codeaurora.org wrote:
Hello All,
I am seeking recommendations for DRM compatible methods of updating
the
HW
other than frame commit path. When exiting idle/runtime_suspend, the
driver
votes for a
Hi Laurent.
> > + "^neweast,.*":
> > +description: Guangdong Neweast Optoelectronics CO., LT
>
> Google only returns two hits for this name, beside the ones related to
> this patch series. Are you sure this is the correct company name ?
Seems legit:
http://www.eastbl.com/
But maybe their
On Thu, Feb 20, 2020 at 01:42:22PM +0530, Sharat Masetty wrote:
> This patch adds a clock definition needed for powering on the GPU TBUs
> and the GPU TCU.
>
> Signed-off-by: Sharat Masetty
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 +++
> 1 file changed, 3 insertions(+)
On Thu, 20 Feb 2020 13:42:22 +0530, Sharat Masetty wrote:
> This patch adds a clock definition needed for powering on the GPU TBUs
> and the GPU TCU.
>
> Signed-off-by: Sharat Masetty
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
My
On Thu, Feb 20, 2020 at 10:45:57AM -0800, jsa...@codeaurora.org wrote:
> Hello All,
>
> I am seeking recommendations for DRM compatible methods of updating the HW
> other than frame commit path. When exiting idle/runtime_suspend, the driver
> votes for a bunch of resources including
On Thu, Feb 20, 2020 at 2:26 PM Sasha Levin wrote:
>
> On Fri, Feb 14, 2020 at 11:31:31AM -0500, Alex Deucher wrote:
> >On Fri, Feb 14, 2020 at 11:00 AM Sasha Levin wrote:
> >>
> >> From: Alex Deucher
> >>
> >> [ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ]
> >>
> >> Cull out 0
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
> On 2/20/20 7:04 PM, Daniel Vetter wrote:
> > On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> > > On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > > > On 2/18/20 10:01 PM, Daniel Vetter
On Thu, Feb 20, 2020 at 10:00:09AM -0800, Rob Clark wrote:
> From: Rob Clark
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55
Le 20/02/2020 à 17:27, Neil Armstrong a écrit :
> Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing
> register.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_registers.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff
On Fri, Feb 14, 2020 at 11:31:31AM -0500, Alex Deucher wrote:
On Fri, Feb 14, 2020 at 11:00 AM Sasha Levin wrote:
From: Alex Deucher
[ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ]
Cull out 0 clocks to avoid a warning in DC.
Bug:
Hi Maxime,
On Thu, Feb 20, 2020 at 06:53:07PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2020 at 08:10:06PM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
I
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:13AM +0100, Thomas Zimmermann wrote:
> The ast driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
>From
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
> The mgag200 driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:12AM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the
Hello All,
I am seeking recommendations for DRM compatible methods of updating the HW
other than frame commit path. When exiting idle/runtime_suspend, the driver
votes for a bunch of resources including power/clk/bandwidth as a part of
first commit handling. This usually adds a few millisecond
On Thu, Feb 20, 2020 at 07:19:08PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Store the timings (apart from the clock) as u16. The uapi mode
> > struct already uses u16 for everything so using something bigger
> >
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:12AM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the
On Thu, Feb 20, 2020 at 4:44 AM Guillaume Gardet
wrote:
>
> Hi,
>
> With (guest) kernel 5.5+ with qemu/kvm on arm64, I get lots of display
> corruptions leading to this kind of screen:
> https://openqa.opensuse.org/tests/1174521#step/yast2_i/24
Looking at the screenshot, it seems
On Thu, Feb 20, 2020 at 07:58:58AM +, Chris Wilson wrote:
> Quoting Alex Deucher (2020-02-20 02:52:32)
> > On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote:
> > >
> > > Hello!
> > >
> > > A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
> > > following (lightly
The GMU has very few memory allocations and uses a flat memory space so
there is no good reason to go out of our way to bypass the DMA APIs which
were basically designed for this exact scenario.
v2: Pass force_dma false to of_dma_configure to require that the DMA
region be set up and return error
Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
text bindings.
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 116 --
.../devicetree/bindings/display/msm/gmu.yaml | 130 +
2 files changed,
On 2/20/20 7:09 PM, Daniel Vetter wrote:
On Wed, Feb 19, 2020 at 02:53:20PM +0100, Nirmoy Das wrote:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 -
1 file
The GMU node now requires a specific dma-range property so that the driver
can use the DMA API to do the few memory allocations required by the GMU.
This sets the IOMMU iova allocator to match the 'uncached' part of the
GMU virtual address space.
v2: Fix the dma-ranges tag. The third pair should
When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of
cache coherency issues because it is mapped as write-combine without clearing
the cache after it was zeroed.
Rather than duplicate the hacky workaround we use in the GEM allocator for the
same reason it turns out that
On Thu, Feb 20, 2020 at 5:30 AM Emil Velikov wrote:
>
> Hi John,
>
> On Thu, 20 Feb 2020 at 08:45, John Bates wrote:
> >
> > The previous code was not thread safe and caused
> > undefined behavior from spurious duplicate resource IDs.
> > In this patch, an atomic_t is used instead. We no longer
On Thu, Feb 20, 2020 at 07:21:41PM +0100, Daniel Vetter wrote:
> On Thu, Feb 20, 2020 at 09:03:28AM +, Xinliang Liu wrote:
> > Update myself email address.
> > Add John Stultz as a reviewer. Thanks John.
> > Update git tree to drm-misc
>
> Acked-by: Daniel Vetter
>
> I guess you're going to
On Thu, Feb 20, 2020 at 09:03:28AM +, Xinliang Liu wrote:
> Update myself email address.
> Add John Stultz as a reviewer. Thanks John.
> Update git tree to drm-misc
Acked-by: Daniel Vetter
I guess you're going to push this to drm-misc?
-Daniel
>
> Signed-off-by: Xinliang Liu
> ---
>
On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the timings (apart from the clock) as u16. The uapi mode
> struct already uses u16 for everything so using something bigger
> internally doesn't really help us.
>
> Signed-off-by: Ville Syrjälä
On Wed, Feb 19, 2020 at 10:35:39PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We only have 7 bits defined for mode->type. Shrink the storage to u8.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_modes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Thu, Feb 20, 2020 at 05:33:09PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > The driver never sets mode->private_flags so copying
> > > it back
On Wed, Feb 19, 2020 at 02:53:21PM +0100, Nirmoy Das wrote:
> Switch over to GEM VRAM's implementation to retrieve bo->offset
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
On Wed, Feb 19, 2020 at 02:53:20PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
index 68cccfa2870a..bbbec8d26870 100644
---
On Fri, Feb 14, 2020 at 11:22:27AM -0500, Alex Deucher wrote:
On Fri, Feb 14, 2020 at 10:57 AM Sasha Levin wrote:
From: "Pan, Xinhui"
[ Upstream commit bd0522112332663e386df1b8642052463ea9b3b9 ]
Initialize notifier_lock.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1016
Reviewed-by:
Hi Frédéric,
It appears Ben made his own version of this patch (probably based on
the one you added to the kernel bz), and it's already upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2=0e6176c6d286316e9431b4f695940cfac4ffe6c2
Cheers,
-ilia
On
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some
On Tue, Dec 17, 2019 at 03:49:46PM +0100, Andrzej Pietrasiewicz wrote:
> This series adds AFBC support for Rockchip. It is inspired by:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>
>
Setup the Amlogic FBC decoder for the VD1 video overlay plane.
The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.
The default mode needs to calculate the content body size since the header
is allocated after.
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(+), 30 deletions(-)
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3
Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing
register.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_registers.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_registers.h
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3
Den 19.02.2020 11.21, skrev Daniel Vetter:
> 7/7 drivers agree that's the right choice, let's do this.
>
> This avoids duplicating the same old error checking code over all 7
> drivers, which is the motivation here.
>
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Sun, Feb 9, 2020 at 11:41 PM Sharat Masetty wrote:
>
> This patch adds the required dt nodes and properties
> to enabled A618 GPU.
>
> Signed-off-by: Sharat Masetty
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 102
> +++
> 1 file changed, 102 insertions(+)
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
dri-devel mailing list
Den 19.02.2020 11.20, skrev Daniel Vetter:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi drivers, the first few
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by:
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
>
On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> >>> On
On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct
Hi Daniel,
On 2/19/20 11:21 AM, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
>
> Signed-off-by: Daniel Vetter
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:08AM -0800, Vasily Khoruzhick wrote:
> From: Icenowy Zheng
>
> Pinebook has an ANX6345 bridge connected to the RGB666 LCD output and
> eDP panel input. The bridge is controlled via I2C that's connected to
> R_I2C bus.
>
>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:07AM -0800, Vasily Khoruzhick wrote:
> This commit adds support for the NewEast Optoelectronics CO., LTD
> WJFH116008A 11.6" 1920x1080 TFT LCD panel.
>
> Signed-off-by: Vasily Khoruzhick
> ---
>
1 - 100 of 172 matches
Mail list logo
