On Wed, May 06, 2020 at 03:08:27PM +0300, Mika Kahola wrote:
> Make an additional note on DRM format modifiers for x and y tiling. These
> format modifiers are defined for BDW+ platforms and therefore definition
> is not valid for older gens. This is due to address swizzling for tiled
> surfaces is
On Mon, 04 May 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN* over WARN* calls.
>
> changes since v1:
> - Added dev_priv local variable and used it
I'll add your patch to drm-misc-next. Thanks!
Am 07.05.20 um 04:40 schrieb Samuel Zou:
> Fix the following sparse warning:
>
> drivers/gpu/drm/ast/ast_mode.c:564:6: warning:
> symbol 'ast_primary_plane_helper_atomic_update'
> was not declared. Should it be static?
>
> Reported-by: Hulk Robot
>
On Thu, May 07, 2020 at 04:07:55PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> With earlier patch we removed the normal overhead so now we can lift
> the helper to the header, folding it __drm_object_put.
>
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/drm_gem.c
On Thu, May 07, 2020 at 04:07:56PM +0100, 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 f
Hi Emil,
one suggestion for this patch: it seems preferable to merge this patch
with patch 11, so that the whole gem core gets converted at once.
Afterwards all those other patches convert the drivers. Finally, patch
36 would only remove the define of drm_gem_object_put_unlocked().
Best regards
T
On Thu, 07 May 2020, 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 transi
On Thu, May 07, 2020 at 04:07:51PM +0100, Emil Velikov wrote:
> 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
Hi
Am 07.05.20 um 17:08 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 suffix. It makes the
On Thu, May 07, 2020 at 04:07:50PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> There's little point in providing partial and ancient information about
> the struct_mutex. Some drivers are using it, new ones should not.
>
> As-it this only provides for confusion.
>
> Signed-off-by: Emil
On Thu, May 07, 2020 at 04:07:49PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Signed-off-by: Emil Velikov
> ---
> i915 uses the _unlocked version of the grm_gem_object API. Yet makes an
> extensive use of the struct_mutex.
>
> Did not check how exactly it all work though.
Reviewed-by:
Quoting Dave Airlie (2020-05-07 21:27:27)
> On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
> >
> > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin whic
Hi Dave and Daniel,
Here goes drm-intel-fixes-2020-05-07:
- Fixes on execlist to avoid GPU hang situation (Chris)
- Fixes couple deadlocks (Chris)
- Timeslice preemption fixes (Chris)
- Fix Display Port interrupt handling on Tiger Lake (Imre)
- Reduce debug noise around Frame Buffer Compression (
Hey Linus,
Another pretty normal week, didn't get any i915 fixes yet, so next
week I'd expect double the usual i915, but otherwise a bunch of amdgpu
and some scattered other fixes.
Dave.
drm-fixes-2020-05-08:
drm fixes for 5.7-rc5
hdcp:
- fix HDCP regression
amdgpu:
- Runtime PM fixes
- DC fix
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
between commit:
e07515563d01 ("PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP")
from the pm tree and commit:
500bd19a7e5d ("drm/amdgpu: only set DPM_FLAG_NEVER_SKIP for legacy ATP
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from include/asm-generic/bug.h:19,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/seq_file.h
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_domain.c
between commit:
47bf7b7a7151 ("drm/i915/gem: Remove object_is_locked assertion from
unpin_from_display_plane")
from the drm-intel-fixes tree and commit:
9da0ea09639f ("drm/i91
Hi Gwan-gyeong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20200507]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.7-rc4]
[if your patch
https://bugzilla.kernel.org/show_bug.cgi?id=207619
Bug ID: 207619
Summary: Screen corrupt in Wayland and kmscube, like wrong
stride / pitch, on Radeon X1400 RV515
Product: Drivers
Version: 2.5
Kernel Version: 5.7-rc4
Ha
From: Ira Weiny
Most architectures define kmap_prot to be PAGE_KERNEL.
Let sparc and xtensa define there own and define PAGE_KERNEL as the
default if not overridden.
Suggested-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
Changes from V3:
Fix semicolon in macro
Changes from V2:
On Thu, May 07, 2020 at 01:53:07PM -0700, Andrew Morton wrote:
> On Thu, 7 May 2020 08:00:03 -0700 ira.we...@intel.com wrote:
>
> > From: Ira Weiny
> >
> > Most architectures define kmap_prot to be PAGE_KERNEL.
> >
> > Let sparc and xtensa define there own and define PAGE_KERNEL as the
> > def
On Thu, May 07, 2020 at 01:52:58PM -0700, Andrew Morton wrote:
> On Thu, 7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote:
>
> > parisc reimplements the kmap calls except to flush it's dcache. This is
> > arguably an abuse of kmap but regardless it is messy and confusing.
> >
> > Remove the
Hi,
On Wed, May 6, 2020 at 2:03 PM Douglas Anderson wrote:
>
> This patch adds the following checks to the yaml:
> - Remapping of the eDP output lanes is now limited to the subset of
> remappings that the hardware supports.
> - No more additional properties can be added under 'ports'.
>
> This
We don't have the HPD line hooked up to the bridge chip. Add it as
suggested in the patch ("dt-bindings: drm/bridge: ti-sn65dsi86:
Document no-hpd").
NOTE: this patch isn't expected to have any effect but just keeps us
cleaner for the future. Currently the driver in Linux just assumes
that nobod
People use panel-simple when they have panels that are builtin to
their device. In these cases the HPD (Hot Plug Detect) signal isn't
really used for hotplugging devices but instead is used for power
sequencing. Panel timing diagrams (especially for eDP panels) usually
have the HPD signal in them
This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: Douglas Anderson
---
I removed Stephen's review tag on v5 since I squashed in a bunch of
other
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware. Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for k
In the cases where there is no connector in a system there's no great
place to put "hpd-gpios". As per discussion [1] the best place to put
it is in the panel. Add this to the device tree bindings.
[1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
Signed-off-by: Dou
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
kinda useless, at least for embedded DisplayPort (eDP). However,
despite the fact that the actual HPD pin on the bridge is mostly
useless for eDP, the concept of H
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's expos
On Thu, 7 May 2020 08:00:03 -0700 ira.we...@intel.com wrote:
> From: Ira Weiny
>
> Most architectures define kmap_prot to be PAGE_KERNEL.
>
> Let sparc and xtensa define there own and define PAGE_KERNEL as the
> default if not overridden.
>
checkpatch considered useful ;)
From: Andrew Mort
On Thu, 7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote:
> parisc reimplements the kmap calls except to flush it's dcache. This is
> arguably an abuse of kmap but regardless it is messy and confusing.
>
> Remove the duplicate code and have parisc define
> ARCH_HAS_FLUSH_ON_KUNMAP for a kunm
Hi,
On Mon 04 May 20, 13:45, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 09:10:07PM +0200, Paul Kocialkowski wrote:
> > Hi Daniel,
> >
> > On Fri 03 Apr 20, 13:04, Daniel Vetter wrote:
> > > On Fri, Apr 03, 2020 at 11:36:17AM +0200, Paul Kocialkowski wrote:
> > > > Introduces a driver for the
From: Colin Ian King
The variable 'start' is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/exynos/exyn
Hi Emil,
Thanks for the review!
On Mon 04 May 20, 14:28, Emil Velikov wrote:
> Just had a casual quick look for custom KMS properties, since new
> drivers made that mistake in the past.
> Thanks for not including any o/
Yeah I made sure not to include any, I know it easily gets very problematic
Applied. Thanks!
Alex
On Thu, May 7, 2020 at 2:45 AM Christian König
wrote:
>
> Am 07.05.20 um 04:02 schrieb Chunming Zhou:
> > Glad to spend time on kernel driver in past years.
> > I've moved to new focus in umd and couldn't commit
> > enough time to discussions.
> >
> > Signed-off-by: Chunmi
Hi Konrad.
On Wed, May 06, 2020 at 11:09:54PM +0200, Konrad Dybcio wrote:
> changes since v3:
> - fix dt-bindings issue
>
> changes since v2:
> - fix Kconfig indentation
>
> changes since v1:
> - make `backlight_properties props` constant
> - a couple of line breaks
> - change name and compatibl
rm69299.o
>
> Signed-off-by: Randy Dunlap
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: dri-devel@lists.freedesktop.org
Thanks.
Added Fixes: tag and applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-visionox-rm69299.c |1 +
> 1 file changed
Applied. Thanks!
Alex
On Thu, May 7, 2020 at 11:27 AM Chen Zhou wrote:
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Chen Zhou
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/displ
On Thu, May 7, 2020 at 9:35 AM ChenTao wrote:
>
> Fix the following warning:
>
> 'en' is uint32_t and can never be negative.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/hw_hpd.c:132:10: warning:
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> if ((en < GPIO_DDC_LI
Applied thanks!
Alex
On Thu, May 7, 2020 at 9:35 AM Jason Yan wrote:
>
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c:3216:16-22:
> Unneeded variable: "result". Return "DC_OK" on line 3229
>
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/a
On Thu, May 7, 2020 at 5:22 AM Christian König wrote:
>
> Am 07.05.20 um 11:13 schrieb Bernard Zhao:
> > There is DEVICE_ATTR mechanism in separate attribute define.
> > So this change is to use attr array, also use
> > sysfs_create_files in init function & sysfs_remove_files in
> > fini function.
Hey guys! Sorry this took me a little while to get to, but I was finally able
to sit down for a bit and do a thorough investigation on the latency issues
here to figure out if it's noise or not. I did this investigation with the
plain work_struct implementation, the original kthread implementation,
On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do. On
Hi Emil.
On Thu, May 07, 2020 at 04:07:46PM +0100, Emil Velikov wrote:
> Hi all,
>
> Recently I had a look at the new dmabuf AMDGPU implementation.
>
> Seemingly it was using the wrong drm_gem_object_put API. Namely the
> locked one, even though the driver is struct_mutex free.
>
> Upon checking
Hi Emil.
On Thu, May 07, 2020 at 04:08:22PM +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
Hi Emil.
On Thu, May 07, 2020 at 04:07:52PM +0100, Emil Velikov wrote:
> 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: a39414716c
Hi Emil.
On Thu, May 07, 2020 at 04:07:50PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> There's little point in providing partial and ancient information about
> the struct_mutex. Some drivers are using it, new ones should not.
>
> As-it this only provides for confusion.
>
> Signed-off
Hi Emil.
On Thu, May 07, 2020 at 04:07:48PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Use the drm_gem_object_put_unlocked in the documentation for
> drm_gem_objects_lookup. The locked version of the helper should be used
> solely by people who know exactly what they are doing.
>
> Sho
Hi Maxime,
Am 24.04.20 um 17:35 schrieb Maxime Ripard:
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 276 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h
Am 07.05.20 um 17:07 schrieb Emil Velikov:
> From: Emil Velikov
>
> No drivers set the callback, so remove it all together.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem.c | 22 +++---
> include/drm/drm_drv.h | 8 --
Hi
Am 07.05.20 um 17:07 schrieb Emil Velikov:
> From: Emil Velikov
>
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Patrik Jakobsson
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
https://bugzilla.kernel.org/show_bug.cgi?id=207613
--- Comment #2 from Michael Fox (m...@trentu.ca) ---
(In reply to Alex Deucher from comment #1)
> Did this system ever work? If so when and can you bisect?
Yes, it works well with the 4.15 kernel. And I did bisect to the extent of
finding out th
On Thu, 7 May 2020 at 13:29, Vinay Simha B N wrote:
>
> Emil,
>
> Reply inline
>
> On Tue, 5 May 2020 at 9:35 PM, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
>> using the generic write. This does not look right.
>>
>>
On 2020-05-07 4:27 p.m., Sasha Levin wrote:
> From: Marek Olšák
>
> [ Upstream commit 9017a4897a20658f010bebea825262963c10afa6 ]
>
> This fixes GPU hangs due to cache coherency issues.
> Bump the driver version. Split out from the original patch.
>
> Signed-off-by: Marek Olšák
> Reviewed-by: C
On Thu, May 7, 2020 at 10:44 AM Chris Wilson wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.
Quoting Jason Ekstrand (2020-05-07 16:36:00)
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is
> only supported by iris which nev
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is
only supported by iris which never uses relocations. The older i965
driver in Mesa d
https://bugzilla.kernel.org/show_bug.cgi?id=207613
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Am 07.05.20 um 17:07 schrieb Emil Velikov:
> From: Emil Velikov
>
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_vm.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 56197ae0b2f9.
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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
fo
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
---
drivers/gpu/drm/drm_gem.c | 1 -
1 file changed, 1 deletion(-)
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
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
---
dr
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=drm_gem
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.
Sig
From: Emil Velikov
With earlier patch we removed the normal overhead so now we can lift
the helper to the header, folding it __drm_object_put.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 19 ---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
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=drm_gem
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=drm_gem
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=drm_gem
From: Emil Velikov
No drivers set the callback, so remove it all together.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 22 +++---
include/drm/drm_drv.h | 8
include/drm/drm_gem.h | 5 +++--
3 files changed, 6 insertions(+), 29 deletions(-)
di
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=drm_gem
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=drm_gem
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=drm_gem
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=drm_gem
From: Emil Velikov
There's little point in providing partial and ancient information about
the struct_mutex. Some drivers are using it, new ones should not.
As-it this only provides for confusion.
Signed-off-by: Emil Velikov
---
Documentation/gpu/drm-mm.rst | 7 ++-
1 file changed, 2 inse
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=drm_gem
From: Emil Velikov
No dev->struct_mutex anywhere to be seen.
Cc: Patrik Jakobsson
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/p
Hi all,
Recently I had a look at the new dmabuf AMDGPU implementation.
Seemingly it was using the wrong drm_gem_object_put API. Namely the
locked one, even though the driver is struct_mutex free.
Upon checking with the documentation, I've noticed it's a bit misleading
so I've went ahead and:
-
From: Emil Velikov
Signed-off-by: Emil Velikov
---
i915 uses the _unlocked version of the grm_gem_object API. Yet makes an
extensive use of the struct_mutex.
Did not check how exactly it all work though.
---
Documentation/gpu/todo.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Emil Velikov
Use the drm_gem_object_put_unlocked in the documentation for
drm_gem_objects_lookup. The locked version of the helper should be used
solely by people who know exactly what they are doing.
Should prevent issues like ones adddressed with the next patch.
Signed-off-by: Emil Veli
From: Emil Velikov
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_vm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 56197ae0b2f9..954baa8a2a8f 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -51,7 +51,6
From: Ira Weiny
Every single architecture (including !CONFIG_HIGHMEM) calls...
pagefault_enable();
preempt_enable();
... before returning from __kunmap_atomic(). Lift this code into the
kunmap_atomic() macro.
While we are at it rename __kunmap_atomic() to kunmap_atomic_high()
From: Ira Weiny
To support kmap_atomic_prot() on all architectures each arch must
support protections passed in to them.
Change csky, mips, nds32 and xtensa to use their global constant
kmap_prot rather than a hard coded value which was equal.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.
Some of the k[un]map_atomic() implementations have some similarities but
1 - 100 of 206 matches
Mail list logo
