On 01/03/2019 01:58 AM, Yi Qingliang wrote: > hello, I sent a email about 'can't wake problem' 4 days ago. > > Is this problem related with mine? No, it's unrelated. I'll take a look at vb2_poll next week. Regards, Hans > >> epoll and vb2_poll: can't wake_up > >> Sun, Dec 30, 2018, 6:17 PM (4 days ago) >> to linux-kernel >> Hello, I encountered a "can't wake_up" problem when use camera on imx6. >> >> if delay some time after 'streamon' the /dev/video0, then add fd >> through epoll_ctl, then the process can't be waken_up after some time. >> >> I checked both the epoll / vb2_poll(videobuf2_core.c) code. >> >> epoll will pass 'poll_table' structure to vb2_poll, but it only >> contain valid function pointer when inserting fd. >> >> in vb2_poll, if found new data in done list, it will not call 'poll_wait'. >> after that, every call to vb2_poll will not contain valid poll_table, >> which will result in all calling to poll_wait will not work. >> >> so if app can process frames quickly, and found frame data when >> inserting fd (i.e. poll_wait will not be called or not contain valid >> function pointer), it will not found valid frame in 'vb2_poll' finally >> at some time, then call 'poll_wait' to expect be waken up at following >> vb2_buffer_done, but no good luck. >> >> I also checked the 'videobuf-core.c', there is no this problem. >> >> of course, both epoll and vb2_poll are right by itself side, but the >> result is we can't get new frames. >> >> I think by epoll's implementation, the user should always call poll_wait. >> >> and it's better to split the two actions: 'wait' and 'poll' both for >> epoll framework and all epoll users, for example, v4l2. >> >> am I right? > > On Thu, Jan 3, 2019 at 4:17 AM Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: >> >> On Thu, 2018-11-08 at 14:03 +0200, Sakari Ailus wrote: >>> [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ] >>> >>> Patch ad608fbcf166 changed how events were subscribed to address an issue >>> elsewhere. As a side effect of that change, the "add" callback was called >>> before the event subscription was added to the list of subscribed events, >>> causing the first event queued by the add callback (and possibly other >>> events arriving soon afterwards) to be lost. >>> >>> Fix this by adding the subscription to the list before calling the "add" >>> callback, and clean up afterwards if that fails. >> [...] >> >> I've queued this up for the next update, thanks. >> >> Ben. >> >> -- >> Ben Hutchings >> Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer >> >>
