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:
>
@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
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
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
> ---
>
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
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:
>
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
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
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
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
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 +-
>
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
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
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
> > ---
> >
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
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
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
> -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
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
>
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
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
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
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
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'
> >
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 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
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,
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
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
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
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
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
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
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 +-
>
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
---
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
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
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
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(+)
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
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
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
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
---
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
---
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
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
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
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
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
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
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
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
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
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
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 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)
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
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
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
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
> >>>
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
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
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
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
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:
>
>
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
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
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 ++-
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
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
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
>-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
https://bugzilla.kernel.org/show_bug.cgi?id=207005
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
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
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:
>
>
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
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
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
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=1
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
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
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
On Mon, Mar 30, 2020 at 8:35 AM Adrian Ratiu wrote:
> +panel@0 {
> +compatible = "sharp,ls032b3sx01";
> +reg = <0>;
> +reset-gpios = < 8 GPIO_ACTIVE_LOW>;
> +ports {
> +port@0 {
There is a unit address here without a
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:
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
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 Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
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: imx: Support Synopsys DesignWare MIPI DSI host controller
Signed-off-by: Liu
Hello everyone,
The v5 series is a significantly cleaned up version from v4,
started by Ezequiel Garcia's suggestion of splitting out the
regmap infrastructure from the drivers (thank you!).
Turns out no changes are required to the existing drivers and
the bridge can transparently take care of
Register existence, address/offsets, field layouts, reserved bits and
so on differ between MIPI-DSI versions and between SoC vendor boards.
Despite these differences the hw IP and protocols are mostly the same
so the generic bridge can be made to compensate these differences.
The current Rockchip
In order to support multiple versions of the Synopsis MIPI DSI host
controller, which have different register layouts but almost identical
HW protocols, we add a regmap infrastructure which can abstract away
register accesses for platform drivers using the bridge.
The controller HW revision is
The Synopsis MIPI DSI v1.01 host controller is quite widely used
on platforms like i.mx6 and is not very different from the other
versions like the 1.31/1.30 used on rockchip/stm. The protocols
appear to be the same, only the register layout is different and
the newer versions have new features
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 wrote a very good intro to vblank here:
>
On Mon, Mar 30, 2020 at 12:29:44PM +0200, Sam Ravnborg wrote:
> On Sat, Mar 28, 2020 at 11:02:26PM +0100, Daniel Vetter wrote:
> > On Sat, Mar 28, 2020 at 7:49 PM Sam Ravnborg wrote:
> > >
> > > Hi Daniel.
> > >
> > > On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> > > > I'm
On Sat, Mar 28, 2020 at 11:02:26PM +0100, Daniel Vetter wrote:
> On Sat, Mar 28, 2020 at 7:49 PM Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> > > I'm thinking this is the warning that fired in the 0day report, but I
> > > can't
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
Ok 0day people uploaded the tree they tested (from patches) now, I
confirmed it's indeed this line that's blowing up.
-Daniel
On Sat, Mar 28, 2020 at 5:24 PM Daniel Vetter wrote:
>
> I'm thinking this is the warning that fired in the 0day report, but I
> can't double-check yet since 0day didn't
1 - 100 of 189 matches
Mail list logo
