Hi, Jani
I love your patch, thanks.
On 2024/5/14 20:55, Jani Nikula wrote:
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> This series is the follow-up of the discussion that John and I had a few
> months ago here:
>
> https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/
>
> The initial problem we were discussing was that
Hi Sui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.9 next-20240515]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > You'll hit the same limitation as we hit in GStreamer, which is that KMS
> > driver
> > only offer allocation for render buffers and most of them are missing
> > allocators
> > for YUV buffers, even though they can import in these
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> In drivers the main thing is a new driver for ARM Mali firmware based
> GPUs, otherwise there are a lot of changes to amdgpu/xe/i915/msm and
> scattered changes to everything else.
Hmm. There's something seriously wrong with amdgpu.
I'm gettin
On Wed, 15 May 2024 at 13:06, Linus Torvalds
wrote:
>
> Hmm. There's something seriously wrong with amdgpu.
>
> I'm getting a ton of__force_merge warnings:
>
> WARNING: CPU: 0 PID: 1069 at drivers/gpu/drm/drm_buddy.c:199
> __force_merge+0x14f/0x180 [drm_buddy]
Adding likely culprits to the part
On Wed, 15 May 2024 at 13:21, Linus Torvalds
wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionalit
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build cleanly. Next step: see if it boots and fixes the
> probl
> In some display subsystems, the functionality of a PCI(e) device may too
…
> of the functionality into child devices can helps to achieve better
> modularity, eaiser for understand and maintain.
>
> Add the loongson_create_platform_device() function to pove the way …
Please avoid typos in such a
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate stupid
Hi,
On Tue, 14 May 2024 10:20:50 -0700, Douglas Anderson wrote:
> The consensus of many DRM folks is that we want to move away from DSI
> drivers defining tables of init commands. Instead, we want to move to
> init functions that can use common DRM functions. The issue thus far
> has been that usi
On 14/05/2024 11:07, Krzysztof Kozlowski wrote:
On 14/05/2024 10:44, Neil Armstrong wrote:
On 13/05/2024 18:41, Dmitry Baryshkov wrote:
On Mon, 13 May 2024 at 16:17, Rob Herring wrote:
On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote:
Hi,
Cleanups for display panel bindi
Hi,
On Tue, May 14, 2024 at 6:47 PM Cong Yang
wrote:
>
> +static int hx83102_prepare(struct drm_panel *panel)
> +{
> + struct hx83102 *ctx = panel_to_hx83102(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> +
Hi,
On 15/05/2024 03:46, Cong Yang wrote:
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
---
arch/arm64/configs
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Lincoln Technology Solutions LCD185-101CT, 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and PCAP
touch support (Goodix GT928).
[0]: Panel Datasheet
https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Microtips Technology USA 13-101HIECAF0-C 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and touch
support (ILITEK 2511).
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101H
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
does not support touch.
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13
Hi,
On Wed, 15 May 2024 15:21:27 +0530, Aradhya Bhatia wrote:
> Picking up this long-standing series which added support for Microtips'
> and LincolnTech's dual-lvds panels.
>
> Microtips Technology Solutions USA, and Lincoln Technology Solutions are
> 2 display panel vendors, and the patches 1/6
Hi,
On Wed, May 15, 2024 at 2:16 PM wrote:
>
> Hi,
>
> On 15/05/2024 03:46, Cong Yang wrote:
> > DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
> > Since the arm64 defconfig had the BOE panel driver enabled, let's also
> > enable the himax driver.
> >
> > Signed-off-b
v4 of
https://lore.kernel.org/all/20240507224510.442971-1-lucas.demar...@intel.com
Add per-client usage statistics to xe. This ports xe to use the common
method in drm to export the usage to userspace per client (where 1
client == 1 drm fd open).
However instead of using the current format measu
XE_ENGINE_CLASS_OTHER was missing from the str conversion. Add it and
remove the default handling so it's protected by -Wswitch.
Currently the only user is xe_hw_engine_class_sysfs_init(), which
already skips XE_ENGINE_CLASS_OTHER, so there's no change in behavior.
Reviewed-by: Nirmoy Das
Signed-
From: Umesh Nerlige Ramappa
Add a helper to accumulate per-client runtime of all its
exec queues. This is called every time a sched job is finished.
v2:
- Use guc_exec_queue_free_job() and execlist_job_free() to accumulate
runtime when job is finished since xe_sched_job_completed() is not
Move it out of the sysfs compilation unit so it can be re-used in other
places.
Reviewed-by: Nirmoy Das
Reviewed-by: Oak Zeng
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_hw_engine.c | 18 ++
drivers/gpu/drm/xe/xe_hw_engine.h | 2 ++
drivers
From: Umesh Nerlige Ramappa
Add a helper to capture CTX_TIMESTAMP from the context image so it can
be used to calculate the runtime.
v2: Add kernel-doc to clarify expectation from caller
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/regs/xe_lrc_la
gt->info.engine_mask used to indicate the available engines, but that
is not always true anymore: some engines are reserved to kernel and some
may be exposed as a single engine (e.g. with ccs_mode).
Runtime changes only happen when no clients exist, so it's safe to cache
the list of engines in the
Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:
1) loop through all the exec queues for the current client and
accumulate the runtime, per engine class. CTX_TIMESTAMP is used for
that, being read from the context image.
2) Rea
Just like CTX_TIMESTAMP is used to calculate runtime, add a helper to
get the timestamp for the engine so it can be used to calculate the
"engine time" with the same unit as the runtime is recorded.
Reviewed-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_hw_e
Get the first available engine from a gt, which helps in the case any
engine serves as a context, like when reading RING_TIMESTAMP.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_gt.c | 11 +++
drivers/gpu/drm/xe/xe_gt.h | 7 +++
2 files changed, 18 insertions(+)
diff --g
On Thu, 16 May 2024 at 06:43, Linus Torvalds
wrote:
>
> On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
> >
> > This is the main pull request for the drm subsystems for 6.10.
>
> .. and now that I look more at this pull request, I find other things wrong.
>
> Why is the DRM code asking if I want
On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
>
> The drm subsystem enables more warnings than the kernel default, so
> this config option is disabled by default.
Irrelevant.
If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
sets CONFIG_DRM_WERROR or n
On Thu, 16 May 2024 at 08:56, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
> >
> > The drm subsystem enables more warnings than the kernel default,
> > so
> > this config option is disabled by default.
>
> Irrelevant.
>
> If the *main* CONFIG_WER
Hi all,
On Mon, 13 May 2024 12:03:12 +1000 Stephen Rothwell
wrote:
>
> On Tue, 7 May 2024 12:51:32 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-msm tree got a conflict in:
> >
> > drivers/gpu/drm/msm/Makefile
> >
> > between commit:
> >
> > 7c972986689b ("
On Thu, 16 May 2024 at 06:29, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
> wrote:
> >
> > I have to revert both
> >
> > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to ma
On Thu, 16 May 2024 at 06:29, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
> wrote:
> >
> > I have to revert both
> >
> > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to ma
On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And PPC_WERRO
On Wed, 15 May 2024 at 16:51, Dave Airlie wrote:
>
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> This worr
On Thu, 16 May 2024 at 09:50, Dave Airlie wrote:
>
> On Thu, 16 May 2024 at 06:29, Linus Torvalds
> wrote:
> >
> > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> > wrote:
> > >
> > > I have to revert both
> > >
> > > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > > e362b7c8
Fix a struct member name in &struct drm_dp_as_sdp.
Add Returns: kernel-doc syntax for 4 functions.
In the Returns: sections, spell "%true" and "%false" consistently.
Fixes these kernel-doc warnings:
drm_dp_helper.h:126: warning: Function parameter or struct member 'mode' not
described in 'drm_dp
Add @width and @height descriptions for &struct drm_plane_size_hint
along with a reference to more info.
Add a short description for &struct drm_mode_closefb.
Change 7 macros not to be marked as kernel-doc notation to prevent
warnings.
Fixes these kernel-doc warnings:
drm_mode.h:877: warning: F
Hi,
On Wed, 15 May 2024 at 17:31, Thorsten Blum wrote:
>
> On 15. May 2024, at 11:22, Thorsten Blum wrote:
> > On 15. May 2024, at 09:43, Luc Ma wrote:
> >> On Tue, 14 May 2024 at 19:37, Thorsten Blum
> >> wrote:
> >>>
> >>> Merge the identical if/elif code blocks and remove the following two
On 5/15/24 17:51, Aradhya Bhatia wrote:
> Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
> MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions'
> LCD185-101CT 10.1"[2] panel.
>
> Thes are all dual-lvds panels.
>
> Panel Links:
> [0]:
> https://simplespec.microtips
Hi,
On 5/16/24 04:30, Markus Elfring wrote:
In some display subsystems, the functionality of a PCI(e) device may too
…
of the functionality into child devices can helps to achieve better
modularity, eaiser for understand and maintain.
Add the loongson_create_platform_device() function to pove
On 5/15/24 17:51, Aradhya Bhatia wrote:
> Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
> 1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
> does not support touch.
>
> [0]: Panel Datasheet
> https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/
https://bugzilla.kernel.org/show_bug.cgi?id=218841
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
On Tue, May 14, 2024 at 3:00 AM Christian König
wrote:
>
> Am 14.05.24 um 06:15 schrieb Zack Rusin:
>
> On Mon, May 13, 2024 at 1:09 PM Christian König
> wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
>
> Hey,
>
> so this is a bit of a silly problem but I'd still like to solve it
> properly.
On Thu, 16 May 2024 at 10:06, Dave Airlie wrote:
>
> On Thu, 16 May 2024 at 09:50, Dave Airlie wrote:
> >
> > On Thu, 16 May 2024 at 06:29, Linus Torvalds
> > wrote:
> > >
> > > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> > > wrote:
> > > >
> > > > I have to revert both
> > > >
> > > > a68
Hi Linus,
Here is the buddy allocator fix I picked up from the list, please apply.
Dave.
drm-next-2024-05-16:
drm urgent for 6.10-rc1 merge:
buddy:
- fix breakage in buddy allocator.
The following changes since commit 275654c02f0ba09d409c36d71dc238e470741e30:
Merge tag 'drm-xe-next-fixes-202
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2024年5月15日 23:17
> To: Keith Zhao
> Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; linux-ri...@lists.infradead.org;
> a...@eecs.berkeley.edu; suijingf...@loongson.cn; tzimmerm...@suse
Hi Maxime,
kernel test robot noticed the following build warnings:
[auto build test WARNING on a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6]
url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/dma-buf-heaps-Introduce-a-new-heap-for-reserved-memory/20240515-215850
base
…
> The idea is to devide the exterinal module dependent part …
divide | separate the external?
Please avoid typos in such a change description.
Regards,
Markus
On 5/16/2024 8:12 AM, Dave Airlie wrote:
On Thu, 16 May 2024 at 10:06, Dave Airlie wrote:
On Thu, 16 May 2024 at 09:50, Dave Airlie wrote:
On Thu, 16 May 2024 at 06:29, Linus Torvalds
wrote:
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
I have to revert both
a68c7eaa7a8f ("dr
Hi,
this small series improves debugging the tc358767 driver by using
dev_err_probe for additional information (patch 1) and print IRQ
debug output only if hotplug status actually changed.
Changes in v2:
* Added patch for supporting write-only registers
Best regards,
Alexander
Alexander Stein (
The function calls preceding these returns can return -EPROBE_DEFER. So
use dev_err_probe to add some information to
/sys/kernel/debug/devices_deferred
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
Currently the output the following output is printed upon each interrupt:
tc358767 1-000f: GPIO0:
This spams the kernel log while debugging an IRQ storm from the bridge.
Only print the debug output if the GPIO hotplug event actually happened.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/b
Most registers are read-writable, but some are only RO or even WO.
regmap does not support using readable_reg and wr_table when outputting
in debugfs, so switch to writeable_reg.
First check for RO or WO registers and fallback tc_readable_reg() for the
leftover RW registers.
Signed-off-by: Alexand
…
> fullfill the implement under the new framework.
fulfil the implementation?
Please improve your change descriptions another bit.
Regards,
Markus
Hi:
If it is determined that a separately patch needs to be sent, then I
will remove this patch in V8 series?
Doug Anderson 于2024年5月16日周四 05:28写道：
>
> Hi,
>
> On Wed, May 15, 2024 at 2:16 PM wrote:
> >
> > Hi,
> >
> > On 15/05/2024 03:46, Cong Yang wrote:
> > > DRM_PANEL_HIMAX_HX83102 is being
Hi Marek,
thanks for the patch.
Am Montag, 13. Mai 2024, 04:16:27 CEST schrieb Marek Vasut:
> Initialize the bridge on attach already, to force lanes into LP11
> state, since attach does trigger attach of downstream bridges which
> may trigger (e)DP AUX channel mode read.
>
> This fixes a corner
On 16/05/2024 08:43, cong yang wrote:
Hi:
If it is determined that a separately patch needs to be sent, then I
will remove this patch in V8 series?
Doug Anderson 于2024年5月16日周四 05:28写道：
Hi,
On Wed, May 15, 2024 at 2:16 PM wrote:
Hi,
On 15/05/2024 03:46, Cong Yang wrote:
DRM_PANEL_HIMAX
101 - 160 of 160 matches
Mail list logo
