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
++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.exampl
kerneldoc problems
2. fix typo in title and commit message
3. adjust naming for secure variable
4. add the missing part for is_suecure plane implementation
5. use BIT_ULL macro to replace bit shifting
6. move modification of ovl_adaptor part to the correct patch
7. add TODO list in commit message
8. add
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
Signed
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
error
5. Remove finalize loop API and write_s_reg API patch
6. Add cmdq secure helper API patch
Changes in v5:
1. Sync the local changes
Changes in v4:
1. Rebase on mediatek-drm-next(278640d4d74cd) and fix the conflicts
2. This series is based on 20240307013458.23550-1-jason-jh@mediatek.com
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
s nothing that a surface level search turns up for it -
other than they appeared to have a logo with a W in a circle...
I think if we genuinely do not know what the vendor is then we just
don't have a prefix.
> >> +compatible = "wl_355608_a8";
> >
> &
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(-)
"panel" label is not used, you should drop it.
>
Noted, ta.
>> +compatible = "wl_355608_a8";
>
> This doesn't match what you documented, be sure to run dt_binding_check.
Thanks, changed underscore to dash mid-patch and neglected to fix all the
examples (
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:
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
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
> ---
>
ap_resource is the correct API, but as it currently doesn't check the
dma_range_map we need Sergey Semin's patch [4].
There seemed to be no follow up over the implications of it. I've therefore
included it in the series at least for discussion. If it's not acceptable then
I'm not sure of the route
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
---
anges per platform and per firmware, shouldn't it all
be explicit in the spec as well?
>
> Signed-off-by: Andi Shyti
> ---
> Hi,
>
> In this second version I removed patch 2 that was ignoring the
> FLR reset timeouts, until we develop a proper patch.
>
> This fir
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 +++
ck,unlock}_irq().
>>
>> Reported-by: syzbot
>> Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe
>> Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
>> context")
>> Signed-off-by: Tetsuo Handa
>
> Re
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',
ed-off-by: Ryan Walklin
> ---
> .../bindings/display/panel/wl-355608-a8.yaml | 68 +++
> 1 file changed, 68 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/wl-355608-a8.yaml
>
My bot found errors running 'make dt_binding_check' on your pa
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);
: 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005
patch link:
https://lore.kernel.org/r/20240523130955.428233-6-jfalempe%40redhat.com
patch subject: [PATCH 5/5] drm/nouveau: Add drm_panic support for nv50+
config: x86_64-randconfig-r113-20240524
(https://download.01.org/0day-ci/archive/20240524/202405241832.etperbon-...@intel.com
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
with the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag in which case, the connector is not
initialized in the bridge's attach call.
Also add this check to the atomic_check call as suggested by Maxime in
v1 patch.
Changelog v2->v3:
- Remove newline that was introduced in [1/2] and later deleted in [2/2]
in v2
v2 patch:
<
drop the above change as you delete the line again
in the next patch.
Sam
While splitting the patches, I must have messed up.
I will quickly send v3 with this fixed.
Thanks,
Jayesh
-Wformat-truncation)
> drivers/gpu/drm/xe/Makefile:subdir-ccflags-y += $(call cc-option,
> -Wformat-truncation)
>
> Just a drive-by comment, I know this patch was mostly for the bots.
Additionally, I didn't want to create any conflicts with [1]. There's no
harm in having the dupli
On Thu, 23 May 2024, Alex Deucher wrote:
> Already fixed with this patch:
> https://patchwork.freedesktop.org/patch/594864/
Great, thanks!
BR,
Jani.
--
Jani Nikula, Intel
On Thu, 23 May 2024, Ville Syrjälä wrote:
> On Thu, May 23, 2024 at 06:51:08PM +0300, Jani Nikula wrote:
>> Enabling -Wformat-truncation yields the following warning:
>>
>> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c: In function ‘imx_ldb_probe’:
>> ../drivers/gpu/drm/imx/ipuv3/imx-ldb.c:658:57:
* There might be flags negotiation supported in future but
>* set the bus flags in atomic_check statically for now.
>*/
> +
> bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
If you spin a v2 then drop the above change as you delete the line again
in the next patch.
Sam
On Thu, 23 May 2024, Michal Wajdeczko wrote:
> All drm_device based logging macros, except those related to WARN,
> include the [drm] prefix. Fix that.
>
> [ ] :00:00.0: this is a warning
> [ ] :00:00.0: drm_WARN_ON(true)
> vs
> [ ] :00:00.0: [drm] this is a warning
> [ ]
1 - 100 of 353568 matches
Mail list logo
