Hi Katya,
thanks for the patch.
Tested-by: Yannick Fertre
BR
Le 19/03/2024 à 14:47, Philippe CORNU - foss a écrit :
zut, déjà un acked-by de RGA...
tu confirmes que je prends?
Philippe
De : Raphael GALLAIS-POU - foss
Envoyé : lundi 26 février 2024 14
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_
Emma stepped back from VC4 maintenance a while ago, and
all patches are now merged through drm-misc.
Drop Emma's tree from MAINTAINERS.
Signed-off-by: Dave Stevenson
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8dabcb16d29f..3fb03de446c3
Add myself as maintainer for VC4 alongside Maxime, and
our internal review list as reviewer.
Signed-off-by: Dave Stevenson
---
v1->v2
Changed the internal list from M to R.
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
asus-z00t-tm5p5-n35596 panel.
Signed-off-by: Tejas Vipin
---
to the device using a transport bus. For this reason, a
.panic_flush handler is needed to flush the panic image to the display.
Thanks for this patch, that's really cool that drm_panic can work on
this device too.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 64
On LNL because of flat CCS, driver creates a migrate job to clear
CCS meta data. Extend that to also clear system pages using GPU.
Inform TTM to allocate pages without __GFP_ZERO to avoid double page
clearing by clearing out TTM_TT_FLAG_ZERO_ALLOC flag.
v2: Handle regression on dgfx(Himal)
On Wed, Jun 19, 2024 at 04:46:48PM +0200, amerg...@baylibre.com wrote:
> + /* gain default values*/
> + regmap_update_bits(priv->regmap, MT6357_AUDENC_ANA_CON0,
> MT6357_AUDPREAMPLGAIN_MASK,
> +UL_GAIN_0DB << MT6357_AUDPREAMPLGAIN_SFT);
> +
This gives very nice improvement for large buffer:
Without the patch:
~/igt-gpu-tools/build/tests/xe_exec_store --run basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889799 for randomisation
Opened device: /dev/dri/card0
Starting subtest
:
Without the patch:
~/igt-gpu-tools/build/tests/xe_exec_store --run basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889799 for randomisation
Opened device: /dev/dri/card0
Starting subtest: basic-store-benchmark
Starting dynamic subtest: WC
On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson wrote:
>
> On Wed, Jun 12, 2024 at 09:28:39PM GMT, Dmitry Baryshkov wrote:
> > On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> > > Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> > > to be added for PD
On Fri, 21 Jun 2024 at 12:30, Maxime Ripard wrote:
>
> On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> > Add necessary glue code to be able to use new HDMI codec framework from
> > the DRM bridge drivers. The drm_bridge implements a limited set of the
> > hdmi_codec_ops
Also, parent_dev is going to be an issue there. IIRC, ASoC will set its
> structure as the device data and overwrite whatever we put there.
It registers driver_data for the created device, it doesn't touch parent_dev.
>
> We worked around it in vc4 by making sure that snd_soc_card was right at
> the start
> On 11 Jun 2024, at 7:50 PM, Jonas Karlman wrote:
>
> This series ensure poweron/poweroff and CEC phys addr invalidation is
> happening under drm mode_config mutex lock, and also ensure EDID is
> updated (when the dw-hdmi connector is used) after a hotplug pulse.
>
> These changes has mainly
Hello Krzysztof,
Thank you for your reply!
On Tue, Jun 18, 2024 at 6:17 PM Krzysztof Kozlowski wrote:
>
> On 18/06/2024 10:15, Hironori KIKUCHI wrote:
> > The RG28XX panel is a panel specific to the Anbernic RG28XX.
> > It is 2.8 inches in size (diagonally) with a resolution of 480x640.
> >
> >
On Wed, Jun 19, 2024 at 09:35:57PM +0200, Uwe Kleine-König wrote:
> These drivers don't use the driver_data member of struct i2c_device_id,
> so don't explicitly initialize this member.
>
> This prepares putting driver_data in an anonymous union which requires
> either no initialization or named
t;>>> FRMSYNC mode should always be enabled (and is apparently force-enabled
> >>>>> on newer bridge chips with no option to disable it) unless the Pixel
> >>>>> clock are sourced from DSI clock (which is never the case with this
> >>&
>>> +
>>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_disable_decap
>>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_inject_rx_err
>>> +What:
>/sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mac_lane_remap
>>
>> Don't think debugfs is the correct interface for all this
the network. Initialize the hbl_cn
>> driver via
>> auxiliary bus and serve as its adapter for accessing the device.
>
> A 1200 line patch deserves a bit more of info in the commit msg.
> Can you please elaborate what network scaling support is being added in this
> patch.
>
On 6/19/24 21:35, Sunil Kovvuri Goutham wrote:
> [Some people who received this message don't often get email from
> sgout...@marvell.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
>> +
>> +What:
ymore,
> possibly due to mailmap doing its magic.
Too much magic in git :-(
I went through and updated all your SoB fields, but mailmap appears to
mean that the author shown by git log is not the same as the patches
created by git format-patch. Never believe what you see. (That feels
like a bug i
On 21-06-24, 15:38, Vinod Koul wrote:
> On 20-06-24, 20:11, Jonathan Cameron wrote:
> > On Thu, 20 Jun 2024 21:50:41 +0530
> > Vinod Koul wrote:
> >
> > > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > > Hi Jonathan,
> > >
> > > Hey Jonathan,
> > >
> > > Assuming we are fine with this
On 20-06-24, 20:11, Jonathan Cameron wrote:
> On Thu, 20 Jun 2024 21:50:41 +0530
> Vinod Koul wrote:
>
> > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > Hi Jonathan,
> >
> > Hey Jonathan,
> >
> > Assuming we are fine with this series, how would you like to proceed.
> > Would you be fine
On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote:
> Here's the v12 of my patchset that introduces DMABUF support to IIO.
>
> Apart from a small documentation fix, it reverts to using
> mutex_lock/mutex_unlock in one particular place, which used cleanup
> GOTOs (which don't play well with
On Fri, 21 Jun 2024 at 09:57, Maxime Ripard wrote:
>
> Hi,
>
> On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote:
> > From: Dom Cobley
> >
> > Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
> > Tested with kmstest and kodi. e.g.
> >
> > kmstest -r 1920x1080@60 -f
On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> Add necessary glue code to be able to use new HDMI codec framework from
> the DRM bridge drivers. The drm_bridge implements a limited set of the
> hdmi_codec_ops interface, with the functions accepting both
> drm_connector and
Hi,
Sorry for taking some time to review this series.
On Sat, Jun 15, 2024 at 08:53:32PM GMT, Dmitry Baryshkov wrote:
> Several DRM drivers implement HDMI codec support (despite its name it
> applies to both HDMI and DisplayPort drivers). Implement generic
> framework to be used by these
On 21/06/2024 08:15, Alan Previn wrote:
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1
On LNL because of flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GPU.
Cc: Matthew Auld
Cc: Michal Mrozek
Cc: "Thomas Hellström"
Signed-off-by: Nirmoy Das
---
On Sat, 15 Jun 2024 20:53:30 +0300, Dmitry Baryshkov wrote:
> Use new HDMI Connector helpers in the Lontium LT9611 bridge driver.
> Program InfoFrames using the helper's callbacks. Also use TMDS char rate
> validation callback to filter out modes, instead of hardcoding 4k@30.
>
> The Audio
; > in
> > > > > > userspace
> > > > > > 2) DRM driver use secure mailbox channel to handle normal and
> > > > > > secure flow
> > > > > > 3) Implement setting mmsys routing table in the secure world
> > >
Hi,
On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote:
> From: Dom Cobley
>
> Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
> Tested with kmstest and kodi. e.g.
>
> kmstest -r 1920x1080@60 -f 400x300-YU24
>
> Note: without the shift of width, only half the
Hi,
I want to push at least the first patch that is an important fix.
But if there are no objections, I can push the whole series except patch
5 "drm/panic: Convert to drm_fb_clip_offset()" which causes some build
issue.
Best regards,
--
Jocelyn
On 13/06/2024 21:17, Geert Uy
Hi Dave,
Thanks for taking the time to send this.
I've gone through most of the patches and it looks pretty good already,
but I have a few general remarks:
- We merged in drm-misc-next the new HDMI infrastructure recently and
it will heavily conflict with some of these patches, so you
在 2024/6/21 下午3:10, Chen Ni 写道:
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3
y powered off at system shutdown time.
> > > > > > > > >
> > > > > > > > > The fact that we should call drm_atomic_helper_shutdown() in
> > > > > > > > > the case
> > > > > > > > > of OS shutdo
ob/master/MAINTAINERS#L4178-L4183
I think it's somewhat different in the case of v4l2, you're the one
taking the patches and sending a PR iirc. In drm-misc, there's a
significant chance someone else will apply it.
> bcm-kernel-feedback-l...@broadcom.com is listed as reviewer for a fair
> number of e
Am 21.06.24 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case
On Fri, 21 Jun 2024, Markus Elfring wrote:
> > The issue is one of communication and the way reviews are conducted.
> >
> > Reviewing other people's work is challenging and requires a certain
> > skill-set, of which _excellent_ communication skills are non-negotia
> The issue is one of communication and the way reviews are conducted.
>
> Reviewing other people's work is challenging and requires a certain
> skill-set, of which _excellent_ communication skills are non-negotiable.
Patch feedback and change tolerance can vary also according
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case while releasing a buffer object. Hence, push a
Am 21.06.24 um 09:16 schrieb Thomas Zimmermann:
Hi
Am 20.06.24 um 16:30 schrieb Hoi Pok Wu:
Dear Thomas,
Thank you for testing my patch. The dev->dev_private is indeed the
problem.
However, most of the functions that uses dev->dev_private is passing
drm_device as parameter, and the
Hi
Am 20.06.24 um 16:30 schrieb Hoi Pok Wu:
Dear Thomas,
Thank you for testing my patch. The dev->dev_private is indeed the problem.
However, most of the functions that uses dev->dev_private is passing
drm_device as parameter, and then uses dev->dev_private to retrieve
rade
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3 +++
1 file changed, 3 insertions(+)
Hi Hironori,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Hironori-KIKUCHI/dt-bindings-display-st7701-Add-Anbernic-RG28XX-panel/20240618-161849
base: https
On Wed, Jun 12, 2024 at 09:28:39PM GMT, Dmitry Baryshkov wrote:
> On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> > Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> > to be added for PD notifications and other missing features. Adding
> > and maintaining new
Hi Arun,
I still don't have commit permission. Can you please help to push this
patches.
Regards,
S.Amarnath
On 6/20/2024 2:38 PM, Karolina Stolarek wrote:
Hi Christian and Amaranath,
On 12.06.2024 14:02, Karolina Stolarek wrote:
Introduce tests for ttm_bo_validate()/ttm_bo_init_validate()
to disable the allocator trimming part. This patch enables
the drivers control trimming and they can do it themselves
based on the application requirements.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 22 --
drivers/gpu/drm/xe
On Wed, 05 Jun 2024 22:10:13 +0200, Konrad Dybcio wrote:
> Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
> but instead rely on a set of combinations of "feature code" (FC) and
> "product code" (PC) identifiers to match the bins. This series adds
> support for that.
>
> I
On Fri, 21 Jun 2024 10:29:57 +0800
Yafang Shao wrote:
> Using __get_task_comm() to read the task comm ensures that the name is
> always NUL-terminated, regardless of the source string. This approach also
> facilitates future extensions to the task comm.
Good catch! Looks good to me.
Acked-by:
that
the
FRMSYNC mode should always be enabled (and is apparently force-enabled
on newer bridge chips with no option to disable it) unless the Pixel
clock are sourced from DSI clock (which is never the case with this
driver). That's what the [1] patch does.
But messing with the HFP isn't really working
To prevent erros from occurring when the src string is longer than the
dst string in strcpy(), we should use __get_task_comm() instead. This
approach also facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
To prevent errors from occurring when the src string is longer than the dst
string in strcpy(), we should use __get_task_comm() instead. This approach
also facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Cc: "David S. Miller"
Cc: David Ahern
Cc: Eric Dumazet
Cc:
Using __get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Mathieu Desnoyers
---
Using __get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
---
kernel/tsacct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since task lock was dropped from __get_task_comm(), it's safe to call it
from kmemleak.
Using __get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by:
These three functions follow the same pattern. To deduplicate the code,
let's introduce a common help __kstrndup().
Suggested-by: Andrew Morton
Signed-off-by: Yafang Shao
---
mm/internal.h | 24
mm/util.c | 27 ---
2 files changed, 28
In kstrdup(), it is critical to ensure that the dest string is always
NUL-terminated. However, potential race condidtion can occur between a
writer and a reader.
Consider the following scenario involving task->comm:
readerwriter
len = strlen(s) + 1;
Let's explicitly ensure the destination string is NUL-terminated. This way,
it won't be affected by changes to the source string.
Signed-off-by: Yafang Shao
Reviewed-by: Quentin Monnet
---
tools/bpf/bpftool/pids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/bpf/bpftool/pids.c
Quoted from Linus [0]:
selinux never wanted a lock, and never wanted any kind of *consistent*
result, it just wanted a *stable* result.
Using __get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
Using __get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Acked-by: Paul Moore
Cc: Eric Paris
---
kernel/auditsc.c | 6 +++---
1
Quoted from Linus [0]:
Since user space can randomly change their names anyway, using locking
was always wrong for readers (for writers it probably does make sense
to have some lock - although practically speaking nobody cares there
either, but at least for a writer some kind of race
. This approach
will facilitate future extensions to the task comm.
As suggested by Linus [0], we can identify all relevant code with the
following git grep command:
git grep 'memcpy.*->comm\>'
git grep 'kstrdup.*->comm\>'
git grep 'strncpy.*->comm\>'
git grep 'strcpy.*->
On Fri, Jun 21, 2024 at 3:56 AM Dmitry Baryshkov
wrote:
>
> On Thu, Jun 20, 2024 at 07:52:45PM GMT, Zhaoxiong Lv wrote:
> > The bias IC of this starry-er88577 panel is placed
> > on the panel side, so when the panel is powered on,
> > there is no need to control AVDD and AVEE in the driver,
> >
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on andi-shyti/i2c/i2c-host]
[also build test WARNING on linus/master v6.10-rc4 next-20240620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Add support for the drm_panic infrastructure, which allows to display
a user friendly message on the screen when a Linux kernel panic occurs.
The display controller doesn't scanout the framebuffer, but instead the
pixels are sent to the device using a transport bus. For this reason, a
y concern is that today the timing engine setup happens in encoder's
> > > enable() and the hdmi's timing is programmed in mode_set().
> > >
> > > Ideally, we should program hdmi's timing registers first before the
> > > encoder's timing.
> > >
> > > Although timing
i's timing registers first before the
encoder's timing.
Although timing engine is not enabled yet, till post_kickoff, this is
changing the sequence.
If this really required for rest of this series?
No, it was just worth doing it as I was doing conversion to atomic_*
anyway. I can delay this pat
0);
---
base-commit: b992b79ca8bc336fa8e2c80990b5af80ed8f36fd
change-id: 20240528-a306a-48e173724d6c
prerequisite-message-id: <20240618164303.66615-1-robdcl...@gmail.com>
prerequisite-patch-id: b26cd6e5aa23ea623fec94f938a06d1e3359de55
prerequisite-patch-id: 301e8fe4c2687a4606ee7debce95a5ada732
e into the list. Imagine two
threads:
one tries to create fence with value A but has data RO, so fence will be
created and inserted into the list, but when copy_to_user fails, it will try to
rollback.
second thread also tries to create fence with value A, but now data is legit.
We might race with the ro
On Thu, Jun 20, 2024 at 11:21 PM Paolo Bonzini wrote:
> Queued, thanks.
Oops, a script started sending "queued" messages for everything that
had "y" in the subject. Sorry about that.
Paolo
d yet, till post_kickoff, this is
> changing the sequence.
>
> If this really required for rest of this series?
No, it was just worth doing it as I was doing conversion to atomic_*
anyway. I can delay this patch for now.
Two questions:
1) Are you sure regarding the HDMI timing registe
Queued, thanks.
Paolo
On 6/7/2024 6:23 AM, Dmitry Baryshkov wrote:
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to
simplify its usage in the driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 6/7/2024 6:23 AM, Dmitry Baryshkov wrote:
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2
rather use atomic_mode_set because moving to atomic_enable() would
be incorrect.
That would be called after encoder's enable and hence changes the sequence.
That was not the intention of this patch.
NAK.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdm
uld rather use atomic_mode_set because moving to atomic_enable() would
> be incorrect.
>
> That would be called after encoder's enable and hence changes the sequence.
> That was not the intention of this patch.
>
> NAK.
>
> > Acked-by: Maxime Ripard
> > Signed-
On Thu, Jun 20, 2024 at 01:17:30PM GMT, Abhinav Kumar wrote:
> clear_pending_flush() ctl op is always assigned irrespective of the DPU
> hardware revision. Hence there is no needed to check whether the op has
> been assigned before calling it.
>
> Drop the checks across the driver for
use atomic_mode_set because moving to atomic_enable()
would be incorrect.
That would be called after encoder's enable and hence changes the
sequence. That was not the intention of this patch.
NAK.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi
Am Mi., 19. Juni 2024 um 06:08 Uhr schrieb Mario Limonciello
> Thanks! I don't have permissions, so can you (or someone else) please
> apply to drm-misc-next for me?
>
> After it's merged I'll rebase and work on the feedback for the new IGT
> tests.
Merging can only happen once a real world
On Sat, Jun 01, 2024 at 08:24:59AM GMT, Adam Ford wrote:
> In the process of adding support for shared IRQ pins, a scenario
> was accidentally created where adv7511_irq_process returned
> prematurely causing the EDID to fail randomly.
>
> Since the interrupt handler is broken up into two main
On 6/7/2024 6:23 AM, Dmitry Baryshkov wrote:
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9
clear_pending_flush() ctl op is always assigned irrespective of the DPU
hardware revision. Hence there is no needed to check whether the op has
been assigned before calling it.
Drop the checks across the driver for clear_pending_flush() and also
update its documentation that it is always expected
On 18/06/2024 15:59, Dzmitry Sankouski wrote:
> This adds basic support for LEDs for the max77705 PMIC.
>
> Signed-off-by: Dzmitry Sankouski
> ---
> MAINTAINERS | 1 +
> drivers/leds/Kconfig | 6 ++
> drivers/leds/Makefile| 1 +
>
On Wed, Jun 19, 2024 at 04:27:40PM GMT, Dzmitry Sankouski wrote:
> вт, 18 июн. 2024 г. в 21:39, Dmitry Baryshkov :
> >
> > > + ret = mipi_dsi_compression_mode(dsi, true);
> > > + if (ret < 0) {
> > > + dev_err(dev, "Failed to set compression mode: %d\n", ret);
> > > +
On Thu, Jun 20, 2024 at 12:12:27PM GMT, Abhinav Kumar wrote:
> clear_pending_flush() ctl op is always assigned irrespective of the DPU
> hardware revision. Hence there is no needed to check whether the op has
> been assigned before calling it.
>
> Drop the checks across the driver for
On Thu, Jun 20, 2024 at 07:52:45PM GMT, Zhaoxiong Lv wrote:
> The bias IC of this starry-er88577 panel is placed
> on the panel side, so when the panel is powered on,
> there is no need to control AVDD and AVEE in the driver,
> only 3.3v and reset are needed.
>
> Signed-off-by: Zhaoxiong Lv
>
son
> Signed-off-by: Tejas Vipin
> ---
> Changes in v3:
> - Remove extra blank line
> - Expanded on error handling functionality in patch notes
>
> Changes in v2:
> - Change rm692e5_on to return void and take mipi_dsi_multi_context
> as an argument.
> -
modes in the ethtool code should be removed
> > from this patch set. They are not relevant for Gaudi2. I'll fix it in the
> > next version.
>
> How do your customers / users check SFP diagnostics?
And perform firmware upgrade of the SFPs?
https://lore.kernel.org/net
On Thu, 20 Jun 2024 20:11:50 +0100
Jonathan Cameron wrote:
> On Thu, 20 Jun 2024 21:50:41 +0530
> Vinod Koul wrote:
>
> > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > Hi Jonathan,
> >
> > Hey Jonathan,
> >
> > Assuming we are fine with this series, how would you like to proceed.
> >
clear_pending_flush() ctl op is always assigned irrespective of the DPU
hardware revision. Hence there is no needed to check whether the op has
been assigned before calling it.
Drop the checks across the driver for clear_pending_flush() and also
update its documentation that it is always expected
On Thu, 20 Jun 2024 21:50:41 +0530
Vinod Koul wrote:
> On 20-06-24, 14:27, Paul Cercueil wrote:
> > Hi Jonathan,
>
> Hey Jonathan,
>
> Assuming we are fine with this series, how would you like to proceed.
> Would you be fine with me picking the dmaengine bits and providing a
> signed tag for
is also tracing
> > involved in that path. Do we care about tracing such a case? Or do we want
> > it explicitly not traced? I would rather keep it as dma_fence_put.
>
> Could be a matter of opinion yeah.
>
So, dma_fence_put has the advantage of being safer in the long term as
fr
prepare() is changed to
properly power the panel off in the case of a wider range of
initialization commands failing than before.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Douglas Anderson
Signed-off-by: Tejas Vipin
---
Changes in v3:
- Remove extra blank line
- Expanded on error handling fu
401 - 500 of 357608 matches
Mail list logo
