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(-)
d
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.
ht
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 accep
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: weston_drm_format_array_ad
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 panthor
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 as
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 ("drm/msm/dpu
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 "drivers/gpu/drm/msm/registers/gen_heade
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
parser.add_argument('--validat
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 drm_conn
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
> ---
> .../b
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 VM
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 add
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 f
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 ++-
arch/ar
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 fil
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 b/drivers/dma/bcm2835
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 St
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.
T
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.
Signed-o
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 insertions(+)
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 file
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.
Signed-off-
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: Stefan
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 t
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)' failed
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 NV3052
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 chan
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 Walkli
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 insertions(+)
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 sam
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
---
drivers/gp
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
overl
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: https://bugzilla.openanolis
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 insertions(+
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 +++
include
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 +++
dri
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 sync_print
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 a/drivers/gpu/drm/msm/dsi/dsi
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 Baryshk
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
Signed-off-b
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
dri
| 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-
5 files changed, 43 insertions(+), 2 deletions(-)
---
base-commit: e6428bcb611f6c164856a41fc5a1ae8471a9b5a9
change-id: 20240524-msm-drm-dsc-dsi-video-upstr
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', connec
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
> ---
> .../bindi
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 segm
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 drm_connector_
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 case
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 case
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 b/drivers/gpu/drm/bri
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 dr
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
DRM_BRIDGE_ATTACH_NO_C
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', c
On Thu, 23 May 2024, Sam Ravnborg wrote:
> Hi Jani,
>
> On Thu, May 23, 2024 at 06:51:09PM +0300, Jani Nikula wrote:
>> With the -Wformat-truncation warnings fixed, finish the job started in
>> commit a61ddb4393ad ("drm: enable (most) W=1 warnings by default across
>> the subsystem"), and enable t
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: error
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', connector is not initialized in
> bridge_attach c
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
> [ ] :
On Thu, 23 May 2024, John Harrison wrote:
> On 5/23/2024 16:54, Daniele Ceraolo Spurio wrote:
>> Forwarded Message
>> Subject: [RFC] drm/print: Introduce drm_line_printer
>> Date:Tue, 14 May 2024 16:56:31 +0200
>> From:Michal Wajdeczko
>> To: dri-devel@lists
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 dr
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 | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/dri
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
DRM_BRIDGE_ATTACH_NO_C
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 drm_connector_helper_funcs. Add this hook in drm_bridge_funcs to
validate the modes in t
81 matches
Mail list logo
