lkml.org 
[lkml]   [2020]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRessurect the atomisp staging driver - current progress
Hi,

I've been trying to ressurrect the driver for the Atom camera hardware,
for systems based on ISP2401, e. g. the ones with this ISP:

00:03.0 Multimedia controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: atomisp_css2401a0_v21

00:0a.0 Non-VGA unclassified device: Intel Corporation Device 22d8 (rev 36)
Subsystem: ASUSTeK Computer Inc. Device 13a0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 20
Region 0: Memory at 91a3a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: intel_ish_ipc
Kernel modules: intel_ish_ipc

Right now, the patches are on this branch:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2.1

This is based on a previous attempt of upstreaming it to staging,
started by Alan Cox. This was removed back in 2018. I fixed it
to work with Kernel 5.7 and solved several issues that were preventing
it from powering the cameras. This version should support earlier
versions (ISP2400-based), by selecting an option compile-time.

The initial goal is to have a working version. One of the problems with
this device is that firmware and drivers are very closely linked.
As I was unable to find the versions used on Alan's port, I also
made an alternate version, using a driver from the Yocto Aero tree
ported to Kernel 5.7-rc2, re-using the work we've done so far at the
original port for it to work with the current Kernel kAPI.

For such second version, I used the Kernel sources found on this
repository:

https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/

Such port is at the atomisp_yocto_v1:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_yocto_v1

(there's a variant of it at https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp-with-yocto-patchset,
with would preserve the history of atomisp changes from Yocto's tree)

The firmware used on such version is at:
https://download.01.org/aero/deb/pool/main/f/firmware-atomisp/firmware-atomisp_0.1.orig.tar.xz

If the ISP revision is equal or bigger than rev 02, this file should be
renamed to:

shisp_2401b0_v21.bin

The goal of the alternate fork is just to use a driver code base that
it is known to work in the past and has a firmware that it is still
available. It should be noticed that the alternate version is for
ISP2401 only (PCI ID 8086:22d8). It would probe on other versions, but
it probably won't work.

As I don't have the Intel Aero controller card (nor the camera, with
comes with the drone hardware), I'm doing my tests on an Asus T101HA.

Before getting excited, both versions failed at the tests I've been
doing so far.

The camera sensor detection is working fine and it is able to power
the camera off/on (when driver loads, it makes the camera usage led
indicator to quickly flash):

ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680
ov2680 i2c-OVTI2680:00: gmin: power management provided via Dollar Cove TI PMIC (i2c addr 0x5e)
ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CamClk'
ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_ClkSrc'
ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CsiPort'
ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CsiLanes'
ov2680 i2c-OVTI2680:00: Found DMI entry for 'gmin_V1P8GPIO'
ov2680 i2c-OVTI2680:00: Found DMI entry for 'gmin_V2P8GPIO'
ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1

However, the ISP code still have issues that seem to be firmware-related.

At the first version, testing with either the original firmware from
Windows or the version from Intel Aero causes a warning when the
devnode is opened:

atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIEWFINDER output
sh_css_hrt_system_is_idle() 44: warning: SP not idle
sh_css_hrt_system_is_idle() 49: warning: ISP not idle
atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIDEO output
sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff

It sounds that the firmware was properly loaded there, but somehow,
it is not answering as expected.

The second version produces this error:

atomisp: Loaded firmware version 'irci_stable_candrpv_0415_20150521_0458'.
atomisp-isp2 0000:00:03.0: css load fw failed.
atomisp-isp2 0000:00:03.0: Failed to init css.

I didn't try to check why it is failing yet - maybe it is just
something related to the port itself.

If someone has access to the Intel Aero board, I'd appreciate if you
could test it and send the results. If it fails too, it would be
nice to have the dmesg output of this version and the dmesg from
a version which works.

It would also be good to have a second pair of eyes on it.

Thanks,
Mauro

\
 
 \ /
  Last update: 2020-05-15 11:38    [W:0.081 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site