On Mon, Aug 15, 2022 at 03:43:48PM +0900, Sergey Senozhatsky wrote: > On (22/08/15 08:36), Greg KH wrote: > > On Mon, Aug 15, 2022 at 11:06:39AM +0900, Sergey Senozhatsky wrote: > > > On (22/08/11 17:30), Greg KH wrote: > > > > On Thu, Aug 11, 2022 at 06:08:55PM +0300, Laurent Pinchart wrote: > > > > > On Thu, Aug 11, 2022 at 05:02:40PM +0200, Greg KH wrote: > > > > > > On Thu, Aug 11, 2022 at 04:54:53PM +0300, Laurent Pinchart wrote: > > > > > > > For the time being, I agree with your recommendation to not buy these > > > > > > > devices if you care about camera support. > > > > > > > > > > > > I second this, don't buy these devices if the vendor is not willing to > > > > > > get their drivers upstreamed properly. > > > > > > > > > > "Not willing" may be a bit too harsh here. I wouldn't just blame Intel > > > > > for not upstreaming a driver if it turns out that the V4L2 API isn't a > > > > > good match and we have no proposal to provide an alternative. > > > > > > > > Did they propose an alternative? From what I saw here they didn't even > > > > attempt it, or did I miss that? > > > > > > The plan here is to land CAM kernel API first and then switch IPU > > > (driver and user-space) to it so that upstreaming for Intel will > > > be easier. > > > > And what is the timeframe on the plan? Where will these changes be sent > > to for review? I'm guessing they are already in a shipping device so > > what's the delay? > > We haven't sent out KCAM for upstream review yet. It's open sourced, > as of this moment [1], but we still need some time and wanted to convert > one of the previous generations of IPU drivers (IPU3) to KCAM first to > see if everything is working as we wanted it to. That didn't answer my question on when you were planning to actually submit this :) thanks, greg k-h
