Le lun. 27 juil. 2026 à 14:35, Mattijs Korpershoek <[email protected]> a écrit : > > Hi Julien, > > On Mon, Jul 27, 2026 at 11:28, Julien Stephan <[email protected]> wrote: > > > Hello Mattijs, > > > > (used the new u-boot ml address [email protected] and > > dropped the old denx one) > > > > Le mar. 21 juil. 2026 à 11:22, Mattijs Korpershoek > > <[email protected]> a écrit : > >> > >> Hi Julien, > >> > >> Thank you for the patch. > >> > >> On Fri, Jul 17, 2026 at 10:26, Julien Stephan <[email protected]> > >> wrote: > >> > >> > Add a new driver for the HDMI PHY. The driver supports MT8188 and MT8195 > >> > based SoCs. The driver is based on the corresponding kernel driver. > >> > >> What kernel version (exact commit, including the sha) has this been > >> ported from ? > >> > >> Mentioning it in the commit message will help reviewers to compare this > >> with the linux codebase. > >> > >> I can do a more detailed review once I know the linux base this has been > >> ported from. > >> > > > > Technically it's not a direct port from the upstream kernel driver. > > The code comes from an old downstream MediaTek code base. > > I guess it was polished a bit during kernel upstream, hence some > > variables names and functions are not 100% identical.. > > Ah, that make sense. > > > > > So what would you like me to do? Send a v2 with a proper backport from > > kernel? Or being more explicit on the commit message is enough? > > Something like: "The driver is loosely based on the corresponding > > kernel driver at 45810d486bb4 phy: mediatek: add support for > > phy-mtk-hdmi-mt8195) > > Ideally, we would do a backport from the Linux driver. That will make > future maintenance easier since we can continue porting fixes (when > relevant) from Linux when they arrive. That's probably a bit more work > though :( > > If you want to keep this implementation, then I'd be more precise in the > commit message. Stating that it's based on a vendor driver and has been > polished up for U-Boot. > > So I have a preference for doing the port from Linux, but I won't block > this if we just reword the commit message. Up to you to decide what > you'd like to do. >
Done :) Cheers Julien > > > >> > > >> > Signed-off-by: Pavlo Yadvychuk <[email protected]> > >> > Signed-off-by: Julien Stephan <[email protected]> > >> > --- > >> > >> [...] > >> > >> > + > >> > + /* RG_HDMITXPLL_RESERVE[12:11] */ > >> > + mtk_hdmi_phy_mask(hdmi_phy, HDMI_1_PLL_CFG_1, > >> > + 0x3 << RG_HDMITXPLL_RESERVE_BIT12_11_SHIFT, > >> > + RG_HDMITXPLL_RESERVE_BIT12_11); > >> > + > >> > + /* TCL_EN */ > >> > + mtk_hdmi_phy_mask(hdmi_phy, HDMI_1_PLL_CFG_0, > >> > + 0x1 << RG_HDMITXPLL_TCL_EN_SHIFT, > >> > + RG_HDMITXPLL_TCL_EN); > >> > + > >> > + /* we should always read calibration impedance > >> > + * from efuse, unless for debugging purposes. > >> > + * This calibraion value is not board-dependent > >> > >> calibraion -> calibration > >> > >> > + * so no SW adjustment required. > >> > + */ > >> > + if (hdmi_phy->conf->efuse_sw_mode) { > >> > + debug("efuse_sw_mode ENABLED!!!"); > >> > + mtk_hdmi_phy_mask(hdmi_phy, HDMI_CTL_1, > >> > + 0x1f << RG_INTR_IMP_RG_MODE_SHIFT, > >> > + RG_INTR_IMP_RG_MODE); > >> > + } > >> > + > >> > + return 0; > >> > +} > >> > + > >> > >> [...]
