Hi, On 5/19/20 7:36 PM, Mauro Carvalho Chehab wrote: <snip>
I did a lot of progress today. After identified the above bug, which was turning down the ISP device, causing the firmware load to fail (as the turn on code is not OK), I solved several other issues there. The current status is that: - the ISP firmware is properly loading; - it can properly communicate with the camera sensor; - Userspace can read video controls (tested with v4l2-ctl and qv4l2); - set a video format is now working; - buffers are being queued, and per-frame IRQs are arriving. I did a really quick test today of trying to get a video from it, using a simple tool I developed for such kind of tests (v4l2grab from v4l-utils package, changed to work with the only format that my camera sensor supports). This tool needs uses a bare minimum set of ioctls, with would avoid hitting a bug somewhere else. Running it makes the device to start receiving frames from the hardware. Yet, there's something wrong at the part with stores the data into the video frame buffers. This driver has a weird mm/DMA code, based on a fork of get_user_pages() taken probably during Kernel 3.10 old days. Addressing it has a high chance of grabbing some image from it. Ok, driver is at staging quality: there are lots of crap there that will require changes, but it seems we're getting there.
This is very good news. Hopefully you will get an actual image out of these soon. That would be awesome. I happened to notice an advert for a second-hand Asus T101HA locally, for not too much money. So now I'm the happy owner of an Asus T101HA myself. So once you have something working I can try to reproduce your work on identical hardware then as time permits help with cleaning things up. Although I might focus at first on trying to get your work to run on more Cherry Trail based models, to find out what bits we need to make configurable and if we can get the info from ACPI or if we need to have a DMI based table with model specific info. Regards, Hans
