if' as a possible
'fsl,imx6sx-lcdif' fallback.
Signed-off-by: Fabio Estevam
Acked-by: Rob Herring (Arm)
Reviewed-by: Ahmad Fatoum
---
Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation
On Wed, Sep 10, 2025 at 12:56 PM Frank Li wrote:
> > compatible = "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
>
> Anyway, you change dts. If you change dts as
>
> compatible = "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif";
>
> needn't update binding here.
This was discussed in previous i
The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.
Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.
Signed-off-by: Fabio Estevam
Reviewed-by: Ahmad Fatoum
---
arch/arm/boot/dts/nxp/imx/imx6sl.dts
28-lcdif fallback:
compatible = "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
This helps keeping DT compatibility as well as using the more advanced
lcdif features found on imx6sl and imx6sll.
Signed-off-by: Fabio Estevam
Acked-by: Rob Herring
On Tue, Aug 19, 2025 at 7:59 AM Maud Spierings via B4 Relay
wrote:
>
> From: Maud Spierings
>
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with intgrated boost controller.
Typo: integrated
Hi Javier and Thomas,
On Tue, Apr 22, 2025 at 6:53 PM Javier Martinez Canillas
wrote:
>
> Fabio Estevam writes:
>
> Hello Fabio,
>
> > From: Fabio Estevam
> >
> > Since commit 559358282e5b ("drm/fb-helper: Don't use the preferred depth
> > f
Hi Tomeu,
On Wed, May 7, 2025 at 8:22 AM Tomeu Vizoso wrote:
>
> We should be comparing the last submitted sequence number with that of
> the address space we may be switching to.
>
> And we should be using the latter as the last submitted sequence number
> afterwards.
>
> Signed-off-by: Tomeu Vi
From: Fabio Estevam
Since commit 559358282e5b ("drm/fb-helper: Don't use the preferred depth
for the BPP default"), RGB565 displays such as the CFAF240320X no longer
render correctly: colors are distorted and the content is shown twice
horizontally.
This regression is due to the
Hi Thomas,
On Wed, Apr 16, 2025 at 3:41 AM Thomas Zimmermann wrote:
> The proper fix would patch the driver to support 32-bit correctly. It
> looks like the panel only supports 16 bpp and 24 bpp, so format
> conversion would be required.
>
> For an easier fix, you can replace drm_client_setup()
From: Fabio Estevam
Since commit 559358282e5b ("drm/fb-helper: Don't use the preferred depth
for the BPP default") an RGB565 CFAF240320X display no longer works
correctly: the colors are wrong and the content appears twice on the
screen, side by side.
The reason for the regressi
= 32;
+ preferred_bpp = 16;
INIT_LIST_HEAD(&helper->kernel_fb_list);
spin_lock_init(&helper->damage_lock);
and the display correctly again.
What is the proper fix for this issue?
Thanks,
Fabio Estevam
Rob,
On Tue, Dec 17, 2024 at 10:20 AM Fabio Estevam wrote:
> > Acked-by: Rob Herring (Arm)
>
> Can you apply 1/3 and 2/3?
Gentle ping.
On Tue, Jan 7, 2025 at 8:21 PM Rob Herring (Arm) wrote:
> Fabio is clearly confused, and I prefer this patch over his. As
> it is probably past the drm-misc cutoff, I applied it to DT tree.
You are right. I am sorry for the confusion.
Hi Alexander,
On Tue, Jan 7, 2025 at 6:50 AM Alexander Stein
wrote:
>
> This add a imx7(d) specific compatible which is compatible to imx8mm.
> This silences the dtbs_check warning:
> arch/arm/boot/dts/nxp/imx/imx7s-mba7.dtb: dsi@3076: compatible: 'oneOf'
> conditional failed, one must be fi
4: 'csi-mux' does
> not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id:
> http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml#
>
> Signed-off-by: Alexander Stein
Reviewed-by: Fabio Estevam
Rob,
On Mon, Nov 4, 2024 at 12:42 PM Rob Herring (Arm) wrote:
>
>
> On Fri, 01 Nov 2024 10:54:04 -0300, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > imx6sx.dtsi has the following lcdif entries:
> >
> > compatible = "fsl,imx6sx-lcdif", &qu
From: Fabio Estevam
The i.MX7D MIPI DSIM block is compatible with i.MX8MM.
imx7s.dtsi uses the following compatible string:
compatible = "fsl,imx7d-mipi-dsim", "fsl,imx8mm-mipi-dsim";
Document "fsl,imx7d-mipi-dsim" to fix the following dt-schema warning:
[
Hi Neil,
On Wed, Dec 11, 2024 at 6:31 AM Krzysztof Kozlowski wrote:
>
> On Tue, Dec 10, 2024 at 07:57:04AM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > The AUO G084SN05 V9 is an 8.4" 800x600 LVDS display.
> >
> > Add a compatible entry fo
From: Fabio Estevam
The AUO G084SN05 V9 is an 8.4" 800x600 LVDS display.
Add a compatible entry for this LVDS display model.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Added devicet...@vger.kernel.org on Cc.
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2
From: Fabio Estevam
The imx8mm-phg board has an AUO G084SN05 V9 8.4" 800x600 LVDS panel.
Improve the devicetree description by passing the LVDS compatible
string to fix the following dt-schema warning:
imx8mm-phg.dtb: panel: compatible:0: 'panel-lvds' is not one of
['ad
From: Fabio Estevam
The imx8mm-phg board has an AUO G084SN05 V9 8.4" 800x600 LVDS panel.
Improve the devicetree description by passing the LVDS compatible
string to fix the following dt-schema warning:
imx8mm-phg.dtb: panel: compatible:0: 'panel-lvds' is not one of
['ad
From: Fabio Estevam
The AUO G084SN05 V9 is a 8.4" 800x600 LVDS display.
Add a compatible entry for this LVDS display model.
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Document
From: Fabio Estevam
imx6sx.dtsi has the following lcdif entries:
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
This causes the following dt-schema warning:
['fsl,imx6sx-lcdif', 'fsl,imx28-lcdif'] is too long
To keep DT compatibility, document &#x
From: Fabio Estevam
mx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:
compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.
['fsl,imx6sl-lcdif
From: Fabio Estevam
The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.
Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- None.
arch/arm/boot/dts
Hi Marek,
On Tue, Oct 29, 2024 at 5:16 PM Marek Vasut wrote:
> So you wouldn't have to write three compatible strings for the 6sl/sll ,
> but only two ? I.e. this:
>
> compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
> compatible = "fsl,imx6sll-lcdif", "fsl,imx28-lcdif";
i.MX6SL and i.MX6SLL
From: Fabio Estevam
imx6sx.dtsi has the following lcdif entries:
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
This causes the following dt-schema warning:
['fsl,imx6sx-lcdif', 'fsl,imx28-lcdif'] is too long
To keep DT compatibility, document &#x
From: Fabio Estevam
The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.
Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- None.
arch/arm/boot/dts
From: Fabio Estevam
mx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:
compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.
['fsl,imx6sl-lcdif
From: Fabio Estevam
imx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:
compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.
['fsl,imx6sl-lcdif
From: Fabio Estevam
The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.
Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Add 3 entries for keep
From: Fabio Estevam
imx6sx.dtsi has the following lcdif entries:
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
This causes the following dt-schema warning:
['fsl,imx6sx-lcdif', 'fsl,imx28-lcdif'] is too long
To keep DT compatibility, document &#x
From: Fabio Estevam
i.MX28 has an RX DMA channel associated with the LCDIF controller.
Document the 'dmas' and 'dma-names' properties to fix the following
dt-schema warnings:
lcdif@8003: 'dma-names', 'dmas' do not match any of the regexes:
'
Hi Marek,
On Tue, Sep 3, 2024 at 1:51 PM Marek Vasut wrote:
> This also applies to MX23 , that one also has the support for
> command-mode LCDs which are then driven by pumping commands via DMA. I
> don't think Linux actually supports this mode of operation, but I do
> recall using it some long
From: Fabio Estevam
i.MX28 has an RX DMA channel associated with the LCDIF controller.
Document the 'dmas' and 'dma-names' properties to fix the following
dt-schema warnings:
lcdif@8003: 'dma-names', 'dmas' do not match any of the regexes:
'
A gentle ping on this series.
Thanks
On Wed, Jun 26, 2024 at 8:07 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS()
> alternative.
>
> The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS()
>
From: Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the
From: Fabio Estevam
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows
From: Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the
From: Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the
From: Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative.
The combined usage of pm_ptr() and RUNTIME_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows removing the
From: Fabio Estevam
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS()
alternative.
The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS()
allows the compiler to evaluate if the runtime suspend/resume() functions
are used at build time or are simply dead code.
This allows
Hi Adam,
On Tue, Feb 6, 2024 at 9:23 PM Adam Ford wrote:
>
> Two separate build warnings were reported. One from an
> uninitialized variable, and the other from returning 0
> instead of NULL from a pointer.
>
> Fixes: 059c53e877ca ("drm/bridge: imx: add driver for HDMI TX Parallel Video
> Inter
Hi Adam,
Thanks for moving this forward.
On Fri, Jan 5, 2024 at 10:56 PM Adam Ford wrote:
>
> From: Lucas Stach
>
> Add binding for the i.MX8MP HDMI parallel video interface block.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Conor Dooley
You missed your own
On Fri, Dec 22, 2023 at 2:32 PM Manuel Traut wrote:
>
> From: Segfault
>
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Segfault
Please use a real name instead...
> +MODULE_AUTHOR("Alexander Warnecke ");
like here.
On Fri, Dec 15, 2023 at 4:01 PM Adam Ford wrote:
> Thanks for the list. I was able to successfully build the stable 6.6
> branch with those patches applied and I have the HDMI working.
> Unfortunately, I get build errors on the linux-next, so it's going to
> take me a little time to sort through
Hi Adam,
On Fri, Dec 15, 2023 at 1:40 PM Adam Ford wrote:
> I started looking into this today, but there appears to be some
> dependencies missing because the PVI is just one small portion of
> this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi
> transmitter itself.
>
> It looks
Hi Adam,
On Sun, Dec 10, 2023 at 2:35 PM Adam Ford wrote:
> Lucas,
>
> It's been a few months since there has been any action. If you want,
> I can help apply the suggestions that Laurent has and re-submit with
> both of our names if you want. It would be nice to get this
> integrated.
It wou
Hi Lucas,
On Tue, Dec 12, 2023 at 3:19 PM Lucas Stach wrote:
> I don't really like this series. While we don't make any strong
> guarantees in this way, it breaks booting older kernels with a new DT.
I thought we needed only to guarantee that old DTs still run with
newer kernels, not the other
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
i.MX8MQ does not have an LCDIF power domain, so pass only
"fsl,imx8mq-lcdif" as compatible string to fix the following
dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
i.MX8MQ does not have an LCDIF power domain, so allow passing only
"fsl,imx8mq-lcdif" as compatible string to fix the following
dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
However, i.MX8MQ does not have an LCDIF power domain.
imx8mq.dtsi has the following compatible string:
compatible = "fsl,imx8mq-lcdif", "fsl,imx6sx-lcdif";
which causes the following dt-schema warn
Hi Richard,
On Thu, Dec 7, 2023 at 10:43 AM Rafael J. Wysocki wrote:
> > Otherwise, the mmc driver will be defer probed after the init
> > executed, as you can imagine, the init will complain it can not find
> > the dev node specified by the 'root=/dev/xxx' in the kernel. command
> > line.
Have
From: Fabio Estevam
i.MX23 has two LCDIF interrupts instead of a single one like other
i.MX devices.
Take this into account for properly describing the i.MX23 LCDIF
interrupts.
This fixes the following dt-schema warning:
imx23-olinuxino.dtb: lcdif@8003: interrupts: [[46], [45]] is too
From: Fabio Estevam
When using audio from ADV7533 or ADV7535 and describing the audio
card via simple-audio-card, the '#sound-dai-cells' needs to be passed.
Document the '#sound-dai-cells' property to fix the following
dt-schema warning:
imx8mn-beacon-kit.dtb: hdmi@3d: &#x
From: Fabio Estevam
When using audio from ADV7533 or ADV7535 and describing the audio
card via simple-audio-card, the '#sound-dai-cells' needs to be passed.
Document the '#sound-dai-cells' property to fix the following
dt-schema warning:
imx8mn-beacon-kit.dtb: hdmi@3d: &#x
From: Fabio Estevam
i.MX23 has two LCDIF interrupts instead of a single one like other
i.MX devices.
Take this into account for properly describing the i.MX23 LCDIF
interrupts.
This fixes the following dt-schema warning:
imx23-olinuxino.dtb: lcdif@8003: interrupts: [[46], [45]] is too
From: Fabio Estevam
i.MX23 has two i.MX23 interrupts instead of a single one like other
i.MX devices.
Take this into account for properly describing the i.MX23 LCDIF
interrupts.
This fixes the following dt-schema warning:
imx23-olinuxino.dtb: lcdif@8003: interrupts: [[46], [45]] is too
)
> Tested-by: Frieder Schrempf (v2)
> Reviewed-by: Laurent Pinchart (v3)
Tested-by: Fabio Estevam
Could someone apply this series, please?
Hi Quentin,
On Fri, Nov 17, 2023 at 3:31 PM Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> This scary message may happen if the panel or bridge is not probed
> before the LVDS controller is, resulting in some head scratching because
> the LVDS panel is actually working, since a later try wil
Hi Emil,
On Thu, Oct 26, 2023 at 11:47 AM Emil Abildgaard Svendsen
wrote:
>
> Currently reading EDID only works because usually only two EDID blocks
> of 128 bytes is used. Where an EDID segment holds 256 bytes or two EDID
> blocks. And the first EDID segment read works fine but E-EDID specifies
From: Fabio Estevam
fsl,imx6-hdmi.yaml makes a reference to synopsys,dw-hdmi.yaml.
The 'interrupts'and 'reg' properties are described in synopsys,dw-hdmi.yaml,
so use 'unevaluatedProperties: false' so that these two properties can
be accepted.
This fixes the fo
On Sun, Sep 24, 2023 at 11:36 AM liuhaoran wrote:
>
> This patch adds error-handling for the of_match_node()
> inside the dw_hdmi_imx_probe().
>
> Signed-off-by: liuhaoran
> ---
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/
Hi Michael,
On Mon, Aug 28, 2023 at 12:59 PM Michael Tretter
wrote:
>
> The porches must be rounded up to make the samsung-dsim work.
The commit log could be improved here.
The way it is written gives the impression that samsung-dsim does not
work currently.
tested with[1] on RZ/G2L SMARC EVK which embeds
> ADV7535.
I have successfully tested this series on a imx8mm-evk, which has an ADV7535:
Tested-by: Fabio Estevam
Hi Tim,
On Thu, Aug 17, 2023 at 5:53 PM Tim Harvey wrote:
> Frieder,
>
> Sorry for the delay. Yes this resolves the regression I ran into. I
> tested it on top of v6.5-rc6 on a gw72xx-0x with a DFROBOT DRF0678 7in
> 800x480 (Raspberry Pi) display which has the Toshiba TC358762
> compatible DSI t
Hi Rob,
Any comments, please?
On Mon, Jul 24, 2023 at 5:28 PM Fabio Estevam wrote:
>
> Hi Rob,
>
> A gentle ping.
>
> On Thu, Jun 22, 2023 at 3:37 PM Dmitry Baryshkov
> wrote:
> >
> > On 21/06/2023 02:23, Fabio Estevam wrote:
> > > From: Fabio Est
Hi Rob,
A gentle ping.
On Thu, Jun 22, 2023 at 3:37 PM Dmitry Baryshkov
wrote:
>
> On 21/06/2023 02:23, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > The adreno_is_a20x() and adreno_is_a225() functions rely on the
> > GPU revision, but such i
On Fri, Jul 21, 2023 at 8:28 AM Marek Szyprowski
wrote:
>
> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
> doesn't report empty level of packer header FIFO. In case of those SoCs,
> use the old way of waiting for empty command tranfsfer FIFO, removed
> recently by commit 1
On Wed, May 17, 2023 at 4:08 AM Alexandru Ardelean wrote:
>
> From: Bogdan Togorean
>
> For ADV7533 and ADV7535 low refresh rate is selected using
> bits [3:2] of 0x4a main register.
> So depending on ADV model write 0xfb or 0x4a register.
>
> Signed-off-by: Bogdan Togorean
> Signed-off-by: Alex
From: Fabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the
GPU revision, but such information is retrieved inside adreno_gpu_init(),
which is called afterwards.
Fix this problem by caling adreno_gpu_init() earlier, so that
the GPU information revision is available when
On 20/06/2023 14:40, Dmitry Baryshkov wrote:
This looks like a boilerplate being added to all aYxx drivers (and
then these fields are also set in adreno_gpu_init()). Can we remove
duplication somehow?
Sorry, I missed this comment prior to sending v2.
Maybe a simpler fix for a2xx_gpu would be:
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions:
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") exposes the need of setting the GPU revision fields
prior to using the adreno_is_xxx() functions.
Pass the GPU revision information to avoid run-time warning.
Signed-off-by: Fab
From: Fabio Estevam
Since commit cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified
before being set") the following run-time warning is observed:
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/msm/adreno/adreno_gpu.h:171
a2xx_gpu_init+0
From: Fabio Estevam
The innolux at043tn24 display is a parallel LCD. Pass the 'connector_type'
information to avoid the following warning:
panel-simple panel: Specify missing connector_type
Signed-off-by: Fabio Estevam
Fixes: 41bcceb4de9c ("drm/panel: simple: Add support for In
From: Fabio Estevam
The innolux at043tn24 display is a parallel LCD. Pass the 'connector_type'
information to avoid the following warning:
panel-simple panel: Specify missing connector_type
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file
From: Fabio Estevam
Use port-base reference for port@1.
This fixes the following schema warning:
imx8mp-dhcom-pdk3.dtb: dsi@32e6: ports:port@1:endpoint: Unevaluated
properties are not allowed ('data-lanes' was unexpected)
>From schema:
>Documentation/devicetree/binding
On 31/05/2023 15:56, Krzysztof Kozlowski wrote:
This would have sense if you kept original intention, so
additionalProperties: false
Without it - you just break bindings to hide warning.
I am not sure I understood your suggestion.
Is this what you mean?
diff --git
a/Documentation/devicetre
From: Fabio Estevam
Use port-base reference for port@0 and port@1.
This fixes the following schema warning:
imx8mm-evk.dtb: dsi@32e1: ports:port@1:endpoint: Unevaluated properties are
not allowed ('data-lanes' was unexpected)
>From schema:
>Documentation/devicetree/
they are equal, this flag is not needed since the driver
> will use the sclk_mipi rate as a fallback.
>
> Signed-off-by: Adam Ford
> Reviewed-by: Conor Dooley
> ---
> V2: Split from driver series. Re-word updates for burst
> and pll-clock frequency.
Reviewed-by: Fabio Estevam
Hi Adam,
On Tue, May 23, 2023 at 8:49 PM Adam Ford wrote:
> Inki,
>
> I haven't heard back from you on whether or not you want the bindings
> patch to be included with me resending the series as V7 or if you're
> OK with a single, stand-alone patch.
> Will you let me know? I have the patch stan
Hi Neil,
On Sun, May 14, 2023 at 9:29 AM Krzysztof Kozlowski
wrote:
>
> On 14/05/2023 13:46, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > The Samsung DSIM IP block allows the inversion of the clock and
> > data lanes.
> >
> > Add an optio
Hi Adam,
On Thu, May 18, 2023 at 8:06 PM Adam Ford wrote:
>
> This series fixes the blanking pack size and the PMS calculation. It then
> adds support to allows the DSIM to dynamically DPHY clocks, and support
> non-burst mode while allowing the removal of the hard-coded clock values
> for the P
On Thu, May 4, 2023 at 6:12 AM Alexander Stein
wrote:
>
> Am Mittwoch, 3. Mai 2023, 18:33:07 CEST schrieb Frieder Schrempf:
> > From: Frieder Schrempf
> >
> > The datasheet describes the following initialization flow including
> > minimum delay times between each step:
> >
> > 1. DSI data lanes n
les, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v3:
- None
drivers/gpu/drm/brid
From: Fabio Estevam
The Samsung DSIM IP block allows the inversion of the clock and
data lanes.
Add an optional property called 'lane-polarities' that describes the
polarities of the MIPI DSI clock and data lanes.
This property is useful for properly describing the hardware when
les, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v2:
- None
drivers/gpu/drm/brid
From: Fabio Estevam
The Samsung DSIM IP block allows the inversion of the clock and
data lanes.
Add an optional property called 'lane-polarities' that describes the
polarities of the MIPI DSI clock and data lanes.
This property is useful for properly describing the hardware when
anes):
lane-polarities = <1 0 0 0 0>;
If the board has no inversion on the clock lane, and has the data lanes
inverted:
lane-polarities = <0 1 1 1 1>;
Should I keep the data-lanes and lane-polarities description as in this
patch?
Please advise.
Thanks,
Fabio Estevam
From: Fabio Estevam
video-interface.txt does not exist anymore, as it has been converted
to video-interfaces.yaml.
Instead of referencing video-interfaces.yaml multiple times,
pass it as a $ref to the schema.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Pass video-interfaces.yaml as
From: Fabio Estevam
video-interface.txt does not exist anymore, as it has been converted
to video-interfaces.yaml.
Update the references to the new file name.
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 8
1 file changed, 4 insertions
les, add
a check which verifies all data lanes have the same polarity.
This has been validated on an imx8mm board that actually has the MIPI DSI
clock lanes inverted.
Signed-off-by: Marek Vasut
Signed-off-by: Fabio Estevam
Reviewed-by: Jagan Teki
---
Changes since v1:
- Use 'drm: bridge: sa
From: Fabio Estevam
The Samsung DSIM IP block allows the inversion of the clock and
data lanes.
Add an optional property called 'lane-polarities' that describes the
polarities of the MIPI DSI clock and data lanes.
This property is useful for properly describing the hardware when
From: Jagan Teki
Samsung MIPI DSIM bridge can be found on Exynos and NXP's
i.MX8M Mini/Nano/Plus SoCs.
Convert exynos_dsim.txt to yaml.
Used the example node from exynos5433.dtsi instead of the one used in
the legacy exynos_dsim.txt.
Signed-off-by: Jagan Teki
Signed-off-by: Fabio Es
1 - 100 of 567 matches
Mail list logo
