On Thu, May 20, 2021 at 03:31:34PM +0200, Johan Hovold wrote: > On Mon, May 17, 2021 at 11:35:22AM +0100, Sean Young wrote: > > On Mon, May 17, 2021 at 11:30:39AM +0200, Johan Hovold wrote: > > > On Sat, May 15, 2021 at 10:22:26AM +0100, Sean Young wrote: > > > > The other nice thing is that IR TX feeds data from an urb interrupt handler, > > > > so you don't need to rely userspace being scheduled quickly enough to feed > > > > more data before the device runs out. > > > > > > The tty layer and tty drivers provide write buffering so that need not > > > be an issue. > > > > Ok. I don't know what the size of the write buffer is or what the maximum > > TX size is; the IR device supports infinite streaming. > > Our tty drivers typically have at least a 4k buffer for transmission. > Surely that should be enough for a remote control but perhaps there are > other more demanding applications? That's more than enough. The most demanding consumer IR I know of, is an air conditioner which encodes temperature and a few others things. That's a maximum of 439 pulse/spaces which should into 1k. > > > > Thanks for that pointer. Judging from a quick look, the new driver > > > appears to based on this one. By abstracting the serial interface bits > > > in a generic RC serdev/ldisc driver you may be able reuse more code, > > > even if I'm not in a position to judge how much of the IR protocol bits > > > that can be shared. > > > > Yes, I agree. Once hotplugging is in place. If you have patches for that, > > please CC me and I can see if will work for IR drivers. > > Let's hope someone steps up to fund that work then. I'm just a volunteer. I've literally never heard anything about kernel work being funded by anyone. Would you mind giving a brief summary what is needed to implement hotplugging for serdev? I get the impression it's not a lot of work, but I'm probably missing something obvious. Sean
