Hi Tian
Am 15.12.20 um 04:01 schrieb Tian Tao:
drm_irq_uninstall should be called before pci_disable_msi, if use
devm_drm_irq_install to register the interrupt, the system will
call pci_disable_msi first and then call drm_irq_uninstall, which
will result in the following callstack.
kernel
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 5dcf8eb3991298ab764be6f83eaa48f75d49e77a [2392/2427] drm/amd/display:
add copy of drm_dp_mst_add_affected_dsc_crtc()
config: i386-randconfig-r022-20201214 (attached as .config
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 470f4be73099cc46478d2c708411fecde8197ca3 [1379/2427] drm/amdkcl: update
DRM_AMD_DC_DCN3_0 to depends on legacy display config
config: x86_64-randconfig-a001-20201214 (attached
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427] drm/amd/display:
convert to use le16_add_cpu()
config: arc-randconfig-s031-20201214 (attached as .config)
compiler: arc-elf
-randconfig-a004-20201214 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
a29ecca7819a6ed4250d3689b12b1f664bb790d7)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: cf13e50dea28cde351fa32767e36135afb30386d [2387/2427] drm/amdgpu: clean
up ras sysfs creation (v2)
config: x86_64-randconfig-a002-20201214
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 353801e46ab9f255e45bff91e185580df75787c0 [2349/2427] drm/amdgpu/gmc9:
print client id string for mmhub
config: i386-randconfig-r022-20201214 (attached as .config)
compiler: gcc
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: abdc393ab8265df9db5d9d64eb33ed1c33e9d95c [1587/2427] drm/amdkfd: Add
gfx10 address watch support
config: powerpc-allyesconfig (attached as .config)
compiler:
-a002-20201214 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
a29ecca7819a6ed4250d3689b12b1f664bb790d7)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
Hi Linus.
On Mon, Dec 14, 2020 at 11:22:10PM +0100, Linus Walleij wrote:
> The "max-brightness" is a standard backlight property that
> we need to support for the Samsung GT-I8190 Golden because
> the display will go black if we crank up the brightness
> too high.
>
> As the platform needs this
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: e1357d7a01b8b3bf23e71415eb7ca101902ee6b4 [2016/2427] drm/amdkcl: fake
drm_gem_fb_get_obj & kcl_drm_gem_fb_set_obj
config: mips-allyesconfig (attached as .config)
compiler:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: e1357d7a01b8b3bf23e71415eb7ca101902ee6b4 [2016/2427] drm/amdkcl: fake
drm_gem_fb_get_obj & kcl_drm_gem_fb_set_obj
config: i386-randconfig-r022-20201214 (attached as .co
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 90e75e02fc4f30c8139b7321f8bbd635ec9d75ce [1835/2427] drm/amdkcl: dkms
support for hmm
config: x86_64-randconfig-a002-20201214 (attached as .config)
compiler: clang version
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: e1357d7a01b8b3bf23e71415eb7ca101902ee6b4 [2016/2427] drm/amdkcl: fake
drm_gem_fb_get_obj & kcl_drm_gem_fb_set_obj
config: arc-randconfig-s031-20201214 (attached as .co
On 15/12/20 3:50 am, Aurabindo Pillai wrote:
> [Why]
> Inorder to enable freesync video mode, driver adds extra
> modes based on preferred modes for common freesync frame rates.
> When commiting these mode changes, a full modeset is not needed.
> If the change in only in the front porch timing
: i386-randconfig-r022-20201214 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-20.45
git checkout
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 0c6b8c594dad29321b0a233ac5b81a6eb1fbf4cf [1016/2427] drm/amdkfd:
Initial gfx9 debug address watch
config: powerpc-allyesconfig (attached as .config)
compiler:
On 15/12/20 3:50 am, Aurabindo Pillai wrote:
> [Why]
> If experimental freesync video mode module parameter is enabled, add
> few extra display modes into the driver's mode list corresponding to common
> video frame rates. When userspace sets these modes, no modeset will be
> performed (if
Hi all,
On Tue, 15 Dec 2020 06:56:08 +1100 Stephen Rothwell
wrote:
>
> On Tue, 17 Nov 2020 15:45:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the amdgpu tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> >
Hi all,
On Tue, 15 Dec 2020 06:50:45 +1100 Stephen Rothwell
wrote:
>
> On Mon, 16 Nov 2020 10:44:44 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 5 Nov 2020 17:50:31 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm tree, today's linux-next build (htmldocs) produced
>
https://bugzilla.kernel.org/show_bug.cgi?id=205147
Richard Herbert (rherb...@sympatico.ca) changed:
What|Removed |Added
Status|NEW |RESOLVED
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: 4978452e875a60112754d1247480cd76321e3ff9 [630/2427] drm/amdkcl:
generate config.h
config: arc-randconfig-s031-20201214 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: cba14b2c4e6c30f8af8c1fe00893e11e040d1873 [1087/2427] drm/amd/display:
combine public interfaces into single header
config: mips-allyesconfig (attached as .config)
compiler:
On Mon, Dec 14, 2020 at 06:52:25PM +0100, Ard Biesheuvel wrote:
> This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
>
> Simply disabling -mgeneral-regs-only left and right is risky, given that
> the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> and GCC is known
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #74 from MasterCATZ (masterc...@hotmail.com) ---
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.autosuspend=-1 amdgpu.dcfeaturemask=2
apparmor=0 amdgpu.ppfeaturemask=0xfffd7fff amdgpu.ppfeaturemask=0x
amdgpu.dc=1 amdgpu.cik_support=1
Hi, Yongqiang:
Yongqiang Niu 於 2020年12月12日 週六 下午12:13寫道：
>
> fix gamma size config
I would like you to provide more information. The original code works
in mt8173, why do you modify this? The description may be something
like this:
According to data sheet, the width is in bits [31, 16] and
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #73 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to MasterCATZ from comment #72)
>
> now if someone could solve the issue when it uses more power when running
> multiple displays ( exactly the same monitors res / hz )
>
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #72 from MasterCATZ (masterc...@hotmail.com) ---
finally this summer the R9 290 GPU's will be manageable
seems to be working , now I just have to find the old settings I changed when
trying to run it at higher rpm , @ 60deg and its
On 14/12/2020 19:39, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Dec 08, 2020 at 02:28:53PM +0200, Tomi Valkeinen wrote:
>> ULPS doesn't work, and I have been unable to get it to work. As ULPS
>> is a minor power-saving feature which requires substantial amount of
>> non-trivial code, and we have
On Mon, Dec 14, 2020 at 5:45 PM Linus Torvalds
wrote:
>
> On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote:
> >
> > The relevant fixes are:
>
> Ok, I can confirm that applying those two patches gets my workstation
> working properly again.
>
> Would it be possible to get those submitted
On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote:
>
> The relevant fixes are:
Ok, I can confirm that applying those two patches gets my workstation
working properly again.
Would it be possible to get those submitted properly (or I can just
take them as-is, but would like to get a "please just
On Mon, Dec 14, 2020 at 5:21 PM Linus Torvalds
wrote:
>
> On Thu, Dec 10, 2020 at 7:52 PM Dave Airlie wrote:
> >
> > This is an early pull request for drm for 5.11 merge window. I'm going
> > to be out for most of the first week of the merge window so thought
> > I'd just preempt things and send
The "max-brightness" is a standard backlight property that
we need to support for the Samsung GT-I8190 Golden because
the display will go black if we crank up the brightness
too high.
As the platform needs this ability to give picture this is
a regression fix along with the addition of the
[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same
[Why]
If experimental freesync video mode module parameter is enabled, add
few extra display modes into the driver's mode list corresponding to common
video frame rates. When userspace sets these modes, no modeset will be
performed (if current mode was one of freesync modes or the base freesync
[Why]
Adds a module parameter to enable experimental freesync video mode modeset
optimization. Enabling this mode allows the driver to skip a full modeset when
freesync compatible modes are requested by the userspace. This paramters also
adds some standard modes based on the connected monitor's
On Thu, Dec 10, 2020 at 7:52 PM Dave Airlie wrote:
>
> This is an early pull request for drm for 5.11 merge window. I'm going
> to be out for most of the first week of the merge window so thought
> I'd just preempt things and send this early.
Ok, I've merged this, and Dave is likely gone
Changes in V3
=
1) Add freesync video modes based on preferred modes:
* Cache base freesync video mode during the first iteration to avoid
iterating over modelist again later.
* Add mode for 60 fps videos
2) Skip modeset for front porch change
* Fixes for bug exposed by caching
Applied. Thanks!
Alex
On Mon, Dec 14, 2020 at 3:18 AM Souptick Joarder wrote:
>
> Kernel test robot throws below warning ->
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_dccg.c:46:6:
> warning: no previous prototype for 'dccg21_update_dpp_dto'
> [-Wmissing-prototypes]
>
> Adding
Hi,
On Mon, Dec 14, 2020 at 08:55:36PM +0200, Tomi Valkeinen wrote:
> On 14/12/2020 19:39, Sebastian Reichel wrote:
> > Hi,
> >
> > On Tue, Dec 08, 2020 at 02:28:53PM +0200, Tomi Valkeinen wrote:
> >> ULPS doesn't work, and I have been unable to get it to work. As ULPS
> >> is a minor
On Wed, 09 Dec 2020 11:51:43 +, Lukasz Luba wrote:
> Add a property dynamic-power-coefficient which allows to register Energy
> Model for the Mali Bifrost devices.
>
> Signed-off-by: Lukasz Luba
> ---
> .../bindings/gpu/arm,mali-bifrost.yaml | 17 +
> 1 file
On Wed, 09 Dec 2020 11:51:42 +, Lukasz Luba wrote:
> Add a property dynamic-power-coefficient which allows to register Energy
> Model for the Mali Midgard devices.
>
> Signed-off-by: Lukasz Luba
> ---
> .../bindings/gpu/arm,mali-midgard.yaml | 17 +
> 1 file
On Fri, Dec 11, 2020 at 2:34 PM Souptick Joarder wrote:
>
> Kernel test robot throws below warning ->
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5349:5:
> warning: no previous prototype for 'amdgpu_dm_crtc_atomic_set_property'
> [-Wmissing-prototypes]
>
On Thu, 2020-12-10 at 20:25 +0100, Thomas Gleixner wrote:
> No driver has any business with the internals of an interrupt
> descriptor. Storing a pointer to it just to use yet another helper at
> the
> actual usage site to retrieve the affinity mask is creative at best.
> Just
> because C does not
On Thu, 2020-12-10 at 20:25 +0100, Thomas Gleixner wrote:
> Using the interrupt affinity mask for checking locality is not really
> working well on architectures which support effective affinity masks.
>
> The affinity mask is either the system wide default or set by user
> space,
> but the
Now that drm_device is embedded in rcar_du_device, we can use
container_of to get the rcar_du_device pointer from the drm_device,
instead of using the drm_device.dev_private field.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
the planes is tied to the DRM device, not the device to driver
binding. drmm_kcalloc() isn't a good option either, as it would result
in the planes being freed before being unregistered during the managed
cleanup of the DRM
Embedding drm_device in rcar_du_device allows usage of the DRM managed
API to allocate both structures in one go, simplifying error handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
The local encoder variable is an alias for >base, and is only use
twice. It doesn't help much, drop it, along with the
rcar_encoder_to_drm_encoder() macro that is then unused.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
devm_kzalloc() is the wrong API to allocate encoders, as the lifetime of
the encoders is tied to the DRM device, not the device to driver
binding. drmm_kzalloc() isn't a good option either, as it would result
in the encoder being freed before being unregistered during the managed
cleanup of the
The rcar-du driver skips registration of the encoder for the LVDS1
output when LVDS is used in dual-link mode, as the LVDS0 and LVDS1 links
are bundled and handled through the LVDS0 output. It however still
allocates the encoder and immediately destroys it, which is pointless.
Skip allocation of
The encoder->name field can never be non-null in the error path, as that
can only be possible after a successful call to
drm_simple_encoder_init(). Drop the cleanup.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
Hello,
This patch series fixes a crash in the LVDS encoder on D3 and E3 SoCs.
See patch 1/9 for details. The next patches are additional cleanups.
Patches 4/9 to 6/9 fix incorrect usage of the devm_* API. They could be
made simpler by using the proposed drmm_* allocators for encoders and
planes
Use drmm_add_action_or_reset() instead of drmm_add_action() to ensure
the vsp device reference is released in case the function call fails.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
1 file changed, 1
On D3 and E3 platforms, the LVDS encoder includes a PLL that can
generate a clock for the corresponding CRTC, used even when the CRTC
output to a non-LVDS port. This mechanism is supported by the driver,
but the implementation is broken in dual-link LVDS mode. In that case,
the LVDS1 drm_encoder
Am 2020-12-14 um 3:27 p.m. schrieb Christian König:
> Am 14.12.20 um 20:17 schrieb Daniel Vetter:
>> I guess Christian didn't compile test amdkfd.
>
> Scratching my head what has happened here. When I tested everything
> was at least building fine.
Looks like you were missing CONFIG_HSA_AMD in
Hi all,
On Tue, 8 Dec 2020 13:27:54 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/vga/vga_switcheroo.c
>
> between commit:
>
> 99efde6c9bb7 ("PCI/PM: Rename pci_wakeup_bus() to pci_resume_bus()")
>
> from the pci tree and
On Mon, Dec 14, 2020 at 4:08 AM Daniel Vetter wrote:
>
> On Sun, Dec 13, 2020 at 2:44 AM Mike Lothian wrote:
> >
> > Hi
> >
> > This patch is causing issues for me on both a Raven system and a Tonga
> > (PRIME) system
> >
> > https://gitlab.freedesktop.org/drm/amd/-/issues/1405
> >
> > It's only
Turned out I did test it, but then forgot to do git add to the changes
before pushing
It was a really long day/week/year :)
Christian.
Am 14.12.20 um 17:55 schrieb Daniel Vetter:
I think you forgot to compile test with amdkfd :-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In
Am 14.12.20 um 20:17 schrieb Daniel Vetter:
I guess Christian didn't compile test amdkfd.
Scratching my head what has happened here. When I tested everything was
at least building fine.
Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
Cc: Christian König
Cc: Huang Rui (v1)
Hi all,
On Tue, 17 Nov 2020 15:45:14 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:353: warning: Function
> parameter or member 'crc_win_x_start_property' not
On Mon, Dec 14, 2020 at 02:20:39PM -0500, Alex Deucher wrote:
> On Mon, Dec 14, 2020 at 2:17 PM Daniel Vetter wrote:
> >
> > I guess Christian didn't compile test amdkfd.
> >
> > Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
> > Cc: Christian König
> > Cc: Huang Rui (v1)
> > Cc:
The pull request you sent on Fri, 11 Dec 2020 13:52:21 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-12-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1d36dffa5d887715dacca0f717f4519b7be5e498
Thank you!
--
Deet-doot-dot, I am a bot.
Hi all,
On Mon, 16 Nov 2020 10:44:44 +1100 Stephen Rothwell
wrote:
>
> On Thu, 5 Nov 2020 17:50:31 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm tree, today's linux-next build (htmldocs) produced
> > these warnings:
> >
> > include/linux/dma-buf-map.h:106: warning: Excess
Am 2020-12-14 um 2:17 p.m. schrieb Daniel Vetter:
> I guess Christian didn't compile test amdkfd.
>
> Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
> Cc: Christian König
> Cc: Huang Rui (v1)
> Cc: Daniel Vetter
> Cc: Felix Kuehling
> Cc: amd-...@lists.freedesktop.org
>
Series is Acked-by: Andrey Grodzovsky
Andrey
On 11/27/20 9:16 AM, Christian König wrote:
We only completely delete the BO from the LRU on destruction.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +-
drivers/gpu/drm/qxl/qxl_release.c | 2 +-
On Mon, Dec 14, 2020 at 2:17 PM Daniel Vetter wrote:
>
> I guess Christian didn't compile test amdkfd.
>
> Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
> Cc: Christian König
> Cc: Huang Rui (v1)
> Cc: Daniel Vetter
> Cc: Felix Kuehling
> Cc: amd-...@lists.freedesktop.org
>
I guess Christian didn't compile test amdkfd.
Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
Cc: Christian König
Cc: Huang Rui (v1)
Cc: Daniel Vetter
Cc: Felix Kuehling
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
Hi Tomi,
On 12/11/20 12:42 PM, Tomi Valkeinen wrote:
> To support legacy gamma ioctls the drivers need to set
> drm_crtc_funcs.gamma_set either to a custom implementation or to
> drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
> latter.
>
> We can simplify this by making
On Sat, Dec 12, 2020 at 04:54:45PM +0800, Philip Li wrote:
> On Fri, Dec 11, 2020 at 04:42:00PM +0200, Ville Syrjälä wrote:
> > On Fri, Dec 11, 2020 at 01:24:49PM +0200, Tomi Valkeinen wrote:
> > > On 10/12/2020 20:06, kernel test robot wrote:
> > > > Hi Tomi,
> > > >
> > > > I love your patch!
On Mon, Dec 14, 2020 at 3:41 AM Kalyan Thota wrote:
>
> Turn off vblank irqs immediately as soon as drm_vblank_put is
> requested so that there are no irqs triggered during idle state.
>
> This will reduce cpu wakeups and help in power saving. The change
> also enable driver timestamp for
https://bugzilla.kernel.org/show_bug.cgi?id=210683
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the
Much more clear to read one function call than four lines doing this
conversion.
Cc: dri-devel@lists.freedesktop.org
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_rect.c | 15 +++
include/drm/drm_rect.h | 2 ++
2 files changed, 17
Hi,
On Tue, Dec 08, 2020 at 02:28:53PM +0200, Tomi Valkeinen wrote:
> ULPS doesn't work, and I have been unable to get it to work. As ULPS
> is a minor power-saving feature which requires substantial amount of
> non-trivial code, and we have trouble just getting and
> keeping DSI working at all,
Hi Laurent,
On 04/12/2020 22:01, Laurent Pinchart wrote:
> The rcar-du driver skips registration of the encoder for the LVDS1
> output when LVDS is used in dual-link mode, as the LVDS0 and LVDS1 links
> are bundled and handled through the LVDS0 output. It however still
> allocates the encoder and
Hi,
On Tue, Dec 08, 2020 at 02:28:55PM +0200, Tomi Valkeinen wrote:
> Panel drivers can send DSI commands in panel's prepare(), which happens
> before the bridge's enable() is called. The OMAP DSI driver currently
> only sets up the DSI interface at bridge's enable(), so prepare() cannot
> be
Hi Laurent,
On 04/12/2020 22:01, Laurent Pinchart wrote:
> The local encoder variable is an alias for >base, and is only use
> twice. It doesn't help much, drop it, along with the
> rcar_encoder_to_drm_encoder() macro that is then unused.
It does seem overkill to have a macro for only a single
At least amdgpu and i915 do, so lets just document this as the rule.
v2: Works better with less typos (intel-gfx-ci)
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
Hi Laurent,
On 14/12/2020 10:58, Jacopo Mondi wrote:
> Hi Laurent,
>
> On Sat, Dec 05, 2020 at 12:01:37AM +0200, Laurent Pinchart wrote:
>> Now that drm_device is embedded in rcar_du_device, we can use
>> container_of to get the rcar_du_device pointer from the drm_device,
>> instead of using the
On 11/12/2020 13:50, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Fri, Dec 11, 2020 at 01:42:36PM +0200, Tomi Valkeinen wrote:
>> To support legacy gamma ioctls the drivers need to set
>> drm_crtc_funcs.gamma_set either to a custom implementation or to
>>
Hi Laurent,
On 04/12/2020 22:01, Laurent Pinchart wrote:
> Embedding drm_device in rcar_du_device allows usage of the DRM managed
> API to allocate both structures in one go, simplifying error handling.
No point making multiple allocations unnecessarily...
LGTM.
Reviewed-by: Kieran Bingham
I think you forgot to compile test with amdkfd :-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function ‘add_bo_to_vm’:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:456:37: error:
‘struct ttm_resource’ has no member named ‘size’
456 | unsigned long bo_size = bo->tbo.mem.size;
Hi,
On Tue, Dec 08, 2020 at 02:28:54PM +0200, Tomi Valkeinen wrote:
> We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when
> the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this
> right by accident, but now we set DCS_CMD_ENABLE for video mode panels
> too.
>
>
Hi,
On Tue, Dec 08, 2020 at 02:28:52PM +0200, Tomi Valkeinen wrote:
> The driver ignores MIPI_DSI_CLOCK_NON_CONTINUOUS, and always uses
> non-continuous clock.
>
> Fix this by using MIPI_DSI_CLOCK_NON_CONTINUOUS and at the same time,
> drop ddr_clk_always_on field which seems pretty useless.
>
Hi,
On Tue, Dec 08, 2020 at 02:28:51PM +0200, Tomi Valkeinen wrote:
> Clean up the code by separating video-mode enable/disable code into
> functions of their own.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Tue, Dec 08, 2020 at 02:28:50PM +0200, Tomi Valkeinen wrote:
> As we now have a fixed setup for VCs (VC0 for video stream, VC1 for
> commands), we can simplify the VC setup.
>
> Signed-off-by: Tomi Valkeinen
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi Kieran,
On Mon, Dec 14, 2020 at 04:20:17PM +, Kieran Bingham wrote:
> On 04/12/2020 22:01, Laurent Pinchart wrote:
> > devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
> > the planes is tied to the DRM device, not the device to driver
> > binding. drmm_kcalloc() isn't
On Fri, Dec 11, 2020 at 09:04:02AM +0200, Chery, Nanley G wrote:
> [...]
> > > We probably don't have to update the header, but we noticed in our
> > > testing that the clear color prefers an alignment greater than 64B.
> > > Unfortunately, I can't find any bspec note about this. As long as the
>
Hi,
On Tue, Dec 08, 2020 at 02:28:49PM +0200, Tomi Valkeinen wrote:
> The function names have evolved to be very confusing, and bunch of them
> have "display" in them even if the function doesn't deal with display as
> such (e.g. dsi_display_enable which just enables the DSI interface).
> Rename
Hi Laurent,
On 04/12/2020 22:01, Laurent Pinchart wrote:
> devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
> the planes is tied to the DRM device, not the device to driver
> binding. drmm_kcalloc() isn't a good option either, as it would result
> in the planes being freed
Hi Maxime,
On 2020-12-14 15:27, Maxime Ripard wrote:
Hi Marc,
On Thu, Dec 10, 2020 at 05:59:09PM +, Marc Zyngier wrote:
[...]
I'm always sceptical of making interrupt controllers user-selectable.
Who is going to know that they need to pick that one?
I'd be much more in favour of
Hi,
On Tue, Dec 08, 2020 at 02:28:48PM +0200, Tomi Valkeinen wrote:
> We can drop dsi_display_disable() which just calls
> _dsi_display_disable(), and rename _dsi_display_disable() to
> dsi_display_disable().
>
> The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_disable is extra and
> can be
Hi,
On Tue, Dec 08, 2020 at 02:28:47PM +0200, Tomi Valkeinen wrote:
> We can drop dsi_display_enable(), which just calls
> _dsi_display_enable(), and rename _dsi_display_enable() to
> dsi_display_enable().
>
> The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_enable is extra and
> can be
Hi,
On Tue, Dec 08, 2020 at 02:28:46PM +0200, Tomi Valkeinen wrote:
> Clean up the code by inlining dsi_enable_video_outputs and
> dsi_disable_video_outputs functions.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Tue, Dec 08, 2020 at 02:28:45PM +0200, Tomi Valkeinen wrote:
> Move structs and defines to a private dsi.h header file to make dsi.c a
> bit easier to navigate. Also move the (now) private structs and defines
> from omapdss.h to dsi.h.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by:
Hi,
On Tue, Dec 08, 2020 at 02:28:44PM +0200, Tomi Valkeinen wrote:
> Drop unneeded includes.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-dsi-cm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git
On Tue, Dec 08, 2020 at 02:28:43PM +0200, Tomi Valkeinen wrote:
> Add a panel database to the driver instead of reading propertes from DT
> data. This is similar to panel-simple, and I believe it's more future
> safe way to handle the panels.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Sam
On Mon, Dec 14, 2020 at 09:33:17PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/video/fbdev/s3c2410fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Krzysztof Kozlowski
On Mon, Dec 14, 2020 at 11:33:10AM +0100, Christian König wrote:
> Am 11.12.20 um 16:58 schrieb Daniel Vetter:
> > Also try to clarify a bit when dma_buf_begin/end_cpu_access should
> > be called.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Thomas Zimmermann
> > Cc: Sumit Semwal
> > Cc:
1 - 100 of 218 matches
Mail list logo
