W dniu 28.03.2020 o 14:20, Sam Ravnborg pisze:
Fix following warnings:
drm_framebuffer.h:342: warning: Function parameter or member 'block_width' not
described in 'drm_afbc_framebuffer'
drm_framebuffer.h:342: warning: Function parameter or member 'block_height' not
described in 'drm_afbc_frameb
Hi Adrian,
On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu wrote:
>
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
>
> - drm:
On Mon, Mar 30, 2020 at 8:35 AM Adrian Ratiu wrote:
> +panel@0 {
> +compatible = "sharp,ls032b3sx01";
> +reg = <0>;
> +reset-gpios = <&gpio6 8 GPIO_ACTIVE_LOW>;
> +ports {
> +port@0 {
There is a unit address here without a c
On Mon, Mar 30, 2020 at 9:18 AM Marek Szyprowski
wrote:
> Today I've noticed that this patch went to final v5.6 without even a day
> of testing in linux-next, so v5.6 is broken on Exynos and probably a few
> other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
> function.
>
> Best r
On Mon, Mar 30, 2020 at 9:18 AM Marek Szyprowski
wrote:
> Today I've noticed that this patch went to final v5.6 without even a day
> of testing in linux-next, so v5.6 is broken on Exynos and probably a few
> other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
> function.
>
> Best
This reverts commit 7be1b9b8e9d1e9ef0342d2e001f44eec4030aa4d.
The drm_mm is supposed to work in atomic context, so calling schedule()
or in this case cond_resched() is illegal.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(
Quoting Christian König (2020-03-30 13:34:25)
> This reverts commit 7be1b9b8e9d1e9ef0342d2e001f44eec4030aa4d.
>
> The drm_mm is supposed to work in atomic context, so calling schedule()
> or in this case cond_resched() is illegal.
https://patchwork.freedesktop.org/patch/358535/?series=74984&rev=1
Hi all, for all = rcu, cpuhotplug and perf maintainers
We've hit an interesting new lockdep splat in our drm/i915 CI:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-gtt.html#dmesg-warnings861
Summarizing away the drive
On 2020-03-29 10:55 am, Marek Szyprowski wrote:
Hi Michael,
On 2020-03-27 19:31, Ruhl, Michael J wrote:
-Original Message-
From: Marek Szyprowski
Sent: Friday, March 27, 2020 12:21 PM
To: dri-devel@lists.freedesktop.org; linux-samsung-...@vger.kernel.org;
linux-ker...@vger.kernel.org
C
On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
wrote:
>
> Hi
>
> On 2020-03-27 10:10, Marek Szyprowski wrote:
> > Hi Christian,
> >
> > On 2020-03-27 09:11, Christian König wrote:
> >> Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
> >>> On 2020-03-25 10:07, Shane Francis wrote:
> As dma_ma
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote:
> Hi all, for all = rcu, cpuhotplug and perf maintainers
>
> We've hit an interesting new lockdep splat in our drm/i915 CI:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-r
Dear Yannick,
Thank you for your patch,
Acked-by: Philippe Cornu
(sorry for the email format)
Philippe :-)
-Original Message-
From: Yannick FERTRE
Sent: Friday, February 28, 2020 09:08
To: Yannick FERTRE ; Philippe CORNU
; Benjamin GAIGNARD ; David
Airlie ; Daniel Vetter ; Maxime Coqu
https://bugzilla.kernel.org/show_bug.cgi?id=207005
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
>-Original Message-
>From: dri-devel On Behalf Of
>Marek Szyprowski
>Sent: Sunday, March 29, 2020 5:56 AM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org; linux-samsung-...@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; Shane Franc
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 2 ++
include/linux/dma-buf.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b
Calling ttm_bo_cleanup_memtype_use() destroys the TT object
which in turn could result in warnings without this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/t
Note if a buffer was imported using peer2peer.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 4277125a79ee..
Importing should work out of the box.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index ffeb20f11c07..aef12ee2f1e3 100
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index aef12ee2f1e3..bbf6
We should be able to do this now after checking all the prerequisites.
v2: fix entrie count in the sgt
v3: manually construct the sg
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 56 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 ++-
drivers/g
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote:
> Hi all, for all = rcu, cpuhotplug and perf maintainers
>
> We've hit an interesting new lockdep splat in our drm/i915 CI:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-r
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
information.
Signed-off-by: Chun-Kuang Hu
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 38fe2f3f7b6f..
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v2:
- include module.h in mtk_hdmi.c
CK Hu (3):
drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mt
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig| 9
On Fri, 27 Mar 2020 15:14:46 +0100
Neil Armstrong wrote:
> Hi,
>
> On 26/03/2020 10:36, Pekka Paalanen wrote:
> > On Wed, 25 Mar 2020 17:18:15 +0100
> > Neil Armstrong wrote:
> >
> >> Hi,
> >>
> >> On 25/03/2020 14:49, Pekka Paalanen wrote:
> >>> On Wed, 25 Mar 2020 11:24:15 +0100
> >>> Ne
https://bugzilla.kernel.org/show_bug.cgi?id=207005
--- Comment #4 from toki1990 (destekerdemon...@gmail.com) ---
(In reply to Alex Deucher from comment #3)
> Is this a regression? If so, can you bisect?
my English is not enough. I cant understand.
--
You are receiving this mail because:
You ar
On Sat, 2020-03-28 at 14:20 +0100, Sam Ravnborg wrote:
> Fix kernel-doc warnings for drm_dp_mst_port.fec_capable.
> This fixed the following warning:
> drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_capable'
> not described in 'drm_dp_mst_port'
>
> Signed-off-by: Sam Ravnborg
On Fri, 27 Mar 2020, Daniel Dadap wrote:
> A number of hybrid GPU notebook computer designs with dual (integrated
> plus discrete) GPUs are equipped with multiplexers (muxes) that allow
> display panels to be driven by either the integrated GPU or the discrete
> GPU. Typically, this is a select
On Tue, 24 Mar 2020 18:18:19 +0100, Angelo Ribeiro wrote:
> Add dt-bindings for Synopsys DesignWare MIPI DSI Host and VPG (Video
> Pattern Generator) support in the IPK display subsystem.
>
> The Synopsys DesignWare IPK display video pipeline is composed by a DSI
> controller (snps,dw-ipk-dsi) and
https://bugzilla.kernel.org/show_bug.cgi?id=207005
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
Did this work correctly on an older kernel? Did something break after an
update? If so, when did it last work correctly?
--
You are receiving this mail because:
You are watching the
On Sun, 29 Mar 2020 19:35:47 +0200, "H. Nikolaus Schaller" wrote:
> and add compatible: jz4780-lcd, including an example how to
> configure both lcd controllers.
>
> Also fix the clock names and examples.
>
> Based on work by Paul Cercueil and
> Sam Ravnborg
>
> Signed-off-by: H. Nikolaus Scha
On Mon, 30 Mar 2020 14:35:42 +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host controller
> present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
>
> Cc: Rob Herring
> Cc: Neil Armstrong
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Sjoerd Simon
https://bugzilla.kernel.org/show_bug.cgi?id=207005
--- Comment #6 from toki1990 (destekerdemon...@gmail.com) ---
(In reply to Alex Deucher from comment #5)
> Did this work correctly on an older kernel? Did something break after an
> update? If so, when did it last work correctly?
Never worked c
On Fri, 2020-03-27 at 14:56 +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2020 at 07:27:56AM +, Mun, Gwan-gyeong wrote:
> > On Fri, 2020-03-20 at 13:57 +0200, Laurent Pinchart wrote:
> > > Hi Jani,
> > >
> > > On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> > > > On Fri, 20 Mar
Added state readout for DP HDR Metadata Infoframe SDP.
v9: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/d
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Byte
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/dis
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VS
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file chang
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and intel_dp_hdr
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed configs
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i91
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
dif
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpac
On Wed, Mar 11, 2020 at 3:55 PM Andrzej Pietrasiewicz
wrote:
>
> The new struct contains afbc-specific data.
>
> The new function can be used by drivers which support afbc to complete
> the preparation of struct drm_afbc_framebuffer. It must be called after
> allocating the said struct and calling
On Sun, 29 Mar 2020 12:37:18 +0200 (CEST)
Julia Lawall wrote:
> On Sun, 29 Mar 2020, Soumyajit Deb wrote:
>
> > I had the same doubt the other day about the replacement of udelay() with
> > usleep_range(). The corresponding range for the single argument value of
> > udelay() is quite confusing a
Hi Daniel,
W dniu 30.03.2020 o 19:01, Daniel Vetter pisze:
On Wed, Mar 11, 2020 at 3:55 PM Andrzej Pietrasiewicz
wrote:
The new struct contains afbc-specific data.
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 439656f55c5d..37a3a023c114 100644
--- a/Documenta
Hi Russell.
On Sun, Mar 29, 2020 at 11:19:10AM +0100, Russell King wrote:
> Globally update my email address in six files scattered through the
> tree.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/armada/armada_drv.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-a
On Mon, Mar 30, 2020 at 7:44 PM Andrzej Pietrasiewicz
wrote:
>
> Hi Daniel,
>
> W dniu 30.03.2020 o 19:01, Daniel Vetter pisze:
> > On Wed, Mar 11, 2020 at 3:55 PM Andrzej Pietrasiewicz
> > wrote:
> >>
> >> The new struct contains afbc-specific data.
>
>
>
> >> diff --git a/Documentation/gpu/tod
Add documentation for newly introduced KMS plane and CRTC scaling
filter properties.
changes since v1:
* None
changes since RFC:
* Add separate documentation for plane and CRTC.
Signed-off-by: Pankaj Bharadiya
---
Documentation/gpu/drm-kms.rst | 12
1 file changed, 12 insertions(+)
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
changes since v1:
* None
chan
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the full PS_CTRL register value
This series is the continuation for the RFC that I posted earlier [1]
[1] RFC: https://patchwork.freedesktop.org/series/73884/
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer (i.e., whole
number) multiplier. Nearest-neighbor (
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest so
Hi,
On Mon, Mar 30, 2020 at 2:04 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered, PM
Hi Thomas.
On Mon, Mar 30, 2020 at 01:29:16PM +0200, Thomas Zimmermann wrote:
> Hi Sam and Lyude,
>
> thanks for improving the documentation. Below are a few points that I'd
> found more understandable. I'm no native speaker, though.
>
> Am 28.03.20 um 14:20 schrieb Sam Ravnborg:
> > Lyude Paul
Lyude Paul wrote a very good intro to vblank here:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Add this to the intro chapter in drm_vblank.c so others
can benefit from it too.
v2:
- Reworded to improve
Hi Andrzej
On Mon, Mar 30, 2020 at 01:35:18PM +0200, Andrzej Pietrasiewicz wrote:
> W dniu 28.03.2020 o 14:20, Sam Ravnborg pisze:
> > Fix following warnings:
> > drm_framebuffer.h:342: warning: Function parameter or member 'block_width'
> > not described in 'drm_afbc_framebuffer'
> > drm_framebu
Hi Lyude.
On Mon, Mar 30, 2020 at 11:01:12AM -0400, Lyude Paul wrote:
> On Sat, 2020-03-28 at 14:20 +0100, Sam Ravnborg wrote:
> > Fix kernel-doc warnings for drm_dp_mst_port.fec_capable.
> > This fixed the following warning:
> > drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_
Hi Qiujun
On Sun, Mar 29, 2020 at 04:56:47PM +0800, Qiujun Huang wrote:
> Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated.
>
> syzkaller report: https://lkml.org/lkml/2020/3/27/403
> general protection fault, probably for non-canonical address
> 0xdc6c: [#1] SMP
With below commit, we have new struct drm_device based WARN* macros,
which include device specific information in the backtrace.
commit dc1a73e50f9c63d4dd928df538082200467dc4b1
Author: Pankaj Bharadiya
Date: Wed Jan 15 09:14:45 2020 +0530
drm/print: introduce new struct drm_device based WA
Hi Matthias.
On Sun, Mar 29, 2020 at 10:44:17AM -0700, Matthias Kaehlcke wrote:
> Hi Sam,
>
> On Sat, Mar 28, 2020 at 09:40:47PM +0100, Sam Ravnborg wrote:
> > Hi Harigovindan
> >
> > On Fri, Mar 27, 2020 at 01:06:34PM +0530, Harigovindan P wrote:
> > > Adding support for visionox rm69299 panel
Hi Pankaj.
On Tue, Mar 31, 2020 at 12:45:24AM +0530, Pankaj Bharadiya wrote:
> With below commit, we have new struct drm_device based WARN* macros,
> which include device specific information in the backtrace.
>
> commit dc1a73e50f9c63d4dd928df538082200467dc4b1
> Author: Pankaj Bharadiya
> Date:
> -Original Message-
> From: Sam Ravnborg
> Sent: 31 March 2020 00:57
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmerma
Hi,
On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya
wrote:
> Userspace patch series link: https://github.com/lrusak/xbmc/pull/24
This pull request is against a fork, not the official Kodi repository.
Are there any plans to upstream the change so that users can benefit
from it? Is there a r
On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya
wrote:
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 906771e03103..b0335e9d887c 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -509,6 +509,18 @@ Variable Refresh Pr
With below commit, we have new struct drm_device based WARN* macros,
which include device specific information in the backtrace.
commit dc1a73e50f9c63d4dd928df538082200467dc4b1
Author: Pankaj Bharadiya
Date: Wed Jan 15 09:14:45 2020 +0530
drm/print: introduce new struct drm_device based WA
On Mon, Mar 30, 2020 at 08:04:44PM +0200, Sam Ravnborg wrote:
> Hi Russell.
>
> On Sun, Mar 29, 2020 at 11:19:10AM +0100, Russell King wrote:
> > Globally update my email address in six files scattered through the
> > tree.
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/armada/
Hi Russell
On Mon, Mar 30, 2020 at 08:33:46PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Mar 30, 2020 at 08:04:44PM +0200, Sam Ravnborg wrote:
> > Hi Russell.
> >
> > On Sun, Mar 29, 2020 at 11:19:10AM +0100, Russell King wrote:
> > > Globally update my email address in six files scat
On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote:
> On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote:
> > This is a giant CC list.
>
> Yes, this is because I received feedback [1] on an earlier patchset
> directing me to add the reviewers of patches to the cover lett
On Mon, 30 Mar 2020, adrian61 wrote:
Hello Adrian,
I am testing hese changes on my STM32F769-DISCO and i found
that:
On Mon, Mar 30, 2020 at 2:35 PM Adrian Ratiu
wrote:
In order to support multiple versions of the Synopsis MIPI DSI
host controller, which have different register layouts
On Tue, Mar 17, 2020 at 02:10:49PM +0100, Mauro Carvalho Chehab wrote:
> The name of the devicetree directory is wrong on those three
> TI bindings:
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml | 2 +-
> Documentation/devicetree/
On Mon, 30 Mar 2020, adrian61 wrote:
Hello Adrian,
Here i get a compile error:
I neglected to test with CONFIG_DEBUG_FS, oops!
Will fix in v6, thanks!
On Mon, Mar 30, 2020 at 2:36 PM Adrian Ratiu wrote:
The Synopsis MIPI DSI v1.01 host controller is quite widely used
on platforms like
On Mon, 30 Mar 2020, Fabio Estevam wrote:
Hi Adrian,
On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
wrote:
This adds support for the Synopsis DesignWare MIPI DSI v1.01
host controller which is embedded in i.MX 6 SoCs.
Based on following patches, but updated/extended to work with
existing
On Mon, 30 Mar 2020, Ezequiel Garcia
wrote:
Hello Fabio, Adrian:
On Mon, 2020-03-30 at 08:49 -0300, Fabio Estevam wrote:
Hi Adrian, On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
wrote:
> This adds support for the Synopsis DesignWare MIPI DSI v1.01
> host controller which is embedded in i.M
I am glad that my explanation of vblanks made sense! Some comments below on
things I think we could improve here
On Mon, 2020-03-30 at 20:57 +0200, Sam Ravnborg wrote:
> Lyude Paul wrote a very good intro to vblank here:
>
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f
On Mon, 30 Mar 2020 15:03:55 -0700
"John B. Wyatt IV" wrote:
> On Mon, 2020-03-30 at 19:40 +0200, Stefano Brivio wrote:
> > On Sun, 29 Mar 2020 12:37:18 +0200 (CEST)
> > Julia Lawall wrote:
> >
> > > On Sun, 29 Mar 2020, Soumyajit Deb wrote:
> > >
> > > > I had the same doubt the other day
On Fri, 20 Mar 2020 12:21:34 +0100, Pascal Roeleven wrote:
> Topwise Communication Co,. Ltd. is a company based in Shenzhen. They
> manufacture all kind of products but seem to be focusing on POS nowadays.
>
> Signed-off-by: Pascal Roeleven
> ---
> Documentation/devicetree/bindings/vendor-prefix
On Fri, 20 Mar 2020 12:21:35 +0100, Pascal Roeleven wrote:
> Add the bindings for Topwise A721 tablet
>
> Signed-off-by: Pascal Roeleven
> ---
> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
Acked-by: Rob Herring
__
@Jani @Ville, this is the one we had discussed on IRC, could you
take a look at this patch?
Manasi
On Tue, Mar 24, 2020 at 06:22:01PM -0700, Manasi Navare wrote:
> From: Aditya Swarup
>
> This function sets the VRR property for connector based
> on the platform support, EDID monitor range and D
Hi Alex,
On 2020-03-30 15:23, Alex Deucher wrote:
> On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
> wrote:
>> Hi
>>
>> On 2020-03-27 10:10, Marek Szyprowski wrote:
>>> Hi Christian,
>>>
>>> On 2020-03-27 09:11, Christian König wrote:
Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
> On
Hi,
just a few more nits below.
Am 30.03.20 um 23:51 schrieb Lyude Paul:
> I am glad that my explanation of vblanks made sense! Some comments below on
> things I think we could improve here
>
> On Mon, 2020-03-30 at 20:57 +0200, Sam Ravnborg wrote:
>> Lyude Paul wrote a very good intro to vblank
101 - 190 of 190 matches
Mail list logo
