MIME-Version: 1.0
From:   Adam Ford <aford173@gmail.com>
Date:   Sun, 12 Mar 2023 14:28:45 -0500
Message-ID: <CAHCN7xJXMmwYqD=Eb2=_vJw390KAd6NgkWCpq6yCbAyaJ3xK5A@mail.gmail.com>
Subject: MXSFB and Video PLL clock on i.MX8M Mini/Nano Question
To:     arm-soc <linux-arm-kernel@lists.infradead.org>
Cc:     Marek Vasut <marex@denx.de>, Stefan Agner <stefan@agner.ch>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jagan Teki <jagan@amarulasolutions.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

I am trying to work through a series that was submitted for enabling
the DSI on the i.MX8M Mini and Nano.  I have extended this series to
route the DSI to an HDMI bridge, and I am able to get several
resolutions to properly sync on my monitor.  However, there are also a
 bunch that appear on the list when I run modetest that do not sync on
my monitor.

When running some debug code, it appears that it's related to the
clocking of the MXSFB driver.

From what I can tell, the MSXFB driver attempts to set the clock based
on the desired resolution and refresh rate.  When the default
VIDEO_PLL clock is set to 594MHz, many of the resolutions that cleanly
divide from the 594MHz clock appear to sync with my monitor.  However,
in order to get other resolutions to appear, I have to manually change
the device tree to set VIDEO_PLL to a different clock rate so MSXFB
can use it.  Unfortunately, that breaks the resolutions that used to
work.

I threw together a hack into the MXSFB driver which adds a new
optional clock to the MSXFB driver.  When I pass VIDEO_PLL to this
driver, it can automatically set the clock rate to match that of
whatever the desired clock is, and I can get many more resolutions to
appear.
Another advantage of this is that the Video_PLL can be the minimum
speed needed for a given rate instead of setting a higher rate, then
dividing it down.

I wasn't sure if that would be the best way to approach this, or if
someone had a better suggestion.

If this is the best approach, I can try to clean up my patch and
submit it to the mailing list for review.

thanks,

adam