On Mon, May 15, 2023 at 2:37 AM Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > On 13.05.2023 06:25, Adam Ford wrote: > > On Fri, May 12, 2023 at 4:02 PM Marek Szyprowski > > <m.szyprowski@xxxxxxxxxxx> wrote: > >> On 12.05.2023 22:00, Adam Ford wrote: > >>> On Fri, May 12, 2023 at 2:37 PM Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > >>>> Am Samstag, dem 06.05.2023 um 14:24 -0500 schrieb Adam Ford: > >>>>> The DPHY timings are currently hard coded. Since the input > >>>>> clock can be variable, the phy timings need to be variable > >>>>> too. Add an additional variable to the driver data to enable > >>>>> this feature to prevent breaking boards that don't support it. > >>>>> > >>>>> The phy_mipi_dphy_get_default_config function configures the > >>>>> DPHY timings in pico-seconds, and a small macro converts those > >>>>> timings into clock cycles based on the pixel clock rate. > >>>>> > >>>> This week I finally had some time to take a deeper look at this series > >>>> and test it on some of my systems. > >>> Thanks for testing this! > >>>> This patch causes issues when the burst clock rate is fixed by > >>>> supplying the DT entry. Instead of describing the issue below, I'm > >>>> attaching the patch that makes things work on my system. > >>> Oops, sorry about that. > >>> > >>>> I would appreciate if you could test this one on your side. Feel free > >>>> to squash it into yours if you find it working properly. > >>> I reviewed your patch, and it looks like it makes a lot of sense. > >>> If it works, I'll squash them together and add your name to the sign-off. > > That worked really well, I'll add it to my WIP directory since Marek S > > said he'd test the other proposal of dropping the dynamic phy flag and > > corresponding check in favor of pushing everyone to the same code. > > > >>>> Also I would almost bet that dynamic_dphy is working on the Exynos > >>>> boards with that fix added. So if anyone with access to those boards > >>>> would like to give it a shot, we may be able to get rid of the > >>>> hardcoded PHY parameters altogether, which would be a nice cleanup. > >>> I wondered the same thing, but I didn't want to create more work for > >>> Marek S and since there was so much churn getting the original driver > >>> ported, I thought it would be the safest thing to try to give the > >>> imx8m m/n/p the features without breaking the Exynos. > >>> > >>> Marek S - Do you want me to post this file without the extra checks to > >>> see if it still works with Exynos? > >> Feel free to send me patches to test or just point to your > >> work-in-progress git repo. > > Thanks for testing this, Marek S. My work-in-progress branch is: > > > > https://protect2.fireeye.com/v1/url?k=2eeb1ed9-4e098384-2eea9596-000babd9f1ba-9ad5c339e5ea6e4d&q=1&e=652be603-d622-4d0e-95d3-639656ab1af1&u=https%3A%2F%2Fgithub.com%2Faford173%2Flinux%2Ftree%2Fdsim-updates-wip > > > > Depending on what you find will determine how I modify the next > > revision of the code I push, so I very much appreciate your feedback. > > Hopefully the suggestion from Lucas will work for your applications > > and we can reduce some of the code complexity. > > The above mentioned 'dsim-updates-wip' branch works fine on all my > Exynos based boards. Thank you for testing. I'll work on squashing some of the patches together and eliminating some of the duplicative stuff so the end result should be the same as what is in WIP and submit another revision soon. thanks! adam > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >
