Ok, thanks a lot. On Thu, Jan 3, 2019 at 6:15 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > 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 > >> > >> >
