Hi Patrik,
On Sun, Apr 26, 2020 at 09:44:30AM +0200, Patrik Gfeller wrote:
> Hi Sakari,
>
> I hope you are well!
>
> We are currently evaluation (mainly Mauro and Laurent) if it is possible
> to continue the work on the atomisp driver. I try to do some tests to
> see if the driver works at all using the patches Mauro made. As the
> firmware is hardcoded I need specific firmware versions. In an earlier
> post related to atomisp you mentioned that you use the following firmware:
>
> shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150423_1753
>
> I only found the following versions
>
> shisp_2400b0_v21.bin
> Version string: irci_master_20140707_0622
>
> shisp_2401a0_v21.bin
> Version string: irci_master_20140707_0622
>
> I tried to change the hardcoded string in the code to the version I have
> available, but not sure if it loaded the firmware at all. I saw that
> there are debug lines to provide more verbose information, but I could
> not figure out how to enable those messages:
>
> atomisp_fops.c
> isp->firmware = atomisp_load_firmware(isp);
> if (!isp->firmware) {
> dev_err(isp->dev, "Failed to load ISP firmware.\n");
> ret = -ENOENT;
> goto error;
> }
> ret = atomisp_css_load_firmware(isp);
> if (ret) {
> dev_err(isp->dev, "Failed to init css.\n");
> goto error;
> }
>
> If you could provide me the correct firmware file would be highly
> appreciated. Maybe you even remember how to enable the more verbose logging?
What verbose logging are you talking about ? If you're referring to
dev_dbg(), Documentation/admin-guide/dynamic-debug-howto.rst if your
kernel is compiled with dynamic debug support, otherwise just
#define DEBUG 1
at the top of the file.
> On 25.04.20 04:39, Laurent Pinchart wrote:
> > On Sat, Apr 18, 2020 at 04:39:25PM +0200, Patrik Gfeller wrote:
> >> Hello Mauro et al,
> >>
> >> I've recently switched to Linux, and I'm very impressed. Almost
> >> everything thing works out of the box. Only the webcam on my device does
> >> not. I did some digging and if I'm right an atomisp driver would be
> >> required. Is this correct? Below the output of lspci:
> >>
> >> 00:00.0 Host bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register (rev 36)
> >> 00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (rev 36)
> >> 00:03.0 Multimedia controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit (rev 36)
> >> 00:0a.0 Non-VGA unclassified device: Intel Corporation Device 22d8 (rev 36)
> >> 00:0b.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller (rev 36)
> >> 00:14.0 USB controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller (rev 36)
> >> 00:1a.0 Encryption controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine (rev 36)
> >> 00:1c.0 PCI bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 (rev 36)
> >> 00:1f.0 ISA bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU (rev 36)
> >> 01:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)
> >>
> >> According to the history it looks like the driver was removed from the
> >> kernel in 2018 and replaced with a dummy driver (to make sure power save
> >> works).
> >>
> >> Is there a chance that the atomisp driver will return to the kernel?
> > As much as I'd like to say yes, I think this is unfortunately very
> > unlikely. There are a few obstacles to getting a working camera with
> > atomisp:
> >
> > - According to some reports, the driver doesn't work. That's the first
> > thing that would need to be fixed, and without hardware documentation
> > and support from Intel, that would be a difficult (to say the least)
> > task.
> >
> > - Assuming we could fix the driver, we would need to make sure it
> > supports your device. If the atomisp is anything like the IPU3 (a more
> > recent ISP from Intel), there are two different and incompatible sets
> > of ACPI data formats related to the device, one developed for Windows,
> > and one developed for Linux. I expect the atomisp driver to support
> > the latter but not the former. If your device was shipped with
> > Windows, it uses the Windows-specific ACPI data format. Furthermore,
> > it would in that case likely not encode all the information we would
> > need in ACPI, as Windows drivers have the bad habit of hardcoding
> > device-specific data in drivers. At the very least we would need to
> > get the atomisp to support the Windows ACPI data format (which is most
> > likely completely undocumented), and we would need to figure out how
> > to retrieve data that are simply not there. This being said, maybe the
> > atomisp ACPI design was better than the IPU3 and all (or part of)
> > those issues don't exist, but I'd be surprised.
> >
> > - At this point you would (hopefully) have a driver that could capture
> > RAW images. In order to use the camera as a webcam, those images would
> > need to be processed by the ISP that is part of the atomisp. This
> > requires complex image processing algorithm control code in userspace.
> > Intel has not released any open version of such code for the atomisp
> > (or any other platform) to my knowledge, so this would need to be
> > implemented from scratch. The libcamera project could help there, as
> > it provides a framework to host such code, but the atomisp-specific
> > code would still need to be implemented. This is a complex task when
> > the hardware is fully documented, without hardware documentation and
> > thus without knowing how the hardware works, it gets extremely
> > difficult. The task would be orders of magnitude more complex than
> > reverse-engineering a GPU.
> >
> > - Finally, in order for the driver to be merged back in the upstream
> > kernel, it would require massive cleanups, but that's the simplest
> > task of all that is required here.
> >
> > I'm sorry for the bad news, we need to be more vocal blaming hardware
> > vendors for this type of mess.
> >
> >> There are quite a few older tablets and 2in1 devices that would benefit.
> >> Unfortunately I do not understand the removed code (my coding skills are
> >> very basic) and can thus not help to change what ever is necessary to
> >> make it fit for the kernel :-( (does not sound like a beginner project).
> >> However - I would be glad to help out to help testing an ISP driver.
> >>
> >> However - even without the cam it is a very impressing operating system
> >> which I enjoy very much. I would like to thank all of you for your work
> >> that benefits so many people!
> > You're welcome. Your thanks are much appreciated :-)
--
Regards,
Laurent Pinchart
