Dave, Daniel
Some minor fixes and a maintainer change.
The following changes since commit 24085f70a6e1b0cb647ec92623284641d8270637:
Merge tag 'trace-v5.7-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2020-05-12
11:06:26 -0700)
are available in the Git
From: Roland Scheidegger
Maintainer switch from Thomas Hellstrom to Roland Scheidegger
Reviewed-by: Charmaine Lee
Reviewed-by: Neha Bhende
Acked-by: Thomas Hellstrom
Signed-off-by: Roland Scheidegger
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Mon, May 4, 2020 at 9:32 PM Douglas Anderson wrote:
>
> If the rate in our table is _equal_ to the rate we want then it's OK
> to pick it. It doesn't need to be greater than the one we want.
>
> Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
> Signed-off-by:
On Fri, May 8, 2020 at 4:33 PM Douglas Anderson wrote:
>
> The AUX channel transfer error bits in the status register are latched
> and need to be cleared. Clear them before doing our transfer so we
> don't see old bits and get confused.
>
> Without this patch having a single failure would mean
On Wed, May 6, 2020 at 2:03 PM Douglas Anderson wrote:
>
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> remapping of eDP lanes and also polarity inversion. Both of these
> features have been described in the device tree bindings for the
> device since the beginning but were
Hi all.
i
...
> Sam Ravnborg (18):
> drm/omap: display: use devm_of_find_backlight
> drm/tilcdc: use devm_of_find_backlight
Tomi - thanks for the prompt review of the above two patches.
> video: amba-clcd: use devm_of_find_backlight
Any takes for review/ack of this patch?
>
Hi myself and others.
On Thu, May 14, 2020 at 09:09:49PM +0200, Sam Ravnborg wrote:
> There are no external users of of_find_backlight_by_node().
> Make it static so we keep it that way.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
>
Quoting Arnd Bergmann (2020-04-28 22:30:50)
> After the function is no longer marked 'inline', there
> is now a new warning pointing out that the only caller
> is inside of an #ifdef:
>
> drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning:
> 'scale_user_to_hw' defined but not used
Hi,
On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote:
>
> This patch simply adds a new compatible string for SC7180 platform.
>
> Signed-off-by: Sharat Masetty
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Fri, 1 May 2020 17:37:55 +0200
Mauro Carvalho Chehab wrote:
> There are a number of random documents that seem to be
> describing some aspects of the core-api. Move them to such
> directory, adding them at the core-api/index.rst file.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
The pull request you sent on Fri, 15 May 2020 16:12:52 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e7cea7905815ac938e6e90b0cb6b91bcd22f6a15
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Ville,
Thank you for notifying me that. I definitely missed the crash.
Sorry for that.
Danial and Jani, I' under debugging the crash case.
If you are availabe please do not merge current version.
Br,
G.G.
>
On Fri, 2020-05-15 at 16:14 +0200, Daniel Vetter wrote:
> On Fri, May 15, 2020 at
Hi,
On Fri, May 15, 2020 at 5:06 AM wrote:
>
> On 2020-05-14 21:47, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 1, 2020 at 6:31 AM Kalyan Thota
> > wrote:
> >>
> >> "The PM core always increments the runtime usage counter
> >> before calling the ->suspend() callback and decrements it
> >>
04-30 11:13:21 +0300)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-05-15
for you to fetch changes up to 3a36aa237e4ed04553c0998cf5f47eda3e206e4f:
drm/i915: Update DRIVER_DATE to 20200515 (2020-
Hi Stephen,
On 23/04/2020 06:17, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen
> wrote:
>>
>> On 21/04/2020 04:52, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc
>>> tree with the
On 15/05/2020 10:50, Emil Velikov wrote:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Add helper, which will allow us to transition the
On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Changes in v6:
> -Rebased on -tip
> -Disabled HDCP over MST on GEN12
> -Addressed Lyude's review comments in the QUERY_STREAM_ENCRYPTION_STATUS patch
Sean,
What is the test setup you have used?
I am afraid our CI dont
On 2020-04-29 at 15:55:02 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> support is the same as the DP case, so we'll re-use those callbacks
>
> Cc:
Hi Bernard,
On Fri, May 08, 2020 at 04:47:17PM +0800, Bernard wrote:
> From: "赵军奎"
> Date: 2020-04-24 19:37:36
> To: Liviu Dudau
> Cc: Brian Starkey ,David Airlie
> ,Daniel Vetter
> ,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
> Subject: Re:Re:
On Fri, May 15, 2020 at 10:51:14AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
On Fri, May 15, 2020 at 10:51:16AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: perjantai 15. toukokuuta 2020 16.13
> To: Ville Syrjälä
> Cc: linux-fb...@vger.kernel.org; daniel.vet...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>
On Fri, May 15, 2020 at 10:50:50AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> With earlier patch we removed the overhead so now we can lift the helper
> into the header effectively folding it with __drm_object_put.
>
> v2: drop struct_mutex references (Daniel)
>
> Signed-off-by: Emil
On Fri, May 15, 2020 at 10:50:49AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> No drivers set the callback, so remove it all together.
>
> Signed-off-by: Emil Velikov
> Acked-by: Sam Ravnborg
> Reviewed-by: Thomas Zimmermann
If I've read your series correctly I think you've missed
Hello!
Registration & Call for Proposals are now open for XDC 2020, which will
take place at the Gdańsk University of Technology in Gdańsk, Poland on
September 16-18, 2020.
Thanks to LWN.net for hosting the website again this year!
https://xdc2020.x.org
As usual, the conference is
On Fri, May 15, 2020 at 04:13:18PM +0300, Jani Nikula wrote:
> On Fri, 15 May 2020, Ville Syrjälä wrote:
> > On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> >> On Thu, 14 May 2020, Gwan-gyeong Mun wrote:
> >> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
>
On Fri, May 15, 2020 at 08:58:02AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 14.05.20 um 22:36 schrieb Rob Herring:
> > On Thu, May 14, 2020 at 7:40 AM Daniel Vetter wrote:
> >>
> >> On Wed, May 13, 2020 at 05:03:11PM +0200, Thomas Zimmermann wrote:
> >>> SHMEM-buffer backing storage is
On Fri, May 15, 2020 at 04:51:53PM +0300, Ville Syrjälä wrote:
> On Fri, May 15, 2020 at 03:36:13PM +0200, Daniel Vetter wrote:
> > Hi all,
> >
> > Maxime seems to have a need for a bit more than what the current
> > drm_mode_config_reste can do, so here's a bunch of ideas inspired by
> > i915.
>
On Fri, May 15, 2020 at 02:55:38PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 28, 2020 at 03:15:12PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Mon, Apr
On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote:
> On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote:
> > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> > > Sorry for the duplicate reply, didn't notice this until now.
> > >
> > > > Just storing
> > > > the uuid
On Fri, May 15, 2020 at 03:36:13PM +0200, Daniel Vetter wrote:
> Hi all,
>
> Maxime seems to have a need for a bit more than what the current
> drm_mode_config_reste can do, so here's a bunch of ideas inspired by
> i915.
>
> I think minimally what you need is a drm_atomic_state_helper_readout()
Hi Ben,
On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> Hi all, any feedback on this patch?
> Thanks, Ben
> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
> > DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
> > block-linear memory layouts. The format is
Hi all,
Maxime seems to have a need for a bit more than what the current
drm_mode_config_reste can do, so here's a bunch of ideas inspired by
i915.
I think minimally what you need is a drm_atomic_state_helper_readout()
functions, which instead of resetting, allocates all the obj->state
pointers
On Fri, 15 May 2020, Ville Syrjälä wrote:
> On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
>> On Thu, 14 May 2020, Gwan-gyeong Mun wrote:
>> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
>> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
This will be handled via the mux-input-bridge.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/Kconfig | 1 -
drivers/gpu/drm/bridge/nwl-dsi.c | 61
2 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig
This bridge allows to select the input source
via a mux controller. The input source is
determined via DT but it could become rutime
selectable in the future.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/Kconfig | 9 ++
drivers/gpu/drm/bridge/Makefile| 1 +
The bridge allows to select the input source via a mux controller.
Signed-off-by: Guido Günther
---
.../display/bridge/mux-input-bridge.yaml | 123 ++
1 file changed, 123 insertions(+)
create mode 100644
Add a node for the Northwestlogic MIPI DSI IP core, "disabled" by
default.
Signed-off-by: Guido Günther
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
No need to encode the SoC specifics in the bridge driver. For the
imx8mq we can use the mux-input-bridge.
Signed-off-by: Guido Günther
---
.../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 --
1 file changed, 6 deletions(-)
diff --git
This bridge driver allows to select the input to a downstream bridge (or panel)
via device tree.
It can be useful to separate the pixel source selection from the actual bridge
processing the pixel data. E.g. NXP's imx8mq has two display controllers. Both
can feed the pixel data to the NWL DSI IP
Enable MIPI LCD panel output by adding nodes for the NWL DSI host
controller, the mux-input-bridge, the Rocktech panel and the eLCDIF
display controller.
Signed-off-by: Guido Günther
---
.../dts/freescale/imx8mq-librem5-devkit.dts | 81 +++
1 file changed, 81 insertions(+)
On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> On Thu, 14 May 2020, Gwan-gyeong Mun wrote:
> > 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
On Wed, May 13, 2020 at 02:40:29PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/dp_mst: Fix timeout handling of MST down messages
> URL : https://patchwork.freedesktop.org/series/77216/
> State : success
Patch pushed to drm-misc-next, thanks for the review.
>
> == Summary
On Tue, Apr 28, 2020 at 03:15:12PM +0200, Daniel Vetter wrote:
> On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 3, 2020
On Wed, May 13, 2020 at 10:43:41PM +0100, Emil Velikov wrote:
> Export a pointer to the sysrq_get_key_op(). This way we can cleanly
> unregister it, instead of the current solutions of modifuing it inplace.
>
> Since __sysrq_get_key_op() is no longer used externally, let's make it
> a static
On 15/05/2020 10:51, Emil Velikov wrote:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
On 15/05/2020 10:50, Emil Velikov wrote:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
On 15/05/2020 10:50, Emil Velikov wrote:
From: Emil Velikov
Vast majority of DRM (core and drivers) are struct_mutex free.
As such we have only a handful of cases where the locked helper should
be used. Make that stand out a little bit better.
Done via the following script:
On 2020-04-29 at 15:54:54 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch is required for HDCP over MST. If a port is being used for
> multiple HDCP streams, we don't want to fully disable HDCP on a port if
> one of them is disabled. Instead, we just disable the HDCP signalling on
>
Hi,
I have reviewed some of these patches. For the rest of the series you
can add
Acked-by: Thomas Zimmermann
Best regards
Thomas
Am 15.05.20 um 11:50 schrieb Emil Velikov:
> Hi all,
>
> Here is v2 of the series, with the requested minor tweaks.
>
> - Add new WARNING in the struct_mutex
On 14/05/2020 22:09, Sam Ravnborg wrote:
Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: Sam Ravnborg
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c |
On 14/05/2020 22:09, Sam Ravnborg wrote:
Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: Sam Ravnborg
Cc: Tomi Valkeinen
Cc: Zheng Bin
Cc: Kate Stewart
Cc: Enrico Weigelt
Cc:
Hi Emil
Am 15.05.20 um 11:50 schrieb Emil Velikov:
> From: Emil Velikov
>
> Vast majority of DRM (core and drivers) are struct_mutex free.
>
> As such we have only a handful of cases where the locked helper should
> be used. Make that stand out a little bit better.
>
> Done via the following
On Fri, May 15, 2020 at 10:51:11AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
Hi Laurentiu,
On Fri, May 15, 2020 at 02:10:13PM +0300, Laurentiu Palcu wrote:
> Hi Guido,
>
> On Fri, May 15, 2020 at 11:27:19AM +0200, Guido Günther wrote:
> > Hi Laurentiu,
> > On Fri, Mar 06, 2020 at 02:49:26PM +0200, Laurentiu Palcu wrote:
> > > From: Laurentiu Palcu
> > >
> > > This adds
Hi Guido,
On Fri, May 15, 2020 at 11:27:19AM +0200, Guido Günther wrote:
> Hi Laurentiu,
> On Fri, Mar 06, 2020 at 02:49:26PM +0200, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities
Am Fr., 15. Mai 2020 um 12:33 Uhr schrieb Lucas Stach :
>
> Am Freitag, den 15.05.2020, 12:27 +0200 schrieb Christian Gmeiner:
> > Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach
> > :
> > > Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > > > Hi Christian,
> > > >
> > > >
On Fri, May 15, 2020 at 11:11:57AM +0100, Emil Velikov wrote:
> On Thu, 14 May 2020 at 12:21, Rafael J. Wysocki wrote:
> >
> > On Wed, May 13, 2020 at 11:46 PM Emil Velikov
> > wrote:
> > >
> > > With earlier commits, the API no longer discards the const-ness of the
> > > sysrq_key_op. As such
Am Freitag, den 15.05.2020, 12:27 +0200 schrieb Christian Gmeiner:
> Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach
> :
> > Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > > Hi Christian,
> > >
> > > Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> > > a écrit :
> > >
Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach :
>
> Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> > a écrit :
> > > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > > :
> > > > The
Hi Paul
Am Fr., 15. Mai 2020 um 12:12 Uhr schrieb Paul Cercueil :
>
> Hi Christian,
>
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > :
> >>
> >> The GC860 has one GPU device which has a 2d and 3d core. In this
>
Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> Hi Christian,
>
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > :
> > > The GC860 has one GPU device which has a 2d and 3d core. In this
> > > case
Am Freitag, 15. Mai 2020, 11:51:10 CEST schrieb Emil Velikov:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
On Fri, May 15, 2020 at 10:51:08AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
On Fri, May 15, 2020 at 10:51:15AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the
On Thu, 14 May 2020 at 12:21, Rafael J. Wysocki wrote:
>
> On Wed, May 13, 2020 at 11:46 PM Emil Velikov
> wrote:
> >
> > With earlier commits, the API no longer discards the const-ness of the
> > sysrq_key_op. As such we can add the notation.
> >
> > Cc: Greg Kroah-Hartman
> > Cc: Jiri Slaby
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index acb26c6..89e293b 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -63,10 +63,9 @@ static struct sg_table *get_sg_table(struct device *dev,
> struct dma_buf *buf,
>
On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>
Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
:
>
> The GC860 has one GPU device which has a 2d and 3d core. In this case
> we want to expose perfmon information for both cores.
>
> The driver has one array which contains all possible perfmon domains
> with some meta data -
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
With earlier patch we removed the overhead so now we can lift the helper
into the header effectively folding it with __drm_object_put.
v2: drop struct_mutex references (Daniel)
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1)
Reviewed-by: Daniel Vetter
---
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
The comment that struct_mutex must be held is misleading. It is only
required when .gem_free_object() is used.
Since that one is going with the next patches, drop the reference.
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
---
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
The driver does not hold struct_mutex, thus using the locked version of
the helper is incorrect.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9"):
Signed-off-by: Emil Velikov
From: Emil Velikov
As of last commit, all the drivers have been updated away from the
_unlocked helper. As such we can now remove the transient #define.
v2: keep sed and #define removal separate
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1)
---
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Add helper, which will allow us to transition the drivers one by one,
dropping the suffix.
From: Emil Velikov
Vast majority of DRM (core and drivers) are struct_mutex free.
As such we have only a handful of cases where the locked helper should
be used. Make that stand out a little bit better.
Done via the following script:
__from=drm_gem_object_put
__to=drm_gem_object_put_locked
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.
Just drop the suffix. It makes the API cleaner.
Done via the following script:
From: Emil Velikov
No drivers set the callback, so remove it all together.
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem.c | 22 +++---
include/drm/drm_drv.h | 8
include/drm/drm_gem.h | 5
1 - 100 of 188 matches
Mail list logo
