linux-kernel - Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANwerB2RHQwZgZc37+dkh9np-SSFks3tZxqFzDPVwQP5oP48hg@mail.gmail.com>
Date:   Sat, 1 Jul 2017 00:14:44 +1000
From:   Jonathan Liu <net147@...il.com>
To:     Chen-Yu Tsai <wens@...e.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     David Airlie <airlied@...ux.ie>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [PATCH v5] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

Hi Chen-Yu and Maxime,

On 30 June 2017 at 13:16, Chen-Yu Tsai <wens@...e.org> wrote:
> On Fri, Jun 30, 2017 at 6:22 AM, Jonathan Liu <net147@...il.com> wrote:
>> Hi Maxime,
>>
>> On 30 June 2017 at 01:56, Maxime Ripard
>> <maxime.ripard@...e-electrons.com> 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.
>
> The manual says "When FIFO level is above this value in read mode, DMA
> request and FIFO request interrupt are asserted if relative enable is on."
>
> Perhaps try enabling the interrupts? But if that were the case, wouldn't
> using interrupts instead of polling be better?
>
> ChenYu
>

I managed to get the thresholds working so switching to using
interrupts instead of polling will be my next goal.

>>
>>> Maxime
>>>
>>> --
>>> Maxime Ripard, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
>>
>> Regards,
>> Jonathan

Regards,
Jonathan