This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays
Signed-off-by: Patrick Gansterer
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
---
.../bindings/leds/backlight/ti,lm3509.yaml| 136 ++
1
On Thu, May 23 2024 at 12:32:18 +01:00:00, Adrián Larumbe
wrote:
Commit a78027847226 ("drm/gem: Acquire reservation lock in
drm_gem_{pin/unpin}()") moved locking the DRM object's dma
reservation to
drm_gem_pin(), but Lima's pin callback kept calling drm_gem_shmem_pin,
which also tries to
I haven't been able to follow or review the work on the driver for some
time now and I don't see the situation improving anytime soon. I'd like
to continue being listed as a reviewer.
Signed-off-by: Melissa Wen
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Jason-JH.Lin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20240523]
[cannot apply to robh/for-next krzk-dt/for-next
fujitsu-integration/mailbox-for-next v6.9]
[If your patch is applied to the wrong git
On Sun, 26 May 2024 07:08:04 +0800, Jason-JH.Lin wrote:
> 1. Add mboxes property to define a GCE loopping thread as a secure IRQ
> handler.
> The CMDQ secure driver requests a mbox channel and sends a looping
> command to the GCE thread. The looping command will wait for a secure
> packet done
From: Jason-jh Lin
Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/userspace).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in
Add secure buffer control flow to mtk_drm_gem.
When user space takes DRM_MTK_GEM_CREATE_RESTRICTED flag and size
to create a mtk_drm_gem object, mtk_drm_gem will find a matched size
dma buffer from secure dma-heap and bind it to mtk_drm_gem object.
TODO:
1. Drop the mtk_gem_create_from_heap()
Add cmdq_insert_backup_cookie to append some commands before EOC:
1. Get GCE HW thread execute count from the GCE HW register.
2. Add 1 to the execute count and then store into a shared memory.
3. Set a software event siganl as secure irq to GCE HW.
Since the value of execute count + 1 is stored
Add DRM_MTK_GEM_CREATE_RESTRICTED flag for the user space to tell the
kernel space this dma buffer is restricted.
The user space can store this flag into the private data of the dma
buffer after allocating.
A restricted buffer is used to store the secure video content to support
secure video path
Add mtk_ddp_sec_write() to configure secure buffer information to
cmdq secure packet data and send to the secure world.
OVL and OVL_ADAPTOR need to use mtk_ddp_sec_write() instead of original
mtk_ddp_write() because the address in plane is secure handle not the real
buffer address.
The secure
Add is_sec flag to identify current mtk_drm_plane is secure.
Add mtk_plane_is_sec_fb() to check current drm_framebuffer is secure.
Signed-off-by: Jason-JH.Lin
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_plane.c | 18 ++
drivers/gpu/drm/mediatek/mtk_plane.h
To add secure flow support for mediatek-drm, each crtc have to
create a secure cmdq mailbox channel. Then cmdq packets with
display HW configuration will be sent to secure cmdq mailbox channel
and configured in the secure world.
Each crtc have to use secure cmdq interface to configure some secure
From: CK Hu
Add an interface to allocate MediaTek GEM buffers, allow the IOCTLs
to be used by render nodes.
This patch also sets the RENDER driver feature.
TODO:
Drop this path after we change all the usages of this ioctl to
DMA_HEAP_IOCTL_ALLOC in the user sapce.
Signed-off-by: CK Hu
On Sun, 26 May 2024, at 10:49 AM, きくちゃんさん wrote:
> Hi Ryan,
>
> How about to use "anbernic,rg35xx-panel" ?
> It's not generic though, some other drivers use similar strings already.
Could do, although I think it is used for more than one of the Anbernic
devices, so "anbernic,wl-355608-a8" might
CMDQ driver will probe a secure CMDQ driver when has_sec flag
in platform data is true and its device node in dts has defined a
event id of CMDQ_SYNC_TOKEN_SEC_EOF.
Secure CMDQ driver support on mt8188 and mt8195 currently.
So add a has_secure flag to their driver data to probe it.
There are 2 kind of GCE event signal:
- The SW token means: a GCE event signal triggered by SW drivers.
e.g. SW driver append a GCE command to set a GCE event after a specific
GCE command. Or SW driver use CPU to write a event id to GCE register to
trigger the GCE event corresponding to that event
To support CMDQ secure driver, move some reuseable definition to header.
- define: e.g. CMDQ_GCE_NUM_MAX, CMDQ_THR_BASE, CMDQ_THR_SIZE.
- struct: e.g. cmdq_thread, cmdq, cmdq_task.
- include: e.g. .
Add "#include " for the function that takes
"struct mbox_chan * chan" as a parameter. That may
Add cmdq_pkt_logic_command to support math operation.
cmdq_pkt_logic_command can append logic command to the CMDQ packet,
ask GCE to execute a arithmetic calculate instruction,
such as add, subtract, multiply, AND, OR and NOT, etc.
Note that all arithmetic instructions are unsigned calculations.
1. Add a loop flag for CMDQ packet struct.
CMDQ helper will use a loop flag to mark CMDQ packet as lopping command
and make current command buffer jumps to the beginning when GCE executes
to the end of command buffer.
2. Add a looping task handle flow in irq handler.
GCE irq occurs when GCE
From: Jason-jh Lin
For the Secure Video Path (SVP) feature, inculding the memory stored
secure video content, the registers of display HW pipeline and the
HW configure operations are required to execute in the secure world.
So using a CMDQ secure driver to make all display HW registers
To support secure video path feature, GCE have to read/write registgers
in the secure world. GCE will enable the secure access permission to the
HW who wants to access the secure content buffer.
Add CMDQ secure mailbox driver to make CMDQ client user is able to
sending their HW settings to the
Open secure cmdq_pkt APIs to support executing commands in secure world.
1. Add cmdq_sec_pkt_alloc_sec_data(), cmdq_sec_pkt_free_sec_data() and
cmdq_sec_pkt_set_data() to prepare the sec_data in cmdq_pkt that will
be referenced in the secure world.
2. Add cmdq_sec_insert_backup_cookie()
1. Add mboxes property to define a GCE loopping thread as a secure IRQ
handler.
The CMDQ secure driver requests a mbox channel and sends a looping
command to the GCE thread. The looping command will wait for a secure
packet done event signal from secure world and then jump back to the
first
Hi Ryan,
How about to use "anbernic,rg35xx-panel" ?
It's not generic though, some other drivers use similar strings already.
Regards,
kikuchan.
On Sun, 26 May 2024, at 3:22 AM, Conor Dooley wrote:
>>
>> Thanks, I don't actually know the vendor, would it be acceptable to just use
>> "wl"?
>
> You mean, "wl,355608-a8"? I did a wee bit of googling of the thing, and
> yeah, there's nothing that a surface level search turns up for it -
>
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1][2].
The "struct dma_fence_array" can be refactored to add a flex array in order
to have the "callback structures allocated behind the array" be more
explicit.
Do so:
- makes
> VCPU_RESERVED and LEGACY_X2APIC are not VMware hypercall commands.
> These are bits in return value of VMWARE_CMD_GETVCPU_INFO command.
> Change VMWARE_CMD_ prefix to GETVCPU_INFO_ one. …
Can such information be relevant for the addition of the tag “Fixes”?
Regards,
Markus
On Sat, May 25, 2024 at 09:26:48AM +1200, Ryan Walklin wrote:
> On Sat, 25 May 2024, at 7:10 AM, Conor Dooley wrote:
>
> Thanks for the review!
>
> >> +
> >> +properties:
> >> + compatible:
> >> +const: wl-355608-a8
> >
> > You're missing a vendor prefix here. And when you add it, update
https://bugzilla.kernel.org/show_bug.cgi?id=218891
sander44 (ionut_n2...@yahoo.com) changed:
What|Removed |Added
Kernel Version||6.9.0
--
You may
https://bugzilla.kernel.org/show_bug.cgi?id=218891
Bug ID: 218891
Summary: In function ‘dcn321_update_bw_bounding_box’ - warning:
the frame size of 1336 bytes is larger than 1280 bytes
Product: Drivers
Version: 2.5
From: John Harrison
Enable another workaround that is implemented inside the GuC.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 32 ---
2 files changed, 21 insertions(+), 12 deletions(-)
The pull request you sent on Sat, 25 May 2024 06:23:25 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-05-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/56fb6f92854f29dcb6c3dc3ba92eeda1b615e88c
Thank you!
--
Deet-doot-dot, I am a bot.
On Sat, 25 May 2024, at 7:10 AM, Conor Dooley wrote:
Thanks for the review!
>> +
>> +properties:
>> + compatible:
>> +const: wl-355608-a8
>
> You're missing a vendor prefix here. And when you add it, update the
> filename to match.
Thanks, I don't actually know the vendor, would it be
On 24/05/2024 20:57, Abhinav Kumar wrote:
Hello
On 5/24/2024 12:55 PM, Paul E. McKenney wrote:
Hello!
I get the following allmodconfig build error on x86 in next-20240523:
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
On Fri, May 24, 2024 at 11:19:41AM -0700, Abhinav Kumar wrote:
>
>
> On 5/24/2024 8:01 AM, Junhao Xie wrote:
> > There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv,
> > which cause weston assertions failed.
> >
> > weston: libweston/drm-formats.c:131:
Hi Linus,
Some fixes for the end of the merge window, mostly amdgpu and panthor,
with one nouveau uAPI change that fixes a bad decision we made a few
months back.
Regards,
Dave.
drm-next-2024-05-25:
drm fixes for 6.10-rc1
nouveau:
- fix bo metadata uAPI for vm bind
panthor:
- Fixes for
On Fri, May 24, 2024 at 12:58:53PM -0700, Abhinav Kumar wrote:
>
>
> On 5/22/2024 3:24 AM, Dmitry Baryshkov wrote:
> > In the DPU driver blank IRQ handling is called from a vblank worker and
> > can happen outside of the irq_enable / irq_disable pair. Using the
> > worker makes that completely
On Fri, May 24, 2024 at 09:18:21PM +0800, Jun Nie wrote:
> From: Jonathan Marek
>
> Add necessary DPU timing and control changes for DSC to work with DSI
> video mode.
>
> Signed-off-by: Jonathan Marek
> Signed-off-by: Jun Nie
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2
On 5/22/2024 3:24 AM, Dmitry Baryshkov wrote:
In the DPU driver blank IRQ handling is called from a vblank worker and
can happen outside of the irq_enable / irq_disable pair. Using the
worker makes that completely asynchronous with the rest of the code.
Revert commit d13f638c9b88
Hello
On 5/24/2024 12:55 PM, Paul E. McKenney wrote:
Hello!
I get the following allmodconfig build error on x86 in next-20240523:
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
File
Hello!
I get the following allmodconfig build error on x86 in next-20240523:
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main
On Fri, May 24, 2024 at 05:54:02PM +0530, Jayesh Choudhary wrote:
> Hello Dmitry,
>
> On 24/05/24 15:11, Dmitry Baryshkov wrote:
> > On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote:
> > > Currently, mode_valid hook returns all mode as valid and it is
> > > defined only in
On Fri, May 24, 2024 at 10:33:13PM +1200, Ryan Walklin wrote:
> The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
> OEM, used in a number of handheld gaming devices made by Anbernic.
>
> Add a device tree binding for the panel.
>
> Signed-off-by: Ryan Walklin
> ---
>
Hi,
Sorry, my previous reply got messed up as a result of HTML formatting. This is
a plain text version of the same reply.
>
>
> Having virtio-gpu import scanout buffers (via prime) from other
> devices means that we'd be adding a head to headless GPUs assigned
> to a Guest
Hi All
This series initially cleans up the BCM2835 DMA driver in preparation for
supporting the 40bit version. It then fixes up the incorrect mapping behaviour
we've had to date.
The cleanups are based on Stefan Wahren's RFC [1], with a couple of minor bugs
fixed, but stopping before actually
The code handling DMA mapping is currently incorrect and
needs a sequence of fixups.
Move the mapping out into a separate function and structure
to allow for those fixes to be applied more cleanly.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 46
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
sound/soc/bcm/bcm2835-i2s.c | 18 --
1
In order to use the dma_map_resource for mappings, add the
dma-ranges to the relevant DT files.
Signed-off-by: Dave Stevenson
---
arch/arm/boot/dts/broadcom/bcm2711.dtsi | 12 ++--
arch/arm/boot/dts/broadcom/bcm2835.dtsi | 3 ++-
arch/arm/boot/dts/broadcom/bcm2836.dtsi | 3 ++-
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/mmc/host/bcm2835.c | 17 +++--
1
Now that all DMA clients are passing in CPU addresses, drop
the workaround that would accept those and not try mapping
them.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c
bcm2835-dma has been (incorrectly) expecting dma addresses to be
passed in, not CPU physical addresses.
In order to fix this up, add temporary handling of clients still
passing in dma addresses until they are fixed up.
This will be reverted once all clients have been fixed.
Signed-off-by: Dave
We have a historical error in the DT files that don't define
the dma-ranges fully, and DMA users have been passing in
DMA addresses instead of CPU physical addresses.
As DT is ABI, we have to be able to work with old DT but new
kernel, which means handling this missing dma-range mapping
somehow.
There is a need to account for dma-ranges and iommus in the
dma mapping process, and the public API for handling that is
dma_map_resource.
Add support for mapping addresses to the DMA driver.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 46
From: Stefan Wahren
Nowadays there is a generic property for dma-channel-mask in the DMA
controller binding. So prefer this one instead of the old vendor specific
one. Print a warning in case the old one is used. Btw use the result of
of_property_read_u32() as return code in error case.
From: Phil Elwell
Slave addresses for DMA are meant to be supplied as physical addresses
(contrary to what struct snd_dmaengine_dai_dma_data does).
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
1 file changed, 4
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/spi/spi-bcm2835.c | 23 ---
From: Stefan Wahren
In preparation to support more platforms pass the dma_chan to the
generic functions. This provides access to the DMA device and possible
platform specific data.
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 24
From: Stefan Wahren
The parameters info and finalextrainfo are platform specific. So drop
them by generating them within bcm2835_dma_create_cb_chain().
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 83 +++
1
From: Stefan Wahren
Actually the criteria to increment source & destination address doesn't
based on platform specific bits. It's just the DMA transfer direction which
is translated into the info bits. So introduce two new helper functions
and get the rid of these platform specifics.
From: Stefan Wahren
Similar to the info generation, generate the final extra info with a
separate function. This is necessary to introduce other platforms
with different info bits.
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 34
From: Stefan Wahren
Actually the generation of the Control Block info follows some simple
rules. So handle this with a separate function to avoid open coding
for every DMA operation. Another advantage is that we can easier
introduce other platforms with different info bits.
Signed-off-by:
From: Serge Semin
A basic device-specific linear memory mapping was introduced back in
commit ("dma: Take into account dma_pfn_offset") as a single-valued offset
preserved in the device.dma_pfn_offset field, which was initialized for
instance by means of the "dma-ranges" DT property. Afterwards
Now the driver looks for the common dma-channel-mask property
rather than the vendor-specific brcm,dma-channel-mask, update
the dt files to follow suit.
Signed-off-by: Dave Stevenson
---
arch/arm/boot/dts/broadcom/bcm2711.dtsi| 2 +-
arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 2 +-
On 5/24/2024 8:01 AM, Junhao Xie wrote:
There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv,
which cause weston assertions failed.
weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format:
Assertion `!weston_drm_format_array_find_format(formats, format)'
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM, used in a number of handheld gaming devices made by Anbernic.
Limited information is available online however the panel timing values
(below) have been obtained from the vendor BSP. The panel appears to
integrate a
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM, used in a number of handheld gaming devices made by Anbernic.
Add a device tree binding for the panel.
Signed-off-by: Ryan Walklin
---
.../bindings/display/panel/wl-355608-a8.yaml | 68 +++
1 file
Hello,
The WL_355608_A8 panel is a VGA LCD display with an NV3052C-compatible driver
IC, used in a number of Anbernic handheld gaming devices. This patch adds a
device tree binding, and support for the display timings and init sequence to
the NV3052C SPI/RGB driver.
Regards,
Ryan
Ryan
Hi Ryan,
Thanks for your contribution. Here's my sign-off:
Signed-off-by: Hironori KIKUCHI
On Wed, 2024-05-15 at 13:24 +0200, Karolina Stolarek wrote:
> List improvements for the test suite with some notes.
>
> Signed-off-by: Karolina Stolarek
LGTM.
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/ttm/tests/TODO | 25 +
> 1 file changed, 25
On 24.05.2024 5:01 PM, Junhao Xie wrote:
> There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv,
> which cause weston assertions failed.
>
> weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format:
> Assertion `!weston_drm_format_array_find_format(formats, format)'
On Wed, 2024-05-15 at 13:24 +0200, Karolina Stolarek wrote:
> BOs in a bulk move have to share the same reservation object. That is
> not the case in the ttm_bo_unreserve_bulk subtest. Update
> ttm_bo_kunit_init() helper to accept dma_resv object so we can define
> buffer objects that share the
There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv,
which cause weston assertions failed.
weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format:
Assertion `!weston_drm_format_array_find_format(formats, format)' failed.
Signed-off-by: Junhao Xie
---
On Fri, May 24, 2024 at 01:58:53AM +0200, Andi Shyti wrote:
> Following the guidelines it takes 3 seconds to perform an FLR
> reset. Let's give it a bit more slack because this time can
> change depending on the platform and on the firmware
But did we see any issue with that?
if that changes per
Trying to build parisc:allmodconfig with gcc 12.x or later results
in the following build error.
drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd':
drivers/gpu/drm/nouveau/nvif/object.c:161:9: error:
'memcpy' accessing 4294967264 or more bytes at offsets 0 and 32
Applied. Thanks!
On Thu, May 23, 2024 at 10:37 PM Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5200
> dc_power_down_on_boot() warn: inconsistent indenting.
>
> Reported-by: Abaci Robot
> Closes:
There is not need for private release action as there are existing
drmm_mm_init() and drmm_mutex_init() helpers that can be used.
Signed-off-by: Michal Wajdeczko
Cc: Thomas Hellström
Cc: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_ggtt.c | 23 +++
1 file changed, 11
Add drmm_mm_init(), a helper that provides managed allocator cleanup.
The allocator will be cleaned up with the final reference of the DRM
device.
Signed-off-by: Michal Wajdeczko
Cc: Thomas Zimmermann
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_managed.c | 27 +++
Add drmm_mm_init(), a helper that provides managed allocator cleanup,
and start using it in the Xe driver.
Michal Wajdeczko (2):
drm: Add DRM-managed drm_mm_init()
drm/xe: Use drm_device managed mutex/mm init helpers in GGTT
drivers/gpu/drm/drm_managed.c | 27 +++
On 2024/05/07 22:09, Christian König wrote:
> Am 05.05.24 um 16:08 schrieb Tetsuo Handa:
>> Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
>> known context") by error replaced spin_unlock_irqrestore() with
>> spin_unlock_irq() for both sync_debugfs_show() and
From: Jonathan Marek
Make it clear why the pkt_per_line value is being "divided by 2".
Signed-off-by: Jonathan Marek
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jun Nie
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Jonathan Marek
The value returned by msm_dsi_wide_bus_enabled() doesn't match what the
driver is doing in video mode. Fix that by actually enabling widebus for
video mode.
Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI")
Signed-off-by: Jonathan Marek
Reviewed-by: Dmitry
From: Jonathan Marek
Video mode DSC won't work if this field is not set correctly. Set it to fix
video mode DSC (for slice_per_pkt==1 cases at least).
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Jonathan Marek
Reviewed-by: Dmitry Baryshkov
data is valid for only half the active window if widebus
is enabled
Signed-off-by: Jun Nie
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index
From: Jonathan Marek
Add necessary DPU timing and control changes for DSC to work with DSI
video mode.
Signed-off-by: Jonathan Marek
Signed-off-by: Jun Nie
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 8
This is follow up update to Jonathan's patch set.
Changes vs V3:
- Rebase to latest msm-next-lumag branch.
- Drop the slice_per_pkt change as it does impact basic DSC feature.
- Remove change in generated dsi header
- update DSC compressed width calculation with bpp and bpc
- split wide bus
Hello Dmitry,
On 24/05/24 15:11, Dmitry Baryshkov wrote:
On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote:
Currently, mode_valid hook returns all mode as valid and it is
defined only in drm_connector_helper_funcs. With the introduction of
'DRM_BRIDGE_ATTACH_NO_CONNECTOR',
On Fri, 24 May 2024 22:33:13 +1200, Ryan Walklin wrote:
> The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
> OEM, used in a number of handheld gaming devices made by Anbernic.
>
> Add a device tree binding for the panel.
>
> Signed-off-by: Ryan Walklin
> ---
>
Hi Maxime,
On 21/05/24 18:45, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 16, 2024 at 03:10:15PM GMT, Aradhya Bhatia wrote:
/**
* @pre_enable:
*
@@ -285,6 +319,26 @@ struct drm_bridge_funcs {
*/
void (*enable)(struct drm_bridge *bridge);
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-panic-Add-ABGR2101010-support/20240523-211335
base:
Hi Heiko,
On 12/14/23 14:46, Andy Yan wrote:
Hi Heiko:
On 12/13/23 22:46, Heiko Stuebner wrote:
On Mon, 11 Dec 2023 19:55:47 +0800, Andy Yan wrote:
From: Andy Yan
This patch sets aims at enable the VOP2 support on rk3588.
Main feature of VOP2 on rk3588:
Four video ports:
VP0 Max 4096x2160
From: Michael Tretter
There is no reason to limit the DMA max segment size for the Rockchip
VOP and VOP2. Set it to the maximum.
This prevents the following warning when DMA API debugging is enabled
with CONFIG_DMA_API_DEBUG_SG=y:
DMA-API: rockchip-drm display-subsystem: mapping sg
On Fri, May 24, 2024 at 12:43:48PM +0530, Jayesh Choudhary wrote:
> With the support for the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR' case,
> the connector_helper funcs are not initialized if the encoder has this
> flag in its bridge_attach call. Till now we had mode_valid hook only in
> the
On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote:
> Currently, mode_valid hook returns all mode as valid and it is
> defined only in drm_connector_helper_funcs. With the introduction of
> 'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
> bridge_attach call for
On Fri, May 24, 2024 at 01:03:04PM +0530, Jayesh Choudhary wrote:
> Currently, mode_valid hook returns all mode as valid and it is
> defined only in drm_connector_helper_funcs. With the introduction of
> 'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
> bridge_attach call for
Check the pixel clock for the mode in atomic_check and ensure that
it is within the range supported by the bridge.
Signed-off-by: Jayesh Choudhary
---
drivers/gpu/drm/bridge/sii902x.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c
Currently, mode_valid hook returns all mode as valid and it is
defined only in drm_connector_helper_funcs. With the introduction of
'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
bridge_attach call for cases when the encoder has this flag enabled.
So add the mode_valid hook in
Currently, there are no check to validate the modes in the bridge.
Add pixel clock check to validate the modes that the bridge can support.
Also add the mode_valid hook in drm_bridge_funcs structure to take care
of the case when the encoder attaches the bridge chain with the
Hello Sam,
On 24/05/24 13:48, Sam Ravnborg wrote:
Hi Jayesh,
On Fri, May 24, 2024 at 01:03:04PM +0530, Jayesh Choudhary wrote:
Currently, mode_valid hook returns all mode as valid and it is
defined only in drm_connector_helper_funcs. With the introduction of
'DRM_BRIDGE_ATTACH_NO_CONNECTOR',
1 - 100 of 488358 matches
Mail list logo
