Hi Thomas,
CC Christian
On Thu, Jun 27, 2024 at 7:35 PM Thomas Huth wrote:
> Starting with kernel 6.7, the framebuffer text console is not working
> anymore with the virtio-gpu device on s390x hosts. Such big endian fb
> devices are usinga different pixel ordering than little endian devices,
> e
Hi Thomas,
On Fri, Jun 28, 2024 at 8:07 AM Thomas Zimmermann wrote:
> Am 27.06.24 um 19:35 schrieb Thomas Huth:
> > Starting with kernel 6.7, the framebuffer text console is not working
> > anymore with the virtio-gpu device on s390x hosts. Such big endian fb
> > devices are usinga different pixe
On 26/06/2024 18:26, Kees Cook wrote:
On Tue, Jun 25, 2024 at 02:39:29PM +0200, Jocelyn Falempe wrote:
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new parameter "const char *desc" to the kmsg_dumper
dump() callback, and update all drivers t
On 6/28/24 05:28, Chen Ni wrote:
Return clk_prepare_enable() in order to transfer the error if it fails.
Signed-off-by: Chen Ni
---
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
applied.
Thanks!
Helge
On Fri, 28 Jun 2024 at 08:44, Abhinav Kumar wrote:
>
>
>
> On 6/27/2024 4:22 PM, Dmitry Baryshkov wrote:
> > On Fri, 28 Jun 2024 at 00:21, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 6/27/2024 2:13 PM, Rob Clark wrote:
> >>> On Thu, Jun 27, 2024 at 1:53 PM Abhinav Kumar
> >>> wrote:
>
On 27/06/2024 18:45, Marc Gonzalez wrote:
> On 27/06/2024 18:25, Conor Dooley wrote:
>
>> On Thu, Jun 27, 2024 at 01:13:03PM +0200, Marc Gonzalez wrote:
>>
>>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
>>> It supports DVI 1.0, HDMI 1.4b and 2.0b.
>>> It supports 4 TMDS ch
On Fri, 28 Jun 2024, John Watts wrote:
> Hello there,
>
> A while ago I added support for the FS035VG158 panel to the kernel, with its
> use case being on a Allwinner T113 board.
Might be helpful to actually point at the source code or commits or
something.
> While troubleshooting some other iss
On Fri, Jun 28, 2024 at 09:36:57AM GMT, Krzysztof Kozlowski wrote:
> On 27/06/2024 18:45, Marc Gonzalez wrote:
> > On 27/06/2024 18:25, Conor Dooley wrote:
> >
> >> On Thu, Jun 27, 2024 at 01:13:03PM +0200, Marc Gonzalez wrote:
> >>
> >>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting R
Hey Christian,
Any thoughts on the below reply? Did I get it wrong or I found a
legitimate issue?
Regards,
Tvrtko
On 14/06/2024 17:06, Tvrtko Ursulin wrote:
On 14/06/2024 10:53, Christian König wrote:
if (domain & abo->preferred_domains &
AMDGPU_GEM_DOMAIN_VRAM &&
-
On 28/06/2024 07:10, Hironori KIKUCHI wrote:
The ST7701 supports not only MIPI DSI, but also SPI as an interface
for configuration. To support a panel connected via SPI with an RGB
parallel interface, add support for SPI using MIPI DBI helpers.
Signed-off-by: Hironori KIKUCHI
---
drivers/gpu/
On 28/06/2024 07:10, Hironori KIKUCHI wrote:
The Anbernic RG28XX is a handheld gaming device with a 2.8 inch 480x640
display. Add support for the display panel.
This panel is driven by a variant of ST7701 driver IC internally,
confirmed by dumping and analyzing its BSP initialization sequence
by
This patch updates the DSI controller schema to include the missing
SM7150 compatibility. It should addresses the following warning in the
SM7150 MDSS schema:
qcom,sm7150-mdss.example.dtb:
dsi@ae94000: compatible: 'oneOf' conditional failed, one must be
fixed:
['qcom,sm7150-dsi-ctrl', 'qco
Add the DSI host found on SM7150.
Signed-off-by: Danila Tikhonov
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/
On 2024/6/28 13:42, Yi Liu wrote:
On 2024/6/10 16:55, Lu Baolu wrote:
The domain_alloc_user operation is currently implemented by allocating a
paging domain using iommu_domain_alloc(). This is because it needs to
fully
initialize the domain before return. Add a helper to do this to avoid
using
On 24/06/2024 16:19, Zhaoxiong Lv wrote:
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send each instruction (an init
code consists of about 200 instructions), so it takes
about 3.5s to send the in
Hi Marco,
On 26/06/2024 18:17, Marco Felsch wrote:
Add compatible to panel-simple for Jiangsu Smartwin Electronics
SMMT043480272A-A19 4.3" 480x272 LCD-TFT panel.
Signed-off-by: Marco Felsch
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 inserti
On Thu, Jun 27, 2024 at 09:26:19PM GMT, Jani Nikula wrote:
> On Thu, 27 Jun 2024, Jani Nikula wrote:
> > On Wed, 26 Jun 2024, Dmitry Baryshkov wrote:
> >> In order to improve testing of drm/msm branches, add drm-msm trees to
> >> the list of the trees to be merged into drm-tip.
> >>
> >> Cc: Rob
On Thu, Jun 27, 2024 at 10:44:44AM GMT, Paul Gerber wrote:
> Add support for the AUO G104STN01 10.4" (800x600) LCD-TFT panel.
>
> Signed-off-by: Paul Gerber
> Reviewed-by: Neil Armstrong
> ---
> Tested on TQ TQMa8MPxL on MBa8MPxL.
>
> drivers/gpu/drm/panel/panel-simple.c | 27 +
Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
length of task comm. Changes in the task comm could result in a destination
string that is overflow. Therefore, we should explicitly ensure the destination
string is always NUL-terminated, regardless of the task comm. This ap
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 could
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 fi
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
facilitates
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 b/
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;
These three functions follow the same pattern. To deduplicate the code,
let's introduce a common helper __kmemdup_nul().
Suggested-by: Andrew Morton
Signed-off-by: Yafang Shao
Cc: Simon Horman
Cc: Matthew Wilcox
---
mm/util.c | 67 +--
1 fil
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:
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(-)
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: Masami Hiramatsu (Google)
Cc: Steven Rostedt
Cc: Mathieu Desnoye
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: Jaku
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
Acked-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Hi,
On Thu, 27 Jun 2024 10:44:42 +0200, Paul Gerber wrote:
> Changes in v2:
> - put explanatory comment for display binding before the list entry
> - collected Acked-by and Reviewed-by
>
> Link to v1:
> https://lore.kernel.org/dri-devel/20240626044727.2330191-1-paul.ger...@ew.tq-group.com/
>
>
Hi,
On Mon, 24 Jun 2024 22:19:21 +0800, Zhaoxiong Lv wrote:
> This kingdisplay panel uses the jd9365da controller, so add it to
> panel-jadard-jd9365da-h3.c driver, but because the init_code and timing
> are different, some variables are added in struct jadard_panel_des to
> control it.
>
> In ad
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #22 from Vasant Hegde (vasant.he...@amd.com) ---
(In reply to dreamlike_clinking040 from comment #21)
> (In reply to Vasant Hegde from comment #19)
>
> Can confirm this patch also fixes my suspend/resume issue, thanks!
Thanks a lot.
On 28/06/2024 10:23, Danila Tikhonov wrote:
> Add the DSI host found on SM7150.
>
> Signed-off-by: Danila Tikhonov
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On Fri, 28 Jun 2024, Dmitry Baryshkov wrote:
> On Thu, Jun 27, 2024 at 09:26:19PM GMT, Jani Nikula wrote:
>> On Thu, 27 Jun 2024, Jani Nikula wrote:
>> > On Wed, 26 Jun 2024, Dmitry Baryshkov wrote:
>> >> In order to improve testing of drm/msm branches, add drm-msm trees to
>> >> the list of the
Add sound support to the RK3066 HDMI driver.
The HDMI TX audio source is connected to I2S_8CH.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
Changed V7:
rebase
---
drivers/gpu/drm/rockchip/Kconfig | 2 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 274 +++
On Fri, 28 Jun 2024, Dave Airlie wrote:
> On Tue, 18 Jun 2024 at 05:26, Rodrigo Vivi wrote:
>>
>> On Wed, Jun 12, 2024 at 02:12:39PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > After merging the drm-intel tree, today's linux-next build (i386
>> > defconfig) failed like this:
>> >
>> > x
On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone wrote:
>
> On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > > So we are kind of stuck here between breaking one or the oth
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The CRTC helpers contain code to enable and disable DisplayPort
connectors. Implement this functionality in the respective connector's
atomic_enable/atomic_disable callbacks. DRM's atomic-modesetting
helpers will call the functions as part of the a
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The CRTC's atomic flush function contains code to program the
display mode ot the AST DP chip. Move the code to the connector's
atomic_mode_set callback. The DRM atomic-modesetting code invoke
this callback as part of the atomic commit.
Thanks, i
On 27/06/2024 17:27, Thomas Zimmermann wrote:
Do all mode setting in ast_crtc_helper_mode_set_nofb(), which
always runs after disabling the CRTC and before programming the
planes. Removes implicit synchronization between the CRTC's
atomic disable, enable and the vertical retrace.
Display-mode
On 27/06/2024 17:27, Thomas Zimmermann wrote:
Several color registers are programmed in the DPMS code of the CRTC's
atomic_enable helper. This code will not be executed if the color format
changes without a full mode switch. The same code already exists in the
atomic_update helper of the prima
Hi,
On Fri, 28 Jun 2024 at 10:43, Tomeu Vizoso wrote:
> On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone wrote:
> > It's not just etnaviv, it's literally every Mesa driver which works
> > with decoupled render/display. So that would be etnaviv-v2,
> > panfrost-v2, panthor-v2, v3d-v2, powervr-v2, ...
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The DPMS code, called from the CRTC's atomic_enable, rewrites the
gamma LUT. This is already done in the CRTC's atomic_flush. Remove
the duplication.
Thanks, it looks good te me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The SCREEN_DISABLE bit controls scanout from display memory. The bit
affects all planes, so set it only in the CRTC's atomic enable and
disable functions.
A number of bugs affect this fix. First of all, ast_set_std_regs()
tries to set VGASR1 excep
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The function ast_crtc_dpms() is left over from when the ast driver
did not implement atomic modesetting. But DPMS is not supported by
atomic modesetting and the helper is only called to enable or
disable the CRTC sync pulses. Inline the function in
On 27/06/2024 17:27, Thomas Zimmermann wrote:
Ast has no special requirements for runtime power management. So
replace drm_atomic_helper_commit_tail_rpm() with the regular helper
drm_atomic_helper_commit_tail().
Thanks, it looks good te me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Th
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The CRTC's mode-setting code contains quite a bit of code that
belongs to the planes or various encoder chips. This patchset
refactors these bits and moves things to the correct places.
With the patches applied, the remaining DPMS function will be
Mina Almasry writes:
> + -
> +name: bind-dmabuf
> +attributes:
> + -
> +name: ifindex
> +doc: netdev ifindex to bind the dma-buf to.
Minor nit:
The series uses a mix of dmabuf and dma-buf but the doc additions
(devmem.rst) consistently uses dmabuf. I think it would
Mina Almasry writes:
> +
> +The user must bind a dmabuf to any number of RX queues on a given NIC using
> +the netlink API::
> +
> + /* Bind dmabuf to NIC RX queue 15 */
> + struct netdev_queue *queues;
> + queues = malloc(sizeof(*queues) * 1);
> +
> + queues[0]._present.type = 1;
On 6/19/24 13:52, Leon Romanovsky wrote:
> On Wed, Jun 19, 2024 at 09:27:54AM +, Omer Shpigelman wrote:
>> On 6/18/24 15:58, Leon Romanovsky wrote:
>>> On Tue, Jun 18, 2024 at 11:08:34AM +, Omer Shpigelman wrote:
On 6/17/24 22:04, Leon Romanovsky wrote:
> [Some people who received
On 6/27/2024 4:43 PM, Dmitry Baryshkov wrote:
> On Thu, Jun 27, 2024 at 11:35:18AM GMT, Ekansh Gupta wrote:
>> For user PD initialization, initmem is allocated and sent to DSP for
>> initial memory requirements like shell loading. This size is passed
>> by user space and is checked against a max
Hello Chen-Yu,
+Rob
On Thu, 27 Jun 2024 15:19:03 +0800
Chen-Yu Tsai wrote:
> Add OF notifier handler needed for creating/destroying MIPI DSI devices
> according to dynamic runtime changes in the DT live tree. This code is
> enabled when CONFIG_OF_DYNAMIC is selected.
>
> This is based on exist
On 6/27/2024 4:50 PM, Greg KH wrote:
> On Thu, Jun 27, 2024 at 11:35:18AM +0530, Ekansh Gupta wrote:
>> For user PD initialization, initmem is allocated and sent to DSP for
>> initial memory requirements like shell loading. This size is passed
>> by user space and is checked against a max size.
Hi Dave, hi Sima,
please pull the following changes for the next merge window. Mostly
fixes, but as they concern new hardware support there's no need to rush
them into the current -rc.
Regards,
Lucas
The following changes since commit e67572cd2204894179d89bd7b984072f19313b03:
Linux 6.9-rc6 (2
On 6/28/2024 3:59 PM, Ekansh Gupta wrote:
>
> On 6/27/2024 4:43 PM, Dmitry Baryshkov wrote:
>> On Thu, Jun 27, 2024 at 11:35:18AM GMT, Ekansh Gupta wrote:
>>> For user PD initialization, initmem is allocated and sent to DSP for
>>> initial memory requirements like shell loading. This size is pas
Large draws can make the GPU appear to be stuck to the current hangcheck
logic as the FE address will not move until the draw is finished. However,
the FE has a debug register, which records the current primitive ID within
a draw. Using this debug register we can extend the timeout as long as the
d
The next changes will introduce another place where the debug registers
need to be en-/disabled. Split into separate functions, so we don't need
to replicate the code there. Also allow those calls to nest, keeping
the debug registers enabled until all callers don't need them any longer.
Signed-off
Update state_hi.xml.h header from etna_viv commit
8f43a34fd9cd ("rndb: document FE current primitve debug reg")
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/state_hi.xml.h | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/etna
Hi
Am 28.06.24 um 11:54 schrieb Jocelyn Falempe:
On 27/06/2024 17:27, Thomas Zimmermann wrote:
Several color registers are programmed in the DPMS code of the CRTC's
atomic_enable helper. This code will not be executed if the color format
changes without a full mode switch. The same code alrea
Hi
Am 28.06.24 um 12:09 schrieb Jocelyn Falempe:
On 27/06/2024 17:27, Thomas Zimmermann wrote:
The CRTC's mode-setting code contains quite a bit of code that
belongs to the planes or various encoder chips. This patchset
refactors these bits and moves things to the correct places.
With the pa
Hi
Am 27.06.24 um 09:47 schrieb Daniel Vetter:
On Wed, Jun 26, 2024 at 07:59:52PM +0200, Daniel Vetter wrote:
On Wed, Jun 26, 2024 at 11:01:11AM +0200, Thomas Zimmermann wrote:
Hi
Am 26.06.24 um 06:34 schrieb Dmitry Baryshkov:
On Tue, Jun 25, 2024 at 03:18:09PM GMT, Thomas Zimmermann wrote:
On Fr, 2024-06-28 at 12:47 +0200, Lucas Stach wrote:
> The next changes will introduce another place where the debug registers
> need to be en-/disabled. Split into separate functions, so we don't need
> to replicate the code there. Also allow those calls to nest, keeping
> the debug registers enab
On Fr, 2024-06-28 at 12:47 +0200, Lucas Stach wrote:
> Update state_hi.xml.h header from etna_viv commit
> 8f43a34fd9cd ("rndb: document FE current primitve debug reg")
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
On Fr, 2024-06-28 at 12:47 +0200, Lucas Stach wrote:
> Large draws can make the GPU appear to be stuck to the current hangcheck
> logic as the FE address will not move until the draw is finished. However,
> the FE has a debug register, which records the current primitive ID within
> a draw. Using t
On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> > On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> > > On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > > > But it makes me a little nervous to add a
Am 27.06.24 um 16:40 schrieb mrip...@kernel.org:
[SNIP]
Why can't you get this information from userspace?
Same reason amd and i915/xe also pass this around internally in the
kernel, it's just that for those gpus the render and kms node are the
same
driver so this is easy.
The reason I ask i
On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> On Thu, Jun 27, 2024 at 08:57:40AM GMT, Christian König wrote:
> > Am 27.06.24 um 05:21 schrieb Jason-JH Lin (林睿祥):
> > >
> > > On Wed, 2024-06-26 at 19:56 +0200, Daniel Vetter wrote:
> > > > > External email : Please do not cli
/soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
Signed-off-by: Alexander Stein
Reviewed-by: Robert Foss
---
Changes in v4:
* Rebased to next-20240628
drivers/gpu/drm/drm_bridge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b
On Wed, May 15, 2024 at 07:23:04PM GMT, Yong Wu wrote:
> Add "struct restricted_heap_ops". For the restricted memory, totally there
> are two steps:
> a) alloc: Allocate the buffer in kernel;
> b) restrict_buf: Restrict/Protect/Secure that buffer.
> The "alloc" is mandatory while "restrict_buf" is
Hi, Michael:
Michael Walle 於 2024年6月6日 週四 下午5:22寫道：
>
> mtk_find_possible_crtcs() assumes that the main path will always have
> the CRTC with id 0, the ext id 1 and the third id 2. This is only true
> if the paths are all available. But paths are optional (see also
> comment in mtk_drm_kms_init()
Am 28.06.24 um 13:47 schrieb Thierry Reding:
[SNIP]
The reason I ask is that encryption here looks just like another parameter
for the buffer, e.g. like format, stride, tilling etc..
So instead of this during buffer import:
mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted", 10
On Wed, May 15, 2024 at 07:23:06PM GMT, Yong Wu wrote:
> Add a MediaTek restricted heap which uses TEE service call to restrict
> buffer. Currently this restricted heap is NULL, Prepare for the later
> patch. Mainly there are two changes:
> a) Add a heap_init ops since TEE probe late than restricte
This kingdisplay panel uses the jd9365da controller, so add it to
panel-jadard-jd9365da-h3.c driver, but because the init_code and timing
are different, some variables are added in struct jadard_panel_des to
control it.
In addition, since sending init_code in the enable() function takes a long
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send each instruction (an init
code consists of about 200 instructions), so it takes
about 3.5s to send the init_code. So we moved the sending
of the int
The kingdisplay-kd101ne3 is a 10.1" WXGA TFT-LCD panel with
jadard-jd9365da controller. Hence, we add a new compatible
with panel specific config.
Signed-off-by: Zhaoxiong Lv
Acked-by: Conor Dooley
---
Changes between V6 and V5:
- 1. No changes.
V5:https://lore.kernel.org/all/20240624141926.5250
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/enable/exit code.
Signed-off-by: Zhaoxiong Lv
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Douglas Anderson
Reviewed-by: Jessica Zhang
---
Changes between V6 and V5:
- 1. Convert the hex in init_code
The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use
jd9365da controller,which fits in nicely with the existing
panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible
with panel specific config.
Although they have the same control IC, the two panels are different,
and the timing will be
This driver does not have the function to adjust the orientation,
so this function is added.
Signed-off-by: Zhaoxiong Lv
Reviewed-by: Douglas Anderson
Reviewed-by: Jessica Zhang
---
Changes between V6 and V5:
- 1. No changes.
V5:
https://lore.kernel.org/all/20240624141926.5250-6-lvzhaoxi...@h
Hi,
On Fri, Jun 28, 2024 at 01:29:17PM GMT, Thierry Reding wrote:
> On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> > On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> > > On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> > > > On Wed, May 15, 2024 at 11:42:58AM -
Hi Johan,
At 2024-06-28 17:23:39, "Johan Jonker" wrote:
>Add sound support to the RK3066 HDMI driver.
>The HDMI TX audio source is connected to I2S_8CH.
>
>Signed-off-by: Zheng Yang
>Signed-off-by: Johan Jonker
>---
>
>Changed V7:
> rebase
>---
> drivers/gpu/drm/rockchip/Kconfig | 2 +
On 1/29/24 11:41, Raphael Gallais-Pou wrote:
This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.
First patch update a PM macro.
Second patch adds runtime PM functionality to the driver.
Third patch adds a clock provider gener
On Fri, Jun 28, 2024 at 01:47:01PM GMT, Thierry Reding wrote:
> On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> > On Thu, Jun 27, 2024 at 08:57:40AM GMT, Christian König wrote:
> > > Am 27.06.24 um 05:21 schrieb Jason-JH Lin (林睿祥):
> > > >
> > > > On Wed, 2024-06-26 at 19:56 +0
On 6/21/24 16:55, Yannick FERTRE wrote:
Hi Raphaël,
Thanks for your patch, it will not merged due to a new clock management.
Philippe,
this patch will be replaced by another which manages all clocks that the
display controller
will need (pixel clock, bus clock reference clock).
Hi Rap
On Fri, Jun 28, 2024 at 01:42:27PM GMT, Christian König wrote:
> Am 27.06.24 um 16:40 schrieb mrip...@kernel.org:
> > [SNIP]
> > > > > > > > Why can't you get this information from userspace?
> > > > > > Same reason amd and i915/xe also pass this around internally in the
> > > > > kernel, it's just
1-20240627
(https://download.01.org/0day-ci/archive/20240628/202406282158.ogy7xnu2-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
ad79a14c9e5ec4a369eed4adf567c22cc029863f)
dtschema version: 2024.6.dev3+g650bf2d
reproduce (this is a W=1 build):
(https:
Hi, Dave & Daniel:
This includes:
1. Convert to platform remove callback returning void
2. Drop chain_mode_fixup call in mode_valid()
3. Fixes the errors of MediaTek display driver found by IGT.
4. Add display support for the MT8365-EVK board
5. Fix bit depth overwritten for mtk_ovl_set bit_depth
On Fri, Jun 28, 2024 at 02:34:24PM GMT, Christian König wrote:
> Am 28.06.24 um 13:47 schrieb Thierry Reding:
> > [SNIP]
> > > > The reason I ask is that encryption here looks just like another
> > > > parameter
> > > > for the buffer, e.g. like format, stride, tilling etc..
> > > >
> > > > So in
Hi,
On Thu, Jun 27, 2024 at 09:22:56PM GMT, Maarten Lankhorst wrote:
> Den 2024-06-27 kl. 19:16, skrev Maxime Ripard:
> > Hi,
> >
> > Thanks for working on this!
> >
> > On Thu, Jun 27, 2024 at 05:47:21PM GMT, Maarten Lankhorst wrote:
> > > The initial version was based roughly on the rdma and m
On Thu, Jun 27, 2024 at 06:41:46PM +0300, Jani Nikula wrote:
> On Wed, 19 Jun 2024, Imre Deak wrote:
> > On Wed, Jun 19, 2024 at 01:10:09PM +0300, Jani Nikula wrote:
> >> On Fri, 14 Jun 2024, Imre Deak wrote:
> >> > Add helpers to convert between x16 fixed point and integer/fraction
> >> > values
On Fri, Jun 28, 2024 at 03:21:51PM GMT, mrip...@kernel.org wrote:
> On Fri, Jun 28, 2024 at 01:47:01PM GMT, Thierry Reding wrote:
> > On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> > > On Thu, Jun 27, 2024 at 08:57:40AM GMT, Christian König wrote:
> > > > Am 27.06.24 um 05:21 s
Hello,
On Fri, Jun 28, 2024 at 01:46:32PM +, Chun-Kuang Hu wrote:
> Hi, Dave & Daniel:
>
> This includes:
>
> 1. Convert to platform remove callback returning void
Note that this change (commit f5d5759d29e93fa76466204ad34169b3900a36c6)
is already in next (as commit 573a39d05053cb234a9ac3c7b
On Fri, Jun 28, 2024 at 04:12:10PM +0530, Ekansh Gupta wrote:
>
>
> On 6/28/2024 3:59 PM, Ekansh Gupta wrote:
> >
> > On 6/27/2024 4:43 PM, Dmitry Baryshkov wrote:
> >> On Thu, Jun 27, 2024 at 11:35:18AM GMT, Ekansh Gupta wrote:
> >>> For user PD initialization, initmem is allocated and sent to D
On Fri, Jun 28, 2024 at 03:08:46PM GMT, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 28, 2024 at 01:29:17PM GMT, Thierry Reding wrote:
> > On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> > > On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> > > > On Thu, May 16, 2024 at 3
Hi Dave & Sima -
Another feature pull towards v6.11, hopefully last. This should also fix
the 32-bit build issue [1] seen in drm-next.
BR,
Jani.
[1]
https://lore.kernel.org/r/CAPM=9tyNGA2wEgnsKdSyjHRGVikywZLdueZj=sytmfyeunz...@mail.gmail.com
drm-intel-next-2024-06-28:
drm/i915 feature pull
Hello,
Here are two relatively trivial fixes for bugs found while woking
on the Vulkan implementation, where NULL CS are needed to implement
VkQueue synchronization.
Regards,
Boris
Boris Brezillon (2):
drm/panthor: Don't check the array stride on empty uobj arrays
drm/panthor: Fix sync-only
A sync-only job is meant to provide a synchronization point on a
queue, so we can't return a NULL fence there, we have to add a signal
operation to the command stream which executes after all other
previously submitted jobs are done.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical blo
The user is likely to leave all the drm_panthor_obj_array fields
to zero when the array is empty, which will cause an EINVAL failure.
Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_drv.c | 6 +++---
1 file cha
On Fri, Jun 21, 2024 at 6:45 AM Mikhail Gavrilov
wrote:
>
> On Fri, Jun 21, 2024 at 12:56 PM Linux regression tracking (Thorsten
> Leemhuis) wrote:
> > Hmmm, I might have missed something, but it looks like nothing happened
> > here since then. What's the status? Is the issue still happening?
>
>
This patch series add dpu support for MSM8996/MSM8953 devices.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Signed-off-by: Barnabás Czémán
---
Dmitry Baryshkov (1):
drm/msm/dpu: add support for MSM8953
Konr
1 - 100 of 182 matches
Mail list logo
