Hi Maxime, On 30 June 2017 at 01:56, Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, Jun 28, 2017 at 08:39:33PM +1000, Jonathan Liu wrote: >> >> + u32 int_status; >> >> + u32 fifo_status; >> >> + /* Read needs empty flag unset, write needs full flag unset */ >> >> + u32 flag = read ? SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY : >> >> + SUN4I_HDMI_DDC_FIFO_STATUS_FULL; >> >> + int ret; >> >> + >> >> + /* Wait until error or FIFO ready */ >> >> + ret = readl_poll_timeout(hdmi->base + SUN4I_HDMI_DDC_INT_STATUS_REG, >> >> + int_status, >> >> + is_err_status(int_status) || >> >> + is_fifo_flag_unset(hdmi, &fifo_status, flag), >> >> + min(len, SUN4I_HDMI_DDC_FIFO_SIZE) * byte_time, >> >> + 100000); >> >> + >> >> + if (is_err_status(int_status)) >> >> + return -EIO; >> >> + if (ret) >> >> + return -ETIMEDOUT; >> > >> > Why not just have >> > ret = readl_poll_timeout(hdmi->base + SUN4I_HDMI_DDC_FIFO_STATUS_REG, reg, >> > !(reg & flag), 100, 100000); >> > >> > if (ret < 0) >> > if (is_err_status()) >> > return -EIO; >> > return ret; >> > >> > >> >> If I check error status after readl_poll_timeout and there is an error >> (e.g. the I2C address does not have a corresponding device connected >> or nothing connected to HDMI port) it will keep checking the fifo >> status even though error bit is set in the int status and then timeout >> after 100 ms. If it checks the int status register at the same time, >> it will error after 100 nanoseconds. I don't want to introduce >> unnecessary delays considering part of the reason for adding this >> driver to make it more usable for non-standard use cases. > > Well, polling for 100ms doesn't seem great either. What was the > rationale behind that timeout? > When an error occurs one of the error bits will be set in the INT_STATUS register so this is detected very quickly if I check the INT_STATUS and FIFO_STATUS at the same time. The 100 ms timeout is in case the I2C slave does clock stretching in which case the transfer may take longer than the predicted time. > And we can also reverse the check and look at the INT_STATUS > register. The errors will be there, and we can program the threshold > we want in both directions and use the > DDC_FIFO_Request_Interrupt_Status bit. > I did try that when I was doing the v3 patch but I couldn't get it to work as mentioned previously in the v3 patch discussion. I programmed the FIFO_RX_TRIGGER_THRES and FIFO_TX_TRIGGER_THRES in DDC_FIFO_Ctrl register at the same time as setting FIFO_Address_Clear but the request interrupt status bit did not get updated to the appropriate state that is consistent with the FIFO level and the thresholds. I did try this several times for subsequent patch versions without success. > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com Regards, Jonathan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
