On 24.06.2023 02:41, Marijn Suijten wrote:
> Enable MDSS and DSI, and configure the Samsung SOFEF01-M ams597ut01
> 6.0" 1080x2520 panel.
>
> Signed-off-by: Marijn Suijten
> ---
> .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59
> ++
> 1 file changed, 59 insertions(+)
On 24.06.2023 02:41, Marijn Suijten wrote:
> Add the DT nodes that describe the MDSS hardware on SM6125, containing
> one MDP (display controller) together with a single DSI and DSI PHY. No
> DisplayPort support is added for now.
>
> Signed-off-by: Marijn Suijten
> ---
> arch/arm64/boot/dts/qco
On Sat, 24 Jun 2023 02:41:05 +0200, Marijn Suijten wrote:
> Document the SM6125 MDSS.
>
> Signed-off-by: Marijn Suijten
> ---
> .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206
> +
> 1 file changed, 206 insertions(+)
>
My bot found errors running 'make DT_CHECKE
On 24.06.2023 02:41, Marijn Suijten wrote:
> Enable and configure the dispcc node on SM6125 for consumption by MDSS
> later on.
>
> Signed-off-by: Marijn Suijten
> ---
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/a
On 24.06.2023 02:41, Marijn Suijten wrote:
> We have a working RPM XO clock; no other driver except rpmcc should be
> parenting directly to the fixed-factor xo_board clock nor should it be
> reachable by that global name. Remove the name to that effect, so that
> every clock relation is explicitly
On 24.06.2023 02:41, Marijn Suijten wrote:
> SM6125 features only a single PHY (despite a secondary PHY PLL source
> being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
> sources for this "trinket" SoC do not define the typical "vcca"
> regulator to be available nor used.
>
>
On 24.06.2023 02:41, Marijn Suijten wrote:
> Add definitions for the display hardware used on the Qualcomm SM6125
> platform.
>
> Signed-off-by: Marijn Suijten
> ---
[...]
> +static const struct dpu_perf_cfg sm6125_perf_data = {
> + .max_bw_low = 410,
> + .max_bw_high = 410,
> +
On 24.06.2023 02:41, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> be passed from DT, and should be required by the bindings.
>
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> bindings")
> Signed-off-by: Marijn Suijten
On 24.06.2023 02:40, Marijn Suijten wrote:
> This node has always resided in the wrong spot, making it somewhat
> harder to contribute new node entries while maintaining proper sorting
> around it. Move the node up to sit after hsusb_phy1 where it maintains
> proper numerial
numerical
sorting on
On 24.06.2023 02:40, Marijn Suijten wrote:
> Bring up the SM6125 DPU now that all preliminary series (such as INTF
> TE) have been merged (for me to test the hardware properly)
We should not repeat the same mistake in the future.. Finding a
balance between releasing early and releasing what we can
On 6/23/2023 5:09 PM, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump har
Enable MDSS and DSI, and configure the Samsung SOFEF01-M ams597ut01
6.0" 1080x2520 panel.
Signed-off-by: Marijn Suijten
---
.../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125-sony-xperia-s
Add the DT nodes that describe the MDSS hardware on SM6125, containing
one MDP (display controller) together with a single DSI and DSI PHY. No
DisplayPort support is added for now.
Signed-off-by: Marijn Suijten
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 190 ++-
Add definitions for the display hardware used on the Qualcomm SM6125
platform.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalo
Document availability of the 14nm DSI PHY on SM6125.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
b/Documentation/devicetree/b
Enable and configure the dispcc node on SM6125 for consumption by MDSS
later on.
Signed-off-by: Marijn Suijten
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
b/arch/arm64/boot/dts/qcom/sm
We have a working RPM XO clock; no other driver except rpmcc should be
parenting directly to the fixed-factor xo_board clock nor should it be
reachable by that global name. Remove the name to that effect, so that
every clock relation is explicitly defined in DTS.
Signed-off-by: Marijn Suijten
--
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml | 1 +
1 file ch
Document the SM6125 MDSS.
Signed-off-by: Marijn Suijten
---
.../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +
1 file changed, 206 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
b/Documentation/devicetree/bindings/di
SM6125's UBWC hardware decoder is version 3.0, and supports decoding
UBWC 1.0.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 05648c910c68..bf68bae2
SM6125 features only a single PHY (despite a secondary PHY PLL source
being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
sources for this "trinket" SoC do not define the typical "vcca"
regulator to be available nor used.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm
Document general compatibility of the DSI controller on SM6125.
Signed-off-by: Marijn Suijten
---
Documentation/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
The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
be passed from DT, and should be required by the bindings.
Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
bindings")
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/clock/qcom,dis
On SM6125 the dispcc block is gated behind VDDCX: allow this domain to
be configured.
Signed-off-by: Marijn Suijten
---
Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6
Bring up the SM6125 DPU now that all preliminary series (such as INTF
TE) have been merged (for me to test the hardware properly), and most
other conflicting work (barring ongoing catalog *improvements*) has made
its way in as well or is still being discussed.
The second part of the series complem
The downsteam driver for dispcc only ever gets and puts this clock
without ever using it in the clocktree; this unnecessary workaround was
never ported to mainline, hence the driver doesn't consume this clock
and shouldn't be required by the bindings.
Fixes: 8397c9c0c26b ("dt-bindings: clock: add
This node has always resided in the wrong spot, making it somewhat
harder to contribute new node entries while maintaining proper sorting
around it. Move the node up to sit after hsusb_phy1 where it maintains
proper numerial sorting on the (first of its many) reg address property.
Fixes: cff4bbaf
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of sub
blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.
Signed-
On 6/23/2023 1:18 PM, Marijn Suijten wrote:
On 2023-06-23 23:10:56, Dmitry Baryshkov wrote:
There is no confusion between what was said earlier and now.
This line is calculating the number of pclks needed to transmit one line
of the compressed data:
hdisplay = DIV_ROUND_UP(msm_dsc_get_byte
On 6/23/2023 1:28 PM, Marijn Suijten wrote:
On 2023-06-23 14:37:12, Dmitry Baryshkov wrote:
In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
the CTL registers, but that change didn't make it through. 0x29c is an
arbitrary number that I have no clue what it was based on.
On 6/23/2023 2:33 PM, Marijn Suijten wrote:
On 2023-06-23 13:34:06, Abhinav Kumar wrote:
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock for u
On 2023-06-23 13:34:06, Abhinav Kumar wrote:
>
>
> On 6/23/2023 1:14 PM, Marijn Suijten wrote:
> > On 2023-06-23 10:29:51, Abhinav Kumar wrote:
> >
> >> The concept is quite simple
> >>
> >> one pixel per clock for uncompresssed without widebubus
> >>
> >> 2 pixels per clock for uncompressed wit
On 6/23/2023 1:14 PM, Marijn Suijten wrote:
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
The concept is quite simple
one pixel per clock for uncompresssed without widebubus
2 pixels per clock for uncompressed with widebus (only enabled for DP
not DSI)
3 bytes worth of data for compressed
On 2023-06-17 03:48:33, Dmitry Baryshkov wrote:
> On 17/06/2023 01:12, Marijn Suijten wrote:
> > On 2023-06-16 13:03:15, Dmitry Baryshkov wrote:
> >> To simplify making changes to the hardware block definitions, expand
> >> corresponding macros. This way making all the changes are more obvious
> >>
On 2023-06-23 14:37:12, Dmitry Baryshkov wrote:
> > In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover
> > the CTL registers, but that change didn't make it through. 0x29c is an
> > arbitrary number that I have no clue what it was based on.
>
> This should have been NAKed. or
On 2023-06-23 12:36:06, Abhinav Kumar wrote:
>
>
> On 6/22/2023 11:57 PM, Marijn Suijten wrote:
> > On 2023-06-23 08:54:39, Marijn Suijten wrote:
> >> On 2023-06-22 22:47:04, Abhinav Kumar wrote:
> >>> On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
> All DSC_BLK_1_2 declarations incorrectly p
On 2023-06-23 14:32:55, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8550 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> .../devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml | 8
>
On 2023-06-23 14:32:54, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8450 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> .../devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml | 8
>
On 2023-06-23 14:32:53, Neil Armstrong wrote:
> Document the optional displayport controller subnode of the SM8350 MDSS.
>
> Acked-by: Rob Herring
> Signed-off-by: Neil Armstrong
Reviewed-by: Marijn Suijten
> ---
> Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml | 6
> ++
On 2023-06-23 23:10:56, Dmitry Baryshkov wrote:
> >> There is no confusion between what was said earlier and now.
> >>
> >> This line is calculating the number of pclks needed to transmit one line
> >> of the compressed data:
> >>
> >> hdisplay = DIV_ROUND_UP(msm_dsc_get_bytes_per_line(msm_host->d
On 2023-06-23 10:29:51, Abhinav Kumar wrote:
> The concept is quite simple
>
> one pixel per clock for uncompresssed without widebubus
>
> 2 pixels per clock for uncompressed with widebus (only enabled for DP
> not DSI)
>
> 3 bytes worth of data for compressed without widebus
>
> 6 bytes wort
On 23/06/2023 23:02, Marijn Suijten wrote:
On 2023-06-23 12:54:17, Abhinav Kumar wrote:
On 6/23/2023 12:26 AM, Marijn Suijten wrote:
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM
On 2023-06-23 12:54:17, Abhinav Kumar wrote:
>
>
> On 6/23/2023 12:26 AM, Marijn Suijten wrote:
> > On 2023-06-22 17:32:17, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
> >>> On 23/06/2023 03:14, Abhinav Kumar wrote:
>
>
> On 6/19/2023 2:06 PM,
On 6/23/2023 12:26 AM, Marijn Suijten wrote:
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
On 23/06/2023 03:14, Abhinav Kumar wrote:
On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
Provide actual documentation for the pclk and hdisplay calcula
On 6/23/2023 12:40 PM, Dmitry Baryshkov wrote:
On 23/06/2023 22:37, Abhinav Kumar wrote:
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 dec
On 23/06/2023 22:37, Abhinav Kumar wrote:
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block
leng
On 6/23/2023 4:37 AM, Dmitry Baryshkov wrote:
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block
length.
This includes the common block itself
On 6/22/2023 11:57 PM, Marijn Suijten wrote:
On 2023-06-23 08:54:39, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itsel
On 6/23/2023 6:58 AM, Dmitry Baryshkov wrote:
Ryan pointed out [1] that some (most) of of sub-blocks do not fill the
field `name'. Further research showed that we can drop the fields `name'
and `id' and further simplify the catalog. The handling code also
usually knows, which sub-block it is n
On 6/23/2023 4:25 AM, Dmitry Baryshkov wrote:
On 23/06/2023 08:47, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. C
On 6/23/2023 12:19 AM, Marijn Suijten wrote:
On 2023-06-22 17:01:34, Abhinav Kumar wrote:
More interesting would be a link to the Mesa MR upstreaming this
bitfield to dsi.xml [2] (which I have not found on my own yet).
[2]:
https://gitlab.freedesktop.org/mesa/mesa/-/blame/main/src/freedren
On 6/22/2023 11:36 AM, Dmitry Baryshkov wrote:
On Thu, 22 Jun 2023 at 20:25, Kuogee Hsieh wrote:
Currently struct drm_dsc_config for DSI is populated at display
setup during system boot up. This mechanism works fine with
embedded display but not for pluggable displays as the
struct drm_dsc_co
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_c
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft. Do not deduplicate the
VIG sub-blocks for different platforms since this is pending another
cleanup/rework (of scaler version).
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu
Merge struct dpu_csc_blk and struct dpu_dsc_blk into new struct
dpu_simple_blk, which contains just base and length.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu
As the subblock info is now mostly gone, inline and drop the macro
DPU_HW_SUBBLK_INFO.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 +--
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_
From: Ryan McCann
Drop unused parameter "num" from all VIG and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
[DB: also added VIG_SBLK and VIG_SBLK_ROT]
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 62
There is little point in having a separate field with the name in the
sub-block info. Ryan pointed out that some (most) of of sub-blocks do
not even fill this field. The handling code also usually knows, which
sub-block it is now looking at.
Drop the unused field completely.
Suggested-by: Ryan Mc
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 24 ++-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|
Ryan pointed out [1] that some (most) of of sub-blocks do not fill the
field `name'. Further research showed that we can drop the fields `name'
and `id' and further simplify the catalog. The handling code also
usually knows, which sub-block it is now looking at.
Drop unused field and arguments and
Document the optional displayport controller subnode of the SM8550 MDSS.
Acked-by: Rob Herring
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml | 8
1 file changed, 8 insertions(+)
diff --git
a/Documentation/devicetree/bindings/displ
Document the displayport subnode to fix the bindings check error:
arch/arm64/boot/dts/qcom/sm8550-mtp.dtb: display-subsystem@ae0: Unevaluated
properties are not allowed ('displayport-controller@ae9' was unexpected)
From schema:
Documentation/devicetree/bindings/display/msm/qco
Document the optional displayport controller subnode of the SM8350 MDSS.
Acked-by: Rob Herring
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/displ
Document the optional displayport controller subnode of the SM8450 MDSS.
Acked-by: Rob Herring
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml | 8
1 file changed, 8 insertions(+)
diff --git
a/Documentation/devicetree/bindings/displ
On 23/06/2023 09:54, Marijn Suijten wrote:
On 2023-06-22 22:47:04, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change
On 23/06/2023 08:47, Abhinav Kumar wrote:
On 6/22/2023 6:37 PM, Dmitry Baryshkov wrote:
All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of comm
On 23/06/2023 09:27, Marijn Suijten wrote:
On 2023-06-21 11:26:25, Neil Armstrong wrote:
Document the optional document displayport controller subnode
document the optional *document*? Same in the other patches IIRC.
oops, will re-spin with this fixed
thanks!
- Marijn
of the SM8350 MD
On 2023-06-22 17:32:17, Abhinav Kumar wrote:
>
>
> On 6/22/2023 5:17 PM, Dmitry Baryshkov wrote:
> > On 23/06/2023 03:14, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/19/2023 2:06 PM, Dmitry Baryshkov wrote:
> >>> Provide actual documentation for the pclk and hdisplay calculations in
> >>> the case o
On 2023-06-21 11:26:25, Neil Armstrong wrote:
> Document the optional document displayport controller subnode
document the optional *document*? Same in the other patches IIRC.
- Marijn
> of the SM8350 MDSS.
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/display/m
On 2023-06-22 17:01:34, Abhinav Kumar wrote:
> > More interesting would be a link to the Mesa MR upstreaming this
> > bitfield to dsi.xml [2] (which I have not found on my own yet).
> >
> > [2]:
> > https://gitlab.freedesktop.org/mesa/mesa/-/blame/main/src/freedreno/registers/dsi/dsi.xml
> >
>
It is nice if cover letters also include the subsystem:
drm/msm: Add support to print DPU sub-block registers
On 2023-06-22 16:48:52, Ryan McCann wrote:
> The purpose of this patch series is to add support to print the registers
> of sub blocks in the dpu hardware catalog and fix the order in whi
On 2023-06-23 04:37:31, Dmitry Baryshkov wrote:
> Both struct dpu_dsc_sub_blks instances declare enc subblock length to be
> 0x100, while the actual length is 0x9c (last register having offset 0x98).
> Reduce subblock length to remove the empty register space from being
> dumped.
>
> Fixes: 0d1b10
On 2023-06-22 16:04:30, Abhinav Kumar wrote:
> >> Is widebus applicable only to the CMD mode, or video mode can employ it
> >> too?
> >
> > The patch description states that it was not tested on video-mode yet,
> > so I assume it will. But this should also be highlighted with a comment
> > (e.g
73 matches
Mail list logo
