On 02/06/2021 20:20, Nelson Costa wrote: > Hi Hans, > > Thanks for your comments and feedback! > > From: Hans Verkuil <hverkuil-cisco@xxxxxxxxx> > Date: qua, jun 02, 2021 at 13:45:45 > >> On 02/06/2021 13:24, Nelson Costa wrote: >>> @@ -3194,10 +3428,29 @@ static int dw_hdmi_rx_probe(struct platform_device *pdev) >>> if (ret) >>> goto err_phy_exit; >>> >>> + /* CEC */ >>> +#if IS_ENABLED(CONFIG_VIDEO_DWC_HDMI_RX_CEC) >>> + dw_dev->cec_adap = cec_allocate_adapter(&dw_hdmi_cec_adap_ops, >>> + dw_dev, dev_name(dev), >>> + (CEC_CAP_DEFAULTS | >>> + CEC_CAP_NEEDS_HPD | >> >> This cap makes no sense for a receiver. >> > > This cap was added in order to overcome a scenario that we have when > there > was an hot plug. The driver performs a main reset that cause the loss of > cec controller configuration. And in that case in order to reconfigure What do you mean with 'there was an hot plug'? Are you talking about the HPD signal? Or when a new source/cable is connected? Can you point to the code where that happens in the driver? Regards, Hans > the > cec this cap was added. Because whenever there is a reset the physical > address is reconfigured (invalidated and set) and with this cap the cec > configuration callback function (adap_enable) is called again allowing to > reconfigure the cec. > > Does it make sense? > > If not, what should be the best approach in order to deal with this > scenario?
