Hello Andre,
On 15/08/2023 21:50, André Almeida wrote:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
v4:
Due to the difference of HW, different dividers need to be set.
Signed-off-by: Shuijing Li
---
Changes in v4:
list all configuration for MT8188 and MT8195.
per suggestion from the previous thread:
https://lore.kernel.org/all/a9d1b9b7ef4780f51574d0bbbe28f6dd109a6ab8.ca...@mediatek.com/
Changes in
The audio packet arrangement function is to only arrange audio
packets into the Hblanking area. In order to align with the HW
default setting of mt8195, this function needs to be turned off.
Signed-off-by: Shuijing Li
---
Changes in v5:
Separate mt8188 related code into mtk_dp_data structure and
Add mtk_dp_audio_sample_arrange_disable function for MT8188.
Signed-off-by: Shuijing Li
---
Changes in v5:
Separate mt8188 related code into mtk_dp_data structure and mt8188 dp/edp
function
per suggestion from the previous thread:
https://lore.kernel.org/lkml/c1c84616f3da83a8a2bc245b0d3c7697153c
Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC.
Mainly add the following two flag:
1.The audio packet arrangement function is to only arrange audio
packets into the Hblanking area. In order to align with the HW
default setting of g1200, this function needs to be turned off.
2.Due t
Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC.
Signed-off-by: Shuijing Li
Signed-off-by: Jitao Shi
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Acked-by: Krzysztof Kozlowski
---
Changes in v2:
add a mediatek,mt8188-edp-tx compatible per suggestion from the previ
On 11.08.2023 14:59, Robert Foss wrote:
> On Wed, 9 Aug 2023 16:56:41 +0200, Marek Szyprowski wrote:
>> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
>> doesn't report empty level of packer header FIFO. In case of those SoCs,
>> use the old way of waiting for empty command t
The val is defined as unsigned int type, if(val<0) is invalid, modify
to int type.
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_pm.c:2813
amdgpu_hwmon_show_power_input() warn: unsigned 'val' is never less than zero.
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_pm.c:2800 amdgpu_hwmon_show_power_avg()
warn:
Am 16.08.23 um 18:33 schrieb Danilo Krummrich:
On 8/16/23 16:59, Christian König wrote:
Am 16.08.23 um 14:30 schrieb Danilo Krummrich:
On 8/16/23 16:05, Christian König wrote:
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel
Hi,
On 8/16/2023 10:05 PM, Dmitry Osipenko wrote:
On 8/16/23 21:10, Kim, Dongwon wrote:
Hi,
On 8/14/2023 9:18 PM, Dmitry Osipenko wrote:
On 7/13/23 01:44, Dongwon Kim wrote:
virtio_gpu_fence_release is added to free virtio-gpu-fence
upon release of dma_fence.
Cc: Gerd Hoffmann
Cc: Vivek Ka
[Public]
Hi Xinhui,
That patch has been reverted on Linux mainline.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/scheduler/sched_main.c?h=v6.5-rc6&id=baad10973fdb442912af676de3348e80bd8fe602
Regards,
Guchun
> -Original Message-
> From: amd-g
[AMD Official Use Only - General]
Can we just add kref for entity?
Or just collect such job time usage somewhere else?
-Original Message-
From: Pan, Xinhui
Sent: Thursday, August 17, 2023 1:05 PM
To: amd-...@lists.freedesktop.org
Cc: Tuikov, Luben ; airl...@gmail.com;
dri-devel@lists.fr
On 8/16/23 21:10, Kim, Dongwon wrote:
> Hi,
>
> On 8/14/2023 9:18 PM, Dmitry Osipenko wrote:
>> On 7/13/23 01:44, Dongwon Kim wrote:
>>> virtio_gpu_fence_release is added to free virtio-gpu-fence
>>> upon release of dma_fence.
>>>
>>> Cc: Gerd Hoffmann
>>> Cc: Vivek Kasireddy
>>> Signed-off-by:
This patch partially revert commit df622729ddbf ("drm/scheduler: track
GPU active time per entity") which touchs entity without any reference.
I notice there is one memory overwritten from gpu scheduler side.
The case is like below.
A(drm_sched_main) B(vm fini)
drm_sched_job_
On 8/17/2023 2:16 AM, Alex Deucher wrote:
On Wed, Aug 16, 2023 at 12:15 AM Lijo Lazar wrote:
7957ec80ef97 ("drm/amdgpu: Add FRU sysfs nodes only if needed") moved
the documentation for some of the sysfs nodes to amdgpu_fru_eeprom.c.
Update the documentation accordingly.
Signed-off-by: Lijo
On 2023/8/16 23:01, kernel test robot wrote:
Hi Qi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on linus/master v6.5-rc6 next-20230816]
[cannot apply to akpm-mm/mm-everything drm-misc/drm-misc-next
vfs
> -Original Message-
> From: Dave Airlie
> Sent: August 16, 2023 6:52 PM
> To: Felix Kuehling
> Cc: Zeng, Oak ; Christian König
> ; Thomas Hellström
> ; Brost, Matthew
> ; maarten.lankho...@linux.intel.com;
> Vishwanathapura, Niranjana ; Welty,
> Brian ; Philip Yang ; intel-
> x...@lists.
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-tip/drm-tip linus/master v6.5-rc6
next-20230816]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Thu, Aug 17, 2023 at 12:14 AM Borislav Petkov wrote:
>
> On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote:
> > that GPU has only a `DMS-59` connector, is that right?
>
> No clue. How do I figure that out?
>
do you have one of these? https://en.wikipedia.org/wiki/DMS-59
> --
> Rega
If we can't load the HuC due to an injected failure, we don't want
to throw and error and trip CI. Using the gt_probe_error macro for
logging ensure that the error is only printed if it wasn't explicitly
injected.
v2: keep the line to less than 100 characters (checkpatch).
Link: https://gitlab.fr
On Thu, 17 Aug 2023 at 08:15, Felix Kuehling wrote:
>
> On 2023-08-16 13:30, Zeng, Oak wrote:
> > I spoke with Thomas. We discussed two approaches:
> >
> > 1) make ttm_resource a central place for vram management functions such as
> > eviction, cgroup memory accounting. Both the BO-based driver a
On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote:
> that GPU has only a `DMS-59` connector, is that right?
No clue. How do I figure that out?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2023-08-16 13:30, Zeng, Oak wrote:
I spoke with Thomas. We discussed two approaches:
1) make ttm_resource a central place for vram management functions such as
eviction, cgroup memory accounting. Both the BO-based driver and BO-less SVM
codes call into ttm_resource_alloc/free functions for
On Wed, Aug 16, 2023 at 5:13 PM Borislav Petkov wrote:
>
> On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote:
> > Do you have any connectors listed in "/sys/class/drm"?
>
> tree /sys/class/drm/
> /sys/class/drm/
> ├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0
Applied. Thanks!
Alex
On Tue, Aug 15, 2023 at 10:20 PM Chen Jiahao wrote:
>
> Using kmemdup() helper function rather than implementing it again
> with kmalloc() + memcpy(), which improves the code readability.
>
> Signed-off-by: Chen Jiahao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors
Reviewed-by: Lyude Paul
On Mon, 2023-08-14 at 16:49 +0200, Karol Herbst wrote:
> We can't simply free the connector after calling drm_connector_init on it.
> We need to clean up the drm side first.
>
> It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp:
> PIOR DP uses GPIO for
On Wed, Aug 16, 2023 at 12:15 AM Lijo Lazar wrote:
>
> 7957ec80ef97 ("drm/amdgpu: Add FRU sysfs nodes only if needed") moved
> the documentation for some of the sysfs nodes to amdgpu_fru_eeprom.c.
> Update the documentation accordingly.
>
> Signed-off-by: Lijo Lazar
> ---
> Documentation/gpu/amd
On Wed, Aug 16, 2023 at 12:05:06PM -0600, Gustavo A. R. Silva wrote:
> Fix checkpatch.pl ERROR: do not use assignment in if condition.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
--
Kees Cook
On Wed, Aug 16, 2023 at 12:04:06PM -0600, Gustavo A. R. Silva wrote:
> One-element and zero-length arrays are deprecated. So, replace
> one-element array in struct nouveau_svm with flexible-array member.
>
> This results in no differences in binary output.
>
> Link: https://github.com/KSPP/linux/
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ef66bf8aeb91fd331cf8f5dca8f9d7bca9ab2849 Add linux-next specific
files for 20230816
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202307281049.40t8s0uv-...@intel.com
https
satile_clcd_type = (enum
versatile_clcd)(uintptr_t)clcd_id->data;
}
map = syscon_node_to_regmap(np);
---
base-commit: 2ccdd1b13c591d306f0401d98dedc4bdcd02b421
change-id: 20230816-void-drivers-gpu-drm-pl111-pl111_versatile-43b109cfa7ad
Best regards,
--
Justin Stitt
Hi Dave, Daniel,
Fixes for 6.5.
The following changes since commit 2ccdd1b13c591d306f0401d98dedc4bdcd02b421:
Linux 6.5-rc6 (2023-08-13 11:29:55 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.5-2023-08-16
for you to fetch
num repaper_model)match;
+ model = (enum repaper_model)(uintptr_t)match;
} else {
spi_id = spi_get_device_id(spi);
model = (enum repaper_model)spi_id->driver_data;
---
base-commit: 2ccdd1b13c591d306f0401d98dedc4bdcd02b421
change-id: 20230816
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) ---
Are any of the external display connectors driven by the APU? If so, do any of
those work correctly on resume?
--
You may reply to this email to add a comment.
You are receiving thi
Hi,
On 8/14/2023 9:18 PM, Dmitry Osipenko wrote:
On 7/13/23 01:44, Dongwon Kim wrote:
virtio_gpu_fence_release is added to free virtio-gpu-fence
upon release of dma_fence.
Cc: Gerd Hoffmann
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 8 +
Fix checkpatch.pl ERROR: do not use assignment in if condition.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index
One-element and zero-length arrays are deprecated. So, replace
one-element array in struct nouveau_svm with flexible-array member.
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/338
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nouve
This small series aims to replace a one-element array with a
flexible-array member in struct nouveau_svm. And, while at it,
fix a checkpatch.pl error.
Gustavo A. R. Silva (2):
nouveau/svm: Replace one-element array with flexible-array member in
struct nouveau_svm
nouveau/svm: Split assignm
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) ---
The display mux is a switch that controls what GPU the built in display is
routed to (dGPU or APU). If it's not set correctly it can route the display to
the wrong GPU. AFAIK, it shou
I spoke with Thomas. We discussed two approaches:
1) make ttm_resource a central place for vram management functions such as
eviction, cgroup memory accounting. Both the BO-based driver and BO-less SVM
codes call into ttm_resource_alloc/free functions for vram allocation/free.
*This way BO d
On 16/08/2023 14:25, Tomi Valkeinen wrote:
This series contains various fixes and cleanups for TC358768. The target
of this work is to get TC358768 working on Toradex's AM62 based board,
which has the following display pipeline:
AM62 DPI -> TC358768 -> LT8912B -> HDMI connector
The main thing t
On 16/08/2023 18:30, Thierry Reding wrote:
On Mon, Aug 07, 2023 at 02:33:00PM +0100, Diogo Ivo wrote:
Hello,
These patches add support for the JDI LPM102A188A display panel,
found in the Google Pixel C.
Patch 1 adds the DT bindings for the panel.
Patch 2 adds the panel driver, which is based
Hi,
On Mon, 07 Aug 2023 14:33:00 +0100, Diogo Ivo wrote:
> These patches add support for the JDI LPM102A188A display panel,
> found in the Google Pixel C.
>
> Patch 1 adds the DT bindings for the panel.
>
> Patch 2 adds the panel driver, which is based on the downstream
> kernel driver published
Hi,
On Mon, 14 Aug 2023 15:40:24 +0200, Luca Ceresoli wrote:
> This panel has been implemented in commit 225213f24c79 ("drm/panel-simple:
> Add Innolux G156HCE-L01 panel entry") with a higher clock than the typical
> one mentioned on the documentation to avoid flickering on the unit
> tested. Test
That's actually a bit of a tricky question. It seems that the existing IGT
syncobj_timeline test asserts the incorrect behavior that waiting for an
unsubmitted fence with WAIT_AVAILABLE set should fail with EINVAL.
I've sent a patch to igt-dev correcting this
https://lists.freedesktop.org/archi
On 07/08/2023 15:33, Diogo Ivo wrote:
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
https://android.googlesource.com
BTW, question: do you know if we could add an IGT test to make sure we
don't regress this?
On 8/16/23 16:59, Christian König wrote:
Am 16.08.23 um 14:30 schrieb Danilo Krummrich:
On 8/16/23 16:05, Christian König wrote:
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
On Mon, Aug 07, 2023 at 02:33:00PM +0100, Diogo Ivo wrote:
> Hello,
>
> These patches add support for the JDI LPM102A188A display panel,
> found in the Google Pixel C.
>
> Patch 1 adds the DT bindings for the panel.
>
> Patch 2 adds the panel driver, which is based on the downstream
> kernel dri
From: Thierry Reding
On Mon, 07 Aug 2023 14:33:00 +0100, Diogo Ivo wrote:
> These patches add support for the JDI LPM102A188A display panel,
> found in the Google Pixel C.
>
> Patch 1 adds the DT bindings for the panel.
>
> Patch 2 adds the panel driver, which is based on the downstream
> kern
If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been
submitted for the given timeline point the call will fail immediately
with EINVAL. This does not match the intended behavior where the call
should wait until the fence has
https://bugzilla.kernel.org/show_bug.cgi?id=201847
Simon Fogliato (simonfogli...@gmail.com) changed:
What|Removed |Added
CC||simonfogli...@g
On 09/08/2023 17:53, Boris Brezillon wrote:
> Contains everything that's FW related, that includes the code dealing
> with the microcontroller unit (MCU) that's running the FW, and anything
> related to allocating memory shared between the FW and the CPU.
>
> A few global FW events are processed i
[AMD Official Use Only - General]
Thanks Li, for the fix, the fix is already in process of merging into
amd-staging-drm-next.
https://patchwork.freedesktop.org/patch/552568/
-Original Message-
From: amd-gfx On Behalf Of Yang Li
Sent: Wednesday, August 16, 2023 6:16 AM
To: airl...@gmail
On 8/16/23 16:38, Matthew Brost wrote:
On Wed, Aug 16, 2023 at 02:30:38PM +0200, Danilo Krummrich wrote:
On 8/16/23 16:05, Christian König wrote:
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #11 from Jose Roberto (colombo...@gmail.com) ---
If I may: have you tried to disable (or even better, uninstall) tlp? Most of
modern GNU/Linuxes come with it previously installed.
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #10 from popus_czy_to_ty (pentelja...@o2.pl) ---
aafter reinstalling and many times trying response for your questions is
1 (mux) whatever it is --> no
2 no
3 no, via command its dead also
4.no
5. insyde corp (bios manufacturer doesn
Hi Dave, Daniel,
please pull the following etnaviv changes for the next merge window.
This time mostly cleanups around the runtime power management handling
and slightly improved GPU hang handling. Also some additions to the
HWDB to get the driver working properly on more NXP i.MX8MP IP cores.
On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote:
> Do you have any connectors listed in "/sys/class/drm"?
tree /sys/class/drm/
/sys/class/drm/
├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0
├── renderD128 ->
../../devices/pci:00/:00:02.0/:03:00.
Hi Qi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on linus/master v6.5-rc6 next-20230816]
[cannot apply to akpm-mm/mm-everything drm-misc/drm-misc-next
vfs-idmapping/for-next]
[If your patch is applied to the
Am 16.08.23 um 14:30 schrieb Danilo Krummrich:
On 8/16/23 16:05, Christian König wrote:
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and dr
On Wed, Aug 16, 2023 at 4:54 PM Borislav Petkov wrote:
>
> On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> > Mind sharing your kernel logs with that patch applied? I suspect your
> > system boots up but you might just not have the connector available or
> > something? It could be t
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> Mind sharing your kernel logs with that patch applied? I suspect your
> system boots up but you might just not have the connector available or
> something? It could be that you have one of those GPUs affected by the
> original change a
On Wed, Aug 16, 2023 at 02:30:38PM +0200, Danilo Krummrich wrote:
> On 8/16/23 16:05, Christian König wrote:
> > Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
> > > Hi Matt,
> > >
> > > On 8/11/23 04:31, Matthew Brost wrote:
> > > > In XE, the new Intel GPU driver, a choice has made to have a 1 t
On 8/16/23 16:05, Christian König wrote:
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd bu
https://bugzilla.kernel.org/show_bug.cgi?id=217797
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
Am 16.08.23 um 15:41 schrieb Hamza Mahfooz:
On 8/16/23 01:55, Christian König wrote:
Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). How
Am 16.08.23 um 13:30 schrieb Danilo Krummrich:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1.
Hi Qi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on linus/master v6.5-rc6 next-20230816]
[cannot apply to akpm-mm/mm-everything drm-misc/drm-misc-next
vfs-idmapping/for-next]
[If your patch is applied to the
On 8/16/23 01:55, Christian König wrote:
Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-
[AMD Official Use Only - General]
Reviewed-by: Alex Deucher
From: Lazar, Lijo
Sent: Tuesday, August 15, 2023 11:56 PM
To: amd-...@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; s...@canb.auug.org.au ;
airl...@redhat.com ; dri-devel@lists.freed
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In XE the submission order from multiple drm_sch
Hi Qi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on linus/master v6.5-rc6 next-20230816]
[cannot apply to akpm-mm/mm-everything drm-misc/drm-misc-next
vfs-idmapping/for-next]
[If your patch is applied to the
https://bugzilla.kernel.org/show_bug.cgi?id=217664
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up
operation, but it misses subtracting one from the dividend.
Fix this by just using DIV_ROUND_UP().
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358768.c
The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer
to clock periods. The original author does not remember where all this
came from. Effectively the driver is using picoseconds as the unit for
clock periods, yet referring to them by "nsk".
Clean this up by just saying the perio
As the TC358768 is a DPI to DSI bridge, the DSI side does not need to
define h/v sync polarities. This means that sometimes we have a mode
without defined sync polarities, which does not work on the DPI side.
Add a mode_fixup hook to default to positive sync polarities.
Signed-off-by: Tomi Valkei
The DSI horizontal timing calculations done by the driver seem to often
lead to underflows or overflows, depending on the videomode.
There are two main things the current driver doesn't seem to get right:
DSI HSW and HFP, and VSDly. However, even following Toshiba's
documentation it seems we don't
The TC358768 documentation uses HFP, HBP, etc. values to deal with the
video mode, while the driver currently uses the DRM display mode
(htotal, hsync_start, etc).
Change the driver to convert the DRM display mode to struct videomode,
which then allows us to use the same units the documentation us
The Toshiba documentation talks about HSByteClk when referring to the
DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a
few places the driver calculates the byte clock from the DSI clock, even
if the byte clock is already available in a variable.
To align the driver with the do
As is quite common, some of TC358768's PLL register fields are to be
programmed with (value - 1). Specifically, the FBD and PRD, multiplier
and divider, are such fields.
However, what the driver currently does is that it considers that the
formula used for PLL rate calculation is:
RefClk * [(FBD
The driver debug prints DSI related timings as raw register values in
hex. It is much more useful to see the "logical" value of the timing,
not the register value.
Change the prints to print the values separately, in case a single
register contains multiple values, and use %u to have it in a more
Simplify the code by capturing the priv->dev value to dev variable, and
use it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358768.c | 41 ---
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358768.c
b/d
The driver has a few places where it does:
if (thing_is_enabled_in_config)
update_thing_bit_in_hw()
This means that if the thing is _not_ enabled, the bit never gets
cleared. This affects the h/vsyncs and continuous DSI clock bits.
Fix the driver to always update the bit.
Fixes: ff1ca63
smatch reports:
drivers/gpu/drm/bridge/tc358768.c:223 tc358768_update_bits() error:
uninitialized symbol 'orig'.
Fix this by bailing out from tc358768_update_bits() if the
tc358768_read() produces an error.
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Tomi Valkeinen
-
From: Thierry Reding
The polarities of the V- and H-sync signals are encoded as flags in the
display mode, so use the existing information to setup the signals for
the RGB interface.
Signed-off-by: Thierry Reding
Cc: Thierry Reding
[tomi.valkei...@ideasonboard.com: default to positive sync]
Si
This series contains various fixes and cleanups for TC358768. The target
of this work is to get TC358768 working on Toradex's AM62 based board,
which has the following display pipeline:
AM62 DPI -> TC358768 -> LT8912B -> HDMI connector
The main thing the series does is to improve the DSI HSW, HFP
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
index f9893d7d6dfc..e9e59c5e
Hi Sarah,
Le mercredi 16 août 2023 à 09:25 +0100, Sarah Walker a écrit :
> Add power management to the driver, using runtime pm. The power off
> sequence depends on firmware commands which are not implemented in
> this
> patch.
>
> Changes since v4:
> - Suspend runtime PM before unplugging device
Fix a warning about casting an integer of different size in
ttm_pool_alloc_basic_dma_addr() subtest. Cast the DMA address to
uintptr_t before casting it to a generic pointer.
Signed-off-by: Karolina Stolarek
Cc: Christian König
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-
Rename the "connector" member of the shmob_drm_connector subclass
structure to "base", to improve readability.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Sui Jingfeng
---
v3:
- No changes,
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_
Convert to managed IRQ handling, to simplify cleanup.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v3:
- No changes,
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git
Hi all,
It has been 3 years since the last conversion of a DRM driver to atomic
modesetting, so I guess it's time for another one? ;-)
Currently, there are two drivers for the LCD controller on Renesas
SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
1. sh_mobile_lcdcfb, using th
From: Laurent Pinchart
Backlight support should be implemented by panels, not by the LCDC
driver. As the feature is currently unused anyway, remove it.
Signed-off-by: Laurent Pinchart
[geert: Cleanups]
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v3:
- No changes,
v
According to the comments for drm_universal_plane_init(), the plane
structure should not be allocated with devm_kzalloc().
Fix lifetime issues by using drmm_universal_plane_alloc() instead.
Signed-off-by: Geert Uytterhoeven
---
v3:
- No changes,
v2:
- Split off removal of call to drm_plane_
When configuring a CHn Source Image Format Register (LDBBSIFR), one
should use the corresponding LDBBSIFR_RPKF_* definition for overlay
planes, not the DDFR_PKF_* definition for the primary plane.
Fortunately both definitions resolve to the same value, so this bug did
not cause any harm.
Signed-o
Add the RGB666 9:9 format MEDIA_BUS_FMT_RGB666_2X9_BE, which is
supported by the SH-Mobile LCD Controller.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
v3:
- No changes,
v2:
- Add Reviewed-b
Rename the "crtc" member of the shmob_drm_crtc subclass structure to
"base", to improve readability.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Sui Jingfeng
---
v3:
- No changes,
v2:
- Add Reviewed-by.
---
.../gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 2
Unify primary and overlay plane allocation:
- Enhance shmob_drm_plane_create() so it can be used to create the
primary plane, too,
- Move overlay plane creation next to primary plane creation.
Signed-off-by: Geert Uytterhoeven
---
v3:
- No changes,
v2:
- Pass plane type to shmob_drm_
When the device is unbound from the driver, the display may be active.
Make sure it gets shut down.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v3:
- No changes,
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 2 ++
1 file changed, 2 in
1 - 100 of 188 matches
Mail list logo
