Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
From: Ahmad Fatoum <a.fatoum@pengutronix.de> Date: 2021-11-01 22:36:01
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted hunk
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
Thanks,
Tommaso
From: Adam Ford <hidden> Date: 2021-11-02 04:22:36
On Mon, Nov 1, 2021 at 5:58 PM Tommaso Merciai [off-list ref] wrote:
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
quoted
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
There was already a driver created for the blk-ctrl stuff and it has a
device tree binding at 32e28000. It's tied into the power-domain
system, so if you want to enable the csi, dsi, or lcd, etc. you can
just reference the blt-ctrl power domain index, and it enables the
device's gpc power domain and takes the corresponding device out of
reset.
adam
On Mon, Nov 01, 2021 at 11:22:21PM -0500, Adam Ford wrote:
On Mon, Nov 1, 2021 at 5:58 PM Tommaso Merciai [off-list ref] wrote:
quoted
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
quoted
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
There was already a driver created for the blk-ctrl stuff and it has a
device tree binding at 32e28000. It's tied into the power-domain
system, so if you want to enable the csi, dsi, or lcd, etc. you can
just reference the blt-ctrl power domain index, and it enables the
device's gpc power domain and takes the corresponding device out of
reset.
Hi Adam,
You mean using the gpcv2.c driver?
drivers/soc/imx/gpcv2.c
With the following node, to put out of reset eLCDIF and mipi_dsi:
gpc: gpc@303a0000 {
compatible = "fsl,imx8mm-gpc";
reg = <0x303a0000 0x10000>;
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <3>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
pgc_mipi: power-domain@0 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_MIPI>;
};
pgc_disp: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_DISP>;
};
};
};
Let me know.
Thanks,
Tommaso
From: Adam Ford <hidden> Date: 2021-11-02 12:23:24
The upcoming 5.16 kernel will have a new blk-ctrl driver which will
work in conjunction with the GPC. You can see it in linux-next [1],
and I would expect it to be present in 5.16-rc1 once the merge is
done.
In [1], Look for :
disp_blk_ctrl: blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
It creates a bunch of virtual power domains which are effectively the
resets for the VPU, CSI, DSI, and LCDIF [2].
Basically, to pull the respective device out of reset, you'd reference
them using power-domains. I have an RFC patch for the CSI located [3]
which should bring the GPC power domain up, then take the CSI bridge
and MIPI_CSI out of reset using the blk-ctrl. A few of us are still
investigating the CSI bridge and mipi_csi drivers to determine what's
going wrong, but inside that patch, you'll see that we reference
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
are part of the new blk-ctrl driver @32e2800. Other peripherals like
LCD, DSI, and the VPU's should be able to reference their respective
power domains to activate the corresponding resets after enabling the
proper GPC power domain.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=next-20211102
[2] - https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/dt-bindings/power/imx8mm-power.h?h=next-20211102
[3] - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20211023203457.1217821-2-aford173@gmail.com/
On Tue, Nov 2, 2021 at 6:59 AM Tommaso Merciai [off-list ref] wrote:
On Mon, Nov 01, 2021 at 11:22:21PM -0500, Adam Ford wrote:
quoted
On Mon, Nov 1, 2021 at 5:58 PM Tommaso Merciai [off-list ref] wrote:
quoted
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
quoted
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
There was already a driver created for the blk-ctrl stuff and it has a
device tree binding at 32e28000. It's tied into the power-domain
system, so if you want to enable the csi, dsi, or lcd, etc. you can
just reference the blt-ctrl power domain index, and it enables the
device's gpc power domain and takes the corresponding device out of
reset.
Hi Adam,
You mean using the gpcv2.c driver?
drivers/soc/imx/gpcv2.c
With the following node, to put out of reset eLCDIF and mipi_dsi:
gpc: gpc@303a0000 {
compatible = "fsl,imx8mm-gpc";
reg = <0x303a0000 0x10000>;
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <3>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
pgc_mipi: power-domain@0 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_MIPI>;
};
pgc_disp: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_DISP>;
};
};
};
Let me know.
Thanks,
Tommaso
On Tue, Nov 02, 2021 at 07:23:06AM -0500, Adam Ford wrote:
The upcoming 5.16 kernel will have a new blk-ctrl driver which will
work in conjunction with the GPC. You can see it in linux-next [1],
and I would expect it to be present in 5.16-rc1 once the merge is
done.
In [1], Look for :
disp_blk_ctrl: blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
It creates a bunch of virtual power domains which are effectively the
resets for the VPU, CSI, DSI, and LCDIF [2].
Basically, to pull the respective device out of reset, you'd reference
them using power-domains. I have an RFC patch for the CSI located [3]
which should bring the GPC power domain up, then take the CSI bridge
and MIPI_CSI out of reset using the blk-ctrl. A few of us are still
investigating the CSI bridge and mipi_csi drivers to determine what's
going wrong, but inside that patch, you'll see that we reference
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
are part of the new blk-ctrl driver @32e2800. Other peripherals like
LCD, DSI, and the VPU's should be able to reference their respective
power domains to activate the corresponding resets after enabling the
proper GPC power domain.
Hi Adam,
Then is all done right. Using this this new driver/dts node eLCDIF/mipi_dsi
module are out of reset. Thanks for the tips. I'm trying to get eLCDIF/mipi_dsi
work on mainline. I try to get work
- eLCDIF using: mxsfb_drv.c
- mipi_dsi using: nwl-dsi.c
What do you think about? You think that can be a good way ( taking
imx8mq as reference )?
Let me know.
Thanks,
Tommaso
On Mon, Nov 01, 2021 at 11:22:21PM -0500, Adam Ford wrote:
quoted
On Mon, Nov 1, 2021 at 5:58 PM Tommaso Merciai [off-list ref] wrote:
quoted
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
quoted
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
There was already a driver created for the blk-ctrl stuff and it has a
device tree binding at 32e28000. It's tied into the power-domain
system, so if you want to enable the csi, dsi, or lcd, etc. you can
just reference the blt-ctrl power domain index, and it enables the
device's gpc power domain and takes the corresponding device out of
reset.
Hi Adam,
You mean using the gpcv2.c driver?
drivers/soc/imx/gpcv2.c
With the following node, to put out of reset eLCDIF and mipi_dsi:
gpc: gpc@303a0000 {
compatible = "fsl,imx8mm-gpc";
reg = <0x303a0000 0x10000>;
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <3>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
pgc_mipi: power-domain@0 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_MIPI>;
};
pgc_disp: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_DISP>;
};
};
};
Let me know.
Thanks,
Tommaso
From: Adam Ford <hidden> Date: 2021-11-02 16:30:20
On Tue, Nov 2, 2021 at 10:47 AM Tommaso Merciai [off-list ref] wrote:
On Tue, Nov 02, 2021 at 07:23:06AM -0500, Adam Ford wrote:
quoted
The upcoming 5.16 kernel will have a new blk-ctrl driver which will
work in conjunction with the GPC. You can see it in linux-next [1],
and I would expect it to be present in 5.16-rc1 once the merge is
done.
In [1], Look for :
disp_blk_ctrl: blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
It creates a bunch of virtual power domains which are effectively the
resets for the VPU, CSI, DSI, and LCDIF [2].
Basically, to pull the respective device out of reset, you'd reference
them using power-domains. I have an RFC patch for the CSI located [3]
which should bring the GPC power domain up, then take the CSI bridge
and MIPI_CSI out of reset using the blk-ctrl. A few of us are still
investigating the CSI bridge and mipi_csi drivers to determine what's
going wrong, but inside that patch, you'll see that we reference
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
are part of the new blk-ctrl driver @32e2800. Other peripherals like
LCD, DSI, and the VPU's should be able to reference their respective
power domains to activate the corresponding resets after enabling the
proper GPC power domain.
Hi Adam,
Then is all done right. Using this this new driver/dts node eLCDIF/mipi_dsi
module are out of reset. Thanks for the tips. I'm trying to get eLCDIF/mipi_dsi
work on mainline. I try to get work
- eLCDIF using: mxsfb_drv.c
- mipi_dsi using: nwl-dsi.c
What do you think about? You think that can be a good way ( taking
imx8mq as reference )?
The DSI controller for the 8MM and 8MN is not the same as the DSI
controller on the 8MQ, but the LCDIF controller should be compatible.
There have been several attempts to support the 8MM DSI, but none of
them have been accepted for various reasons.
The latest was found here [1], but others [2] and [3] , when used
together, do something similar.
If memory serves, the main issue has to do with the fact that the DSIM
controller in the 8MM and 8MN is also present in one of the Samsung
processors, and the goal is to rework those drivers so we'll have one
driver that supports both Samsung progressors and NXP instead of
having two duplicate drivers doing the same thing. When whatever
driver is chosen is ready, it'll be likely that the LCDIF will use
power-domains = <&disp_blk_ctrl MX8MM_DISPBLK_PD_LCDIF> and the DSI
node will use power-domains = <&disp_blk_ctrl
IMX8MM_DISPBLK_PD_MIPI_DSI> to pull their respective devices out of
reset and enable the gpc.
[1] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=510489&archive=both&state=*
[2] - https://patchwork.kernel.org/project/dri-devel/list/?series=347439&archive=both&state=*
[3] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=359775&archive=both&state=*
On Mon, Nov 01, 2021 at 11:22:21PM -0500, Adam Ford wrote:
quoted
On Mon, Nov 1, 2021 at 5:58 PM Tommaso Merciai [off-list ref] wrote:
quoted
On Mon, Nov 01, 2021 at 11:35:49PM +0100, Ahmad Fatoum wrote:
quoted
Hello Tommaso,
On 01.11.21 23:28, Tommaso Merciai wrote:
quoted
Add system controller node for registers of module Display Block Control
(DISPLAY_BLK_CTRL, base address: 0x32e28000).
The DISPLAY_BLK_CTRL module contains general purpose registers (GPRs),
which control varied features of the associated peripherals.
Reference: IMX8MMRM Rev. 3, 11/2020, p 3897
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++++
1 file changed, 5 insertions(+)
Please read vendor patches before submitting them. The space
is out-of-place in the compatible and the compatible is wrong:
This doesn't look like a i.MX8MM pin controller.
Cheers,
Ahmad
Hi Ahmad,
Thanks for your review. Do you think this is correct?
compatible = "fsl,imx8mm-dispmix-gpr", "syscon";
Let me know.
There was already a driver created for the blk-ctrl stuff and it has a
device tree binding at 32e28000. It's tied into the power-domain
system, so if you want to enable the csi, dsi, or lcd, etc. you can
just reference the blt-ctrl power domain index, and it enables the
device's gpc power domain and takes the corresponding device out of
reset.
Hi Adam,
You mean using the gpcv2.c driver?
drivers/soc/imx/gpcv2.c
With the following node, to put out of reset eLCDIF and mipi_dsi:
gpc: gpc@303a0000 {
compatible = "fsl,imx8mm-gpc";
reg = <0x303a0000 0x10000>;
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <3>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
pgc_mipi: power-domain@0 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_MIPI>;
};
pgc_disp: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8M_POWER_DOMAIN_DISP>;
};
};
};
Let me know.
Thanks,
Tommaso
From: Tim Harvey <tharvey@gateworks.com> Date: 2021-11-02 18:19:14
On Tue, Nov 2, 2021 at 9:08 AM Adam Ford [off-list ref] wrote:
On Tue, Nov 2, 2021 at 10:47 AM Tommaso Merciai [off-list ref] wrote:
quoted
On Tue, Nov 02, 2021 at 07:23:06AM -0500, Adam Ford wrote:
quoted
The upcoming 5.16 kernel will have a new blk-ctrl driver which will
work in conjunction with the GPC. You can see it in linux-next [1],
and I would expect it to be present in 5.16-rc1 once the merge is
done.
In [1], Look for :
disp_blk_ctrl: blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
It creates a bunch of virtual power domains which are effectively the
resets for the VPU, CSI, DSI, and LCDIF [2].
Basically, to pull the respective device out of reset, you'd reference
them using power-domains. I have an RFC patch for the CSI located [3]
which should bring the GPC power domain up, then take the CSI bridge
and MIPI_CSI out of reset using the blk-ctrl. A few of us are still
investigating the CSI bridge and mipi_csi drivers to determine what's
going wrong, but inside that patch, you'll see that we reference
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
are part of the new blk-ctrl driver @32e2800. Other peripherals like
LCD, DSI, and the VPU's should be able to reference their respective
power domains to activate the corresponding resets after enabling the
proper GPC power domain.
Hi Adam,
Then is all done right. Using this this new driver/dts node eLCDIF/mipi_dsi
module are out of reset. Thanks for the tips. I'm trying to get eLCDIF/mipi_dsi
work on mainline. I try to get work
- eLCDIF using: mxsfb_drv.c
- mipi_dsi using: nwl-dsi.c
What do you think about? You think that can be a good way ( taking
imx8mq as reference )?
The DSI controller for the 8MM and 8MN is not the same as the DSI
controller on the 8MQ, but the LCDIF controller should be compatible.
There have been several attempts to support the 8MM DSI, but none of
them have been accepted for various reasons.
The latest was found here [1], but others [2] and [3] , when used
together, do something similar.
If memory serves, the main issue has to do with the fact that the DSIM
controller in the 8MM and 8MN is also present in one of the Samsung
processors, and the goal is to rework those drivers so we'll have one
driver that supports both Samsung progressors and NXP instead of
having two duplicate drivers doing the same thing. When whatever
driver is chosen is ready, it'll be likely that the LCDIF will use
power-domains = <&disp_blk_ctrl MX8MM_DISPBLK_PD_LCDIF> and the DSI
node will use power-domains = <&disp_blk_ctrl
IMX8MM_DISPBLK_PD_MIPI_DSI> to pull their respective devices out of
reset and enable the gpc.
[1] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=510489&archive=both&state=*
[2] - https://patchwork.kernel.org/project/dri-devel/list/?series=347439&archive=both&state=*
[3] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=359775&archive=both&state=*
Adam,
Thanks for the good summary... I was just putting this info together
as well. I'm also interested to see if anyone has made progress on
IMX8MM MIPI DSI display. Now that blk-ctl and most of the dt bindings
have been merged for 5.16 I think we are just down to the drm/exynos
driver issue.
Added Frieder, Jagan, and Michael to the thread.
Best Regards,
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Nov 02, 2021 at 11:18:53AM -0700, Tim Harvey wrote:
On Tue, Nov 2, 2021 at 9:08 AM Adam Ford [off-list ref] wrote:
quoted
On Tue, Nov 2, 2021 at 10:47 AM Tommaso Merciai [off-list ref] wrote:
quoted
On Tue, Nov 02, 2021 at 07:23:06AM -0500, Adam Ford wrote:
quoted
The upcoming 5.16 kernel will have a new blk-ctrl driver which will
work in conjunction with the GPC. You can see it in linux-next [1],
and I would expect it to be present in 5.16-rc1 once the merge is
done.
In [1], Look for :
disp_blk_ctrl: blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
It creates a bunch of virtual power domains which are effectively the
resets for the VPU, CSI, DSI, and LCDIF [2].
Basically, to pull the respective device out of reset, you'd reference
them using power-domains. I have an RFC patch for the CSI located [3]
which should bring the GPC power domain up, then take the CSI bridge
and MIPI_CSI out of reset using the blk-ctrl. A few of us are still
investigating the CSI bridge and mipi_csi drivers to determine what's
going wrong, but inside that patch, you'll see that we reference
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
"power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
are part of the new blk-ctrl driver @32e2800. Other peripherals like
LCD, DSI, and the VPU's should be able to reference their respective
power domains to activate the corresponding resets after enabling the
proper GPC power domain.
Hi Adam,
Then is all done right. Using this this new driver/dts node eLCDIF/mipi_dsi
module are out of reset. Thanks for the tips. I'm trying to get eLCDIF/mipi_dsi
work on mainline. I try to get work
- eLCDIF using: mxsfb_drv.c
- mipi_dsi using: nwl-dsi.c
What do you think about? You think that can be a good way ( taking
imx8mq as reference )?
The DSI controller for the 8MM and 8MN is not the same as the DSI
controller on the 8MQ, but the LCDIF controller should be compatible.
There have been several attempts to support the 8MM DSI, but none of
them have been accepted for various reasons.
The latest was found here [1], but others [2] and [3] , when used
together, do something similar.
If memory serves, the main issue has to do with the fact that the DSIM
controller in the 8MM and 8MN is also present in one of the Samsung
processors, and the goal is to rework those drivers so we'll have one
driver that supports both Samsung progressors and NXP instead of
having two duplicate drivers doing the same thing. When whatever
driver is chosen is ready, it'll be likely that the LCDIF will use
power-domains = <&disp_blk_ctrl MX8MM_DISPBLK_PD_LCDIF> and the DSI
node will use power-domains = <&disp_blk_ctrl
IMX8MM_DISPBLK_PD_MIPI_DSI> to pull their respective devices out of
reset and enable the gpc.
[1] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=510489&archive=both&state=*
[2] - https://patchwork.kernel.org/project/dri-devel/list/?series=347439&archive=both&state=*
[3] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=359775&archive=both&state=*
Adam,
Thanks for the good summary... I was just putting this info together
as well. I'm also interested to see if anyone has made progress on
IMX8MM MIPI DSI display. Now that blk-ctl and most of the dt bindings
have been merged for 5.16 I think we are just down to the drm/exynos
driver issue.
Added Frieder, Jagan, and Michael to the thread.
Best Regards,
Tim
Hi Adam,
Thanks again for your explanation. Then, now the main goal is refactoring
exynos dsim driver as bridge driver in order to support both imx8mm and exynos
SOC. I'll investigate on it.
Regards,
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel