Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: 52f70af32a6cef1ec5735145486d9154ab1248ac
commit: a5784d79d1577c00e6e81f892cde52593546a5f4 [3698/4200] drm/amdkcl: drop
kcl_dma_fence_set_error
config: x86_64-allyes
Am 29.10.19 um 01:31 schrieb Changbin Du:
But is it, really? I agree with Jon about the distinction between None
and '' being confusing.
Here python is different from C. Both empty string and None are False in python.
Note such condition is common in python.
The one is a empty string str(''),
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: 52f70af32a6cef1ec5735145486d9154ab1248ac
commit: f460c248a3f0bca3a875602cf40693de672485c4 [3697/4200] drm/amd/autoconf:
refactor dma_fence header check
config: x86_
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: 52f70af32a6cef1ec5735145486d9154ab1248ac
commit: fbb2398b29e0de236e9ee3ad48385095ebcb2a84 [2219/4200] drm/amd/autoconf:
fix in-build error for O=...
config: mips-al
On Thu, Sep 12, 2019 at 4:33 PM Andreas Kemnade wrote:
>
> add enable-gpios to describe HWEN pin
>
> Signed-off-by: Andreas Kemnade
> Acked-by: Daniel Thompson
This breaking linux-next now...
> ---
> changes in v2: added example
> changes in v3: added Acked-by
> changes in v4: moved enable-gpi
https://bugzilla.kernel.org/show_bug.cgi?id=205335
--- Comment #5 from Arne Woerner (arne_woer...@yahoo.com) ---
i am using 5.4.0-rc5ARNE now...
my first self-compiled kernel since years... giggle
OpenGL and btrfs and bcache and sound work fine...
it cannot hibernate via s2disk (when i try it, i
On Mon, Oct 28, 2019 at 2:47 AM Rob Herring wrote:
>
> On Fri, 25 Oct 2019 23:26:20 +0530, Jagan Teki wrote:
> > The MIPI DSI PHY controller on Allwinner A64 is similar
> > on the one on A31.
> >
> > Add A64 compatible and append A31 compatible as fallback.
> >
> > Signed-off-by: Jagan Teki
> > -
Hi Maxime,
On Mon, Oct 28, 2019 at 9:06 PM Maxime Ripard wrote:
>
> On Fri, Oct 25, 2019 at 11:26:22PM +0530, Jagan Teki wrote:
> > Usage of clocks are varies between different Allwinner
> > DSI controllers. Clocking in A33 would need bus and
> > mod clocks where as A64 would need only bus clock.
On Mon, Oct 28, 2019 at 1:03 PM John Stultz wrote:
>
> On Mon, Oct 28, 2019 at 12:12 PM wrote:
> > On Fri, Oct 25, 2019 at 11:48:33PM +, John Stultz wrote:
> > > --- a/kernel/dma/contiguous.c
> > > +++ b/kernel/dma/contiguous.c
> > > @@ -31,6 +31,7 @@
> > > #endif
> > >
> > > struct cma *dm
On Mon, Oct 28, 2019 at 11:39 AM John Stultz wrote:
> On Mon, Oct 28, 2019 at 12:46 AM Christoph Hellwig wrote:
> >
> > On Fri, Oct 25, 2019 at 11:48:33PM +, John Stultz wrote:
> > > struct cma *dma_contiguous_default_area;
> > > +EXPORT_SYMBOL(dma_contiguous_default_area);
> >
> > Please CC
https://bugs.freedesktop.org/show_bug.cgi?id=109887
har...@gmx.de changed:
What|Removed |Added
See Also||https://bugzilla.kernel.org
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #179 from Shmerl ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #33)
> Created attachment 145323 [details] [review]
> wip patch
>
> You can give a try to the attached kernel patch which hopefully could
> prevent some sdma
https://bugs.freedesktop.org/show_bug.cgi?id=111240
--- Comment #7 from Jacek Konieczny ---
I have tried kernel 5.4-rc5 – that did not help.
Disabling cpufreq boost (echo 0 > /sys/devices/system/cpu/cpufreq/boost) stops
the drastic slowdown from happening, but this also makes the system
signific
https://bugs.freedesktop.org/show_bug.cgi?id=111240
Jacek Konieczny changed:
What|Removed |Added
Summary|RX 560x is very slow|ASUS TUF Gaming laptops
On 2019/10/28 22:06, Alex Deucher wrote:
> On Mon, Oct 28, 2019 at 9:37 AM YueHaibing wrote:
>>
>> Fix sparse warnings:
>>
>> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2050:5:
>> warning: symbol 'arcturus_i2c_eeprom_control_init' was not declared. Should
>> it be static?
>> driver
Hello,
I have taken another look also at the implementation of the function
“mcde_probe”.
Now I wonder why the statement “drm->dev_private = mcde;” was specified twice
there.
https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/mcde/mcde_drv.c#L339
https://git.kernel.org/pub/scm/linu
This patchset addresses the sparse warning about the
`amdgpu_exp_hw_support` variable and corrects the mispelling of the
word "_LENTH".
Wambui Karuga (2):
drm/amd: declare amdgpu_exp_hw_support in amdgpu.h
drm/amd: correct "_LENTH" mispelling in constant
drivers/gpu/drm/amd/amdgpu/amdgpu.h
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:963:6:
warning: symbol 'calculate_integer_scaling' was not declared. Should it be
static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file cha
ping
On 2019/10/9 14:25, zhengbin wrote:
> zhengbin (3):
> drm/amd/display: Remove set but not used variables
> 'bl_pwm_cntl','pwm_period_cntl'
> drm/amd/display: Remove set but not used variable 'value0'
> drm/amd/display: Remove set but not used variables 'regval','speakers'
>
> drive
> …
>> +free_dbidev:
>> +kfree(dbidev);
> …
>
> I became curious if there is a need for such a memory release at another
> place.
I have taken another look also at a related implementation detail.
Now I have realised that the desired clean-up should usually be achieved by
the callback functio
Fix sparse warnings:
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2050:5:
warning: symbol 'arcturus_i2c_eeprom_control_init' was not declared. Should it
be static?
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2068:6:
warning: symbol 'arcturus_i2c_eeprom_control_fini' was not
Correct the "_LENTH" mispelling in the AMDGPU_MAX_TIMEOUT_PARAM_LENGTH
constant.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 2 +-
3 files changed, 5 insert
Hi Steve,
Thanks a lot for your time and patience :)
> On 25/10/2019 02:30, Yi Wang wrote:
> > We get these warnings when build kernel W=1:
> > drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
> > prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes]
> >
Declare `amdgpu_exp_hw_support` as extern in amdgpu.h to address the
following sparse warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:118:5: warning: symbol
'amdgpu_exp_hw_support' was not declared. Should it be static?
Signed-off-by: Wambui Karuga
Suggested-by: Harry Wentland
---
drivers/gpu
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_range_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that uses
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_range_notifier_insert)
support overlapping ranges directly. Simply delete all this code.
Since this driver i
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid == true
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell i
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted to a
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_range_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
include/linux/hmm.h | 183 +-
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_range notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_range_notifier api in
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Cc: Ben Skeggs
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Ralph Campbell
Signed-off-by: Jason Gu
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason Gunthorp
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this is
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind (scif_dm
https://bugzilla.kernel.org/show_bug.cgi?id=204241
Andrew Hutchings (and...@linuxjedi.co.uk) changed:
What|Removed |Added
CC||and...@linuxje
It seems that killing an application while faults are occurring
(particularly with a GPU in FPGA at a whopping 40MHz) can lead to
handling a lingering page fault after all the address space contexts
have already been freed. In this situation, the LRU list is empty so
addr_to_drm_mm_node() ends up d
On Mon, Oct 28, 2019 at 12:12 PM wrote:
> On Fri, Oct 25, 2019 at 11:48:33PM +, John Stultz wrote:
> > --- a/kernel/dma/contiguous.c
> > +++ b/kernel/dma/contiguous.c
> > @@ -31,6 +31,7 @@
> > #endif
> >
> > struct cma *dma_contiguous_default_area;
> > +EXPORT_SYMBOL(dma_contiguous_default_a
Hi Cheng-Yi,
I love your patch! Yet something to improve:
[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v5.4-rc5 next-20191028]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base&#x
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.
Th
Hi,
On 25-10-2019 21:45, Ville Syrjälä wrote:
On Fri, Oct 25, 2019 at 09:23:47PM +0200, Hans de Goede wrote:
Hi,
On 21-10-2019 16:39, Ville Syrjälä wrote:
On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
https://bugs.freedesktop.org/show_bug.cgi?id=112160
Alex Deucher changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
On Mon, Oct 28, 2019 at 12:46 AM Christoph Hellwig wrote:
>
> On Fri, Oct 25, 2019 at 11:48:33PM +, John Stultz wrote:
> > struct cma *dma_contiguous_default_area;
> > +EXPORT_SYMBOL(dma_contiguous_default_area);
>
> Please CC the dma maintainer. And no, you have no business using this.
Sur
On Mon, Oct 21, 2019 at 6:23 PM Geert Uytterhoeven
wrote:
>
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
Applied. Thanks!
Alex
>
On Wed, Oct 23, 2019 at 4:10 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1221:24: warning: variable adev set
> but not used [-Wunused-but-set-variable]
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:488:24: warning: variable adev set
> but not used [-Wunused-but-set-variable]
> d
On Mon, Oct 28, 2019 at 12:38:22PM +0200, Jani Nikula wrote:
> Add new struct drm_device based logging macros modeled after the core
> kernel device based logging macros. These would be preferred over the
> drm printk and struct device based macros in drm code, where possible.
>
> We have existing
Fixes: 0cc0922ae849 ("ASoC: rockchip_max98090: Optionally support HDMI use
case")
Signed-off-by: kbuild test robot
---
rockchip_max98090.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rockchip_max98090.c
b/sound/soc/rockchip/rockchip_max98090.c
inde
Hi Cheng-Yi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on rockchip/for-next]
[also build test WARNING on v5.4-rc5 next-20191028]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '-
(cc: yc_c...@aspeedtech.com)
Am 28.10.19 um 16:49 schrieb Thomas Zimmermann:
> This patch set adds universal planes to ast and converts the driver to
> atomic modesetting.
>
> The first patch is purely for clean-up.
>
> Patches 2 to 5 prepare the ast modesetting code for universal planes and
> a
The content of the base-address and offset registers are state of
the primary plane. Clearing it to default values will interfere with
plane functions for atomic mode setting.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 8 ++--
1 file changed, 6 insertions(+), 2 del
The cursor plane uses an internal format of ARGB. To userspace, we
announce ARGB and do the transformation internally.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_mode.c | 161 -
2 files changed, 161
As the CRTC code has already been prepared for a split between mode
setting and plane handling, most of the CRTC's atomic modesetting is
build upon primitives of the non-atomic implementation.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 105 +
Each video mode's primary plane requires a minimum amount of video
memory. For double buffering, this is at most half the available
VRAM. Check this constraint.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 25 -
1 file changed, 24 insertions(+), 1
The implementation of ast_set_vbios_mode() converts a DRM display mode
and framebuffer into an adjusted mode and stores information for the
video BIOS to several scratch regsiters.
Here we split the function into individual functions that do the
conversion, set the VBIOS mode information and forma
Like the original mode-setting code, the primary plane supports XRGB888,
RGB565 and C8. The plane itself only pins BOs and sets the base address
and scanline offset. The mode-setting code will be located in the CRTC's
atomic helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_d
This patch set adds universal planes to ast and converts the driver to
atomic modesetting.
The first patch is purely for clean-up.
Patches 2 to 5 prepare the ast modesetting code for universal planes and
atomic modesetting. The size calculation for each mode has to take double
buffering into acco
This commit sets the remaining atomic-modesetting helpers and the flag
DRIVER_ATOMIC. Legacy cursor functions are removed in favor of the cursor
plane. For power management, atomic helpers replace the indvidual
operations that the driver currently runs.
Atomic modesetting is enabled with this comm
The ast driver has switched to struct drm_vram_gem_object a while ago.
This patch removes a function and forward declaration that were forgotten
before.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 6 --
drivers/gpu/drm/ast/ast_main.c | 24
In ast_set_ext_reg() sets several framebuffer options and CRT threshold
parameters. The former is mostly state of the primary plane; the latter
is constant. Hence, split the function in two and make it work with
atomic modesetting.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mod
https://bugzilla.kernel.org/show_bug.cgi?id=205335
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
bisecting is a git feature which allows you to identify what commit caused an
issue. There were several suspend/resume issues related to multi-media engines
that were fixed recently. C
https://bugzilla.kernel.org/show_bug.cgi?id=205335
--- Comment #3 from Arne Woerner (arne_woer...@yahoo.com) ---
bisect means compiling a kernel again and again with different patches and
testing?
in a "nested intervals" fashion?
i think that is too much load for my box...
i even deleted the 5.1
On Fri, Oct 25, 2019 at 11:26:22PM +0530, Jagan Teki wrote:
> Usage of clocks are varies between different Allwinner
> DSI controllers. Clocking in A33 would need bus and
> mod clocks where as A64 would need only bus clock.
>
> To support this kind of clocking structure variants
> in the same dsi d
On Fri, Oct 25, 2019 at 11:35:32AM -0700, Yiwei Zhang wrote:
> Hi folks,
>
> This is the plain text version of the previous email in case that was
> considered as spam.
>
> --- Background ---
> On the downstream Android, vendors used to report GPU private memory
> allocations with debugfs nodes i
On Mon, Oct 28, 2019 at 10:56 AM Jordan Crouse wrote:
>
> On Mon, Oct 28, 2019 at 08:47:58AM -0600, Jordan Crouse wrote:
> > On Wed, Oct 23, 2019 at 11:00:58AM -0700, Yiwei Zhang wrote:
> > > Hi folks,
> > >
> > > This is Yiwei from the Android Platform Graphics team. On the downstream
> > > Andro
The DCS command has been named SET_PARTIAL_ROWS in the DCS spec since
v1.02, for more than a decade. Rename the enumeration to match the spec.
v2: add comment about the rename (David Lechner)
Cc: David Lechner
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/tiny/st7586.c |
Update from the DCS specification.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
include/video/mipi_display.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index 6b6390dfa203..928f8c4b6658 100644
--- a/include/v
Add helper functions for sending the DSI compression mode and picture
parameter set data type packets. For the time being, limit the support
to using VESA DSC 1.1 and the default PPS. This may need updating if the
need arises for proprietary compression or non-default PPS, however keep
it simple fo
Add execute queue and compressed pixel stream packet data types for
completeness.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_mipi_dsi.c | 2 ++
include/video/mipi_display.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/dri
Rename picture parameter set (it's a long packet, not a long write) and
compression mode (it's not a DCS command) enumerations according to the
DSI specification. Order the types according to the spec. Use tabs
instead of spaces for indentation. Use all lower case for hex.
Cc: Vandita Kulkarni
Re
On Mon, Oct 28, 2019 at 08:47:58AM -0600, Jordan Crouse wrote:
> On Wed, Oct 23, 2019 at 11:00:58AM -0700, Yiwei Zhang wrote:
> > Hi folks,
> >
> > This is Yiwei from the Android Platform Graphics team. On the downstream
> > Android, vendors used to report GPU private memory allocations with debug
On Wed, Oct 23, 2019 at 11:00:58AM -0700, Yiwei Zhang wrote:
> Hi folks,
>
> This is Yiwei from the Android Platform Graphics team. On the downstream
> Android, vendors used to report GPU private memory allocations with debugfs
> nodes in their own formats. However, debugfs nodes are getting depre
On Mon, Oct 28, 2019 at 9:37 AM YueHaibing wrote:
>
> Fix sparse warnings:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2050:5:
> warning: symbol 'arcturus_i2c_eeprom_control_init' was not declared. Should
> it be static?
> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:206
On Mon, Oct 28, 2019 at 8:47 AM Wambui Karuga wrote:
>
> This patchset addresses the sparse warning about the
> `amdgpu_exp_hw_support` variable and corrects the mispelling of the
> word "_LENTH".
>
> Wambui Karuga (2):
> drm/amd: declare amdgpu_exp_hw_support in amdgpu.h
> drm/amd: correct "_
Hi Zheng,
Harry's previous comment about the superfluous REG_READ()s is still unaddressed.
Once that's fixed, I can give my r-b.
Thanks,
Leo
On 2019-10-28 5:32 a.m., zhengbin (A) wrote:
> ping
>
> On 2019/10/9 14:25, zhengbin wrote:
>> zhengbin (3):
>> drm/amd/display: Remove set but not use
On Mon, Oct 28, 2019 at 9:36 AM YueHaibing wrote:
>
> Fix sparse warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:963:6:
> warning: symbol 'calculate_integer_scaling' was not declared. Should it be
> static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Appli
https://bugzilla.kernel.org/show_bug.cgi?id=205277
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Mon, Oct 28, 2019 at 09:27:33AM +, wang.y...@zte.com.cn wrote:
> Hi Steve,
>
> Thanks a lot for your time and patience :)
>
> > On 25/10/2019 02:30, Yi Wang wrote:
> > > We get these warnings when build kernel W=1:
> > > drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previou
On Mon, Oct 28, 2019 at 02:57:26PM +0200, Joonas Lahtinen wrote:
> Quoting paul...@kernel.org (2019-10-22 22:12:08)
> > From: "Paul E. McKenney"
> >
> > This commit replaces the use of rcu_swap_protected() with the more
> > intuitively appealing rcu_replace() as a step towards removing
> > rcu_sw
Am 28.10.19 um 14:31 schrieb Hans de Goede:
> Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer
> with generic implemenation") removed the diy framebuffer code from
> the vboxvideo driver, resulting in a nice cleanup.
>
> But since the vboxvideo driver needs the generic dirty t
Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer
with generic implemenation") removed the diy framebuffer code from
the vboxvideo driver, resulting in a nice cleanup.
But since the vboxvideo driver needs the generic dirty tracking code,
it's drm_mode_config_funcs.fb_create shou
https://bugzilla.kernel.org/show_bug.cgi?id=205335
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Quoting paul...@kernel.org (2019-10-22 22:12:08)
> From: "Paul E. McKenney"
>
> This commit replaces the use of rcu_swap_protected() with the more
> intuitively appealing rcu_replace() as a step towards removing
> rcu_swap_protected().
>
> Link:
> https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFE
From: Thierry Reding
All the devices that make up the DRM device are now part of the same
IOMMU group. This simplifies the handling of the IOMMU attachment and
also avoids exhausting the number of IOMMUs available on early Tegra
SoC generations.
Signed-off-by: Thierry Reding
---
drivers/gpu/dr
From: Thierry Reding
Rename paddr -> iova and vaddr -> virt to make it clearer how these
addresses are used. This is important for a subsequent patch that makes
a distinction between the physical address (physical address of the
system memory from the CPU's point of view) and the IOVA (physical
a
From: Thierry Reding
If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups w
From: Thierry Reding
If a client is already attached to an IOMMU domain that is not the
shared domain, don't try to attach it again. This allows using the
IOMMU-backed DMA API.
Since the IOMMU-backed DMA API is now supported and there's no way
to detach from it on 64-bit ARM, don't bother to det
From: Thierry Reding
All of the devices making up the Tegra DRM device want to share a single
IOMMU domain. Put them into a single group to allow them to do that.
Signed-off-by: Thierry Reding
---
drivers/memory/tegra/tegra114.c | 10 ++
drivers/memory/tegra/tegra124.c | 8 +---
d
From: Thierry Reding
Having to provide allocator hooks to the Falcon library is somewhat
cumbersome and it doesn't give the users of the library a lot of
flexibility to deal with allocations. Instead, remove the notion of
Falcon "operations" and let drivers deal with the memory allocations
themse
From: Thierry Reding
The debugfs files created for host1x are never removed, causing these
files to be left dangling in debugfs. This results in a crash when any
of these files are accessed after the host1x driver has been removed,
as well as a failure to create the debugfs entries when they are
From: Thierry Reding
If the Tegra DRM clients are backed by an IOMMU, push buffers are likely
to be allocated beyond the 32-bit boundary if sufficient system memory
is available. This is problematic on earlier generations of Tegra where
host1x supports a maximum of 32 address bits for the GATHER
From: Thierry Reding
If host1x_bo_pin() returns an SG table, create a DMA mapping for the
buffer. For buffers that the host1x client has already mapped itself,
host1x_bo_pin() returns NULL and the existing DMA address is used.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 18
From: Thierry Reding
Add direction flags to host1x relocations performed during job pinning.
These flags indicate the kinds of accesses that hardware is allowed to
perform on the relocated buffers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 2 ++
include/linux/host1x.h
From: Thierry Reding
This series is a continuation of the work to move host1x and Tegra DRM
towards being able to use the IOMMU-backed DMA API.
The first two patches are required to workaround the shortage of IOMMU
domains on older Tegra SoC generations. The remainder of the patches is
mostly pr
From: Thierry Reding
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin
buffers during host1x job submission. Pinning currently returns the SG
table and the DMA address (an IOVA if an IOMMU is used or a physical
address if no IOMMU is used) of the buffer. The DMA address is
From: Thierry Reding
Currently when the gather buffers are copied, they are copied to a
buffer that is allocated for the host1x client that wants to execute the
command streams in the buffers. However, the gather buffers will be read
by the host1x device, which causes SMMU faults if the DMA API i
Hi Dave,
Just one build warning fixup.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 3275a71e76fac5bc276f0d60e027b18c2e8d7a5b:
Merge tag 'drm-next-5.5-2019-10-09' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2019
Hi
Am 28.10.19 um 13:06 schrieb Hans de Goede:
> Hi,
>
> On 28-10-2019 12:34, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.10.19 um 12:26 schrieb Hans de Goede:
>>> Hi Thomas,
>>>
>>> On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev
>
2019년 10월 24일 (목) 오전 12:45, Boris Brezillon
님이 작성:
>
> bridge->next is only points to the new bridge if drm_bridge_attach()
> succeeds. No need to reset it manually here.
>
> Note that this change is part of the attempt to make the bridge chain
> a double-linked list. In order to do that we must pa
From: Thierry Reding
The ->load() and ->unload() drivers are midlayers and should be avoided
in modern drivers. Fix this by moving the code into the driver ->probe()
and ->remove() implementations, respectively.
v2: kick out conflicting framebuffers before initializing fbdev
v3: rebase onto drm/
1 - 100 of 163 matches
Mail list logo
