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")
Reviewed-by: Peter Ujfalusi
Tested-by: Maxim Schwalm # Asus TF700T
T
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
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
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
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
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.
Reviewed-by: Peter Ujfalus
Simplify the code by capturing the priv->dev value to dev variable, and
use it.
Reviewed-by: Peter Ujfalusi
Tested-by: Maxim Schwalm # Asus TF700T
Tested-by: Marcel Ziswiler
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358768.c | 41 ---
1 fil
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
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]
Re
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
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")
Reviewed-by: Peter Ujfalusi
Tes
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
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
> On 8/23/2023 10:37, John Harrison wrote:
> > On 8/23/2023 09:00, Daniel Vetter wrote:
> > > On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
> > > > On 8/11/2023 11:20, Zhanjun Dong wrote:
> > > > > This attempts to avoi
Am 05.09.23 um 16:28 schrieb Sui Jingfeng:
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already mad
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above m
Hi,
On Di, 2023-09-05 at 13:29 -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Sep 4, 2023 at 1:30 AM Philipp Zabel wrote:
> >
> > On Fr, 2023-09-01 at 16:41 -0700, Douglas Anderson wrote:
> > > Based on grepping through the source code this driver appears to be
> > > missing a call to drm_atomic
Hi Maxime,
On 05/09/23 19:10, Maxime Ripard wrote:
With,
&usb {
dr_mode = "host";
};
The target is <0x> and fdtoverlay fails to apply the dtbo.
You do have /plugin/ and have compiled the base device tree with overlay
support, right?
After compiling base dtbs with overlay sup
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
You might have found a bug in the ast driver. Ast has means to detect
if the device has been POSTed and maybe do that. If this doesn't work
correctly, it needs a fix.
That sounds fine.
The bug is not a big deal, I'm just take it as an example
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist. 'Primary' is the device that is available via VGA, VESA or EFI.
I may miss the point, what do you means by choose the word "modern"?
Are you trying to tell me that X se
On Tue, 2023-09-05 at 18:02 +0800, Konstantin Meskhidze wrote:
> Since size of 'header' pointer and '*header' structure is equal on 64-bit
> machines issue probably didn't cause any wrong behavior. But anyway,
> fixing typo is required.
>
> Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead
On 2023/9/5 23:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which
one is prim
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist.
No, it do exist. X server need to know which one is the primary GPU.
The '*' character at the of (4@0:0:0) PCI device is the Primary.
The '*' denote primary, see the l
On 2023-09-05 04:25:19, Dmitry Baryshkov wrote:
> The function _dpu_hw_sspp_setup_scaler3() passes and
> dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
> the scaler (QSEED3) block should be programmed. However up to now we
> were not setting this field. Set it now, splitti
On Wed, Aug 30, 2023 at 8:51 AM Adrián Larumbe
wrote:
>
> >> The current implementation will try to pick the highest available
> >> unit. This is rather unflexible, and allowing drivers to display BO size
> >> statistics through fdinfo in units of their choice might be desirable.
> >>
> >> The new
Quoting Dmitry Baryshkov (2023-09-03 15:40:49)
> On 29/08/2023 21:47, Stephen Boyd wrote:
> > This function is simply drm_dp_is_branch() so use that instead of
> > open-coding it.
> >
> > Cc: Vinod Polimera
> > Cc: Kuogee Hsieh
> > Signed-off-by: Stephen Boyd
> > ---
> > drivers/gpu/drm/msm/dp
The previous patch exposed the accumulated amount of active time per
client for each V3D queue. But this doesn't provide a global notion of
the GPU usage.
Therefore, provide the accumulated amount of active time for each V3D
queue (BIN, RENDER, CSD, TFU and CACHE_CLEAN), considering all the jobs
s
This patchset exposes GPU usages stats both globally and per-file
descriptor.
The first patch exposes the accumulated amount of active time per client
through the fdinfo infrastructure. The amount of active time is exposed
for each V3D queue. Moreover, it exposes the number of jobs submitted to
ea
This patch exposes the accumulated amount of active time per client
through the fdinfo infrastructure. The amount of active time is exposed
for each V3D queue: BIN, RENDER, CSD, TFU and CACHE_CLEAN.
In order to calculate the amount of active time per client, a CPU clock
is used through the functio
To fully cover drm_fb_blit(), add format conversion tests that are only
supported through drm_fb_blit().
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 142 +
1 file changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_form
Add a call to drm_fb_blit() on existing format conversion tests that
has support.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 142 +
1 file changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/dri
This patchset tests the drm_fb_blit() function.
As this function can be used with already tested formats, the first
patch adds calls to drm_fb_blit() on the tests of supported formats.
Some supported formats were not yet covered by the existing tests
because they are only supported by drm_fb_blit
Hi,
On Mon, Sep 4, 2023 at 12:55 AM Maxime Ripard wrote:
>
> On Fri, 1 Sep 2023 16:39:52 -0700, Douglas Anderson wrote:
> > As with other places in the Linux kernel--kfree(NULL) being the most
> > famous example--it's convenient to treat being passed a NULL argument
> > as a noop in cleanup funct
Hi,
On Mon, Sep 4, 2023 at 12:28 AM Geert Uytterhoeven wrote:
>
> Hi Douglas,
>
> On Sat, Sep 2, 2023 at 1:42 AM Douglas Anderson wrote:
> > Based on grepping through the source code, this driver appears to be
> > missing a call to drm_atomic_helper_shutdown(), or in this case the
> > non-atomic
Hi Dmitry,
On 8/31/2023 3:51 PM, Dmitry Osipenko wrote:
On 8/24/23 20:58, Kim, Dongwon wrote:
...
You can do fence-wait in the guest userspace/Mesa after blitting/drawing
to the udmabuf.
There is already synchronization between QEMU and virtio-gpu driver on
the guest. Upon resource flush, virt
Dne sobota, 02. september 2023 ob 01:39:53 CEST je Douglas Anderson
napisal(a):
> Based on grepping through the source code these drivers appear to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won'
Hi Elmar,
Just had a few minor comments:
Looking at past panel-simple changes, I think the prefix here should be
"drm/panel: simple:"
On 8/28/2023 2:49 AM, Elmar Albert wrote:
From: Elmar Albert
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driv
Hi,
On Mon, Sep 4, 2023 at 1:30 AM Philipp Zabel wrote:
>
> On Fr, 2023-09-01 at 16:41 -0700, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown time
> > and at driver unbind time. A
Hi Rob,
On 21.08.23 18:14, Rob Herring wrote:
> On Mon, Aug 07, 2023 at 05:35:12PM +0300, Svyatoslav Ryhel wrote:
>> From: Maxim Schwalm
>>
>> Either this node, which is optional, or the nvidia,panel property can be
>> present.
>>
>> Signed-off-by: Maxim Schwalm
>> Signed-off-by: Svyatoslav Ryhe
Paul,
On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil wrote:
>
> Hi Douglas,
>
> Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a écrit :
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown
> > t
On Wed, Aug 16, 2023 at 11:15:47AM +0200, Thomas Hellström wrote:
> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
>
> The document describes and discuss the locking used during exec-
> functions, evicton and for userptr
Meteorlake has been very usable for a while now, all of uapi changes
related to fundamental platform usage have been finalized and all
required firmware blobs are available. Recent CI results have also
been healthy, so we're ready to drop the force_probe requirement and
enable the platform by defau
On 2023-09-05 14:53, Hamza Mahfooz wrote:
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab
Hi,
On Thu, Aug 10, 2023 at 1:23 AM Linus Walleij wrote:
>
> On Fri, Aug 4, 2023 at 11:07 PM Douglas Anderson
> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that was
Hi,
On Tue, Sep 5, 2023 at 9:45 AM Doug Anderson wrote:
>
> As per our discussion, in V2 we will make drm_panel_remove() actually
> unprepare / disable a panel if it was left enabled. This would
> essentially fold in the drm_panel_helper_shutdown() from my RFC patch.
> This would make tdo_tl070ws
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes: a
Some BO's might be mapped onto physical memory chunkwise and on demand,
like Panfrost's tiler heap. In this case, even though the
drm_gem_shmem_object page array might already be allocated, only a very
small fraction of the BO is currently backed by system memory, but
drm_show_memory_stats will the
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier.
By selecting a higher threshold, we could show more accurate size numbers.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/drm_file.c | 2 +-
1 f
BO's RSS is updated every time new pages are allocated on demand and mapped
for the object at GPU page fault's IRQ handler, but only for heap buffers.
The reason this is unnecessary for non-heap buffers is that they are mapped
onto the GPU's VA space and backed by physical memory in their entirety
Allow user space to decide whether the cycle counting register should be
enabled. The main goal is letting tools like nvtop or IGT's gputop access
this information in debug builds to obtain engine utilisation numbers.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/Makefile
A new DRM GEM object function is added so that drm_show_memory_stats can
provide more accurate memory usage numbers.
Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
after locking the driver's shrinker mutex, but drm_show_memory_stats takes
over the drm file's object handl
In a future development, we will want to keep track of the number of GPU
cycles spent on a given job. That means we should enable it only when the
GPU has work to do, and switch it off whenever it is idle to avoid power
waste.
To avoid race conditions during enablement/disabling, a reference count
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a single
set of key:value pairs is provided for the whole render engine. However,
Panfrost has separat
This patch series adds fdinfo support to the Panfrost DRM driver. It will
display a series of key:value pairs under /proc/pid/fdinfo/fd for render
processes that open the Panfrost DRM file.
The pairs contain basic drm gpu engine and memory region information that
can either be cat by a privileged
These GPU registers will be used when programming the cycle counter, which
we need for providing accurate fdinfo drm-cycles values to user space.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 5 +
1 file
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: f45acf7acf75921c0409d452f0165f51a19a74fd
commit: 8e455145d8f163aefa6b9cc29478e0a9f82276e6 [3/3] drm/debugfs: rework
drm_debugfs_create_files implementation v2
config: openrisc-randconfig-r015-20230906
(https://download.01.or
From: Konrad Dybcio
Add support for MSM8996, which - fun fact - was the SoC that this driver
(or rather SDE, its downstream origin) was meant for and first tested on.
It has some hardware that differs from the modern SoCs, so not a lot of
current structs could have been reused. It's also seeming
According to the vendor DT files, msm8998 has highest-bank-bit equal to
2. Update the data accordingly.
Fixes: 6f410b246209 ("drm/msm/mdss: populate missing data")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Co-developed-by: Konrad Dybcio
Signed-off-by: Konrad
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms supported by both drivers are by default handled
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU driver asks for it.
It is not possible to generate thi
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dis
Over the last several years the DPU driver has been actively developed,
while the MDP5 is mostly in the maintenance mode. This results in some
features being available only in the DPU driver. For example, bandwidth
scaling, writeback support, properly supported bonded DSI aka dual DSI
support.
All
Applied the series. Thanks!
Alex
On Thu, Aug 31, 2023 at 9:29 PM Yang Li wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn35/dcn35_fpu.c:260
> dcn35_update_bw_bounding_box_fpu() warn: inconsistent indenting
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn35
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c:
> dcn35_clk_mgr.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 1 -
> 1 file cha
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c: clk_mgr.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> di
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c: dcn35_optc.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> d
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c:
> dcn31/dcn31_dio_link_encoder.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c | 1 -
> 1 file ch
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control th
Applied and dropped the printk.
Alex
On Fri, Sep 1, 2023 at 3:40 AM Christian König wrote:
>
> Am 01.09.23 um 09:02 schrieb Jiapeng Chong:
> > No functional modification involved.
> >
> > drivers/gpu/drm/amd/amdgpu/nbio_v7_11.c:34 nbio_v7_11_get_rev_id() warn:
> > inconsistent indenting.
>
>
>
[WHY]
edid_override and drm_edid_override_connector_update, according to drm
documentation, should not be referred outside drm_edid.
[HOW]
Remove and replace them accordingly.
Signed-off-by: Alex Hung
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 2
Hi,
On Mon, Sep 4, 2023 at 8:33 AM Maxime Ripard wrote:
>
> > I don't understand the benefit of switching to refcounting, though. We
> > don't ever expect the "prepare" or "enable" function to be called more
> > than once and all we're guarding against is a double-unprepare and a
> > double-enabl
On Wed, 6 Sep 2023 00:21:09 +0800
suijingfeng wrote:
> Hi,
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over which
> >> one is pr
Hi Paul,
On Wed, 2023-08-16 at 12:56 +0200, Paul Cercueil wrote:
> 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
>
Hi Linus,
Thank you for your feedback (comments below).
On Fri, 2023-08-18 at 11:36 +0200, Linus Walleij wrote:
> Hi Sarah,
>
> thanks for your patch!
>
> Patches adding device tree bindings need to be CC:ed to
> devicet...@vger.kernel.org
> and the DT binding maintainers, I have added it for n
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the -
On 2023/9/5 18:49, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary
On 09/05, Melissa Wen wrote:
> Hi,
>
> I'm updating the color state part of DTN log to match DCN3.0 HW better.
> Currently, the DTN log considers the DCN10 color pipeline, which is
> useless for DCN3.0 because of all the differences in color caps between
> DCN versions. In addition to new color bl
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve abo
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The specifi
On 04/09/2023 16:29, Thomas Zimmermann wrote:
Hi Jocelyn,
thanks for moving this effort forward. It's much appreciated. I looked
through the patches and tried the patchset on my test machine.
Thanks for taking the time to review and test it.
Am 09.08.23 um 21:17 schrieb Jocelyn Falempe:
Thi
On Fri, 04 Aug 2023 13:48:09 +0300, Tomi Valkeinen wrote:
> Fix various issues in lt8912b driver.
>
> Tomi
>
>
Fixed the mentioned commit message typos, and an incorrect has
for a "Fixes" tag.
Applied, thanks!
[1/4] drm/bridge: lt8912b: Fix bridge_detach
https://cgit.freedesktop.org/dr
On Fri, 1 Sep 2023 15:01:23 +0530, Jai Luthra wrote:
> Fix the NULL pointer dereference when no monitor is connected, and the
> sound card is opened from userspace.
>
> Instead return an empty buffer (of zeroes) as the EDID information to
> the sound framework if there is no connector attached.
>
Hi, Christian
On 9/5/23 15:14, Christian König wrote:
Am 05.09.23 um 10:58 schrieb Thomas Hellström:
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the addre
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already made
undesired
decision for you.
3) This
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git a/d
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +-
...
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 28 +--
drivers/gpu/drm/am
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers
Hi,
I'm updating the color state part of DTN log to match DCN3.0 HW better.
Currently, the DTN log considers the DCN10 color pipeline, which is
useless for DCN3.0 because of all the differences in color caps between
DCN versions. In addition to new color blocks and caps, some semantic
differences
Hi,
On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle)
wrote:
>
> On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown
> > time. Among other
On Fri, 18 Aug 2023 20:18:15 +0100, Biju Das wrote:
> This patch series aims to add match data improvements for it66121 driver.
>
> v2->v3:
> * Removed fixes tag from patch#1 as nothing broken.
> * Added Rb tag from Andy.
> v1->v2:
> * Split the patch into two.
> * patch#1 extend match support
https://bugzilla.kernel.org/show_bug.cgi?id=217872
Bug ID: 217872
Summary: RIP: 0010:amdgpu_vm_pde_update [amdgpu]
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: high
Hi, Maxime
On 9/5/23 15:16, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 02:32:38PM +0200, Thomas Hellström wrote:
Hi,
On 9/5/23 14:05, Maxime Ripard wrote:
Hi,
On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
Check that object freeing from within drm_exec_fini() works as e
On Tue, Sep 05, 2023 at 07:06:43PM +0530, Vignesh Raman wrote:
> Hi Maxime,
>
> On 05/09/23 17:27, Maxime Ripard wrote:
> > On Tue, Sep 05, 2023 at 05:11:43PM +0530, Vignesh Raman wrote:
> > > > > Also, that node actually has a label ("usb"), defined here:
> > > > > https://git.kernel.org/pub/scm/
Hi Maxime,
On 05/09/23 17:27, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 05:11:43PM +0530, Vignesh Raman wrote:
Also, that node actually has a label ("usb"), defined here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/msm8916.dtsi#n2322
So y
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphic
Am 05.09.23 um 12:38 schrieb Jani Nikula:
On Tue, 05 Sep 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() functi
1 - 100 of 165 matches
Mail list logo
