Re: atomisp kernel driver(s)

[Patrik Gfeller <patrik.gfeller@gmail.com>]

On Sat, 2 May 2020 19:08:36 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

Hi Andy,

> On Sat, Apr 18, 2020 at 5:42 PM Patrik Gfeller <patrik.gfeller@gmail.com> 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?
> > 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!  
> 
> I follow your attempts to enable that driver (I, myself, spent a lot
> of time to an attempt of getting this driver in a shape). However, I
> guess you started from a wrong side. Even with access to internal tree
> for Android firmware we didn't manage to find a proper one to whatever
> has been published in drivers/staging. So, to get it done, one should
> first to find a *working* Android for the certain device. Without that
> it will be a journey of wasted time and big disappointment.

Thank you for your advice, I've tried various Android distros for x86 on
my device. Unfortunately none of the boots. I'll investigate if I can
make one of them to work. I also found that a predecessor of the driver
seemed to have worked for E3800. At lease there is a users guide from intel
(for Fedora 18):

https://cdrdv2.intel.com/v1/dl/getcontent/331329

Unfortunately this targets the 2400, and I have 2401 rev B chip. However -
I'll give Fedora 18 a try, but if the HW detection works as in the
current driver it will not accept my device.

> 
> My achievements end with no getting IRQ from the driver (and I was
> experimenting on MRD-7 CRB).

I could not find information about MRD-7 CRB HW. Do you still have this
HW? Fedora 18 might be worth a try if it uses a 2400 chip.

> P.S. I also have some (semi-) debug patches I can share. Perhaps they
> will give some more ideas. Btw, based on this discussion I think that
> it can be power issues with sensors that possible affect IRQ
> generation inside SiliconHive vector processor. In IPU3 the dedicated
> PMIC is used for camera devices, and I have no idea of the design for
> old ones.
> 

with kind regards,
Patrik