On 27/02/2020 19:08, Enric Balletbo i Serra wrote:
> The mmsys system controller is not only a pure clock controller, so
> update the binding documentation to reflect that apart from providing
> clocks, it also provides routing and miscellaneous control registers.
>
> Signed-off-by: Enric
On 2020-02-27 at 13:56:58 -0500, Sean Paul wrote:
> From: Sean Paul
>
> De-duplicate the HDCP version code and print it for all connectors.
>
> Cc: Juston Li
> Signed-off-by: Sean Paul
>
> Changes in v4:
> - Added to the set
> ---
> .../drm/i915/display/intel_display_debugfs.c| 17
On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > The good news: gitlab.fd.o has become very popular
Hi Daniel
Am 27.02.20 um 19:15 schrieb Daniel Vetter:
> There's only two functions called from that:
> drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
> also called from the ubs_driver->disconnect hook, so entirely
> pointless to do the same again in the ->release hook.
The
Hi Daniel
Am 27.02.20 um 19:14 schrieb Daniel Vetter:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's not also possible that (at least for
Hi Wambui,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linus/master v5.6-rc3 next-20200227]
[cannot apply to tegra/for-next anholt/for-next]
[if your patch is applied to the wrong git tree, please drop us a note
Hi Sam
Am 27.02.20 um 21:45 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, Feb 25, 2020 at 02:10:55PM +0100, Thomas Zimmermann wrote:
>> The qxl driver uses an empty implementation for its encoder. Replace
>> the code with the generic simple encoder.
>>
>> v2:
>> * rebase onto new
> 2020年2月28日 13:45，panxinhui 写道：
>
>
>
>> 2020年2月26日 03:11，Koenig, Christian 写道：
>>
>> Am 25.02.20 um 18:23 schrieb Daniel Vetter:
>>> On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote:
Am 23.02.20 um 12:56 schrieb Pan, Xinhui:
> If shared fence list is not empty,
The pull request you sent on Fri, 28 Feb 2020 15:22:04 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-02-28
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/45d0b75b98bf1de4b3a5b09188c75f3bfa3152b0
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Jitao.
On Fri, Feb 28, 2020 at 01:21:25PM +0800, Jitao Shi wrote:
> Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
> the dpi pins to gpio mode and output-low to avoid leakage current when dpi
> disabled.
>
> Signed-off-by: Jitao Shi
> ---
>
> -Original Message-
> From: Daniel Stone
> Sent: 25 February 2020 13:00
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: Jani Nikula ; Daniel Vetter
> ; intel-gfx ; dri-devel
> ; Ville Syrjälä
> ; David Airlie ; Maarten
> Lankhorst ; tzimmerm...@suse.de;
> Maxime Ripard ;
> 2020年2月26日 03:11，Koenig, Christian 写道：
>
> Am 25.02.20 um 18:23 schrieb Daniel Vetter:
>> On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote:
>>> Am 23.02.20 um 12:56 schrieb Pan, Xinhui:
If shared fence list is not empty, even we want to test all fences, excl
fence
Changes since v9:
- rename pinctrl-names = "gpiomode", "dpimode" to "active", "idle".
- fix some typo.
Changes since v8:
- drop pclk-sample redefine in mediatek,dpi.txt
- only get the gpiomode and dpimode when dpi->pinctrl is successful.
Changes since v7:
- separate dt-bindings to
Add property "pclk-sample" to config the dpi sample on falling (0),
rising (1), both falling and rising (2).
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.
Reviewed-by: CK Hu
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
Hey Linus,
Just some fixes for this week, amdgpu, radeon and i915. The main i915
one is a regression Gen7 (Ivybridge/Haswell), this moves them back
from trying to use the full-ppgtt support to the aliasing version it
used to use due to gpu hangs. Otherwise it's pretty quiet.
Dave.
Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
the dpi pins to gpio mode and output-low to avoid leakage current when dpi
disabled.
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 7 +++
1 file changed, 7 insertions(+)
Some chips's sample mode are rising, falling and dual edge (both
falling and rising edge).
Extern the pclk-sample property to support dual edge.
Acked-by: Rob Herring
Reviewed-by: CK Hu
Signed-off-by: Jitao Shi
---
Documentation/devicetree/bindings/media/video-interfaces.txt | 4 ++--
1 file
Config dpi pins mode to output and pull low when dpi is disabled.
Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 31 ++
1 file changed, 31 insertions(+)
diff --git
> -Original Message-
> From: Jani Nikula
> Sent: 27 February 2020 14:00
> To: Laxminarayan Bharadiya, Pankaj
> ; Chris Wilson wilson.co.uk>
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; David
> Airlie
> ; Joonas Lahtinen ; Vivi,
> Rodrigo ; dan...@ffwll.ch
>
On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially
On Wed, Feb 26, 2020 at 11:23 PM Gerd Hoffmann wrote:
>
> On Wed, Feb 26, 2020 at 04:25:53PM -0800, Gurchetan Singh wrote:
> > The main motivation behind this is to have eventually have something like
> > this:
> >
> > struct virtio_gpu_shmem {
> > struct drm_gem_shmem_object base;
> >
On 02/27/2020 05:00 PM, Tom Stellard wrote:
> On 02/27/2020 01:27 PM, Daniel Vetter wrote:
>> Hi all,
>>
>> You might have read the short take in the X.org board meeting minutes
>> already, here's the long version.
>>
>> The good news: gitlab.fd.o has become very popular with our
>> communities,
On 02/27/2020 01:27 PM, Daniel Vetter wrote:
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes
On Thu, Feb 27, 2020 at 01:54:33PM -0800, Matthias Kaehlcke wrote:
> On Mon, Dec 02, 2019 at 01:48:57PM +, Chandan Uddaraju wrote:
> > Add the needed displayPort files to enable DP driver
> > on msm target.
> >
> > "dp_display" module is the main module that calls into
> > other sub-modules.
On Thu, Feb 27, 2020 at 10:27:04PM +0100, Daniel Vetter wrote:
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
between commits:
ea702333e567 ("drm/amdgpu: Convert to struct
drm_crtc_helper_funcs.get_scanout_position()")
e3eff4b5d91e ("drm/amdgpu: Convert to CRTC VBLANK callbacks")
from
On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially
On Thu, 2020-02-27 at 13:56 -0500, Sean Paul wrote:
> From: Sean Paul
>
> De-duplicate the HDCP version code and print it for all connectors.
>
> Cc: Juston Li
> Signed-off-by: Sean Paul
>
> Changes in v4:
> - Added to the set
LGTM, thanks for adding this!
Reviewed-by: Juston Li
> ---
>
On Mon, Dec 02, 2019 at 01:48:27PM +, Chandan Uddaraju wrote:
> Add the needed DP PLL specific files to support
> display port interface on msm targets.
>
> The DP driver calls the DP PLL driver registration.
> The DP driver sets the link and pixel clock sources.
>
> Changes in v2:
> --
Hi Tony,
On Mon, Feb 24, 2020 at 03:47:59PM -0800, Tony Lindgren wrote:
> * Laurent Pinchart [200224 23:38]:
> > On Tue, Feb 25, 2020 at 12:20:32AM +0100, Sebastian Reichel wrote:
> > > Add Droid 4 specific compatible value in addition to the
> > > generic one, so that we have the ability to add
Hi Sebastian,
Thank you for the patch.
On Thu, Feb 27, 2020 at 09:35:21PM +0100, Sam Ravnborg wrote:
> On Tue, Feb 25, 2020 at 12:53:41PM +0100, Sebastian Reichel wrote:
> > Convert panel-dsi-cm bindings to YAML and add
> > missing properties while at it.
> >
> > Signed-off-by: Sebastian
On Mon, Dec 02, 2019 at 01:48:57PM +, Chandan Uddaraju wrote:
> Add the needed displayPort files to enable DP driver
> on msm target.
>
> "dp_display" module is the main module that calls into
> other sub-modules. "dp_drm" file represents the interface
> between DRM framework and DP driver.
>
On Thu, 27 Feb 2020 13:38:03 -0800 Cong Wang wrote:
> On Tue, Feb 25, 2020 at 5:54 PM Andrew Morton
> wrote:
> >
> > On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang
> > wrote:
> >
> > > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set
> > > it never gets freed.
> > >
> > > Free
Hi all,
You might have read the short take in the X.org board meeting minutes
already, here's the long version.
The good news: gitlab.fd.o has become very popular with our
communities, and is used extensively. This especially includes all the
CI integration. Modern development process and
On Thu, Feb 27, 2020 at 07:14:44PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
> everything through a drm_dev_put. Rework the unwind code to match
> that.
>
> Signed-off-by:
On Thu, Feb 27, 2020 at 07:14:40PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> I also noticed that cirrus forgot to call drm_dev_fini().
>
> v2: Don't call kfree(cirrus) after we've handed overship of that to
> drm_device and the drmm_
On Thu, Feb 27, 2020 at 07:14:37PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> v2: We need drm_dev_put to unroll the driver creation (once
> drm_dev_init and drmm_add_final_kfree suceeded), otherwise
> the drmm_ magic doesn't happen.
>
> v3:
On Thu, Feb 27, 2020 at 07:14:36PM +0100, Daniel Vetter wrote:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi
Hi Daniel.
Nicely written overview.
Acked-by: Sam Ravnborg
snip - detailed changelog + patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Thomas.
On Tue, Feb 25, 2020 at 02:10:55PM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
>
On Tue, Feb 25, 2020 at 02:10:54PM +0100, Thomas Zimmermann wrote:
> The mgag200 driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v3:
> * init pre-allocated encoder with drm_simple_encoder_init()
> v2:
> * rebase onto new
On Tue, Feb 25, 2020 at 02:10:52PM +0100, Thomas Zimmermann wrote:
> This patch makes the internal encoder implementation of the simple
> KMS helpers available to drivers.
>
> These simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the requirements of most
On Wed, Feb 26, 2020 at 3:46 AM Kevin Tang wrote:
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> Cc: Orson Zhai
> Cc: Baolin Wang
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
Hi Sebastian.
On Tue, Feb 25, 2020 at 12:53:41PM +0100, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Signed-off-by: Sebastian Reichel
As saind in previous mail - I prefer to convert ann then patch.
But end result is the same so
On Tue, Feb 25, 2020 at 12:20:32AM +0100, Sebastian Reichel wrote:
> Add Droid 4 specific compatible value in addition to the
> generic one, so that we have the ability to add panel
> specific quirks in the future.
>
Yes, exactly as explained in previous mail. Thanks.
> Signed-off-by: Sebastian
Hi Sebastian.
On Tue, Feb 25, 2020 at 12:20:31AM +0100, Sebastian Reichel wrote:
> The standard binding for DSI requires, that the channel number
> of the panel is encoded in DT. This adds the channel number in
> all OMAP3-5 boards, in preparation for using common infrastructure.
>
>
Hi Harry
Ok, back from various other emergencies and deadlines, sorry for the
late reply. I also fixed my e-mail address - it was mistyped, causing
all these delivery failures :/
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
> On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
> > On Thu,
Hi,
On 2/27/20 7:15 PM, Daniel Vetter wrote:
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
Hi,
Thanks for the patch.
I reviewed and tested this patch, and everything looks fine.
Reviewed-by: Rodrigo Siqueira
Tested-by: Rodrigo Siqueira
On 02/27, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> v2: After drm_dev_init/drmm_add_final_kfree
From: Sean Paul
De-duplicate the HDCP version code and print it for all connectors.
Cc: Juston Li
Signed-off-by: Sean Paul
Changes in v4:
- Added to the set
---
.../drm/i915/display/intel_display_debugfs.c| 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff
> -Original Message-
> From: amd-gfx On Behalf Of Liu,
> Zhan
> Sent: 2020/February/27, Thursday 1:40 PM
> To: Melissa Wen ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
> ; Rodrigo Siqueira
On Tue, Jan 28, 2020 at 03:00:14PM -0700, Jordan Crouse wrote:
> This is another iteration for the split pagetable support based on the
> suggestions from Robin and Will [1].
>
> Background: In order to support per-context pagetables the GPU needs to enable
> split tables so that we can store
Hi,
On 2/27/20 7:41 PM, Lyude Paul wrote:
hi - I almost certainly know the solution to this, the patches that we got
from amd to do bandwidth checking in the DP MST helpers don't actually work
correctly in a lot of cases and I need to fix them. I've just been busy on PTO
and only just got back
On Thu, 2020-02-27 at 10:04 -0500, Mikita Lipski wrote:
>
> On 2/26/20 6:41 PM, Souza, Jose wrote:
> > Hi Hans
> >
> > Just commenting in the "[3.309061] [drm:intel_dump_pipe_config
> > [i915]] MST master transcoder: " message, it is the expected
> > behaviour for anything older than
hi - I almost certainly know the solution to this, the patches that we got
from amd to do bandwidth checking in the DP MST helpers don't actually work
correctly in a lot of cases and I need to fix them. I've just been busy on PTO
and only just got back today, and have been busy with fixing a lot
> -Original Message-
> From: amd-gfx On Behalf Of
> Melissa Wen
> Sent: 2020/February/26, Wednesday 5:08 PM
> To: Wentland, Harry ; Li, Sun peng (Leo)
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
> ; Rodrigo Siqueira
> Cc:
Hi Rodrigo,
On 02/27, Rodrigo Siqueira wrote:
> Hi Melissa,
>
> First of all, thank you very much for this patchset; in general,
> everything looks good to me.
>
> I noticed that your patchset does not apply because you made your
> changes based on `drm-misc-next`; when you send patches to
On Thu, Feb 27, 2020 at 07:14:49PM +0100, Daniel Vetter wrote:
> These are the leftover drivers that didn't have a ->release hook that
> needed to be updated.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Russell King
> Cc: Hans de
Hi Daniel,
On 20-02-27 19:14, Daniel Vetter wrote:
> On Thu, Feb 27, 2020 at 6:44 PM Lucas Stach wrote:
> >
> > Hi Daniel,
> >
> > On Do, 2020-02-27 at 18:29 +0100, Daniel Vetter wrote:
> > > On Thu, Feb 27, 2020 at 05:21:25PM +0100, Marco Felsch wrote:
> > > > Currently there is a race
All collected together to provide a consistent story in one patch,
instead of the somewhat bumpy refactor-evolution leading to this.
Also some thoughts on what the next steps could be:
- Create a macro called devm_drm_dev_alloc() which essentially wraps
the kzalloc(); devm_drm_dev_init();
There's only two functions called from that:
drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
also called from the ubs_driver->disconnect hook, so entirely
pointless to do the same again in the ->release hook.
Furthermore by the time we clean up the drm_driver we really
The drm_mode_config_cleanup call we can drop, and all the allocations
we can switch over to drmm_kzalloc. Unfortunately the work queue is
still present, so can't get rid of the drm_driver->release function
outright.
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc:
Allows us to drop the drm_driver.release callback from all
drivers, and remove the mipi_dbi_release() function.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
tracking. If we schedule the work with a 0 delay
Also there's a race in the disconnect implemenation. First shut
down, then unplug, leaves a window where userspace could sneak
in and restart the entire machinery.
With this we can also delete the very un-atomic global pipe_enabled
tracking.
Reviewed-by: Hans de Goede
Signed-off-by: Daniel
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
It's right above the drm_dev_put().
This allows us to delete a bit of onion unwinding in
udl_modeset_init().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: This
7/7 drivers agree that's the right choice, let's do this.
This avoids duplicating the same old error checking code over all 7
drivers, which is the motivation here.
Reviewed-by: Noralf Trønnes
Tested-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc:
Nothing special here, except that this is the first time that we
automatically clean up something that's initialized with an explicit
driver call. But the cleanup was done at the very of the release
sequence for all drivers, and that's still the case. At least without
more uses of drmm_ through
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 11
Auto-unwind ftw, now possible with the fixed drm_device related
management.
Aside, clk/regulator seem to be missing devm versions for a bunch of
functions, preventing a pile of these simpler drivers from outright
losing their ->remove hook.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel
Only drops the drm_dev_put, but hey a few lines!
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git
It has become empty. Given the few users I figured not much point
splitting this up.
v2: Rebase over i915 changes.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 1 -
drivers/gpu/drm/drm_drv.c | 23 +--
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc:
Small mistake that crept into
commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
Author: Gerd Hoffmann
Date: Tue Feb 11 14:52:18 2020 +0100
drm/bochs: add drm_driver.release callback
where drm_atomic_helper_shutdown was left in both places. The
->release callback really shouldn't touch
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.
The kdev for the minor already handles NULL, so no problem there.
It's (almost, there's some iommu stuff without significance) right
above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: This
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
With this we can drop the final kfree from the release function.
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c
We can even delete the drm_driver.release hook now!
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Chris Wilson
Cc: Sean
Well for the simple stuff at least, vblank, gem and minor cleanup I
want to further split up as a demonstration.
v2: We need to clear drm_device->dev otherwise the debug drm printing
after our cleanup hook (e.g. in drm_manged_release) will chase
released memory and result in a use-after-free. Not
We might want to look into pushing this down into drm_mm_init, but
that would mean rolling out return codes to a pile of functions
unfortunately. So let's leave that for now.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 8 +---
drivers/gpu/drm/drm_gem.c | 21
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
drm_mode_config_cleanup is idempotent, so no harm in calling this
twice. This allows us to gradually switch drivers over by removing
explicit drm_mode_config_cleanup calls.
With this step it's not also possible that (at least for simple
drivers) automatic resource cleanup can be done correctly
With this we can drop the final kfree from the release function.
The mock device in the selftests needed it's pci_device split
up from the drm_device. In the future we could simplify this again
by allocating the pci_device as a managed allocation too.
v2: I overlooked that i915_driver_destroy is
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
This is made possible by a preceeding patch which added a drmm_
cleanup action to
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc:
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
These are the leftover drivers that didn't have a ->release hook that
needed to be updated.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Russell King
Cc: Hans de Goede
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 ++
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton
Signed-off-by: Daniel Vetter
Cc: Christoph Lameter
Cc: Pekka
We need to add a drmm_kstrdup for this, but let's start somewhere.
This is not exactly perfect onion unwinding, but it's jsut a kfree so
doesn't really matter at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 5 ++---
drivers/gpu/drm/drm_managed.c | 16
1 - 100 of 262 matches
Mail list logo
