mbox series

[RFC,00/17] drm: bridge: Samsung MIPI DSIM bridge

Message ID 20210704090230.26489-1-jagan@amarulasolutions.com (mailing list archive)
Headers show
Series drm: bridge: Samsung MIPI DSIM bridge | expand

Message

Jagan Teki July 4, 2021, 9:02 a.m. UTC
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8MM DSI devices.

Right now bridge offers two sets of implementations.

A. With component_ops and exynos specific code exclusively for
   exynos dsi drivers and it's legacy bindings.

B. Without componenet_ops for newly implemented bridges and its
   users like i.MX8MM.

The future plan is to fix the implementation A) by dropping
component_ops and fixing exynos specific code in order to make
the bridge more mature to use and the same is mentioned in
drivers TODO.

Patch 0001 - 0006: Bridge conversion
Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions

Tested in Engicam i.Core MX8M Mini SoM.

Anyone interest, please have a look on this repo
https://github.com/openedev/linux/tree/070421-imx8mm-dsim

Would appreciate anyone from the exynos team to test it on
the exynos platform?

Any inputs?
Jagan.

Jagan Teki (17):
  drm/exynos: dsi: Convert to bridge driver
  drm/exynos: dsi: Handle drm_device for bridge
  drm/exynos: dsi: Use the drm_panel_bridge API
  drm/exynos: dsi: Create bridge connector for encoder
  drm/exynos: dsi: Get the mode from bridge
  drm/exynos: dsi: Handle exynos specifics via driver_data
  drm: bridge: Move exynos_drm_dsi into bridges
  dt-bindings: display: bridge: Add Samsung MIPI DSIM bridge
  drm: bridge: samsung-dsim: Add module init, exit
  drm: bridge: samsung-dsim: Update the of_node for port(s)
  drm: bridge: samsung-dsim: Find the possible DSI devices
  dt-bindings: display: bridge: samsung,mipi-dsim: Add i.MX8MM support
  drm: bridge: samsung-dsim: Add i.MX8MM support
  drm: bridge: samsung-dsim: Add input_bus_flags
  drm: bridge: samsung-dsim: Move DSI init in bridge enable
  drm: bridge: samsung-dsim: Fix PLL_P offset
  drm: bridge: samsung-dsim: Add bridge mode_fixup

 .../display/bridge/samsung,mipi-dsim.yaml     | 360 +++++++++
 .../bindings/display/exynos/exynos_dsim.txt   |  90 ---
 MAINTAINERS                                   |  12 +
 drivers/gpu/drm/bridge/Kconfig                |  15 +
 drivers/gpu/drm/bridge/Makefile               |   1 +
 .../samsung-dsim.c}                           | 758 ++++++++++--------
 drivers/gpu/drm/exynos/Kconfig                |   9 -
 drivers/gpu/drm/exynos/Makefile               |   1 -
 8 files changed, 795 insertions(+), 451 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
 rename drivers/gpu/drm/{exynos/exynos_drm_dsi.c => bridge/samsung-dsim.c} (69%)

Comments

Jagan Teki July 25, 2021, 5:13 p.m. UTC | #1
Hi Sam,

On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Jagan,
>
> On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> >
> > Right now bridge offers two sets of implementations.
> >
> > A. With component_ops and exynos specific code exclusively for
> >    exynos dsi drivers and it's legacy bindings.
> >
> > B. Without componenet_ops for newly implemented bridges and its
> >    users like i.MX8MM.
> >
> > The future plan is to fix the implementation A) by dropping
> > component_ops and fixing exynos specific code in order to make
> > the bridge more mature to use and the same is mentioned in
> > drivers TODO.
> >
> > Patch 0001 - 0006: Bridge conversion
> > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> >
> > Tested in Engicam i.Core MX8M Mini SoM.
> >
> > Anyone interest, please have a look on this repo
> > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> >
> > Would appreciate anyone from the exynos team to test it on
> > the exynos platform?
> >
> > Any inputs?
>
> I really like where you are headign with this!
> No testing - sorry. But I will try to provide a bit of feedback on the
> individual patches.
>
> I hope you find a way to move forward with this.

Thanks for the response.

We have found some issues with Bridge conversion on existing exynos
drivers. The component based DSI drivers(like exynos) are difficult to
attach if it involves kms hotplug. kms hotplug would require drm
pointer and that pointer would only available after the bind call
finishes. But the bridge attach in bind call will defer till it find
the attached bridge.

Right now I'm trying to find the proper way to attach the bridges for
component based DSI drivers which involves kms hot-plug.

If you have any ideas on this, please let me know.

Thanks,
Jagan.
Tim Harvey Oct. 5, 2021, 9:43 p.m. UTC | #2
On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi Sam,
>
> On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Jagan,
> >
> > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > This series supports common bridge support for Samsung MIPI DSIM
> > > which is used in Exynos and i.MX8MM SoC's.
> > >
> > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > >
> > > Right now bridge offers two sets of implementations.
> > >
> > > A. With component_ops and exynos specific code exclusively for
> > >    exynos dsi drivers and it's legacy bindings.
> > >
> > > B. Without componenet_ops for newly implemented bridges and its
> > >    users like i.MX8MM.
> > >
> > > The future plan is to fix the implementation A) by dropping
> > > component_ops and fixing exynos specific code in order to make
> > > the bridge more mature to use and the same is mentioned in
> > > drivers TODO.
> > >
> > > Patch 0001 - 0006: Bridge conversion
> > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > >
> > > Tested in Engicam i.Core MX8M Mini SoM.
> > >
> > > Anyone interest, please have a look on this repo
> > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > >
> > > Would appreciate anyone from the exynos team to test it on
> > > the exynos platform?
> > >
> > > Any inputs?
> >
> > I really like where you are headign with this!
> > No testing - sorry. But I will try to provide a bit of feedback on the
> > individual patches.
> >
> > I hope you find a way to move forward with this.
>
> Thanks for the response.
>
> We have found some issues with Bridge conversion on existing exynos
> drivers. The component based DSI drivers(like exynos) are difficult to
> attach if it involves kms hotplug. kms hotplug would require drm
> pointer and that pointer would only available after the bind call
> finishes. But the bridge attach in bind call will defer till it find
> the attached bridge.
>
> Right now I'm trying to find the proper way to attach the bridges for
> component based DSI drivers which involves kms hot-plug.
>
> If you have any ideas on this, please let me know.
>

Jagan,

How is your progress on this series? Looking at your repo it looks
like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
branch but you've got a lot of things there that are likely not
related to this series?

Best regards,

Tim
Michael Nazzareno Trimarchi Dec. 9, 2021, 8:36 a.m. UTC | #3
Hi Tim

On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > Hi Sam,
> >
> > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > which is used in Exynos and i.MX8MM SoC's.
> > > >
> > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > >
> > > > Right now bridge offers two sets of implementations.
> > > >
> > > > A. With component_ops and exynos specific code exclusively for
> > > >    exynos dsi drivers and it's legacy bindings.
> > > >
> > > > B. Without componenet_ops for newly implemented bridges and its
> > > >    users like i.MX8MM.
> > > >
> > > > The future plan is to fix the implementation A) by dropping
> > > > component_ops and fixing exynos specific code in order to make
> > > > the bridge more mature to use and the same is mentioned in
> > > > drivers TODO.
> > > >
> > > > Patch 0001 - 0006: Bridge conversion
> > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > >
> > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > >
> > > > Anyone interest, please have a look on this repo
> > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > >
> > > > Would appreciate anyone from the exynos team to test it on
> > > > the exynos platform?
> > > >
> > > > Any inputs?
> > >
> > > I really like where you are headign with this!
> > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > individual patches.
> > >
> > > I hope you find a way to move forward with this.
> >
> > Thanks for the response.
> >
> > We have found some issues with Bridge conversion on existing exynos
> > drivers. The component based DSI drivers(like exynos) are difficult to
> > attach if it involves kms hotplug. kms hotplug would require drm
> > pointer and that pointer would only available after the bind call
> > finishes. But the bridge attach in bind call will defer till it find
> > the attached bridge.
> >
> > Right now I'm trying to find the proper way to attach the bridges for
> > component based DSI drivers which involves kms hot-plug.
> >
> > If you have any ideas on this, please let me know.
> >
>
> Jagan,
>
> How is your progress on this series? Looking at your repo it looks
> like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> branch but you've got a lot of things there that are likely not
> related to this series?

I have a bit of work on those patches and tested on imx8mn. Basically:

- add the dsi timing calculation
- change few difference with samsung bridge
- fix crashes of my dsi panels
- compare with NXP driver the final results

I found that I have one problem that gives me some instability. In the
NXP original driver the panel needs to be
enabled in bridge_enable before out the standby. If I understand
correctly, our standby should be done after.
I would like to have some feedback and help and testing on other
boards/devices and some suggestions on how to handle
some of the differences. Another big problem is etnavi that is not stable

Michael

>
> Best regards,
>
> Tim
>
>
Tim Harvey Dec. 9, 2021, 4:40 p.m. UTC | #4
On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi Tim
>
> On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > Hi Sam,
> > >
> > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Hi Jagan,
> > > >
> > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > >
> > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > >
> > > > > Right now bridge offers two sets of implementations.
> > > > >
> > > > > A. With component_ops and exynos specific code exclusively for
> > > > >    exynos dsi drivers and it's legacy bindings.
> > > > >
> > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > >    users like i.MX8MM.
> > > > >
> > > > > The future plan is to fix the implementation A) by dropping
> > > > > component_ops and fixing exynos specific code in order to make
> > > > > the bridge more mature to use and the same is mentioned in
> > > > > drivers TODO.
> > > > >
> > > > > Patch 0001 - 0006: Bridge conversion
> > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > >
> > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > >
> > > > > Anyone interest, please have a look on this repo
> > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > >
> > > > > Would appreciate anyone from the exynos team to test it on
> > > > > the exynos platform?
> > > > >
> > > > > Any inputs?
> > > >
> > > > I really like where you are headign with this!
> > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > individual patches.
> > > >
> > > > I hope you find a way to move forward with this.
> > >
> > > Thanks for the response.
> > >
> > > We have found some issues with Bridge conversion on existing exynos
> > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > attach if it involves kms hotplug. kms hotplug would require drm
> > > pointer and that pointer would only available after the bind call
> > > finishes. But the bridge attach in bind call will defer till it find
> > > the attached bridge.
> > >
> > > Right now I'm trying to find the proper way to attach the bridges for
> > > component based DSI drivers which involves kms hot-plug.
> > >
> > > If you have any ideas on this, please let me know.
> > >
> >
> > Jagan,
> >
> > How is your progress on this series? Looking at your repo it looks
> > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > branch but you've got a lot of things there that are likely not
> > related to this series?
>
> I have a bit of work on those patches and tested on imx8mn. Basically:
>
> - add the dsi timing calculation
> - change few difference with samsung bridge
> - fix crashes of my dsi panels
> - compare with NXP driver the final results
>
> I found that I have one problem that gives me some instability. In the
> NXP original driver the panel needs to be
> enabled in bridge_enable before out the standby. If I understand
> correctly, our standby should be done after.
> I would like to have some feedback and help and testing on other
> boards/devices and some suggestions on how to handle
> some of the differences. Another big problem is etnavi that is not stable
>

Michael,

Where can I find your patches?

What do you mean by etnaviv not being stable?

I did some limited testing with etnaviv on imx8mm with 5.15 + dsi
patches on an Ubuntu focal root filesystem by:
apt update
apt install gnome-session gnome-terminal
^^^ 2D hardware acceleration appears to be working (dragging opaque
windows around)
apt install mesa-utils glmark2
glxgears
^^^ ~160fps on IMX8MM
glmark2
^^^ score of 39 on IMX8MM

I haven't seen any updates from Jagan since Nov 24
(https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
sure if he's been able to work through drm/exynos issues that have
been blocking his progress.

Best regards,

Tim
Michael Nazzareno Trimarchi Dec. 9, 2021, 5:09 p.m. UTC | #5
Hi Tim

On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
> >
> > Hi Tim
> >
> > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > >
> > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > Hi Sam,
> > > >
> > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > >
> > > > > Hi Jagan,
> > > > >
> > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > > >
> > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > > >
> > > > > > Right now bridge offers two sets of implementations.
> > > > > >
> > > > > > A. With component_ops and exynos specific code exclusively for
> > > > > >    exynos dsi drivers and it's legacy bindings.
> > > > > >
> > > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > > >    users like i.MX8MM.
> > > > > >
> > > > > > The future plan is to fix the implementation A) by dropping
> > > > > > component_ops and fixing exynos specific code in order to make
> > > > > > the bridge more mature to use and the same is mentioned in
> > > > > > drivers TODO.
> > > > > >
> > > > > > Patch 0001 - 0006: Bridge conversion
> > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > > >
> > > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > > >
> > > > > > Anyone interest, please have a look on this repo
> > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > > >
> > > > > > Would appreciate anyone from the exynos team to test it on
> > > > > > the exynos platform?
> > > > > >
> > > > > > Any inputs?
> > > > >
> > > > > I really like where you are headign with this!
> > > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > > individual patches.
> > > > >
> > > > > I hope you find a way to move forward with this.
> > > >
> > > > Thanks for the response.
> > > >
> > > > We have found some issues with Bridge conversion on existing exynos
> > > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > > attach if it involves kms hotplug. kms hotplug would require drm
> > > > pointer and that pointer would only available after the bind call
> > > > finishes. But the bridge attach in bind call will defer till it find
> > > > the attached bridge.
> > > >
> > > > Right now I'm trying to find the proper way to attach the bridges for
> > > > component based DSI drivers which involves kms hot-plug.
> > > >
> > > > If you have any ideas on this, please let me know.
> > > >
> > >
> > > Jagan,
> > >
> > > How is your progress on this series? Looking at your repo it looks
> > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > > branch but you've got a lot of things there that are likely not
> > > related to this series?
> >
> > I have a bit of work on those patches and tested on imx8mn. Basically:
> >
> > - add the dsi timing calculation
> > - change few difference with samsung bridge
> > - fix crashes of my dsi panels
> > - compare with NXP driver the final results
> >
> > I found that I have one problem that gives me some instability. In the
> > NXP original driver the panel needs to be
> > enabled in bridge_enable before out the standby. If I understand
> > correctly, our standby should be done after.
> > I would like to have some feedback and help and testing on other
> > boards/devices and some suggestions on how to handle
> > some of the differences. Another big problem is etnavi that is not stable
> >
>
> Michael,
>
> Where can I find your patches?
>

I will push on some tree and share

> What do you mean by etnaviv not being stable?
>
> I did some limited testing with etnaviv on imx8mm with 5.15 + dsi



> patches on an Ubuntu focal root filesystem by:
> apt update
> apt install gnome-session gnome-terminal
> ^^^ 2D hardware acceleration appears to be working (dragging opaque
> windows around)
> apt install mesa-utils glmark2
> glxgears
> ^^^ ~160fps on IMX8MM
> glmark2
> ^^^ score of 39 on IMX8MM
>
> I haven't seen any updates from Jagan since Nov 24
> (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
> sure if he's been able to work through drm/exynos issues that have
> been blocking his progress.

I plan to push on github

[17:07:42.315] Sending ready to systemd
[  214.052085] etnaviv-gpu 38000000.gpu: recover hung GPU!
[  214.595998] etnaviv-gpu 38000000.gpu: recover hung GPU!

** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success
[17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list
[17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list
** Message: 17:07:44.289: New advertisement app id maynard
** Message: 17:07:44.290: New advertisement app id maynard
[17:07:45.171] (background) position view 0xaaab0261f860, x 0, y 0, on
output DSI-1
[17:07:45.171] (panel) geom.width 100, geom.height 480, geom.x 0, geom.y 0
[17:07:45.171] (panel) edge 2 position view 0xaaab02634510, x 0, y 0
[17:07:45.172] panel type 2 inited on output DSI-1
[17:07:45.172] Usable area: 380x480+100,0
[  216.932080] etnaviv-gpu 38000000.gpu: recover hung GPU!
[  217.476015] etnaviv-gpu 38000000.gpu: recover hung GPU!
[  218.020157] etnaviv-gpu 38000000.gpu: recover hung GPU!

This is my problem on imx8mn

Michael

Michael
> Best regards,
>
> Tim

--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
Tim Harvey Dec. 9, 2021, 5:57 p.m. UTC | #6
On Thu, Dec 9, 2021 at 9:09 AM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi Tim
>
> On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > >
> > > Hi Tim
> > >
> > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > >
> > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > > Hi Sam,
> > > > >
> > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > > >
> > > > > > Hi Jagan,
> > > > > >
> > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > > > >
> > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > > > >
> > > > > > > Right now bridge offers two sets of implementations.
> > > > > > >
> > > > > > > A. With component_ops and exynos specific code exclusively for
> > > > > > >    exynos dsi drivers and it's legacy bindings.
> > > > > > >
> > > > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > > > >    users like i.MX8MM.
> > > > > > >
> > > > > > > The future plan is to fix the implementation A) by dropping
> > > > > > > component_ops and fixing exynos specific code in order to make
> > > > > > > the bridge more mature to use and the same is mentioned in
> > > > > > > drivers TODO.
> > > > > > >
> > > > > > > Patch 0001 - 0006: Bridge conversion
> > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > > > >
> > > > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > > > >
> > > > > > > Anyone interest, please have a look on this repo
> > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > > > >
> > > > > > > Would appreciate anyone from the exynos team to test it on
> > > > > > > the exynos platform?
> > > > > > >
> > > > > > > Any inputs?
> > > > > >
> > > > > > I really like where you are headign with this!
> > > > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > > > individual patches.
> > > > > >
> > > > > > I hope you find a way to move forward with this.
> > > > >
> > > > > Thanks for the response.
> > > > >
> > > > > We have found some issues with Bridge conversion on existing exynos
> > > > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > > > attach if it involves kms hotplug. kms hotplug would require drm
> > > > > pointer and that pointer would only available after the bind call
> > > > > finishes. But the bridge attach in bind call will defer till it find
> > > > > the attached bridge.
> > > > >
> > > > > Right now I'm trying to find the proper way to attach the bridges for
> > > > > component based DSI drivers which involves kms hot-plug.
> > > > >
> > > > > If you have any ideas on this, please let me know.
> > > > >
> > > >
> > > > Jagan,
> > > >
> > > > How is your progress on this series? Looking at your repo it looks
> > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > > > branch but you've got a lot of things there that are likely not
> > > > related to this series?
> > >
> > > I have a bit of work on those patches and tested on imx8mn. Basically:
> > >
> > > - add the dsi timing calculation
> > > - change few difference with samsung bridge
> > > - fix crashes of my dsi panels
> > > - compare with NXP driver the final results
> > >
> > > I found that I have one problem that gives me some instability. In the
> > > NXP original driver the panel needs to be
> > > enabled in bridge_enable before out the standby. If I understand
> > > correctly, our standby should be done after.
> > > I would like to have some feedback and help and testing on other
> > > boards/devices and some suggestions on how to handle
> > > some of the differences. Another big problem is etnavi that is not stable
> > >
> >
> > Michael,
> >
> > Where can I find your patches?
> >
>
> I will push on some tree and share
>
> > What do you mean by etnaviv not being stable?
> >
> > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi
>
>
>
> > patches on an Ubuntu focal root filesystem by:
> > apt update
> > apt install gnome-session gnome-terminal
> > ^^^ 2D hardware acceleration appears to be working (dragging opaque
> > windows around)
> > apt install mesa-utils glmark2
> > glxgears
> > ^^^ ~160fps on IMX8MM
> > glmark2
> > ^^^ score of 39 on IMX8MM
> >
> > I haven't seen any updates from Jagan since Nov 24
> > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
> > sure if he's been able to work through drm/exynos issues that have
> > been blocking his progress.
>
> I plan to push on github
>
> [17:07:42.315] Sending ready to systemd
> [  214.052085] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  214.595998] etnaviv-gpu 38000000.gpu: recover hung GPU!
>
> ** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success
> [17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list
> [17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list
> ** Message: 17:07:44.289: New advertisement app id maynard
> ** Message: 17:07:44.290: New advertisement app id maynard
> [17:07:45.171] (background) position view 0xaaab0261f860, x 0, y 0, on
> output DSI-1
> [17:07:45.171] (panel) geom.width 100, geom.height 480, geom.x 0, geom.y 0
> [17:07:45.171] (panel) edge 2 position view 0xaaab02634510, x 0, y 0
> [17:07:45.172] panel type 2 inited on output DSI-1
> [17:07:45.172] Usable area: 380x480+100,0
> [  216.932080] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  217.476015] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  218.020157] etnaviv-gpu 38000000.gpu: recover hung GPU!
>
> This is my problem on imx8mn
>

Do you have an imx8mm to compare with? Unfortunately I do not have an
imx8mn with a MIPI DSI connector and can only test with imx8mm.

What software (other than kernel which you will share) do you have
installed above and how is it configured or run to show the issue?

Best regards,

Tim
Lucas Stach Dec. 9, 2021, 8:24 p.m. UTC | #7
Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
Trimarchi:
> Hi Tim
> 
> On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > 
> > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > > 
> > > Hi Tim
> > > 
> > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > > 
> > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > 
> > > > > Hi Sam,
> > > > > 
> > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > > > 
> > > > > > Hi Jagan,
> > > > > > 
> > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > > > > 
> > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > > > > 
> > > > > > > Right now bridge offers two sets of implementations.
> > > > > > > 
> > > > > > > A. With component_ops and exynos specific code exclusively for
> > > > > > >    exynos dsi drivers and it's legacy bindings.
> > > > > > > 
> > > > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > > > >    users like i.MX8MM.
> > > > > > > 
> > > > > > > The future plan is to fix the implementation A) by dropping
> > > > > > > component_ops and fixing exynos specific code in order to make
> > > > > > > the bridge more mature to use and the same is mentioned in
> > > > > > > drivers TODO.
> > > > > > > 
> > > > > > > Patch 0001 - 0006: Bridge conversion
> > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > > > > 
> > > > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > > > > 
> > > > > > > Anyone interest, please have a look on this repo
> > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > > > > 
> > > > > > > Would appreciate anyone from the exynos team to test it on
> > > > > > > the exynos platform?
> > > > > > > 
> > > > > > > Any inputs?
> > > > > > 
> > > > > > I really like where you are headign with this!
> > > > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > > > individual patches.
> > > > > > 
> > > > > > I hope you find a way to move forward with this.
> > > > > 
> > > > > Thanks for the response.
> > > > > 
> > > > > We have found some issues with Bridge conversion on existing exynos
> > > > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > > > attach if it involves kms hotplug. kms hotplug would require drm
> > > > > pointer and that pointer would only available after the bind call
> > > > > finishes. But the bridge attach in bind call will defer till it find
> > > > > the attached bridge.
> > > > > 
> > > > > Right now I'm trying to find the proper way to attach the bridges for
> > > > > component based DSI drivers which involves kms hot-plug.
> > > > > 
> > > > > If you have any ideas on this, please let me know.
> > > > > 
> > > > 
> > > > Jagan,
> > > > 
> > > > How is your progress on this series? Looking at your repo it looks
> > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > > > branch but you've got a lot of things there that are likely not
> > > > related to this series?
> > > 
> > > I have a bit of work on those patches and tested on imx8mn. Basically:
> > > 
> > > - add the dsi timing calculation
> > > - change few difference with samsung bridge
> > > - fix crashes of my dsi panels
> > > - compare with NXP driver the final results
> > > 
> > > I found that I have one problem that gives me some instability. In the
> > > NXP original driver the panel needs to be
> > > enabled in bridge_enable before out the standby. If I understand
> > > correctly, our standby should be done after.
> > > I would like to have some feedback and help and testing on other
> > > boards/devices and some suggestions on how to handle
> > > some of the differences. Another big problem is etnavi that is not stable
> > > 
> > 
> > Michael,
> > 
> > Where can I find your patches?
> > 
> 
> I will push on some tree and share
> 
> > What do you mean by etnaviv not being stable?
> > 
> > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi
> 
> 
> 
> > patches on an Ubuntu focal root filesystem by:
> > apt update
> > apt install gnome-session gnome-terminal
> > ^^^ 2D hardware acceleration appears to be working (dragging opaque
> > windows around)
> > apt install mesa-utils glmark2
> > glxgears
> > ^^^ ~160fps on IMX8MM
> > glmark2
> > ^^^ score of 39 on IMX8MM
> > 
> > I haven't seen any updates from Jagan since Nov 24
> > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
> > sure if he's been able to work through drm/exynos issues that have
> > been blocking his progress.
> 
> I plan to push on github
> 
> [17:07:42.315] Sending ready to systemd
> [  214.052085] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  214.595998] etnaviv-gpu 38000000.gpu: recover hung GPU!
> 
> ** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success
> [17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list
> [17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list
> ** Message: 17:07:44.289: New advertisement app id maynard
> ** Message: 17:07:44.290: New advertisement app id maynard
> [17:07:45.171] (background) position view 0xaaab0261f860, x 0, y 0, on
> output DSI-1
> [17:07:45.171] (panel) geom.width 100, geom.height 480, geom.x 0, geom.y 0
> [17:07:45.171] (panel) edge 2 position view 0xaaab02634510, x 0, y 0
> [17:07:45.172] panel type 2 inited on output DSI-1
> [17:07:45.172] Usable area: 380x480+100,0
> [  216.932080] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  217.476015] etnaviv-gpu 38000000.gpu: recover hung GPU!
> [  218.020157] etnaviv-gpu 38000000.gpu: recover hung GPU!
> 
> This is my problem on imx8mn

Note that the GPU on the 8MN is from the GC7000 generation, which
genreally has bogus feature registers, as VeriSilicon stopped using
them in favor of a hardware database. To get the GPu working you need
to transcribe the entry for this specific GPU from the downstream GPU
driver into the etanviv HWDB format, to make the kernel and userspace
driver aware of how to drive this GPU.

Regards,
Lucas
Michael Nazzareno Trimarchi Dec. 9, 2021, 9:24 p.m. UTC | #8
Hi

On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach <dev@lynxeye.de> wrote:
>
> Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
> Trimarchi:
> > Hi Tim
> >
> > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > >
> > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > > <michael@amarulasolutions.com> wrote:
> > > >
> > > > Hi Tim
> > > >
> > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > > >
> > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > >
> > > > > > Hi Sam,
> > > > > >
> > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > > > >
> > > > > > > Hi Jagan,
> > > > > > >
> > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > > > > >
> > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > > > > >
> > > > > > > > Right now bridge offers two sets of implementations.
> > > > > > > >
> > > > > > > > A. With component_ops and exynos specific code exclusively for
> > > > > > > >    exynos dsi drivers and it's legacy bindings.
> > > > > > > >
> > > > > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > > > > >    users like i.MX8MM.
> > > > > > > >
> > > > > > > > The future plan is to fix the implementation A) by dropping
> > > > > > > > component_ops and fixing exynos specific code in order to make
> > > > > > > > the bridge more mature to use and the same is mentioned in
> > > > > > > > drivers TODO.
> > > > > > > >
> > > > > > > > Patch 0001 - 0006: Bridge conversion
> > > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > > > > >
> > > > > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > > > > >
> > > > > > > > Anyone interest, please have a look on this repo
> > > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > > > > >
> > > > > > > > Would appreciate anyone from the exynos team to test it on
> > > > > > > > the exynos platform?
> > > > > > > >
> > > > > > > > Any inputs?
> > > > > > >
> > > > > > > I really like where you are headign with this!
> > > > > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > > > > individual patches.
> > > > > > >
> > > > > > > I hope you find a way to move forward with this.
> > > > > >
> > > > > > Thanks for the response.
> > > > > >
> > > > > > We have found some issues with Bridge conversion on existing exynos
> > > > > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > > > > attach if it involves kms hotplug. kms hotplug would require drm
> > > > > > pointer and that pointer would only available after the bind call
> > > > > > finishes. But the bridge attach in bind call will defer till it find
> > > > > > the attached bridge.
> > > > > >
> > > > > > Right now I'm trying to find the proper way to attach the bridges for
> > > > > > component based DSI drivers which involves kms hot-plug.
> > > > > >
> > > > > > If you have any ideas on this, please let me know.
> > > > > >
> > > > >
> > > > > Jagan,
> > > > >
> > > > > How is your progress on this series? Looking at your repo it looks
> > > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > > > > branch but you've got a lot of things there that are likely not
> > > > > related to this series?
> > > >
> > > > I have a bit of work on those patches and tested on imx8mn. Basically:
> > > >
> > > > - add the dsi timing calculation
> > > > - change few difference with samsung bridge
> > > > - fix crashes of my dsi panels
> > > > - compare with NXP driver the final results
> > > >
> > > > I found that I have one problem that gives me some instability. In the
> > > > NXP original driver the panel needs to be
> > > > enabled in bridge_enable before out the standby. If I understand
> > > > correctly, our standby should be done after.
> > > > I would like to have some feedback and help and testing on other
> > > > boards/devices and some suggestions on how to handle
> > > > some of the differences. Another big problem is etnavi that is not stable
> > > >
> > >
> > > Michael,
> > >
> > > Where can I find your patches?
> > >
> >
> > I will push on some tree and share
> >
> > > What do you mean by etnaviv not being stable?
> > >
> > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi
> >
> >
> >
> > > patches on an Ubuntu focal root filesystem by:
> > > apt update
> > > apt install gnome-session gnome-terminal
> > > ^^^ 2D hardware acceleration appears to be working (dragging opaque
> > > windows around)
> > > apt install mesa-utils glmark2
> > > glxgears
> > > ^^^ ~160fps on IMX8MM
> > > glmark2
> > > ^^^ score of 39 on IMX8MM
> > >
> > > I haven't seen any updates from Jagan since Nov 24
> > > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
> > > sure if he's been able to work through drm/exynos issues that have
> > > been blocking his progress.
> >
> > I plan to push on github
> >
> > [17:07:42.315] Sending ready to systemd
> > [  214.052085] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > [  214.595998] etnaviv-gpu 38000000.gpu: recover hung GPU!
> >
> > ** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success
> > [17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list
> > [17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list
> > ** Message: 17:07:44.289: New advertisement app id maynard
> > ** Message: 17:07:44.290: New advertisement app id maynard
> > [17:07:45.171] (background) position view 0xaaab0261f860, x 0, y 0, on
> > output DSI-1
> > [17:07:45.171] (panel) geom.width 100, geom.height 480, geom.x 0, geom.y 0
> > [17:07:45.171] (panel) edge 2 position view 0xaaab02634510, x 0, y 0
> > [17:07:45.172] panel type 2 inited on output DSI-1
> > [17:07:45.172] Usable area: 380x480+100,0
> > [  216.932080] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > [  217.476015] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > [  218.020157] etnaviv-gpu 38000000.gpu: recover hung GPU!
> >
> > This is my problem on imx8mn
>
> Note that the GPU on the 8MN is from the GC7000 generation, which
> genreally has bogus feature registers, as VeriSilicon stopped using
> them in favor of a hardware database. To get the GPu working you need
> to transcribe the entry for this specific GPU from the downstream GPU
> driver into the etanviv HWDB format, to make the kernel and userspace
> driver aware of how to drive this GPU.

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
index f2fc645c7956..724f78fd37e5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
@@ -68,6 +68,37 @@ static const struct etnaviv_chip_identity
etnaviv_chip_identities[] = {
                .minor_features10 = 0x00004040,
                .minor_features11 = 0x00000024,
        },
+       {
+               .model = 0x7000,
+               .revision = 0x6203,
+               .product_id = ~0U,
+               .customer_id = ~0U,
+               .eco_id = 0,
+               .stream_count = 16,
+               .register_max = 64,
+               .thread_count = 512,
+               .shader_core_count = 2,
+               .vertex_cache_size = 16,
+               .vertex_output_buffer_size = 1024,
+               .pixel_pipes = 1,
+               .instruction_count = 512,
+               .num_constants = 320,
+               .buffer_size = 0,
+               .varyings_count = 16,
+               .features = 0xe0287c8c,
+               .minor_features0 = 0xc1589eff,
+               .minor_features1 = 0xfefbfad9,
+               .minor_features2 = 0xeb9d4fbf,
+               .minor_features3 = 0xedfffced,
+               .minor_features4 = 0xdb0dafc7,
+               .minor_features5 = 0x3b5ac333,
+               .minor_features6 = 0xfcce6000,
+               .minor_features7 = 0xfffbfa6f,
+               .minor_features8 = 0x00e10ef3,
+               .minor_features9 = 0x00c8003c,
+               .minor_features10 = 0x00004040,
+               .minor_features11 = 0x00000024,
+       },
        {
                .model = 0x7000,
                .revision = 0x6204,

Ok, should something like this. Only does not know about this
gcFEATURE_BIT_DE_2D_FAST_CLEAR. I put in features but can even a
minor. Do you know the right mapping?

Michael

Michael

>
> Regards,
> Lucas
>
Adam Ford Dec. 15, 2021, 1:34 p.m. UTC | #9
On Thu, Dec 9, 2021 at 3:24 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi
>
> On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach <dev@lynxeye.de> wrote:
> >
> > Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
> > Trimarchi:
> > > Hi Tim
> > >
> > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > >
> > > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi
> > > > <michael@amarulasolutions.com> wrote:
> > > > >
> > > > > Hi Tim
> > > > >
> > > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey <tharvey@gateworks.com> wrote:
> > > > > >
> > > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > > > >
> > > > > > > Hi Sam,
> > > > > > >
> > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > > > > >
> > > > > > > > Hi Jagan,
> > > > > > > >
> > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote:
> > > > > > > > > This series supports common bridge support for Samsung MIPI DSIM
> > > > > > > > > which is used in Exynos and i.MX8MM SoC's.
> > > > > > > > >
> > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices.
> > > > > > > > >
> > > > > > > > > Right now bridge offers two sets of implementations.
> > > > > > > > >
> > > > > > > > > A. With component_ops and exynos specific code exclusively for
> > > > > > > > >    exynos dsi drivers and it's legacy bindings.
> > > > > > > > >
> > > > > > > > > B. Without componenet_ops for newly implemented bridges and its
> > > > > > > > >    users like i.MX8MM.
> > > > > > > > >
> > > > > > > > > The future plan is to fix the implementation A) by dropping
> > > > > > > > > component_ops and fixing exynos specific code in order to make
> > > > > > > > > the bridge more mature to use and the same is mentioned in
> > > > > > > > > drivers TODO.
> > > > > > > > >
> > > > > > > > > Patch 0001 - 0006: Bridge conversion
> > > > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions
> > > > > > > > >
> > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM.
> > > > > > > > >
> > > > > > > > > Anyone interest, please have a look on this repo
> > > > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim
> > > > > > > > >
> > > > > > > > > Would appreciate anyone from the exynos team to test it on
> > > > > > > > > the exynos platform?
> > > > > > > > >
> > > > > > > > > Any inputs?
> > > > > > > >
> > > > > > > > I really like where you are headign with this!
> > > > > > > > No testing - sorry. But I will try to provide a bit of feedback on the
> > > > > > > > individual patches.
> > > > > > > >
> > > > > > > > I hope you find a way to move forward with this.
> > > > > > >
> > > > > > > Thanks for the response.
> > > > > > >
> > > > > > > We have found some issues with Bridge conversion on existing exynos
> > > > > > > drivers. The component based DSI drivers(like exynos) are difficult to
> > > > > > > attach if it involves kms hotplug. kms hotplug would require drm
> > > > > > > pointer and that pointer would only available after the bind call
> > > > > > > finishes. But the bridge attach in bind call will defer till it find
> > > > > > > the attached bridge.
> > > > > > >
> > > > > > > Right now I'm trying to find the proper way to attach the bridges for
> > > > > > > component based DSI drivers which involves kms hot-plug.
> > > > > > >
> > > > > > > If you have any ideas on this, please let me know.
> > > > > > >
> > > > > >
> > > > > > Jagan,
> > > > > >
> > > > > > How is your progress on this series? Looking at your repo it looks
> > > > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim
> > > > > > branch but you've got a lot of things there that are likely not
> > > > > > related to this series?
> > > > >
> > > > > I have a bit of work on those patches and tested on imx8mn. Basically:
> > > > >
> > > > > - add the dsi timing calculation
> > > > > - change few difference with samsung bridge
> > > > > - fix crashes of my dsi panels
> > > > > - compare with NXP driver the final results
> > > > >
> > > > > I found that I have one problem that gives me some instability. In the
> > > > > NXP original driver the panel needs to be
> > > > > enabled in bridge_enable before out the standby. If I understand
> > > > > correctly, our standby should be done after.
> > > > > I would like to have some feedback and help and testing on other
> > > > > boards/devices and some suggestions on how to handle
> > > > > some of the differences. Another big problem is etnavi that is not stable
> > > > >
> > > >
> > > > Michael,
> > > >
> > > > Where can I find your patches?
> > > >
> > >
> > > I will push on some tree and share
> > >
> > > > What do you mean by etnaviv not being stable?
> > > >
> > > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi
> > >
> > >
> > >
> > > > patches on an Ubuntu focal root filesystem by:
> > > > apt update
> > > > apt install gnome-session gnome-terminal
> > > > ^^^ 2D hardware acceleration appears to be working (dragging opaque
> > > > windows around)
> > > > apt install mesa-utils glmark2
> > > > glxgears
> > > > ^^^ ~160fps on IMX8MM
> > > > glmark2
> > > > ^^^ score of 39 on IMX8MM
> > > >
> > > > I haven't seen any updates from Jagan since Nov 24
> > > > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not
> > > > sure if he's been able to work through drm/exynos issues that have
> > > > been blocking his progress.
> > >
> > > I plan to push on github
> > >
> > > [17:07:42.315] Sending ready to systemd
> > > [  214.052085] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > > [  214.595998] etnaviv-gpu 38000000.gpu: recover hung GPU!

Which Nano variant do you have?  Not all Nano's have a GPU.  I know
Tim Harvey was having a similar issue, but it turns out his variant of
the Nano did not include a GPU.

> > >
> > > ** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success
> > > [17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list
> > > [17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list
> > > ** Message: 17:07:44.289: New advertisement app id maynard
> > > ** Message: 17:07:44.290: New advertisement app id maynard
> > > [17:07:45.171] (background) position view 0xaaab0261f860, x 0, y 0, on
> > > output DSI-1
> > > [17:07:45.171] (panel) geom.width 100, geom.height 480, geom.x 0, geom.y 0
> > > [17:07:45.171] (panel) edge 2 position view 0xaaab02634510, x 0, y 0
> > > [17:07:45.172] panel type 2 inited on output DSI-1
> > > [17:07:45.172] Usable area: 380x480+100,0
> > > [  216.932080] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > > [  217.476015] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > > [  218.020157] etnaviv-gpu 38000000.gpu: recover hung GPU!
> > >
> > > This is my problem on imx8mn
> >
> > Note that the GPU on the 8MN is from the GC7000 generation, which
> > genreally has bogus feature registers, as VeriSilicon stopped using
> > them in favor of a hardware database. To get the GPu working you need
> > to transcribe the entry for this specific GPU from the downstream GPU
> > driver into the etanviv HWDB format, to make the kernel and userspace
> > driver aware of how to drive this GPU.
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> index f2fc645c7956..724f78fd37e5 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> @@ -68,6 +68,37 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
>                 .minor_features10 = 0x00004040,
>                 .minor_features11 = 0x00000024,
>         },
> +       {
> +               .model = 0x7000,
> +               .revision = 0x6203,
> +               .product_id = ~0U,
> +               .customer_id = ~0U,
> +               .eco_id = 0,
> +               .stream_count = 16,
> +               .register_max = 64,
> +               .thread_count = 512,
> +               .shader_core_count = 2,
> +               .vertex_cache_size = 16,
> +               .vertex_output_buffer_size = 1024,
> +               .pixel_pipes = 1,
> +               .instruction_count = 512,
> +               .num_constants = 320,
> +               .buffer_size = 0,
> +               .varyings_count = 16,
> +               .features = 0xe0287c8c,
> +               .minor_features0 = 0xc1589eff,
> +               .minor_features1 = 0xfefbfad9,
> +               .minor_features2 = 0xeb9d4fbf,
> +               .minor_features3 = 0xedfffced,
> +               .minor_features4 = 0xdb0dafc7,
> +               .minor_features5 = 0x3b5ac333,
> +               .minor_features6 = 0xfcce6000,
> +               .minor_features7 = 0xfffbfa6f,
> +               .minor_features8 = 0x00e10ef3,
> +               .minor_features9 = 0x00c8003c,
> +               .minor_features10 = 0x00004040,
> +               .minor_features11 = 0x00000024,
> +       },
>         {
>                 .model = 0x7000,
>                 .revision = 0x6204,
>
> Ok, should something like this. Only does not know about this
> gcFEATURE_BIT_DE_2D_FAST_CLEAR. I put in features but can even a
> minor. Do you know the right mapping?
>
> Michael
>
> Michael
>
> >
> > Regards,
> > Lucas
> >
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> michael@amarulasolutions.com
> __________________________________
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> info@amarulasolutions.com
> www.amarulasolutions.com