On Wed, Jun 3, 2020 at 1:31 AM Thomas Zimmermann wrote:
>
> The kirin driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
>
> Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
> sets
On Wed, Jun 3, 2020 at 1:31 AM Thomas Zimmermann wrote:
>
> The kirin drivers uses drm_gem_cma_dumb_create_internal() for its
> .dumb_create implementation. The function is meant for internal use
> only by drivers that require additional buffer setup.
>
> Kirin does not do an additional setup, so
On Wed, Apr 22, 2020 at 5:23 PM Maxime Ripard wrote:
>
> Hi,
>
> On Wed, Apr 15, 2020 at 07:52:28PM +0200, Jernej Škrabec wrote:
> > Dne sreda, 15. april 2020 ob 12:42:14 CEST je Maxime Ripard napisal(a):
> > > On Mon, Apr 13, 2020 at 06:09:08PM +0200, Jernej Škrabec wrote:
> > > > Dne
Signed-off-by: Khaled Almahallawy
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/display/intel_dp.c | 40 ++---
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
Hey Dave, Daniel,
Another -fixes pull for nouveau, mostly more HDA fixes, but also a fix
for display hangs on Volta/Turing, and a GK20A regression fix.
Thanks,
Ben.
The following changes since commit 0ad679d157aa69ddf0ee46b564c9fbb646cf6d4e:
drm/nouveau/kms/gt215-: fix race with audio driver
Hi Thomas,
Thank you for the patch.
On Wed, Jun 03, 2020 at 10:31:25AM +0200, Thomas Zimmermann wrote:
> The rcar-du driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
> macro now sets these defaults and
That's a sensible change.
In your title you can use "macro" or "definition" or "macro definition".
"Define" is a verb.
"PCI: Add a macro for message-signalled interrupt types"
On 2020-06-03 7:45 a.m., Piotr Stankiewicz wrote:
> There are several places in the kernel which check/ask for MSI or
On Tue, May 19, 2020 at 11:37:01AM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
>
Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than ~540
usec, leading to MST probe failures.
According to the DP alt mode specification adapters should forward short
pulses with a duration greater than 250 usec.
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Make the locking look symmetric with the unlocking.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the
On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
>
> > > >
> > > > Actually it occurs to me that the patch consolidating kmap_prot is odd
> > > > for
> > > > sparc 32 bit...
> > > >
> > > > Its a long shot but could you try
Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than ~540
usec, leading to MST probe failures.
According to the DP alt mode specification adapters should forward short
pulses with a duration greater than 250 usec.
Currently MST on a port can get enabled/disabled from the hotplug work
and get disabled from the short pulse work in a racy way. Fix this by
relying on the MST state checking in the hotplug work and just schedule
a hotplug work from the short pulse handler if some problem happened
during the MST
Make the locking look symmetric with the unlocking.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index
On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> > >
> > > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > > sparc 32 bit...
> > >
> > > Its a long shot but could you try reverting this patch?
> > >
> > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
Hi Noralf,
On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes wrote:
>
> Den 28.05.2020 17.27, skrev Emil Velikov:
> > On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote:
> >>
> >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote:
> >>>
> >>>
> >>>
> >>> Den 24.05.2020 18.13, skrev Paul Cercueil:
Hi,
On 2020-06-03 11:12, Pekka Paalanen wrote:
> On Wed, 3 Jun 2020 10:50:28 +0530
> Yogish Kulkarni wrote:
>
>> Inline..
>>
>> On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
>>
>>> On Mon, 1 Jun 2020 09:22:27 +0530
>>> Yogish Kulkarni wrote:
>>>
Hi,
For letting DRM
Hi Maxime,
Am 27.05.20 um 17:49 schrieb Maxime Ripard:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 +++-
> arch/arm/boot/dts/bcm2711.dtsi
Hi Emil.
> >
> > I expect to have some hours for linux work friday or saturday, but no
> > promises...
> >
> Don't worry - once the DT maintainers ack 1/2, I'll merge the series.
If it is in alphabetical order then we are good to go.
For such simple patches we do not need DT maintainer ack.
You
On Thu, 4 Jun 2020 at 01:43, Emil Velikov wrote:
>
> On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > Tegra firmware doesn't actually use any version numbers and passing -1
> > causes the existing firmware binaries not to be found. Use version 0 to
> >
Den 02.06.2020 02.12, skrev Peter Stuge:
> Hi Noralf,
>
> Thanks a lot for going into more detail.
>
> Noralf Trønnes wrote:
>>> Several Linux/DRM internals have "leaked" into the USB protocol - this
>>> should be avoided if you want device implementations other than your
>>> gadget, because
TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
then all other used buffers must also be TMZ or read only. If no TMZ
buffers are used by a command buffer, then TMZ is disabled. If a context is
not secure, TMZ is also disabled. A context can switch between secure and
Looks like a nice cleanup to me. (No idea if at some point there
actually was a reason for a return value...)
Reviewed-by: Roland Scheidegger
Am 30.05.20 um 14:46 schrieb Emil Velikov:
> The function always returns zero (success). Ideally we'll remove it all
> together - although that's
Am 02.06.20 um 17:54 schrieb Maxime Ripard:
> On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
>> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote:
>>> the vc4_hdmi driver has some custom structures to hold the data it needs to
>>> associate with the drm_encoder and drm_connector
On Tue, 2 Jun 2020 at 21:57, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Tue, Jun 02, 2020 at 01:46:19PM +0100, Emil Velikov wrote:
> > On Tue, 2 Jun 2020 at 08:17, Liu Ying wrote:
> > >
> > > This patch adds support for Kaohsiung Opto-Electronics Inc.
> > > 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT
Hi all,
On Wed, 3 Jun 2020 at 10:57, Ville Syrjälä
wrote:
>
> On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote:
> > On Wed, 3 Jun 2020 10:50:28 +0530
> > Yogish Kulkarni wrote:
> >
> > > Inline..
> > >
> > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
> > >
> > > > On
Add some information about pre-atomic modeset properties alongside a
list of suggestions how to handle the different instances.
Signed-off-by: Emil Velikov
---
Documentation/gpu/todo.rst | 32
1 file changed, 32 insertions(+)
diff --git
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by
Hi! Was going through my email and found this from last month, it's a bit late
and someone might have reviewed/pushed this already but just in case:
Reviewed-by: Lyude Paul
On Wed, 2020-05-20 at 18:47 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
On Wed, Jun 3, 2020 at 6:12 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
> >>
> >>
> >>
> >> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> >>> On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi
On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
>
> From: Thierry Reding
>
> Tegra firmware doesn't actually use any version numbers and passing -1
> causes the existing firmware binaries not to be found. Use version 0 to
> find the correct files.
>
> Signed-off-by: Thierry Reding
Fixes:
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> > On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> >>> On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support
Hi Maxime,
Am 03.06.20 um 15:14 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote:
>> Am 02.06.20 um 21:31 schrieb Eric Anholt:
>>> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
>>> wrote:
Hi Maxime and Eric
On Tue, 2 Jun 2020 at
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Daniel,
>
> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> > On 27/05/2020 11:58, Lukasz Luba wrote:
> >> Add support for other devices than CPUs. The registration function
> >> does not require a valid cpumask pointer and is ready to handle
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent
From: Thierry Reding
Tegra firmware doesn't actually use any version numbers and passing -1
causes the existing firmware binaries not to be found. Use version 0 to
find the correct files.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +-
1 file changed,
On Tue, Jun 02, 2020 at 02:00:16PM +0100, Liviu Dudau wrote:
> On Tue, Jun 02, 2020 at 11:51:40AM +0200, Daniel Vetter wrote:
> > This is already taken care of by drm_atomic_helper_shutdown(), and
> > in that case only for the CRTC which are actually on.
> >
> > Only tricky bit here is that we
On Wed, Jun 03, 2020 at 01:17:14PM +, Simon Ser wrote:
> On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote:
>
> > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
> >
> > > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> > >
> > > > In update_output_state,
On Wed, Jun 03, 2020 at 01:27:55PM +, Simon Ser wrote:
> > > + * When user-space performs an atomic commit on a connector with a
> > > "BAD"
> > > + * link-status without resetting the property to "GOOD", it gets
> > > + * implicitly reset. This might make the atomic commit
On Wed, Jun 3, 2020 at 7:48 AM Piotr Stankiewicz
wrote:
>
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz
> Reviewed-by: Andy Shevchenko
> ---
>
> > + * When user-space performs an atomic commit on a connector with a
> > "BAD"
> > + * link-status without resetting the property to "GOOD", it gets
> > + * implicitly reset. This might make the atomic commit fail if the
> > modeset
> > + * is unsuccessful.
>
> I think
On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote:
> On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
>
> > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> >
> > > In update_output_state, the link-status property was reset to GOOD to
> > > ensure legacy
On Thu, May 14, 2020 at 09:30:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > Just a bit of light paranoia. Also sprinkle this check over
> > drm_gem_shmem_get_sg_table, which should only be called when
> > exporting, same for the pin/unpin functions,
On Thu, May 14, 2020 at 02:47:57PM +0200, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 09:25:18AM +0200, Thomas Zimmermann wrote:
> > Hi,
> >
> > given the upcoming removal of this file, I don't know if you really want
> > to merge this patch. If so, please see my comment on patch 6 and
>
>
On Sun, May 31, 2020 at 09:02:11AM -0700, Rob Clark wrote:
> On Thu, May 14, 2020 at 1:11 PM Daniel Vetter wrote:
> >
> > I honestly don't exactly understand what's going on here, but the
> > current code is wrong for sure: It calls dma_buf_vunmap without ever
> > calling dma_buf_vmap.
> >
> >
Den 28.05.2020 15.48, skrev Emil Velikov:
> Hi all,
>
> I realise this has landed, so a small FYI comment.
>
> On Sat, 9 May 2020 at 15:16, Noralf Trønnes wrote:
>
>> +int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct
>> drm_rect *rect)
>> +{
>> + if (!buffer
Den 28.05.2020 17.27, skrev Emil Velikov:
> On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote:
>>
>> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote:
>>>
>>>
>>>
>>> Den 24.05.2020 18.13, skrev Paul Cercueil:
Hi list,
I'd like to open a discussion about the current support
On Wed, 03 Jun 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
Up until now the assumption was that the synopsis dsi bridge
will directly connect to an encoder provided by the platform
driver,
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++---
1 file changed, 2
There are several places in the kernel which check/ask for MSI or MSI-X
interrupts. It would make sense to have a shorthand constant, similar to
PCI_IRQ_ALL_TYPES, to use in these situations. So add PCI_IRQ_MSI_TYPES,
for this purpose.
Signed-off-by: Piotr Stankiewicz
Suggested-by: Andy
The primary objective of this patch series is to change the behaviour
of pci_alloc_irq_vectors_affinity() such that it forwards the MSI-X enable
error code when appropriate. In the process, though, it was pointed out
that there are multiple places in the kernel which check/ask for message
On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> > In update_output_state, the link-status property was reset to GOOD to
> > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> > is also performed
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> In update_output_state, the link-status property was reset to GOOD to
> ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> is also performed on an atomic commit without ALLLOW_MODESET. If a
I didn't think
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> In update_output_state, the link-status property was reset to GOOD to
> ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> is also performed on an atomic commit without ALLLOW_MODESET. If a
> driver reads
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #26 from Cyrax (ev...@hotmail.com) ---
(In reply to Petteri Aimonen from comment #25)
> Looks like there are two kinds of crash bugs here. Many of the amdgpu
> crashes have been fixed in 5.7.0, but the specific one that gives "simd
>
In update_output_state, the link-status property was reset to GOOD to
ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
is also performed on an atomic commit without ALLLOW_MODESET. If a
driver reads link-status to figure out whether to re-train the link,
this could cause an
On Tue, 02 Jun 2020, Emil Velikov
wrote:
Hi Adrian,
Hi Email,
On Mon, 1 Jun 2020 at 10:14, Adrian Ratiu
wrote:
On Fri, 29 May 2020, Philippe CORNU
wrote:
> Hi Adrian, and thank you very much for the patchset. Thank
> you also for having tested it on STM32F769 and STM32MP1.
>
Hi Chanwoo,
On 01.06.2020 09:58, Chanwoo Choi wrote:
> On 5/30/20 1:32 AM, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> This patch adds interconnect support to exynos-mixer. The mixer works
>> the same as before when CONFIG_INTERCONNECT is 'n'.
>>
>> For proper operation of the
On Thursday, June 27, 2019 4:59 PM, Jani Nikula
wrote:
> On Sat, 22 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote:
>
> > On Wed, Jun 19, 2019 at 10:16 PM Jani Nikula
> > jani.nik...@linux.intel.com wrote:
> >
> > > On Wed, 19 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote:
> > >
> > > > -
On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote:
> On Wed, 3 Jun 2020 10:50:28 +0530
> Yogish Kulkarni wrote:
>
> > Inline..
> >
> > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
> >
> > > On Mon, 1 Jun 2020 09:22:27 +0530
> > > Yogish Kulkarni wrote:
> > >
> > > >
Hi Alex,
On Mon, 1 Jun 2020 at 15:25, Alex Deucher wrote:
> On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote:
> > What Weston _does_ know, however, is that display controller can work
> > with modifier set A, and the GPU can work with modifier set B, and if
> > the client can pick something
On Tue, 02 Jun 2020 19:18:15 +
Simon Ser wrote:
> Describe what a "BAD" link-status means for user-space and how it should
> handle it. The logic described has been implemented in igt [1].
>
> v2:
>
> - Change wording to avoid "enabled" (Daniel)
> - Add paragraph about multiple connectors
On 02.06.2020 10:21, Krzysztof Kozlowski wrote:
>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> +struct of_phandle_args args;
>> +int num, ret;
>> +
>> +num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>> +
On Wed, 3 Jun 2020 10:50:28 +0530
Yogish Kulkarni wrote:
> Inline..
>
> On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
>
> > On Mon, 1 Jun 2020 09:22:27 +0530
> > Yogish Kulkarni wrote:
> >
> > > Hi,
> > >
> > > For letting DRM clients to select output encoding:
> > > Sink can
On 6/2/20 4:25 PM, Christian König wrote:
Am 02.06.20 um 16:13 schrieb Nirmoy:
Hi Christian,
On 6/2/20 2:47 PM, Christian König wrote:
Nirmoy please keep in mind that your current implementation doesn't
fully solve the issue the test case is exercising.
In other words what you have
The atmel-hlcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
The kirin drivers uses drm_gem_cma_dumb_create_internal() for its
.dumb_create implementation. The function is meant for internal use
only by drivers that require additional buffer setup.
Kirin does not do an additional setup, so convert it over to
drm_gem_cma_dumb_create().
Signed-off-by:
The stm driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets
The mcde driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets
The mxsfb driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
The malidp driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
to their defaults. No functional changes are made.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
The arm driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The komeda driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver. All
remaining operations are provided by CMA GEM object functions.
By using
The tilcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
helpers. An internal version is provided for drivers that override
the default .dumb_create callback. Adapt drivers to the changes.
v2:
* provide DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
The zte driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The arc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The kirin driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
Most of the CMA-based drivers use the default implementation for the
callbacks in struct drm_driver. With this patch, these interfaces are
initialized with a common helper macro and GEM object functions replace
several deprecated interfaces.
The first patch updates the existing macro to similar
The meson driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets
The sti driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA
The fsl-dcu driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
The imx driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The ingenic driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
The shmobile driver uses the default implementation for CMA functions.
The DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct
drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
The rcar-du driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets
The .gem_print_info callback in struct drm_driver is obsolete and has
no users left. Remove it.
Signed-off-by: Thomas Zimmermann
Suggested-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 2 --
include/drm/drm_drv.h | 17 -
2 files changed, 19 deletions(-)
diff --git
The tve200 driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
https://bugzilla.kernel.org/show_bug.cgi?id=201539
v.j.du...@gmail.com changed:
What|Removed |Added
CC||v.j.du...@gmail.com
--- Comment
On Tue, Jun 02, 2020 at 08:37:31PM -0700, Jeykumar Sankaran wrote:
> drm connector notifies userspace on hotplug event prematurely before
> late_register and mode_object register completes. This leads to a race
> between userspace and kernel on updating the IDR list. So, move the
> notification to
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent
On Tue, Jun 02, 2020 at 10:00:10AM -0400, Andrey Grodzovsky wrote:
>
> On 6/1/20 10:32 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like
> > to
> > userspace.
> >
> > Written by Daniel Vetter's request and
On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote:
> > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
> > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
> > > > On
On Wed, Jun 3, 2020 at 2:19 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> May I remind you about the -v option to git-format-patch ? :-) Seriously
> speaking, it really helps review.
>
> On Tue, Jun 02, 2020 at 11:51:38AM +0200, Daniel Vetter wrote:
> > Only when
Hi
Am 25.05.20 um 17:38 schrieb Kieran Bingham:
> On 25/05/2020 13:49, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.05.20 um 22:12 schrieb Laurent Pinchart:
>>> Hi Thomas,
>>>
>>> Thank you for the patch.
>>>
>>> On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
The rcar-du
On Wed, Jun 3, 2020 at 9:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.06.20 um 23:56 schrieb Linus Torvalds:
> > On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds
> > wrote:
> >>
> >> I'm still working through the rest of the merge, so far that was the
> >> only one that made me go "Whaa?".
> >
>
Hi
Am 02.06.20 um 23:56 schrieb Linus Torvalds:
> On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds
> wrote:
>>
>> I'm still working through the rest of the merge, so far that was the
>> only one that made me go "Whaa?".
>
> Hmm. I'm also ending up effectively reverting the drm commit
>
Hi,
Noralf Trønnes writes:
>> I missed this completely until now.
>> Noralf Trønnes writes:
>>> This adds the gadget side support for the Generic USB Display. It presents
>>> a DRM display device as a USB Display configured through configfs.
>>>
>>> The display is implemented as a vendor type
1 - 100 of 120 matches
Mail list logo
