* fw_devlink=on and sunxi HDMI @ 2021-05-16 17:05 Ondřej Jirman 2021-05-17 6:32 ` Saravana Kannan 0 siblings, 1 reply; 7+ messages in thread From: Ondřej Jirman @ 2021-05-16 17:05 UTC (permalink / raw) To: saravanak, linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, gregkh, rafael, linux-kernel, andre.przywara Hello, Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this breaks probing display pipeline and HDMI output on sunxi boards, because of fwnode_link between hdmi and hdmi-phy nodes. HDMI device probe keeps being avoided with these repeated messages in dmesg: platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready Both nodes have their own compatible, but are implemented by a single struct device. This looks like a kind of situation that's expected to break fw_devlink expectations by my reading of the the e-mails about trying the fw_devlink=on during 5.12 cycle. Is this supposed to be solved by implementing the PHY node as it's own device or by breaking the fwnode_link between the hdmi phy and hdmi nodes? Seems like second solution would be quicker now that rc1 is out. Where would be a good place to break that fwnode_link in code? Or can the fw_devlink code be made aware of this situation, where two fwnodes are implemented by the same Linux device, somehow? Relevant references: https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c#L600 https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c#L212 https://elixir.bootlin.com/linux/v5.13-rc1/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L1176 kind regards, o. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-16 17:05 fw_devlink=on and sunxi HDMI Ondřej Jirman @ 2021-05-17 6:32 ` Saravana Kannan 2021-05-17 8:29 ` Ondřej Jirman 0 siblings, 1 reply; 7+ messages in thread From: Saravana Kannan @ 2021-05-17 6:32 UTC (permalink / raw) To: Ondřej Jirman, Saravana Kannan, linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman <megi@xff.cz> wrote: > > Hello, > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this > breaks probing display pipeline and HDMI output on sunxi boards, because of > fwnode_link between hdmi and hdmi-phy nodes. > > HDMI device probe keeps being avoided with these repeated messages in dmesg: > > platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready > > Both nodes have their own compatible, but are implemented by a single > struct device. > > This looks like a kind of situation that's expected to break fw_devlink > expectations by my reading of the the e-mails about trying the fw_devlink=on > during 5.12 cycle. > > Is this supposed to be solved by implementing the PHY node as it's own > device or by breaking the fwnode_link between the hdmi phy and hdmi nodes? > Seems like second solution would be quicker now that rc1 is out. Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make the PHY a separate driver. Why not just finish it up by really making it a separate driver? I'd really prefer doing that because this seems unnecessarily messed up. The phy will have a struct device created for it already. You are just not probing it. Thanks, Saravana > > Where would be a good place to break that fwnode_link in code? > > Or can the fw_devlink code be made aware of this situation, where two fwnodes > are implemented by the same Linux device, somehow? > > Relevant references: > > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c#L600 > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c#L212 > https://elixir.bootlin.com/linux/v5.13-rc1/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L1176 > > kind regards, > o. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-17 6:32 ` Saravana Kannan @ 2021-05-17 8:29 ` Ondřej Jirman 2021-05-18 14:04 ` Maxime Ripard 2021-05-19 21:29 ` Saravana Kannan 0 siblings, 2 replies; 7+ messages in thread From: Ondřej Jirman @ 2021-05-17 8:29 UTC (permalink / raw) To: Saravana Kannan Cc: linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara On Sun, May 16, 2021 at 11:32:47PM -0700, Saravana Kannan wrote: > On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman <megi@xff.cz> wrote: > > > > Hello, > > > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this > > breaks probing display pipeline and HDMI output on sunxi boards, because of > > fwnode_link between hdmi and hdmi-phy nodes. > > > > HDMI device probe keeps being avoided with these repeated messages in dmesg: > > > > platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready > > > > Both nodes have their own compatible, but are implemented by a single > > struct device. > > > > This looks like a kind of situation that's expected to break fw_devlink > > expectations by my reading of the the e-mails about trying the fw_devlink=on > > during 5.12 cycle. > > > > Is this supposed to be solved by implementing the PHY node as it's own > > device or by breaking the fwnode_link between the hdmi phy and hdmi nodes? > > Seems like second solution would be quicker now that rc1 is out. > > Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make > the PHY a separate driver. Why not just finish it up by really making > it a separate driver? I'd really prefer doing that because this seems > unnecessarily messed up. The phy will have a struct device created for > it already. You are just not probing it. Currently it's all just a glue code for dw-hdmi, which is not using a phy framework and handles both the controller and phy parts. dw-hdmi needs passing platform data around (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdmi.h#L115) to get a specific set of phy glue callbacks hooked into platform data of dw-hdmi prior to calling dw_hdmi_probe. Looking at other users of dw_hdmi_probe this is the only one that has this unfortunate issue due to using phys binding internally as a part of one device. Just making it a platform driver will also change the probe order of phy and the controller, which I've heard from Jernej needs to have the current order of (controller and then phy) perserved, for some reason, and will make things still a bit more convoluted. So this looks like needs quite a bit of thought. regards, o. > Thanks, > Saravana > > > > > Where would be a good place to break that fwnode_link in code? > > > > Or can the fw_devlink code be made aware of this situation, where two fwnodes > > are implemented by the same Linux device, somehow? > > > > Relevant references: > > > > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c#L600 > > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c#L212 > > https://elixir.bootlin.com/linux/v5.13-rc1/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L1176 > > > > kind regards, > > o. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-17 8:29 ` Ondřej Jirman @ 2021-05-18 14:04 ` Maxime Ripard 2021-05-19 21:29 ` Saravana Kannan 1 sibling, 0 replies; 7+ messages in thread From: Maxime Ripard @ 2021-05-18 14:04 UTC (permalink / raw) To: Ondřej Jirman, Saravana Kannan, linux-arm-kernel, linux-sunxi, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara [-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --] On Mon, May 17, 2021 at 10:29:57AM +0200, Ondřej Jirman wrote: > On Sun, May 16, 2021 at 11:32:47PM -0700, Saravana Kannan wrote: > > On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman <megi@xff.cz> wrote: > > > > > > Hello, > > > > > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this > > > breaks probing display pipeline and HDMI output on sunxi boards, because of > > > fwnode_link between hdmi and hdmi-phy nodes. > > > > > > HDMI device probe keeps being avoided with these repeated messages in dmesg: > > > > > > platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready > > > > > > Both nodes have their own compatible, but are implemented by a single > > > struct device. > > > > > > This looks like a kind of situation that's expected to break fw_devlink > > > expectations by my reading of the the e-mails about trying the fw_devlink=on > > > during 5.12 cycle. > > > > > > Is this supposed to be solved by implementing the PHY node as it's own > > > device or by breaking the fwnode_link between the hdmi phy and hdmi nodes? > > > Seems like second solution would be quicker now that rc1 is out. > > > > Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make > > the PHY a separate driver. Why not just finish it up by really making > > it a separate driver? I'd really prefer doing that because this seems > > unnecessarily messed up. The phy will have a struct device created for > > it already. You are just not probing it. > > Currently it's all just a glue code for dw-hdmi, which is not using a phy > framework and handles both the controller and phy parts. dw-hdmi needs passing > platform data around > (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdmi.h#L115) > to get a specific set of phy glue callbacks hooked into platform data of dw-hdmi > prior to calling dw_hdmi_probe. > > Looking at other users of dw_hdmi_probe this is the only one that has this > unfortunate issue due to using phys binding internally as a part of one device. > > Just making it a platform driver will also change the probe order of phy and the > controller, which I've heard from Jernej needs to have the current order of > (controller and then phy) perserved, for some reason, and will make things > still a bit more convoluted. > > So this looks like needs quite a bit of thought. Yep, and even if it was simple (which it really isn't), it wouldn't be -rc* material. Maxime [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-17 8:29 ` Ondřej Jirman 2021-05-18 14:04 ` Maxime Ripard @ 2021-05-19 21:29 ` Saravana Kannan 2021-05-19 22:00 ` Ondřej Jirman 1 sibling, 1 reply; 7+ messages in thread From: Saravana Kannan @ 2021-05-19 21:29 UTC (permalink / raw) To: Ondřej Jirman, Saravana Kannan, linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara [-- Attachment #1: Type: text/plain, Size: 2979 bytes --] On Mon, May 17, 2021 at 1:29 AM Ondřej Jirman <megous@megous.com> wrote: > > On Sun, May 16, 2021 at 11:32:47PM -0700, Saravana Kannan wrote: > > On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman <megi@xff.cz> wrote: > > > > > > Hello, > > > > > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this > > > breaks probing display pipeline and HDMI output on sunxi boards, because of > > > fwnode_link between hdmi and hdmi-phy nodes. > > > > > > HDMI device probe keeps being avoided with these repeated messages in dmesg: > > > > > > platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready > > > > > > Both nodes have their own compatible, but are implemented by a single > > > struct device. > > > > > > This looks like a kind of situation that's expected to break fw_devlink > > > expectations by my reading of the the e-mails about trying the fw_devlink=on > > > during 5.12 cycle. > > > > > > Is this supposed to be solved by implementing the PHY node as it's own > > > device or by breaking the fwnode_link between the hdmi phy and hdmi nodes? > > > Seems like second solution would be quicker now that rc1 is out. > > > > Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make > > the PHY a separate driver. Why not just finish it up by really making > > it a separate driver? I'd really prefer doing that because this seems > > unnecessarily messed up. The phy will have a struct device created for > > it already. You are just not probing it. > > Currently it's all just a glue code for dw-hdmi, which is not using a phy > framework and handles both the controller and phy parts. dw-hdmi needs passing > platform data around > (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdmi.h#L115) > to get a specific set of phy glue callbacks hooked into platform data of dw-hdmi > prior to calling dw_hdmi_probe. > > Looking at other users of dw_hdmi_probe this is the only one that has this > unfortunate issue due to using phys binding internally as a part of one device. > > Just making it a platform driver will also change the probe order of phy and the > controller, which I've heard from Jernej needs to have the current order of > (controller and then phy) perserved, for some reason, and will make things > still a bit more convoluted. > > So this looks like needs quite a bit of thought. Nothing in sun8i_hdmi_phy_probe() depends on anything from sun8i_dw_hdmi.c other than getting a struct device pointer to use with dev_err and some devm_* APIs. So it seems pretty straightforward to fix this so that you don't have one struct device trying to represent two distinct hardware blocks. What am I missing? Anyway, I took a swing at fixing this while preserving the ordering of the important bits. The changes are fairly trivial/straightforward and not meant to be final code, but can you test this out please? -Saravana [-- Attachment #2: 0001-Try-fixing-HDMI-probe.patch --] [-- Type: application/x-patch, Size: 4440 bytes --] [-- Attachment #3: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-19 21:29 ` Saravana Kannan @ 2021-05-19 22:00 ` Ondřej Jirman 2021-05-19 22:15 ` Saravana Kannan 0 siblings, 1 reply; 7+ messages in thread From: Ondřej Jirman @ 2021-05-19 22:00 UTC (permalink / raw) To: Saravana Kannan Cc: linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara Hello Saravana, On Wed, May 19, 2021 at 02:29:48PM -0700, Saravana Kannan wrote: > > Nothing in sun8i_hdmi_phy_probe() depends on anything from > sun8i_dw_hdmi.c other than getting a struct device pointer to use with > dev_err and some devm_* APIs. So it seems pretty straightforward to > fix this so that you don't have one struct device trying to represent > two distinct hardware blocks. What am I missing? > > Anyway, I took a swing at fixing this while preserving the ordering of > the important bits. The changes are fairly trivial/straightforward and > not meant to be final code, but can you test this out please? the patch seems to work, after fixing a few compilation issues. See bellow. Thanks! I think the probe order is reversed, but HDMI works in my case, so I guess that doesn't matter in the end. Or at least it didn't in the short test I made. kind regards, o. From 0eac644368711f52fffa4246aefc546591cef090 Mon Sep 17 00:00:00 2001 From: Ondrej Jirman <megous@megous.com> Date: Wed, 19 May 2021 23:44:45 +0200 Subject: [PATCH] fix compilation issues --- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index c44ed22d8aef0..947b4231f6449 100644 --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c @@ -5,6 +5,7 @@ #include <linux/delay.h> #include <linux/of_address.h> +#include <linux/of_platform.h> #include "sun8i_dw_hdmi.h" @@ -748,7 +749,7 @@ int sun8i_hdmi_phy_probe(struct platform_device *pdev) return ret; } -void sun8i_hdmi_phy_remove(struct platform_device *pdev) +int sun8i_hdmi_phy_remove(struct platform_device *pdev) { struct sun8i_hdmi_phy *phy = platform_get_drvdata(pdev); -- 2.31.1 [ 0.307254] platform 1c28000.serial: probe deferral - supplier 1c20800.pinctrl not ready [ 0.307340] platform 1c28400.serial: probe deferral - supplier 1c20800.pinctrl not ready [ 0.307379] platform 1c28c00.serial: probe deferral - supplier 1c20800.pinctrl not ready [ 0.309235] fwnode_links_purge_suppliers: display-engine [ 0.310176] platform 1c0c000.lcd-controller: probe deferral - wait for supplier mixer@200000 [ 0.310228] platform 1c0d000.lcd-controller: probe deferral - wait for supplier mixer@200000 [ 0.311902] platform 1ca0000.dsi: probe deferral - wait for supplier pmic@3a3 [ 0.312287] platform 1ee0000.hdmi: probe deferral - wait for supplier pmic@3a3 [ 0.313076] fwnode_links_purge_suppliers: hdmi-phy@1ef0000 <------ phy probed [ 0.316766] platform 1c21800.lradc: probe deferral - wait for supplier pmic@3a3 [ 0.317258] platform vibrator: probe deferral - wait for supplier pmic@3a3 [ 0.318703] sun6i-rtc 1f00000.rtc: registered as rtc0 [ 0.318748] sun6i-rtc 1f00000.rtc: setting system clock to 2021-05-19T21:40:59 UTC (1621460459) [ 0.318917] sun6i-rtc 1f00000.rtc: RTC enabled [ 0.318938] fwnode_links_purge_suppliers: rtc@1f00000 [ 0.318960] fwnode_links_purge_consumers: reboot-mode@4 [ 0.319185] i2c /dev entries driver .... [ 0.453301] fwnode_links_purge_consumers: port [ 0.453323] fwnode_links_purge_consumers: endpoint [ 0.453346] fwnode_links_purge_consumers: panel@0 [ 0.491868] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffffffc010a44230) [ 0.501830] sun4i-drm display-engine: bound 1200000.mixer (ops 0xffffffc010a44230) [ 0.502915] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 0.502956] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xffffffc010a415a0) [ 0.503466] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xffffffc010a415a0) [ 0.503545] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffffffc010a431c8) [ 0.505330] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) [ 0.507566] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver [ 0.510717] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xffffffc010a43568) [ 0.514674] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [ 0.514932] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 0.515160] fwnode_links_purge_suppliers: hdmi@1ee0000 <------ hdmi probed [ 0.515195] fwnode_links_purge_consumers: ports [ 0.515217] fwnode_links_purge_consumers: port@0 [ 0.515240] fwnode_links_purge_consumers: endpoint [ 0.515264] fwnode_links_purge_consumers: port@1 [ 0.515343] fwnode_links_purge_consumers: endpoint [ 0.517089] input: 1c21800.lradc as /devices/platform/soc/1c21800.lradc/input/input1 [ 0.517358] fwnode_links_purge_suppliers: lradc@1c21800 [ 0.517384] fwnode_links_purge_consumers: button-200 [ 0.517407] fwnode_links_purge_consumers: button-400 [ 0.518414] input: gpio-vibrator as /devices/platform/vibrator/input/input2 [ 0.518582] fwnode_links_purge_suppliers: vibrator > -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: fw_devlink=on and sunxi HDMI 2021-05-19 22:00 ` Ondřej Jirman @ 2021-05-19 22:15 ` Saravana Kannan 0 siblings, 0 replies; 7+ messages in thread From: Saravana Kannan @ 2021-05-19 22:15 UTC (permalink / raw) To: Ondřej Jirman, Saravana Kannan, linux-arm-kernel, linux-sunxi, mripard, wens, jernej.skrabec, Greg Kroah-Hartman, Rafael J. Wysocki, LKML, andre.przywara On Wed, May 19, 2021 at 3:00 PM Ondřej Jirman <megous@megous.com> wrote: > > Hello Saravana, > > On Wed, May 19, 2021 at 02:29:48PM -0700, Saravana Kannan wrote: > > > > Nothing in sun8i_hdmi_phy_probe() depends on anything from > > sun8i_dw_hdmi.c other than getting a struct device pointer to use with > > dev_err and some devm_* APIs. So it seems pretty straightforward to > > fix this so that you don't have one struct device trying to represent > > two distinct hardware blocks. What am I missing? > > > > Anyway, I took a swing at fixing this while preserving the ordering of > > the important bits. The changes are fairly trivial/straightforward and > > not meant to be final code, but can you test this out please? > > the patch seems to work, after fixing a few compilation issues. See > bellow. Thanks! Thanks for the quick test! Do you want to fix it up and get it upstreamed? I can do it, but I have other stuff I need to take care of. Also, I just wanted to prove the change I was suggesting wasn't complicated and fairly trivial. > I think the probe order is reversed, but HDMI works in my case, so > I guess that doesn't matter in the end. Or at least it didn't in the > short test I made. I don't think the "probe" order really changed. Firstly there was no real phy "probe" before. However, I'm guessing the order that really matters is the order between sun8i_hdmi_phy_init() and dw_hdmi_bind(). My patch still preserves that and that's why I think it works fine. sun8i_hdmi_phy_probe() was just doing a bunch of "gets" on resources so doing that a bit earlier seens pretty harmless. -Saravana > > kind regards, > o. > > > From 0eac644368711f52fffa4246aefc546591cef090 Mon Sep 17 00:00:00 2001 > From: Ondrej Jirman <megous@megous.com> > Date: Wed, 19 May 2021 23:44:45 +0200 > Subject: [PATCH] fix compilation issues > > --- > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > index c44ed22d8aef0..947b4231f6449 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > @@ -5,6 +5,7 @@ > > #include <linux/delay.h> > #include <linux/of_address.h> > +#include <linux/of_platform.h> > > #include "sun8i_dw_hdmi.h" > > @@ -748,7 +749,7 @@ int sun8i_hdmi_phy_probe(struct platform_device *pdev) > return ret; > } > > -void sun8i_hdmi_phy_remove(struct platform_device *pdev) > +int sun8i_hdmi_phy_remove(struct platform_device *pdev) > { > struct sun8i_hdmi_phy *phy = platform_get_drvdata(pdev); > > -- > 2.31.1 > > > [ 0.307254] platform 1c28000.serial: probe deferral - supplier 1c20800.pinctrl not ready > [ 0.307340] platform 1c28400.serial: probe deferral - supplier 1c20800.pinctrl not ready > [ 0.307379] platform 1c28c00.serial: probe deferral - supplier 1c20800.pinctrl not ready > [ 0.309235] fwnode_links_purge_suppliers: display-engine > [ 0.310176] platform 1c0c000.lcd-controller: probe deferral - wait for supplier mixer@200000 > [ 0.310228] platform 1c0d000.lcd-controller: probe deferral - wait for supplier mixer@200000 > [ 0.311902] platform 1ca0000.dsi: probe deferral - wait for supplier pmic@3a3 > [ 0.312287] platform 1ee0000.hdmi: probe deferral - wait for supplier pmic@3a3 > [ 0.313076] fwnode_links_purge_suppliers: hdmi-phy@1ef0000 <------ phy probed > [ 0.316766] platform 1c21800.lradc: probe deferral - wait for supplier pmic@3a3 > [ 0.317258] platform vibrator: probe deferral - wait for supplier pmic@3a3 > [ 0.318703] sun6i-rtc 1f00000.rtc: registered as rtc0 > [ 0.318748] sun6i-rtc 1f00000.rtc: setting system clock to 2021-05-19T21:40:59 UTC (1621460459) > [ 0.318917] sun6i-rtc 1f00000.rtc: RTC enabled > [ 0.318938] fwnode_links_purge_suppliers: rtc@1f00000 > [ 0.318960] fwnode_links_purge_consumers: reboot-mode@4 > [ 0.319185] i2c /dev entries driver > > .... > > [ 0.453301] fwnode_links_purge_consumers: port > [ 0.453323] fwnode_links_purge_consumers: endpoint > [ 0.453346] fwnode_links_purge_consumers: panel@0 > [ 0.491868] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffffffc010a44230) > [ 0.501830] sun4i-drm display-engine: bound 1200000.mixer (ops 0xffffffc010a44230) > [ 0.502915] sun4i-drm display-engine: No panel or bridge found... RGB output disabled > [ 0.502956] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xffffffc010a415a0) > [ 0.503466] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xffffffc010a415a0) > [ 0.503545] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffffffc010a431c8) > [ 0.505330] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) > [ 0.507566] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver > [ 0.510717] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xffffffc010a43568) > [ 0.514674] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 > [ 0.514932] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes > [ 0.515160] fwnode_links_purge_suppliers: hdmi@1ee0000 <------ hdmi probed > [ 0.515195] fwnode_links_purge_consumers: ports > [ 0.515217] fwnode_links_purge_consumers: port@0 > [ 0.515240] fwnode_links_purge_consumers: endpoint > [ 0.515264] fwnode_links_purge_consumers: port@1 > [ 0.515343] fwnode_links_purge_consumers: endpoint > [ 0.517089] input: 1c21800.lradc as /devices/platform/soc/1c21800.lradc/input/input1 > [ 0.517358] fwnode_links_purge_suppliers: lradc@1c21800 > [ 0.517384] fwnode_links_purge_consumers: button-200 > [ 0.517407] fwnode_links_purge_consumers: button-400 > [ 0.518414] input: gpio-vibrator as /devices/platform/vibrator/input/input2 > [ 0.518582] fwnode_links_purge_suppliers: vibrator > > > > > -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-05-19 22:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-16 17:05 fw_devlink=on and sunxi HDMI Ondřej Jirman 2021-05-17 6:32 ` Saravana Kannan 2021-05-17 8:29 ` Ondřej Jirman 2021-05-18 14:04 ` Maxime Ripard 2021-05-19 21:29 ` Saravana Kannan 2021-05-19 22:00 ` Ondřej Jirman 2021-05-19 22:15 ` Saravana Kannan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).