atomisp kernel driver(s)

atomisp kernel driver(s)

[Patrik Gfeller]

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!

All the best and stay healthy.

With kind regards,

Patrik Gfeller <patrik.gfeller@gmail.com>

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 18 Apr 2020 16:39:25 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> 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.

There are simply too many things there to be fixed, and nobody without
time for it. Also, the last reports we had is that the driver was not
working.

Unfortunately, I don't have myself any atomisp hardware, otherwise I
could try fixing it on my spare time.

> 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!
> 
> All the best and stay healthy.
> 
> With kind regards,
> 
> Patrik Gfeller <patrik.gfeller@gmail.com>
> 



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 18 Apr 2020 17:25:49 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Sat, 18 Apr 2020 16:39:25 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
> > 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.
> 
> There are simply too many things there to be fixed, and nobody without
> time for it. Also, the last reports we had is that the driver was not
> working.
> 
> Unfortunately, I don't have myself any atomisp hardware, otherwise I
> could try fixing it on my spare time.

In time: not really sure if it would be a worth project, as newer Intel
hardware are coming with a different IP block (IPU3).

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 18.04.20 17:26, Mauro Carvalho Chehab wrote:
> Em Sat, 18 Apr 2020 17:25:49 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>
>> Em Sat, 18 Apr 2020 16:39:25 +0200
>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>
>>> 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.
>> There are simply too many things there to be fixed, and nobody without
>> time for it. Also, the last reports we had is that the driver was not
>> working.
>>
>> Unfortunately, I don't have myself any atomisp hardware, otherwise I
>> could try fixing it on my spare time.
> In time: not really sure if it would be a worth project, as newer Intel
> hardware are coming with a different IP block (IPU3).

I don't know how widespread the IPU that I have is, I assume that some 
other tablets & 2in1 devices that are a few years old use it as well. 
For me it would be definitely nice to have this driver. However, I can 
ask around in some of the forums  if there is a wider interest. Might be 
a niche tough, but the support for the Atom device I use have been 
greatly improved in the recent years. So there is at least some work 
going on for that platform (I do not know, but I think it is called 
cherry trail?). As there are many older reports of problems with audio, 
touchscreen, stability (freezes) ... and none of them are present anymore.

As mentioned, if the development is hindered by missing hardware I would 
be glad to help. Anyhow - many thanks for your replies, much appreciated!

>
> Thanks,
> Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 18 Apr 2020 17:37:22 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 18.04.20 17:26, Mauro Carvalho Chehab wrote:
> > Em Sat, 18 Apr 2020 17:25:49 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> >  
> >> Em Sat, 18 Apr 2020 16:39:25 +0200
> >> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>  
> >>> 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)

What hardware do you have?

I did a look at the atomisp driver. There are some APIs that changed upstream,
but making the driver to build again is not hard:

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

If this would work or just hang, I don't know :-)

This driver is still a big mess, and it requires some defines on its source
code, in order to use it with some different Atom models.

> >>>
> >>> 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.  
> >> There are simply too many things there to be fixed, and nobody without
> >> time for it. Also, the last reports we had is that the driver was not
> >> working.
> >>
> >> Unfortunately, I don't have myself any atomisp hardware, otherwise I
> >> could try fixing it on my spare time.  
> > In time: not really sure if it would be a worth project, as newer Intel
> > hardware are coming with a different IP block (IPU3).  
> 
> I don't know how widespread the IPU that I have is, I assume that some 
> other tablets & 2in1 devices that are a few years old use it as well. 

The IPU is used on some Dell 2in1 devices(I guess they use an i5core 
with a chipset made for mobile market). Not sure if they're using IPU3
also on Atom.

> For me it would be definitely nice to have this driver. However, I can 
> ask around in some of the forums  if there is a wider interest. Might be 
> a niche tough, but the support for the Atom device I use have been 
> greatly improved in the recent years. So there is at least some work 
> going on for that platform (I do not know, but I think it is called 
> cherry trail?). As there are many older reports of problems with audio, 
> touchscreen, stability (freezes) ... and none of them are present anymore.
> 
> As mentioned, if the development is hindered by missing hardware I would 
> be glad to help. Anyhow - many thanks for your replies, much appreciated!
> 
> >
> > Thanks,
> > Mauro  



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 20.04.20 01:31, Mauro Carvalho Chehab wrote:
> Em Sat, 18 Apr 2020 17:37:22 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> On 18.04.20 17:26, Mauro Carvalho Chehab wrote:
>>> Em Sat, 18 Apr 2020 17:25:49 +0200
>>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>>>   
>>>> Em Sat, 18 Apr 2020 16:39:25 +0200
>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>   
>>>>> 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)
> What hardware do you have?
I have aASUS Transformer Book T101HA-GR029T (HW probe @

https://linux-hardware.org/?probe=ccc26d4cd3).

> I did a look at the atomisp driver. There are some APIs that changed upstream,
> but making the driver to build again is not hard:
>
> 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp
>
> If this would work or just hang, I don't know :-)

Cool!

Meanwhile I downloaded to kernel source and checked out the latest 
commit that still has the driver in staging. I'm currently in the 
process of building the old kernel in order to test if the driver works 
at all (1st time I'm doing this - thus takes some time, especially on my 
Atom :-). But I will then switch over to your changed version to give it 
a try.

>
> This driver is still a big mess, and it requires some defines on its source
> code, in order to use it with some different Atom models.
>
>>>>> 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.
>>>> There are simply too many things there to be fixed, and nobody without
>>>> time for it. Also, the last reports we had is that the driver was not
>>>> working.
>>>>
>>>> Unfortunately, I don't have myself any atomisp hardware, otherwise I
>>>> could try fixing it on my spare time.
>>> In time: not really sure if it would be a worth project, as newer Intel
>>> hardware are coming with a different IP block (IPU3).
>> I don't know how widespread the IPU that I have is, I assume that some
>> other tablets & 2in1 devices that are a few years old use it as well.
> The IPU is used on some Dell 2in1 devices(I guess they use an i5core
> with a chipset made for mobile market). Not sure if they're using IPU3
> also on Atom.
>
>> For me it would be definitely nice to have this driver. However, I can
>> ask around in some of the forums  if there is a wider interest. Might be
>> a niche tough, but the support for the Atom device I use have been
>> greatly improved in the recent years. So there is at least some work
>> going on for that platform (I do not know, but I think it is called
>> cherry trail?). As there are many older reports of problems with audio,
>> touchscreen, stability (freezes) ... and none of them are present anymore.
>>
>> As mentioned, if the development is hindered by missing hardware I would
>> be glad to help. Anyhow - many thanks for your replies, much appreciated!
>>
>>> Thanks,
>>> Mauro
>
>
> Thanks,
> Mauro

thanks & kind regards,

Patrik

Re: atomisp kernel driver(s)

[Patrik Gfeller]

Me again ... sorry to ask such a basic question, but I can't get your 
modified source code. I get the following error:

 > git clone https://git.linuxtv.org/mchehab/experimental.git/
Cloning into 'experimental'...
warning: adding alternate object store: 
https://git.linuxtv.org/git/linux.git/
warning: adding alternate object store: 
https://git.linuxtv.org/git/media_tree.git/
warning: adding alternate object store: 
https://git.linuxtv.org/git/linux.git/
error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under 
https://git.linuxtv.org/mchehab/experimental.git
Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
error: fetch failed.

Do I use the wrong command?

kind regards,

Patrik

On 20.04.20 19:48, Patrik Gfeller wrote:
>
> On 20.04.20 01:31, Mauro Carvalho Chehab wrote:
>> Em Sat, 18 Apr 2020 17:37:22 +0200
>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>
>>> On 18.04.20 17:26, Mauro Carvalho Chehab wrote:
>>>> Em Sat, 18 Apr 2020 17:25:49 +0200
>>>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>>>>> Em Sat, 18 Apr 2020 16:39:25 +0200
>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>> 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)
>> What hardware do you have?
> I have aASUS Transformer Book T101HA-GR029T (HW probe @
>
> https://linux-hardware.org/?probe=ccc26d4cd3).
>
>> I did a look at the atomisp driver. There are some APIs that changed 
>> upstream,
>> but making the driver to build again is not hard:
>>
>>     https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp
>>
>> If this would work or just hang, I don't know :-)
>
> Cool!
>
> Meanwhile I downloaded to kernel source and checked out the latest 
> commit that still has the driver in staging. I'm currently in the 
> process of building the old kernel in order to test if the driver 
> works at all (1st time I'm doing this - thus takes some time, 
> especially on my Atom :-). But I will then switch over to your changed 
> version to give it a try.
>
>>
>> This driver is still a big mess, and it requires some defines on its 
>> source
>> code, in order to use it with some different Atom models.
>>
>>>>>> 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.
>>>>> There are simply too many things there to be fixed, and nobody 
>>>>> without
>>>>> time for it. Also, the last reports we had is that the driver was not
>>>>> working.
>>>>>
>>>>> Unfortunately, I don't have myself any atomisp hardware, otherwise I
>>>>> could try fixing it on my spare time.
>>>> In time: not really sure if it would be a worth project, as newer 
>>>> Intel
>>>> hardware are coming with a different IP block (IPU3).
>>> I don't know how widespread the IPU that I have is, I assume that some
>>> other tablets & 2in1 devices that are a few years old use it as well.
>> The IPU is used on some Dell 2in1 devices(I guess they use an i5core
>> with a chipset made for mobile market). Not sure if they're using IPU3
>> also on Atom.
>>
>>> For me it would be definitely nice to have this driver. However, I can
>>> ask around in some of the forums  if there is a wider interest. 
>>> Might be
>>> a niche tough, but the support for the Atom device I use have been
>>> greatly improved in the recent years. So there is at least some work
>>> going on for that platform (I do not know, but I think it is called
>>> cherry trail?). As there are many older reports of problems with audio,
>>> touchscreen, stability (freezes) ... and none of them are present 
>>> anymore.
>>>
>>> As mentioned, if the development is hindered by missing hardware I 
>>> would
>>> be glad to help. Anyhow - many thanks for your replies, much 
>>> appreciated!
>>>
>>>> Thanks,
>>>> Mauro
>>
>>
>> Thanks,
>> Mauro
>
> thanks & kind regards,
>
> Patrik
>

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Mon, 20 Apr 2020 20:27:25 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> Me again ... sorry to ask such a basic question, but I can't get your 
> modified source code. I get the following error:
> 
>  > git clone https://git.linuxtv.org/mchehab/experimental.git/  
> Cloning into 'experimental'...
> warning: adding alternate object store: 
> https://git.linuxtv.org/git/linux.git/
> warning: adding alternate object store: 
> https://git.linuxtv.org/git/media_tree.git/
> warning: adding alternate object store: 
> https://git.linuxtv.org/git/linux.git/
> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under 
> https://git.linuxtv.org/mchehab/experimental.git
> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
> error: fetch failed.
> 
> Do I use the wrong command?

Better to use git:// url:

	git clone git://git.linuxtv.org/mchehab/experimental.git/  


> 
> kind regards,
> 
> Patrik
> 
> On 20.04.20 19:48, Patrik Gfeller wrote:
> >
> > On 20.04.20 01:31, Mauro Carvalho Chehab wrote:  
> >> Em Sat, 18 Apr 2020 17:37:22 +0200
> >> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>  
> >>> On 18.04.20 17:26, Mauro Carvalho Chehab wrote:  
> >>>> Em Sat, 18 Apr 2020 17:25:49 +0200
> >>>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:  
> >>>>> Em Sat, 18 Apr 2020 16:39:25 +0200
> >>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:  
> >>>>>> 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)  
> >> What hardware do you have?  
> > I have aASUS Transformer Book T101HA-GR029T (HW probe @
> >
> > https://linux-hardware.org/?probe=ccc26d4cd3).
> >  
> >> I did a look at the atomisp driver. There are some APIs that changed 
> >> upstream,
> >> but making the driver to build again is not hard:
> >>
> >>     https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp
> >>
> >> If this would work or just hang, I don't know :-)  
> >
> > Cool!
> >
> > Meanwhile I downloaded to kernel source and checked out the latest 
> > commit that still has the driver in staging. I'm currently in the 
> > process of building the old kernel in order to test if the driver 
> > works at all (1st time I'm doing this - thus takes some time, 
> > especially on my Atom :-). But I will then switch over to your changed 
> > version to give it a try.
> >  
> >>
> >> This driver is still a big mess, and it requires some defines on its 
> >> source
> >> code, in order to use it with some different Atom models.
> >>  
> >>>>>> 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.  
> >>>>> There are simply too many things there to be fixed, and nobody 
> >>>>> without
> >>>>> time for it. Also, the last reports we had is that the driver was not
> >>>>> working.
> >>>>>
> >>>>> Unfortunately, I don't have myself any atomisp hardware, otherwise I
> >>>>> could try fixing it on my spare time.  
> >>>> In time: not really sure if it would be a worth project, as newer 
> >>>> Intel
> >>>> hardware are coming with a different IP block (IPU3).  
> >>> I don't know how widespread the IPU that I have is, I assume that some
> >>> other tablets & 2in1 devices that are a few years old use it as well.  
> >> The IPU is used on some Dell 2in1 devices(I guess they use an i5core
> >> with a chipset made for mobile market). Not sure if they're using IPU3
> >> also on Atom.
> >>  
> >>> For me it would be definitely nice to have this driver. However, I can
> >>> ask around in some of the forums  if there is a wider interest. 
> >>> Might be
> >>> a niche tough, but the support for the Atom device I use have been
> >>> greatly improved in the recent years. So there is at least some work
> >>> going on for that platform (I do not know, but I think it is called
> >>> cherry trail?). As there are many older reports of problems with audio,
> >>> touchscreen, stability (freezes) ... and none of them are present 
> >>> anymore.
> >>>
> >>> As mentioned, if the development is hindered by missing hardware I 
> >>> would
> >>> be glad to help. Anyhow - many thanks for your replies, much 
> >>> appreciated!
> >>>  
> >>>> Thanks,
> >>>> Mauro  
> >>
> >>
> >> Thanks,
> >> Mauro  
> >
> > thanks & kind regards,
> >
> > Patrik
> >  



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
> Em Mon, 20 Apr 2020 20:27:25 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> Me again ... sorry to ask such a basic question, but I can't get your
>> modified source code. I get the following error:
>>
>>   > git clone https://git.linuxtv.org/mchehab/experimental.git/
>> Cloning into 'experimental'...
>> warning: adding alternate object store:
>> https://git.linuxtv.org/git/linux.git/
>> warning: adding alternate object store:
>> https://git.linuxtv.org/git/media_tree.git/
>> warning: adding alternate object store:
>> https://git.linuxtv.org/git/linux.git/
>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>> https://git.linuxtv.org/mchehab/experimental.git
>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>> error: fetch failed.
>>
>> Do I use the wrong command?
> Better to use git:// url:
>
> 	git clone git://git.linuxtv.org/mchehab/experimental.git/

I was able to download and compile the code. I installed the kernel and 
tried to boot; unfortunately it hangs with the message "Loading initial 
ramdisk ..." - after I start the old kernel I check kern.log and syslog 
- but I do not see entries from the failed boot attempt. I'll read into 
the topic and try around. This will take some time ... so there will be 
a dealy, but it's not that I do not care or lacking  interest, I just 
first have to sort this out.

>
>> kind regards,
>>
>> Patrik
>>
>> On 20.04.20 19:48, Patrik Gfeller wrote:
>>> On 20.04.20 01:31, Mauro Carvalho Chehab wrote:
>>>> Em Sat, 18 Apr 2020 17:37:22 +0200
>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>   
>>>>> On 18.04.20 17:26, Mauro Carvalho Chehab wrote:
>>>>>> Em Sat, 18 Apr 2020 17:25:49 +0200
>>>>>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>>>>>>> Em Sat, 18 Apr 2020 16:39:25 +0200
>>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>>>> 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)
>>>> What hardware do you have?
>>> I have aASUS Transformer Book T101HA-GR029T (HW probe @
>>>
>>> https://linux-hardware.org/?probe=ccc26d4cd3).
>>>   
>>>> I did a look at the atomisp driver. There are some APIs that changed
>>>> upstream,
>>>> but making the driver to build again is not hard:
>>>>
>>>>      https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp
>>>>
>>>> If this would work or just hang, I don't know :-)
>>> Cool!
>>>
>>> Meanwhile I downloaded to kernel source and checked out the latest
>>> commit that still has the driver in staging. I'm currently in the
>>> process of building the old kernel in order to test if the driver
>>> works at all (1st time I'm doing this - thus takes some time,
>>> especially on my Atom :-). But I will then switch over to your changed
>>> version to give it a try.
>>>   
>>>> This driver is still a big mess, and it requires some defines on its
>>>> source
>>>> code, in order to use it with some different Atom models.
>>>>   
>>>>>>>> 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.
>>>>>>> There are simply too many things there to be fixed, and nobody
>>>>>>> without
>>>>>>> time for it. Also, the last reports we had is that the driver was not
>>>>>>> working.
>>>>>>>
>>>>>>> Unfortunately, I don't have myself any atomisp hardware, otherwise I
>>>>>>> could try fixing it on my spare time.
>>>>>> In time: not really sure if it would be a worth project, as newer
>>>>>> Intel
>>>>>> hardware are coming with a different IP block (IPU3).
>>>>> I don't know how widespread the IPU that I have is, I assume that some
>>>>> other tablets & 2in1 devices that are a few years old use it as well.
>>>> The IPU is used on some Dell 2in1 devices(I guess they use an i5core
>>>> with a chipset made for mobile market). Not sure if they're using IPU3
>>>> also on Atom.
>>>>   
>>>>> For me it would be definitely nice to have this driver. However, I can
>>>>> ask around in some of the forums  if there is a wider interest.
>>>>> Might be
>>>>> a niche tough, but the support for the Atom device I use have been
>>>>> greatly improved in the recent years. So there is at least some work
>>>>> going on for that platform (I do not know, but I think it is called
>>>>> cherry trail?). As there are many older reports of problems with audio,
>>>>> touchscreen, stability (freezes) ... and none of them are present
>>>>> anymore.
>>>>>
>>>>> As mentioned, if the development is hindered by missing hardware I
>>>>> would
>>>>> be glad to help. Anyhow - many thanks for your replies, much
>>>>> appreciated!
>>>>>   
>>>>>> Thanks,
>>>>>> Mauro
>>>>
>>>> Thanks,
>>>> Mauro
>>> thanks & kind regards,
>>>
>>> Patrik
>>>   
>
>
> Thanks,
> Mauro

kind regards,

Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Wed, 22 Apr 2020 19:56:56 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
> > Em Mon, 20 Apr 2020 20:27:25 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >  
> >> Me again ... sorry to ask such a basic question, but I can't get your
> >> modified source code. I get the following error:
> >>  
> >>   > git clone https://git.linuxtv.org/mchehab/experimental.git/  
> >> Cloning into 'experimental'...
> >> warning: adding alternate object store:
> >> https://git.linuxtv.org/git/linux.git/
> >> warning: adding alternate object store:
> >> https://git.linuxtv.org/git/media_tree.git/
> >> warning: adding alternate object store:
> >> https://git.linuxtv.org/git/linux.git/
> >> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
> >> https://git.linuxtv.org/mchehab/experimental.git
> >> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
> >> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
> >> error: fetch failed.
> >>
> >> Do I use the wrong command?  
> > Better to use git:// url:
> >
> > 	git clone git://git.linuxtv.org/mchehab/experimental.git/  
> 
> I was able to download and compile the code. I installed the kernel and 
> tried to boot; unfortunately it hangs with the message "Loading initial 
> ramdisk ..." - after I start the old kernel I check kern.log and syslog 
> - but I do not see entries from the failed boot attempt. I'll read into 
> the topic and try around. This will take some time ... so there will be 
> a dealy, but it's not that I do not care or lacking  interest, I just 
> first have to sort this out.

Well, try to build it first without the atomisp driver. This would allow
you to see what's going on. 

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
> Em Wed, 22 Apr 2020 19:56:56 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>   
>>>> Me again ... sorry to ask such a basic question, but I can't get your
>>>> modified source code. I get the following error:
>>>>   
>>>>    > git clone https://git.linuxtv.org/mchehab/experimental.git/
>>>> Cloning into 'experimental'...
>>>> warning: adding alternate object store:
>>>> https://git.linuxtv.org/git/linux.git/
>>>> warning: adding alternate object store:
>>>> https://git.linuxtv.org/git/media_tree.git/
>>>> warning: adding alternate object store:
>>>> https://git.linuxtv.org/git/linux.git/
>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>> error: fetch failed.
>>>>
>>>> Do I use the wrong command?
>>> Better to use git:// url:
>>>
>>> 	git clone git://git.linuxtv.org/mchehab/experimental.git/
>> I was able to download and compile the code. I installed the kernel and
>> tried to boot; unfortunately it hangs with the message "Loading initial
>> ramdisk ..." - after I start the old kernel I check kern.log and syslog
>> - but I do not see entries from the failed boot attempt. I'll read into
>> the topic and try around. This will take some time ... so there will be
>> a dealy, but it's not that I do not care or lacking  interest, I just
>> first have to sort this out.
> Well, try to build it first without the atomisp driver. This would allow
> you to see what's going on.

I was able to solve the problem I had with the ramdisk - I had to strip 
the kernel modules, probably the ramdisk file was too big.

It is possible to boot with the atomisp driver, but I can not see the 
camera yet - but maybe that's due to missing firmware, as there were 
warnings when I installed the kernel that firmware files are missing.

The following I found in dmesg:

[    9.331011] kernel: atomisp_ov2680: module is from the staging 
directory, the quality is unknown, you have been warned.
[    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
atomisp module subdev data.PMIC ID 1
[    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable 
OVTI2680:00_CamClk
[    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable 
OVTI2680:00_ClkSrc
[    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable 
OVTI2680:00_CsiPort
[    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable 
OVTI2680:00_CsiLanes
[    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found, 
using dummy regulator
[    ...
[    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found, 
using dummy regulator
[    ...
[    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
using dummy regulator
[    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
using dummy regulator
[   ...'
[    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
lanes: 1 order: 00000002
[    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
0x2680, rev= 0
[    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
module type 1

The first signs of live :-) ... I'll try to find the firmware files to 
see if it makes a difference.

> Thanks,
> Mauro

kind regards,

Patrik

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 24.04.20 10:52, Patrik Gfeller wrote:
>
> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
>> Em Wed, 22 Apr 2020 19:56:56 +0200
>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>
>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>> Me again ... sorry to ask such a basic question, but I can't get your
>>>>> modified source code. I get the following error:
>>>>>      > git clone https://git.linuxtv.org/mchehab/experimental.git/
>>>>> Cloning into 'experimental'...
>>>>> warning: adding alternate object store:
>>>>> https://git.linuxtv.org/git/linux.git/
>>>>> warning: adding alternate object store:
>>>>> https://git.linuxtv.org/git/media_tree.git/
>>>>> warning: adding alternate object store:
>>>>> https://git.linuxtv.org/git/linux.git/
>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>>> error: fetch failed.
>>>>>
>>>>> Do I use the wrong command?
>>>> Better to use git:// url:
>>>>
>>>>     git clone git://git.linuxtv.org/mchehab/experimental.git/
>>> I was able to download and compile the code. I installed the kernel and
>>> tried to boot; unfortunately it hangs with the message "Loading initial
>>> ramdisk ..." - after I start the old kernel I check kern.log and syslog
>>> - but I do not see entries from the failed boot attempt. I'll read into
>>> the topic and try around. This will take some time ... so there will be
>>> a dealy, but it's not that I do not care or lacking  interest, I just
>>> first have to sort this out.
>> Well, try to build it first without the atomisp driver. This would allow
>> you to see what's going on.
>
> I was able to solve the problem I had with the ramdisk - I had to 
> strip the kernel modules, probably the ramdisk file was too big.
>
> It is possible to boot with the atomisp driver, but I can not see the 
> camera yet - but maybe that's due to missing firmware, as there were 
> warnings when I installed the kernel that firmware files are missing.
>
> The following I found in dmesg:
>
> [    9.331011] kernel: atomisp_ov2680: module is from the staging 
> directory, the quality is unknown, you have been warned.
> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
> atomisp module subdev data.PMIC ID 1
> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> OVTI2680:00_CamClk
> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> OVTI2680:00_ClkSrc
> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> OVTI2680:00_CsiPort
> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> OVTI2680:00_CsiLanes
> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not 
> found, using dummy regulator
> [    ...
> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not 
> found, using dummy regulator
> [    ...
> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
> using dummy regulator
> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not 
> found, using dummy regulator
> [   ...'
> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
> lanes: 1 order: 00000002
> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
> 0x2680, rev= 0
> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
> module type 1
>
> The first signs of live :-) ... I'll try to find the firmware files to 
> see if it makes a difference.

May be of interest as well:

$ i2cdetect -l
i2c-3    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-10    unknown       i915 gmbus dpc                      N/A
i2c-1    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-8    unknown       i915 gmbus vga                      N/A
i2c-6    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-13    unknown       AUX D/port D                        N/A
i2c-4    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-11    unknown       i915 gmbus dpb                      N/A
i2c-2    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-0    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-9    unknown       i915 gmbus panel                    N/A
i2c-7    unknown       i915 gmbus ssc                      N/A
i2c-5    unknown       Synopsys DesignWare I2C adapter     N/A
i2c-12    unknown       i915 gmbus dpd                      N/A

>
>> Thanks,
>> Mauro
>
> kind regards,
>
> Patrik
>

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 24.04.20 11:10, Patrik Gfeller wrote:
>
> On 24.04.20 10:52, Patrik Gfeller wrote:
>>
>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
>>> Em Wed, 22 Apr 2020 19:56:56 +0200
>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>
>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>> Me again ... sorry to ask such a basic question, but I can't get 
>>>>>> your
>>>>>> modified source code. I get the following error:
>>>>>>      > git clone https://git.linuxtv.org/mchehab/experimental.git/
>>>>>> Cloning into 'experimental'...
>>>>>> warning: adding alternate object store:
>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>> warning: adding alternate object store:
>>>>>> https://git.linuxtv.org/git/media_tree.git/
>>>>>> warning: adding alternate object store:
>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>>>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>>>> error: fetch failed.
>>>>>>
>>>>>> Do I use the wrong command?
>>>>> Better to use git:// url:
>>>>>
>>>>>     git clone git://git.linuxtv.org/mchehab/experimental.git/
>>>> I was able to download and compile the code. I installed the kernel 
>>>> and
>>>> tried to boot; unfortunately it hangs with the message "Loading 
>>>> initial
>>>> ramdisk ..." - after I start the old kernel I check kern.log and 
>>>> syslog
>>>> - but I do not see entries from the failed boot attempt. I'll read 
>>>> into
>>>> the topic and try around. This will take some time ... so there 
>>>> will be
>>>> a dealy, but it's not that I do not care or lacking interest, I just
>>>> first have to sort this out.
>>> Well, try to build it first without the atomisp driver. This would 
>>> allow
>>> you to see what's going on.
>>
>> I was able to solve the problem I had with the ramdisk - I had to 
>> strip the kernel modules, probably the ramdisk file was too big.
>>
>> It is possible to boot with the atomisp driver, but I can not see the 
>> camera yet - but maybe that's due to missing firmware, as there were 
>> warnings when I installed the kernel that firmware files are missing.
I've added the missing firmware files and now I do not have warnings 
when I create the ramdisk. Unfortunately it makes no difference - the 
device does not work yet (dmesg looks the same).
>>
>> The following I found in dmesg:
>>
>> [    9.331011] kernel: atomisp_ov2680: module is from the staging 
>> directory, the quality is unknown, you have been warned.
>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
>> atomisp module subdev data.PMIC ID 1
>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable 
>> OVTI2680:00_CamClk
>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable 
>> OVTI2680:00_ClkSrc
>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable 
>> OVTI2680:00_CsiPort
>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable 
>> OVTI2680:00_CsiLanes
>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not 
>> found, using dummy regulator
>> [    ...
>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not 
>> found, using dummy regulator
>> [    ...
>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not 
>> found, using dummy regulator
>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not 
>> found, using dummy regulator
>> [   ...'
>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
>> lanes: 1 order: 00000002
>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
>> 0x2680, rev= 0
>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
>> module type 1
>>
>> The first signs of live :-) ... I'll try to find the firmware files 
>> to see if it makes a difference.
>
> May be of interest as well:
>
> $ i2cdetect -l
> i2c-3    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-10    unknown       i915 gmbus dpc                      N/A
> i2c-1    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-8    unknown       i915 gmbus vga                      N/A
> i2c-6    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-13    unknown       AUX D/port D                        N/A
> i2c-4    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-11    unknown       i915 gmbus dpb                      N/A
> i2c-2    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-0    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-9    unknown       i915 gmbus panel                    N/A
> i2c-7    unknown       i915 gmbus ssc                      N/A
> i2c-5    unknown       Synopsys DesignWare I2C adapter     N/A
> i2c-12    unknown       i915 gmbus dpd                      N/A
>
>>
>>> Thanks,
>>> Mauro
>>
>> kind regards,
>>
>> Patrik
>>

Re: atomisp kernel driver(s)

[Patrik Gfeller]

[-- Attachment #1: Type: text/plain, Size: 11268 bytes --]


On 24.04.20 12:07, Patrik Gfeller wrote:
>
> On 24.04.20 11:10, Patrik Gfeller wrote:
>>
>> On 24.04.20 10:52, Patrik Gfeller wrote:
>>>
>>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
>>>> Em Wed, 22 Apr 2020 19:56:56 +0200
>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>
>>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>>> Me again ... sorry to ask such a basic question, but I can't get 
>>>>>>> your
>>>>>>> modified source code. I get the following error:
>>>>>>>      > git clone https://git.linuxtv.org/mchehab/experimental.git/
>>>>>>> Cloning into 'experimental'...
>>>>>>> warning: adding alternate object store:
>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>> warning: adding alternate object store:
>>>>>>> https://git.linuxtv.org/git/media_tree.git/
>>>>>>> warning: adding alternate object store:
>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f 
>>>>>>> under
>>>>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>>>>> Cannot obtain needed object 
>>>>>>> fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>>>>> error: fetch failed.
>>>>>>>
>>>>>>> Do I use the wrong command?
>>>>>> Better to use git:// url:
>>>>>>
>>>>>>     git clone git://git.linuxtv.org/mchehab/experimental.git/
>>>>> I was able to download and compile the code. I installed the 
>>>>> kernel and
>>>>> tried to boot; unfortunately it hangs with the message "Loading 
>>>>> initial
>>>>> ramdisk ..." - after I start the old kernel I check kern.log and 
>>>>> syslog
>>>>> - but I do not see entries from the failed boot attempt. I'll read 
>>>>> into
>>>>> the topic and try around. This will take some time ... so there 
>>>>> will be
>>>>> a dealy, but it's not that I do not care or lacking interest, I just
>>>>> first have to sort this out.
>>>> Well, try to build it first without the atomisp driver. This would 
>>>> allow
>>>> you to see what's going on.
>>>
>>> I was able to solve the problem I had with the ramdisk - I had to 
>>> strip the kernel modules, probably the ramdisk file was too big.
>>>
>>> It is possible to boot with the atomisp driver, but I can not see 
>>> the camera yet - but maybe that's due to missing firmware, as there 
>>> were warnings when I installed the kernel that firmware files are 
>>> missing.
> I've added the missing firmware files and now I do not have warnings 
> when I create the ramdisk. Unfortunately it makes no difference - the 
> device does not work yet (dmesg looks the same).
>>>
>>> The following I found in dmesg:
>>>
>>> [    9.331011] kernel: atomisp_ov2680: module is from the staging 
>>> directory, the quality is unknown, you have been warned.
>>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
>>> atomisp module subdev data.PMIC ID 1
>>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin 
>>> variable OVTI2680:00_CamClk
>>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin 
>>> variable OVTI2680:00_ClkSrc
>>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin 
>>> variable OVTI2680:00_CsiPort
>>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin 
>>> variable OVTI2680:00_CsiLanes

As this seems to be related to acpi here the section of the acpidump 
(full dump attached):

DSDT @ 0x0000000000000000
    ...
    19950: 00 14 0C 5F 50 53 33 00 70 00 43 4B 43 33 14 0C ..._PS3.p.CKC3..
    19960: 5F 50 53 30 00 70 01 43 4B 43 33 10 4F 4E 2F 03 _PS0.p.CKC3.ON/.
    19970: 5F 53 42 5F 50 43 49 30 49 32 43 33 14 24 4D 45 _SB_PCI0I2C3.$ME
    19980: 4D 42 01 5B 80 4D 52 47 4E 00 68 01 5B 81 0B 4D MB.[.MRGN.h.[..M
    19990: 52 47 4E 01 44 41 54 41 08 70 44 41 54 41 60 A4 RGN.DATA.pDATA`.
    199A0: 60 5B 84 33 43 4C 4B 34 00 00 00 14 0B 5F 53 54 `[.3CLK4....._ST
    199B0: 41 00 A4 43 4B 43 34 14 10 5F 4F 4E 5F 00 70 01 A..CKC4.._ON_.p.
    199C0: 43 4B 43 34 5B 22 0A 05 14 0D 5F 4F 46 46 00 70 CKC4["...._OFF.p
    199D0: 0A 02 43 4B 43 34 5B 82 43 48 43 41 4D 31 08 5F ..CKC4[.CHCAM1._
    199E0: 41 44 52 00 08 5F 48 49 44 0D 4F 56 54 49 32 36 ADR.._HID.OVTI26
    199F0: 38 30 00 08 5F 43 49 44 0D 4F 56 54 49 32 36 38 80.._CID.OVTI268
    19A00: 30 00 08 5F 53 55 42 0D 31 33 41 30 31 30 34 33 0.._SUB.13A01043
    19A10: 00 08 5F 44 44 4E 0D 4F 56 32 36 38 30 00 08 5F .._DDN.OV2680.._
    19A20: 55 49 44 01 08 5F 44 45 50 12 11 02 49 32 43 37 UID.._DEP...I2C7
    19A30: 5E 5E 2E 49 32 43 37 50 4D 49 32 08 5F 50 52 30 ^^.I2C7PMI2._PR0
    19A40: 12 0E 03 50 32 38 54 50 31 38 44 43 4C 4B 34 08 ...P28TP18DCLK4.
    19A50: 50 4C 44 42 12 1A 01 11 17 0A 14 82 00 00 00 00 PLDB............
    19A60: 00 00 00 61 0C 00 00 03 00 00 00 FF FF FF FF 14 ...a............
    19A70: 0B 5F 50 4C 44 08 A4 50 4C 44 42 14 09 5F 53 54 ._PLD..PLDB.._ST
    19A80: 41 00 A4 0A 0F 14 4C 05 5F 43 52 53 00 08 53 42 A.....L._CRS..SB
    19A90: 55 46 11 4A 04 0A 46 8C 20 00 01 01 01 00 02 00 UF.J..F. .......
    19AA0: 00 00 00 00 00 17 00 00 19 00 23 00 00 00 37 00 ..........#...7.
    19AB0: 5C 5F 53 42 2E 47 50 4F 31 00 8E 1E 00 01 00 01 \_SB.GPO1.......
    19AC0: 02 00 00 01 06 00 80 1A 06 00 36 00 5C 5F 53 42 ..........6.\_SB
    19AD0: 2E 50 43 49 30 2E 49 32 43 33 00 79 00 A4 53 42 .PCI0.I2C3.y..SB
    19AE0: 55 46 08 43 31 43 44 11 04 0B 20 02 14 4E 36 5F UF.C1CD... ..N6_
    19AF0: 44 53 4D 04 A0 4C 09 93 68 11 13 0A 10 4F 6C 2F DSM..L..h....Ol/
    19B00: DC 5B 04 1D 4F 97 B9 88 2A 68 60 A4 BE 70 12 4F .[..O...*h`..p.O
    19B10: 07 12 0D 43 61 6D 49 64 00 0D 6F 76 32 36 38 30 ...CamId..ov2680
    19B20: 00 0D 43 61 6D 54 79 70 65 00 0D 31 00 0D 43 73 ..CamType..1..Cs
    19B30: 69 50 6F 72 74 00 0D 30 00 0D 43 73 69 4C 61 6E iPort..0..CsiLan
    19B40: 65 73 00 0D 31 00 0D 43 73 69 46 6D 74 00 0D 31 es..1..CsiFmt..1
    19B50: 35 00 0D 43 73 69 42 61 79 65 72 00 0D 30 00 0D 5..CsiBayer..0..
    19B60: 43 61 6D 43 6C 6B 00 0D 31 00 0D 52 65 67 75 6C CamClk..1..Regul
    19B70: 61 74 6F 72 31 70 38 76 00 0D 30 00 0D 52 65 67 ator1p8v..0..Reg
    19B80: 75 6C 61 74 6F 72 32 70 38 76 00 0D 30 00 60 A4 ulator2p8v..0.`.
    19B90: 60 A0 22 93 68 11 13 0A 10 6A A7 7B 37 90 F3 FF `.".h....j.{7...
    19BA0: 4A AB 38 9B 1B F3 3A 30 15 A4 0D 4F 56 54 49 32 J.8...:0...OVTI2
    19BB0: 36 38 30 00 A0 20 93 68 11 13 0A 10 AA AA 62 3C  680.. .h......b<
    19BC0: E0 D8 1A 40 84 C3 FC 05 65 6F A2 8C A4 0D 4F 56 ...@....eo....OV
    19BD0: 32 36 38 30 00 A0 22 93 68 11 13 0A 10 8F CE 2A 2680..".h......*
    19BE0: 82 14 28 74 41 A5 6B 5F 02 9F E0 79 EE A4 0D 43 ..(tA.k_...y...C
    19BF0: 49 46 46 32 31 39 32 00 A0 49 05 93 68 11 13 0A IFF2192..I..h...
    19C00: 10 2A 51 59 29 8C 02 46 46 B7 3D 4D 1B 56 72 FA .*QY)..FF.=M.Vr.
    19C10: D8 A0 34 93 42 44 49 44 0A 04 A0 15 93 46 42 49 ..4.BDID.....FBI
    19C20: 44 0A 02 A4 0D 49 4E 54 45 4C 5F 46 46 52 44 00 D....INTEL_FFRD.
    19C30: A0 15 93 46 42 49 44 0A 03 A4 0D 49 4E 54 45 4C ...FBID....INTEL
    19C40: 5F 46 46 52 44 00 A4 0D 49 4E 54 45 4C 5F 52 56 _FFRD...INTEL_RV
    19C50: 50 00 A0 1B 93 68 11 13 0A 10 42 B2 8A 91 7C C3 P....h....B...|.
    19C60: 0A 45 9D 0F F4 7A B9 7C 3D EA A4 0B 01 01 A0 1B .E...z.|=.......
    19C70: 93 68 11 13 0A 10 D8 7B 3B EA 9B E0 39 42 AD 6E .h.....{;...9B.n
    19C80: ED 52 5F 3F 26 AB A4 0B 11 10 A0 19 93 68 11 13 .R_?&........h..

>>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not 
>>> found, using dummy regulator
>>> [    ...
>>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not 
>>> found, using dummy regulator
>>> [    ...
>>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not 
>>> found, using dummy regulator
>>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not 
>>> found, using dummy regulator
>>> [   ...'
>>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
>>> lanes: 1 order: 00000002
>>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
>>> 0x2680, rev= 0
>>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
>>> module type 1
>>>
>>> The first signs of live :-) ... I'll try to find the firmware files 
>>> to see if it makes a difference.

There was probably also a problem as I did not unload intel_atomisp2_pm. 
That is what lsmod reports now:

$ lsmod | grep atom
atomisp               790528  0
videobuf_vmalloc       16384  1 atomisp
videobuf_core          28672  2 atomisp,videobuf_vmalloc
punit_atom_debug       16384  0
snd_soc_sst_atom_hifi2_platform   110592  2 snd_intel_sst_core
snd_soc_core          253952  3 
snd_soc_sst_atom_hifi2_platform,snd_soc_rt5645,snd_soc_sst_cht_bsw_rt5645
snd_pcm               114688  7 
snd_compress,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_soc_rt5645,snd_soc_sst_cht_bsw_rt5645,snd_pcm_dmaengine
atomisp_ov2680         28672  0
videodev              237568  2 atomisp,atomisp_ov2680
snd                    94208  15 
snd_seq,snd_seq_device,snd_timer,snd_compress,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_pcm,snd_rawmidi
mc                     53248  3 atomisp,videodev,atomisp_ov2680

But it looks as there are no devices for atomisp, or ov2680:

pgfeller@ASUS:~$ ls -l /sys/dev/block | grep atom
pgfeller@ASUS:~$ ls -l /sys/dev/block | grep 2680
pgfeller@ASUS:~$ ls -l /sys/dev/char | grep atom
pgfeller@ASUS:~$ ls -l /sys/dev/char | grep 2680
pgfeller@ASUS:~$

>>
>> May be of interest as well:
>>
>> $ i2cdetect -l
>> i2c-3    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-10    unknown       i915 gmbus dpc                      N/A
>> i2c-1    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-8    unknown       i915 gmbus vga                      N/A
>> i2c-6    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-13    unknown       AUX D/port D                        N/A
>> i2c-4    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-11    unknown       i915 gmbus dpb                      N/A
>> i2c-2    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-0    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-9    unknown       i915 gmbus panel                    N/A
>> i2c-7    unknown       i915 gmbus ssc                      N/A
>> i2c-5    unknown       Synopsys DesignWare I2C adapter     N/A
>> i2c-12    unknown       i915 gmbus dpd                      N/A
>>
>>>
>>>> Thanks,
>>>> Mauro
>>>
>>> kind regards,
>>>
>>> Patrik
>>>
with kind regards,
Patrik

[-- Attachment #2: acpidump.txt.tar.gz --]
[-- Type: application/gzip, Size: 152589 bytes --]

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Hi Patrik,

Em Fri, 24 Apr 2020 12:07:30 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 24.04.20 11:10, Patrik Gfeller wrote:
> >
> > On 24.04.20 10:52, Patrik Gfeller wrote:  
> >>
> >> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:  
> >>> Em Wed, 22 Apr 2020 19:56:56 +0200
> >>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>>  
> >>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:  
> >>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
> >>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:  
> >>>>>> Me again ... sorry to ask such a basic question, but I can't get 
> >>>>>> your
> >>>>>> modified source code. I get the following error:
> >>>>>>      > git clone https://git.linuxtv.org/mchehab/experimental.git/
> >>>>>> Cloning into 'experimental'...
> >>>>>> warning: adding alternate object store:
> >>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>> warning: adding alternate object store:
> >>>>>> https://git.linuxtv.org/git/media_tree.git/
> >>>>>> warning: adding alternate object store:
> >>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
> >>>>>> https://git.linuxtv.org/mchehab/experimental.git
> >>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
> >>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
> >>>>>> error: fetch failed.
> >>>>>>
> >>>>>> Do I use the wrong command?  
> >>>>> Better to use git:// url:
> >>>>>
> >>>>>     git clone git://git.linuxtv.org/mchehab/experimental.git/  
> >>>> I was able to download and compile the code. I installed the kernel 
> >>>> and
> >>>> tried to boot; unfortunately it hangs with the message "Loading 
> >>>> initial
> >>>> ramdisk ..." - after I start the old kernel I check kern.log and 
> >>>> syslog
> >>>> - but I do not see entries from the failed boot attempt. I'll read 
> >>>> into
> >>>> the topic and try around. This will take some time ... so there 
> >>>> will be
> >>>> a dealy, but it's not that I do not care or lacking interest, I just
> >>>> first have to sort this out.  
> >>> Well, try to build it first without the atomisp driver. This would 
> >>> allow
> >>> you to see what's going on.  
> >>
> >> I was able to solve the problem I had with the ramdisk - I had to 
> >> strip the kernel modules, probably the ramdisk file was too big.
> >>
> >> It is possible to boot with the atomisp driver, but I can not see the 
> >> camera yet - but maybe that's due to missing firmware, as there were 
> >> warnings when I installed the kernel that firmware files are missing.  
> I've added the missing firmware files and now I do not have warnings 
> when I create the ramdisk. Unfortunately it makes no difference - the 
> device does not work yet (dmesg looks the same).
> >>
> >> The following I found in dmesg:
> >>
> >> [    9.331011] kernel: atomisp_ov2680: module is from the staging 
> >> directory, the quality is unknown, you have been warned.
> >> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
> >> atomisp module subdev data.PMIC ID 1
> >> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> >> OVTI2680:00_CamClk
> >> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> >> OVTI2680:00_ClkSrc
> >> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> >> OVTI2680:00_CsiPort
> >> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable 
> >> OVTI2680:00_CsiLanes
> >> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not 
> >> found, using dummy regulator
> >> [    ...
> >> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not 
> >> found, using dummy regulator
> >> [    ...
> >> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not 
> >> found, using dummy regulator
> >> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not 
> >> found, using dummy regulator
> >> [   ...'
> >> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> >> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
> >> lanes: 1 order: 00000002
> >> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
> >> 0x2680, rev= 0
> >> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
> >> module type 1
> >>
> >> The first signs of live :-) ... I'll try to find the firmware files 
> >> to see if it makes a difference.  

Atomisp driver uses ACPI to detect the camera configuration. As you
can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:

	static const struct acpi_device_id ov2680_acpi_match[] = {
	        {"XXOV2680"},
	        {"OVTI2680"},
	        {},
	};
	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);

The regulator data is parsed at
drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:

        if (pmic_id == PMIC_REGULATOR) {
                gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
                gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
                gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
                gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");

                /* Note: ideally we would initialize v[12]p8_on to the
                 * output of regulator_is_enabled(), but sadly that
                 * API is broken with the current drivers, returning
                 * "1" for a regulator that will then emit a
                 * "unbalanced disable" WARNing if we try to disable
                 * it.
                 */
        }

There are two things that could be the cause of this issue:

1) Some patch could have broken support for it.

Doing a:

	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c

will allow you to check the changes on this file.

2) Maybe recent BIOSes may have changed the names of the ACPI variables.

For instance, from the code, the driver should be seeking for those
variables for OV2680 (and several others that seem to be common among
multiple combinations):

	XXOV2680:00_CsiPort
	XXOV2680:00_CsiLanes
	XXOV2680:00_CamClk

It would be possible, that, on a modern BIOS, such vars were, for example,
renamed to 'XXOV2680_V2*'.

-

In any case, I guess the next step is to use some ACPI dump facility to check
how your BIOS is exporting camera-related data[1].

If the vars are the same, then there's a bug (condition 1) above. If
the vars are different, then some vars were added or renamed (condition 2).

With such information, you should be able to write a patch to
atomisp_gmin_platform.c adding support for the new way. Please notice that,
in the case of renames, the patch should keep support to the old way, as
otherwise support for other older hardware would break.

Using the file you sent, I decoded the DTST table and paste the relevant
parts for this camera, using:

	$ acpixtract /tmp/dmp/acpidump.txt 
	$ iasl -d dsdt.dat

Now, we need to compare what it provides with what the code expects.
On a quick check, it seems that it provides those info about the sensor:


                    Local0 = Package (0x12)
                        {
                            "CamId", 
                            "ov2680", 
                            "CamType", 
                            "1", 
                            "CsiPort", 
                            "0", 
                            "CsiLanes", 
                            "1", 
                            "CsiFmt", 
                            "15", 
                            "CsiBayer", 
                            "0", 
                            "CamClk", 
                            "1", 
                            "Regulator1p8v", 
                            "0", 
                            "Regulator2p8v", 
                            "0"
                        }

The regulator code seems to be expecting something different:

                gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
                gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
                gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
                gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");

Maybe if we add something like:

	if (IS_ERR(gmin_subdevs[i].v1p8_reg))
		gmin_subdevs[i].v1p8_reg = regulator_get(dev, "Regulator1p8v");

	if (IS_ERR(gmin_subdevs[i].v2p8_reg))
		gmin_subdevs[i].v2p8_reg = regulator_get(dev, "Regulator2p8v");

It would be able to properly initialize the regulators.

[1] Please take a look on this article:

	https://blog.fpmurphy.com/2014/12/decompiling-acpi-tables.html

    It explains how to transform an ACPI table dump into something useful.

    Basically, ACPI contains some code that the OSes run in order to get
    information about some devices. 

Thanks,
Mauro

        Device (CAM1)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "OVTI2680")  // _HID: Hardware ID
            Name (_CID, "OVTI2680")  // _CID: Compatible ID
            Name (_SUB, "13A01043")  // _SUB: Subsystem ID
            Name (_DDN, "OV2680")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID
            Name (_DEP, Package (0x02)  // _DEP: Dependencies
            {
                I2C7, 
                ^^I2C7.PMI2
            })
            Name (_PR0, Package (0x03)  // _PR0: Power Resources for D0
            {
                P28T, 
                P18D, 
                CLK4
            })
            Name (PLDB, Package (0x01)
            {
                Buffer (0x14)
                {
                    /* 0000 */  0x82, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                    /* 0008 */  0x61, 0x0C, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,  // a.......
                    /* 0010 */  0xFF, 0xFF, 0xFF, 0xFF                           // ....
                }
            })
            Method (_PLD, 0, Serialized)  // _PLD: Physical Location of Device
            {
                Return (PLDB) /* \_SB_.PCI0.I2C3.CAM1.PLDB */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (SBUF, ResourceTemplate ()
                {
                    GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                        "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                        )
                        {   // Pin list
                            0x0037
                        }
                    I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PCI0.I2C3",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (SBUF) /* \_SB_.PCI0.I2C3.CAM1._CRS.SBUF */
            }

            Name (C1CD, Buffer (0x0220){})
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If ((Arg0 == ToUUID ("dc2f6c4f-045b-4f1d-97b9-882a6860a4be")))
                {
                    Local0 = Package (0x12)
                        {
                            "CamId", 
                            "ov2680", 
                            "CamType", 
                            "1", 
                            "CsiPort", 
                            "0", 
                            "CsiLanes", 
                            "1", 
                            "CsiFmt", 
                            "15", 
                            "CsiBayer", 
                            "0", 
                            "CamClk", 
                            "1", 
                            "Regulator1p8v", 
                            "0", 
                            "Regulator2p8v", 
                            "0"
                        }
                    Return (Local0)
                }

                If ((Arg0 == ToUUID ("377ba76a-f390-4aff-ab38-9b1bf33a3015")))
                {
                    Return ("OVTI2680")
                }

                If ((Arg0 == ToUUID ("3c62aaaa-d8e0-401a-84c3-fc05656fa28c")))
                {
                    Return ("OV2680")
                }

                If ((Arg0 == ToUUID ("822ace8f-2814-4174-a56b-5f029fe079ee")))
                {
                    Return ("CIFF2192")
                }

                If ((Arg0 == ToUUID ("2959512a-028c-4646-b73d-4d1b5672fad8")))
                {
                    If ((BDID == 0x04))
                    {
                        If ((FBID == 0x02))
                        {
                            Return ("INTEL_FFRD")
                        }

                        If ((FBID == 0x03))
                        {
                            Return ("INTEL_FFRD")
                        }
                    }

                    Return ("INTEL_RVP")
                }

                If ((Arg0 == ToUUID ("918ab242-c37c-450a-9d0f-f47ab97c3dea")))
                {
                    Return (0x0101)
                }

                If ((Arg0 == ToUUID ("ea3b7bd8-e09b-4239-ad6e-ed525f3f26ab")))
                {
                    Return (0x1011)
                }

                If ((Arg0 == ToUUID ("b65ac492-9e30-4d60-b5b2-f497c790d9cf")))
                {
                    Return (Zero)
                }

                If ((Arg0 == ToUUID ("e770ab0f-2644-4bab-8628-d62f1683fb9d")))
                {
                    Return (0x05)
                }

                If ((Arg0 == ToUUID ("1ea54ab2-cd84-48cc-9dd4-7f594ec3b015")))
                {
                    Return (0x02)
                }

                If ((Arg0 == ToUUID ("8dbe2651-70c1-4c6f-ac87-a37cb46e4af6")))
                {
                    Return (One)
                }

                If ((Arg0 == ToUUID ("75c9a639-5c8a-4a00-9f48-a9c3b5da789f")))
                {
                    Return (Zero)
                }

                If ((Arg0 == ToUUID ("2fa9bb94-9c5d-4aeb-8e6e-27434f81e3d3")))
                {
                    Return ("CHT_CR")
                }

                If ((Arg0 == ToUUID ("647a6ca2-8b29-49ac-8806-d58b3d2d3ef5")))
                {
                    Return ("FFD")
                }

                If ((Arg0 == ToUUID ("a6e922a1-f7b3-4399-b56a-406ae416843b")))
                {
                    Return ("CHV")
                }

                If ((Arg0 == ToUUID ("5960313b-0ab0-4940-8840-2cafa420c015")))
                {
                    Return ("ASUS")
                }

                If ((Arg0 == ToUUID ("26257549-9271-4ca4-bb43-c4899d5a4881")))
                {
                    If ((Arg2 == One))
                    {
                        Return (One)
                    }

                    If ((Arg2 == 0x02))
                    {
                        Return (0x03003600)
                    }
                }

                If ((Arg0 == ToUUID ("79234640-9e10-4fea-a5c1-b5aa8b19756f")))
                {
                    If ((Arg2 == One))
                    {
                        Return (One)
                    }

                    If ((Arg2 == 0x02))
                    {
                        Return (0x01003701)
                    }
                }

                If ((Arg0 == ToUUID ("e9914eb6-592b-4228-ba5d-a0994bcb20dd")))
                {
                    Local0 = Zero
                    While ((Local0 < 0x0220))
                    {
                        C1CD [Local0] = MEMB ((CA10 + Local0))
                        Local0++
                    }

                    Return (C1CD) /* \_SB_.PCI0.I2C3.CAM1.C1CD */
                }

                If ((Arg0 == ToUUID ("f486d39f-d657-484b-84a6-42a565712b92")))
                {
                    Return (Buffer (0x20)
                    {
                        /* 0000 */  0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x05, 0x00,  // ........
                        /* 0008 */  0x05, 0x01, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00,  // ........
                        /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                        /* 0018 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   // ........
                    })
                }

                Return (Zero)
            }
        }

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 25.04.20 13:22, Mauro Carvalho Chehab wrote:
> Hi Patrik,
>
> Em Fri, 24 Apr 2020 12:07:30 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> On 24.04.20 11:10, Patrik Gfeller wrote:
>>> On 24.04.20 10:52, Patrik Gfeller wrote:
>>>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
>>>>> Em Wed, 22 Apr 2020 19:56:56 +0200
>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>   
>>>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>>>> Me again ... sorry to ask such a basic question, but I can't get
>>>>>>>> your
>>>>>>>> modified source code. I get the following error:
>>>>>>>>       > git clone https://git.linuxtv.$ sudo make M=drivers/staging/media/atomisp/ modules_install
>>>>>>>> org/mchehab/experimental.git/
>>>>>>>> Cloning into 'experimental'...
>>>>>>>> warning: adding alternate object store:
>>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>>> warning: adding alternate object store:
>>>>>>>> https://git.linuxtv.org/git/media_tree.git/
>>>>>>>> warning: adding alternate object store:
>>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>>>>>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>>>>>> error: fetch failed.
>>>>>>>>
>>>>>>>> Do I use the wrong command?
>>>>>>> Better to use git:// url:
>>>>>>>
>>>>>>>      git clone git://git.linuxtv.org/mchehab/experimental.git/
>>>>>> I was able to download and compile the code. I installed the kernel
>>>>>> and
>>>>>> tried to boot; unfortunately it hangs with the message "Loading
>>>>>> initial
>>>>>> ramdisk ..." - after I start the old kernel I check kern.log and
>>>>>> syslog
>>>>>> - but I do not see entries from the failed boot attempt. I'll read
>>>>>> into
>>>>>> the topic and try around. This will take some time ... so there
>>>>>> will be
>>>>>> a dealy, but it's not that I do not care or lacking interest, I just
>>>>>> first have to sort this out.
>>>>> Well, try to build it first without the atomisp driver. This would
>>>>> allow
>>>>> you to see what's going on.
>>>> I was able to solve the problem I had with the ramdisk - I had to
>>>> strip the kernel modules, probably the ramdisk file was too big.
>>>>
>>>> It is possible to boot with the atomisp driver, but I can not see the
>>>> camera yet - but maybe that's due to missing firmware, as there were
>>>> warnings when I installed the kernel that firmware files are missing.
>> I've added the missing firmware files and now I do not have warnings
>> when I create the ramdisk. Unfortunately it makes no difference - the
>> device does not work yet (dmesg looks the same).
>>>> The following I found in dmesg:
>>>>
>>>> [    9.331011] kernel: atomisp_ov2680: module is from the staging
>>>> directory, the quality is unknown, you have been warned.
>>>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
>>>> atomisp module subdev data.PMIC ID 1
>>>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>> OVTI2680:00_CamClk
>>>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>> OVTI2680:00_ClkSrc
>>>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>> OVTI2680:00_CsiPort
>>>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>> OVTI2680:00_CsiLanes
>>>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not
>>>> found, using dummy regulator
>>>> [    ...
>>>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not
>>>> found, using dummy regulator
>>>> [    ...
>>>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
>>>> found, using dummy regulator
>>>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
>>>> found, using dummy regulator
>>>> [   ...'
>>>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>>>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
>>>> lanes: 1 order: 00000002
>>>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
>>>> 0x2680, rev= 0
>>>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
>>>> module type 1
>>>>
>>>> The first signs of live :-) ... I'll try to find the firmware files
>>>> to see if it makes a difference.
> Atomisp driver uses ACPI to detect the camera configuration. As you
> can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:
>
> 	static const struct acpi_device_id ov2680_acpi_match[] = {
> 	        {"XXOV2680"},
> 	        {"OVTI2680"},
> 	        {},
> 	};
> 	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
>
> The regulator data is parsed at
> drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:
>
>          if (pmic_id == PMIC_REGULATOR) {
>                  gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
>                  gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
>                  gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
>                  gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");
>
>                  /* Note: ideally we would initialize v[12]p8_on to the
>                   * output of regulator_is_enabled(), but sadly that
>                   * API is broken with the current drivers, returning
>                   * "1" for a regulator that will then emit a
>                   * "unbalanced disable" WARNing if we try to disable
>                   * it.
>                   */
>          }
>
> There are two things that could be the cause of this issue:
>
> 1) Some patch could have broken support for it.
>
> Doing a:
>
> 	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>
> will allow you to check the changes on this file.
>
> 2) Maybe recent BIOSes may have changed the names of the ACPI variables.
>
> For instance, from the code, the driver should be seeking for those
> variables for OV2680 (and several others that seem to be common among
> multiple combinations):
>
> 	XXOV2680:00_CsiPort
> 	XXOV2680:00_CsiLanes
> 	XXOV2680:00_CamClk
>
> It would be possible, that, on a modern BIOS, such vars were, for example,
> renamed to 'XXOV2680_V2*'.

Thank you for the explanations. I've read the article about ACPI and 
have now a basic idea what it is.

I tried to figure out if the ACPI variable names changed ... in the ACPI 
dump the variables seem to match the code (if I understood correctly). I 
tried to scan the firmware file to check if there's a hint regarding a 
changed variable:

$ strings shisp_2401a0_v21.bin | grep 2680
$ strings shisp_2401a0_v21.bin | grep OV

But found not matches. I then checked the android source code to check 
if I find the information in their code (as there is kind of a atomisp 
driver). But unfortunately I was not able to find the ACPI code and a 
simple search for 2680 did not find anything. Next I downloaded a 
windows driver and searched all the files for 2680:

$ ls | xargs strings | grep 2680
OV2680
D:\work\vied-vieddrv-camerasw_base\Source\Camera\Platform\SKYCAM\DriversOutput\ov2680\ov2680_Release_x64\ov2680.pdb
OV2680
OV2680

This did not find something useful, - had expected to find OVTI2680.

I wonder if it fails to load the variable because it can not load the 
firmware - what would surprise me, as if I understood the ACPI thing 
correctly, that information should be available without firmware ...

Apr 26 12:35:42 ASUS kernel: [ 3731.387524] acpi OVTI2680:00: Failed to 
find gmin variable OVTI2680:00_CamClk
Apr 26 12:35:42 ASUS kernel: [ 3731.388195] acpi OVTI2680:00: Failed to 
find gmin variable OVTI2680:00_ClkSrc
Apr 26 12:35:42 ASUS kernel: [ 3731.388855] acpi OVTI2680:00: Failed to 
find gmin variable OVTI2680:00_CsiPort
Apr 26 12:35:42 ASUS kernel: [ 3731.389541] acpi OVTI2680:00: Failed to 
find gmin variable OVTI2680:00_CsiLanes

However, I tried to find out if the firmware is actually loaded and 
found that the filename was correct, but the actual version string in 
the firmware was not. I tried to find the correct firmware, but could 
not find it. I hoped for a stable interface and changed the version 
string in the code to match my firmware. No change in behavior. To check 
if it actually loads the firmware I searched the code and found in file 
sh_css_firmware.c some code that seems to be related: 
sh_css_load_firmware. In case of a version mismatch I expect a debug 
message:

     if (!valid_firmware)
     {
#if !defined(HRT_RTL)
         IA_CSS_ERROR("CSS code version (%s) and firmware version (%s) 
mismatch!",
                  file_header->version, release_version);
         return IA_CSS_ERR_VERSION_MISMATCH;
#endif
     } else
     {
         IA_CSS_LOG("successfully load firmware version %s", 
release_version);
     }

Surprisingly I do not see either of the two message with dmesg or in 
kern.log. I assumed that it is necessary to activate those debug 
messages somehow - but could not figure out how. During my research I 
found printk - so I added a printk just after a message I see in dmesg 
as a 1st test (my plan was to use it later to log if the firmware is 
loaded, or not):

     dev_info(dev,
          "gmin: initializing atomisp module subdev data.PMIC ID %d\n",
          pmic_id);

     pr_err("printk Hello World");

I did not find the message in dmesg, nor kern.log. So I increased the 
loglevel:

$ echo 8 | sudo tee /proc/sys/kernel/printk

But still no result. Maybe I didn't recompile the module the right way 
(did not compile the full kernel):

$ make clean M=drivers/staging/media/atomisp/
$ make -j4 M=drivers/staging/media/atomisp/
$ sudo make M=drivers/staging/media/atomisp/ modules_install
$ sudo depmod -a
$ sudo rmmod atomisp-ov2680
$ sudo modprobe atomisp-ov2680

Currently I'm a little confused, as this printk thing did not work. I'll 
investigate further to see where I did the mistake.

kind regards,

Patrik

>
> -
>
> In any case, I guess the next step is to use some ACPI dump facility to check
> how your BIOS is exporting camera-related data[1].
>
> If the vars are the same, then there's a bug (condition 1) above. If
> the vars are different, then some vars were added or renamed (condition 2).
>
> With such information, you should be able to write a patch to
> atomisp_gmin_platform.c adding support for the new way. Please notice that,
> in the case of renames, the patch should keep support to the old way, as
> otherwise support for other older hardware would break.
>
> Using the file you sent, I decoded the DTST table and paste the relevant
> parts for this camera, using:
>
> 	$ acpixtract /tmp/dmp/acpidump.txt
> 	$ iasl -d dsdt.dat
>
> Now, we need to compare what it provides with what the code expects.
> On a quick check, it seems that it provides those info about the sensor:
>
>
>                      Local0 = Package (0x12)
>                          {
>                              "CamId",
>                              "ov2680",
>                              "CamType",
>                              "1",
>                              "CsiPort",
>                              "0",
>                              "CsiLanes",
>                              "1",
>                              "CsiFmt",
>                              "15",
>                              "CsiBayer",
>                              "0",
>                              "CamClk",
>                              "1",
>                              "Regulator1p8v",
>                              "0",
>                              "Regulator2p8v",
>                              "0"
>                          }
>
> The regulator code seems to be expecting something different:
>
>                  gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
>                  gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
>                  gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
>                  gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");
>
> Maybe if we add something like:
>
> 	if (IS_ERR(gmin_subdevs[i].v1p8_reg))
> 		gmin_subdevs[i].v1p8_reg = regulator_get(dev, "Regulator1p8v");
>
> 	if (IS_ERR(gmin_subdevs[i].v2p8_reg))
> 		gmin_subdevs[i].v2p8_reg = regulator_get(dev, "Regulator2p8v");
>
> It would be able to properly initialize the regulators.
>
> [1] Please take a look on this article:
>
> 	https://blog.fpmurphy.com/2014/12/decompiling-acpi-tables.html
>
>      It explains how to transform an ACPI table dump into something useful.
>
>      Basically, ACPI contains some code that the OSes run in order to get
>      information about some devices.
>
> Thanks,
> Mauro
>
>          Device (CAM1)
>          {
>              Name (_ADR, Zero)  // _ADR: Address
>              Name (_HID, "OVTI2680")  // _HID: Hardware ID
>              Name (_CID, "OVTI2680")  // _CID: Compatible ID
>              Name (_SUB, "13A01043")  // _SUB: Subsystem ID
>              Name (_DDN, "OV2680")  // _DDN: DOS Device Name
>              Name (_UID, One)  // _UID: Unique ID
>              Name (_DEP, Package (0x02)  // _DEP: Dependencies
>              {
>                  I2C7,
>                  ^^I2C7.PMI2
>              })
>              Name (_PR0, Package (0x03)  // _PR0: Power Resources for D0
>              {
>                  P28T,
>                  P18D,
>                  CLK4
>              })
>              Name (PLDB, Package (0x01)
>              {
>                  Buffer (0x14)
>                  {
>                      /* 0000 */  0x82, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
>                      /* 0008 */  0x61, 0x0C, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,  // a.......
>                      /* 0010 */  0xFF, 0xFF, 0xFF, 0xFF                           // ....
>                  }
>              })
>              Method (_PLD, 0, Serialized)  // _PLD: Physical Location of Device
>              {
>                  Return (PLDB) /* \_SB_.PCI0.I2C3.CAM1.PLDB */
>              }
>
>              Method (_STA, 0, NotSerialized)  // _STA: Status
>              {
>                  Return (0x0F)
>              }
>
>              Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>              {
>                  Name (SBUF, ResourceTemplate ()
>                  {
>                      GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>                          )
>                          {   // Pin list
>                              0x0037
>                          }
>                      I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
>                          AddressingMode7Bit, "\\_SB.PCI0.I2C3",
>                          0x00, ResourceConsumer, , Exclusive,
>                          )
>                  })
>                  Return (SBUF) /* \_SB_.PCI0.I2C3.CAM1._CRS.SBUF */
>              }
>
>              Name (C1CD, Buffer (0x0220){})
>              Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
>              {
>                  If ((Arg0 == ToUUID ("dc2f6c4f-045b-4f1d-97b9-882a6860a4be")))
>                  {
>                      Local0 = Package (0x12)
>                          {
>                              "CamId",
>                              "ov2680",
>                              "CamType",
>                              "1",
>                              "CsiPort",
>                              "0",
>                              "CsiLanes",
>                              "1",
>                              "CsiFmt",
>                              "15",
>                              "CsiBayer",
>                              "0",
>                              "CamClk",
>                              "1",
>                              "Regulator1p8v",
>                              "0",
>                              "Regulator2p8v",
>                              "0"
>                          }
>                      Return (Local0)
>                  }
>
>                  If ((Arg0 == ToUUID ("377ba76a-f390-4aff-ab38-9b1bf33a3015")))
>                  {
>                      Return ("OVTI2680")
>                  }
>
>                  If ((Arg0 == ToUUID ("3c62aaaa-d8e0-401a-84c3-fc05656fa28c")))
>                  {
>                      Return ("OV2680")
>                  }
>
>                  If ((Arg0 == ToUUID ("822ace8f-2814-4174-a56b-5f029fe079ee")))
>                  {
>                      Return ("CIFF2192")
>                  }
>
>                  If ((Arg0 == ToUUID ("2959512a-028c-4646-b73d-4d1b5672fad8")))
>                  {
>                      If ((BDID == 0x04))
>                      {
>                          If ((FBID == 0x02))
>                          {
>                              Return ("INTEL_FFRD")
>                          }
>
>                          If ((FBID == 0x03))
>                          {
>                              Return ("INTEL_FFRD")
>                          }
>                      }
>
>                      Return ("INTEL_RVP")
>                  }
>
>                  If ((Arg0 == ToUUID ("918ab242-c37c-450a-9d0f-f47ab97c3dea")))
>                  {
>                      Return (0x0101)
>                  }
>
>                  If ((Arg0 == ToUUID ("ea3b7bd8-e09b-4239-ad6e-ed525f3f26ab")))
>                  {
>                      Return (0x1011)
>                  }
>
>                  If ((Arg0 == ToUUID ("b65ac492-9e30-4d60-b5b2-f497c790d9cf")))
>                  {
>                      Return (Zero)
>                  }
>
>                  If ((Arg0 == ToUUID ("e770ab0f-2644-4bab-8628-d62f1683fb9d")))
>                  {
>                      Return (0x05)
>                  }
>
>                  If ((Arg0 == ToUUID ("1ea54ab2-cd84-48cc-9dd4-7f594ec3b015")))
>                  {
>                      Return (0x02)
>                  }
>
>                  If ((Arg0 == ToUUID ("8dbe2651-70c1-4c6f-ac87-a37cb46e4af6")))
>                  {
>                      Return (One)
>                  }
>
>                  If ((Arg0 == ToUUID ("75c9a639-5c8a-4a00-9f48-a9c3b5da789f")))
>                  {
>                      Return (Zero)
>                  }
>
>                  If ((Arg0 == ToUUID ("2fa9bb94-9c5d-4aeb-8e6e-27434f81e3d3")))
>                  {
>                      Return ("CHT_CR")
>                  }
>
>                  If ((Arg0 == ToUUID ("647a6ca2-8b29-49ac-8806-d58b3d2d3ef5")))
>                  {
>                      Return ("FFD")
>                  }
>
>                  If ((Arg0 == ToUUID ("a6e922a1-f7b3-4399-b56a-406ae416843b")))
>                  {
>                      Return ("CHV")
>                  }
>
>                  If ((Arg0 == ToUUID ("5960313b-0ab0-4940-8840-2cafa420c015")))
>                  {
>                      Return ("ASUS")
>                  }
>
>                  If ((Arg0 == ToUUID ("26257549-9271-4ca4-bb43-c4899d5a4881")))
>                  {
>                      If ((Arg2 == One))
>                      {
>                          Return (One)
>                      }
>
>                      If ((Arg2 == 0x02))
>                      {
>                          Return (0x03003600)
>                      }
>                  }
>
>                  If ((Arg0 == ToUUID ("79234640-9e10-4fea-a5c1-b5aa8b19756f")))
>                  {
>                      If ((Arg2 == One))
>                      {
>                          Return (One)
>                      }
>
>                      If ((Arg2 == 0x02))
>                      {
>                          Return (0x01003701)
>                      }
>                  }
>
>                  If ((Arg0 == ToUUID ("e9914eb6-592b-4228-ba5d-a0994bcb20dd")))
>                  {
>                      Local0 = Zero
>                      While ((Local0 < 0x0220))
>                      {
>                          C1CD [Local0] = MEMB ((CA10 + Local0))
>                          Local0++
>                      }
>
>                      Return (C1CD) /* \_SB_.PCI0.I2C3.CAM1.C1CD */
>                  }
>
>                  If ((Arg0 == ToUUID ("f486d39f-d657-484b-84a6-42a565712b92")))
>                  {
>                      Return (Buffer (0x20)
>                      {
>                          /* 0000 */  0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x05, 0x00,  // ........
>                          /* 0008 */  0x05, 0x01, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00,  // ........
>                          /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
>                          /* 0018 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   // ........
>                      })
>                  }
>
>                  Return (Zero)
>              }
>          }
>
>
>
>
>

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sun, 26 Apr 2020 13:38:19 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 25.04.20 13:22, Mauro Carvalho Chehab wrote:
> > Hi Patrik,
> >
> > Em Fri, 24 Apr 2020 12:07:30 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >  
> >> On 24.04.20 11:10, Patrik Gfeller wrote:  
> >>> On 24.04.20 10:52, Patrik Gfeller wrote:  
> >>>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:  
> >>>>> Em Wed, 22 Apr 2020 19:56:56 +0200
> >>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>>>>     
> >>>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:  
> >>>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
> >>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:  
> >>>>>>>> Me again ... sorry to ask such a basic question, but I can't get
> >>>>>>>> your
> >>>>>>>> modified source code. I get the following error:
> >>>>>>>>       > git clone https://git.linuxtv.$ sudo make M=drivers/staging/media/atomisp/ modules_install
> >>>>>>>> org/mchehab/experimental.git/
> >>>>>>>> Cloning into 'experimental'...
> >>>>>>>> warning: adding alternate object store:
> >>>>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>>>> warning: adding alternate object store:
> >>>>>>>> https://git.linuxtv.org/git/media_tree.git/
> >>>>>>>> warning: adding alternate object store:
> >>>>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
> >>>>>>>> https://git.linuxtv.org/mchehab/experimental.git
> >>>>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
> >>>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
> >>>>>>>> error: fetch failed.
> >>>>>>>>
> >>>>>>>> Do I use the wrong command?  
> >>>>>>> Better to use git:// url:
> >>>>>>>
> >>>>>>>      git clone git://git.linuxtv.org/mchehab/experimental.git/  
> >>>>>> I was able to download and compile the code. I installed the kernel
> >>>>>> and
> >>>>>> tried to boot; unfortunately it hangs with the message "Loading
> >>>>>> initial
> >>>>>> ramdisk ..." - after I start the old kernel I check kern.log and
> >>>>>> syslog
> >>>>>> - but I do not see entries from the failed boot attempt. I'll read
> >>>>>> into
> >>>>>> the topic and try around. This will take some time ... so there
> >>>>>> will be
> >>>>>> a dealy, but it's not that I do not care or lacking interest, I just
> >>>>>> first have to sort this out.  
> >>>>> Well, try to build it first without the atomisp driver. This would
> >>>>> allow
> >>>>> you to see what's going on.  
> >>>> I was able to solve the problem I had with the ramdisk - I had to
> >>>> strip the kernel modules, probably the ramdisk file was too big.
> >>>>
> >>>> It is possible to boot with the atomisp driver, but I can not see the
> >>>> camera yet - but maybe that's due to missing firmware, as there were
> >>>> warnings when I installed the kernel that firmware files are missing.  
> >> I've added the missing firmware files and now I do not have warnings
> >> when I create the ramdisk. Unfortunately it makes no difference - the
> >> device does not work yet (dmesg looks the same).  
> >>>> The following I found in dmesg:
> >>>>
> >>>> [    9.331011] kernel: atomisp_ov2680: module is from the staging
> >>>> directory, the quality is unknown, you have been warned.
> >>>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
> >>>> atomisp module subdev data.PMIC ID 1
> >>>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>> OVTI2680:00_CamClk
> >>>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>> OVTI2680:00_ClkSrc
> >>>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>> OVTI2680:00_CsiPort
> >>>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>> OVTI2680:00_CsiLanes
> >>>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not
> >>>> found, using dummy regulator
> >>>> [    ...
> >>>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not
> >>>> found, using dummy regulator
> >>>> [    ...
> >>>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> >>>> found, using dummy regulator
> >>>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> >>>> found, using dummy regulator
> >>>> [   ...'
> >>>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> >>>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
> >>>> lanes: 1 order: 00000002
> >>>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
> >>>> 0x2680, rev= 0
> >>>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
> >>>> module type 1
> >>>>
> >>>> The first signs of live :-) ... I'll try to find the firmware files
> >>>> to see if it makes a difference.  
> > Atomisp driver uses ACPI to detect the camera configuration. As you
> > can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:
> >
> > 	static const struct acpi_device_id ov2680_acpi_match[] = {
> > 	        {"XXOV2680"},
> > 	        {"OVTI2680"},
> > 	        {},
> > 	};
> > 	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
> >
> > The regulator data is parsed at
> > drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:
> >
> >          if (pmic_id == PMIC_REGULATOR) {
> >                  gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
> >                  gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
> >                  gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
> >                  gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");
> >
> >                  /* Note: ideally we would initialize v[12]p8_on to the
> >                   * output of regulator_is_enabled(), but sadly that
> >                   * API is broken with the current drivers, returning
> >                   * "1" for a regulator that will then emit a
> >                   * "unbalanced disable" WARNing if we try to disable
> >                   * it.
> >                   */
> >          }
> >
> > There are two things that could be the cause of this issue:
> >
> > 1) Some patch could have broken support for it.
> >
> > Doing a:
> >
> > 	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >
> > will allow you to check the changes on this file.
> >
> > 2) Maybe recent BIOSes may have changed the names of the ACPI variables.
> >
> > For instance, from the code, the driver should be seeking for those
> > variables for OV2680 (and several others that seem to be common among
> > multiple combinations):
> >
> > 	XXOV2680:00_CsiPort
> > 	XXOV2680:00_CsiLanes
> > 	XXOV2680:00_CamClk
> >
> > It would be possible, that, on a modern BIOS, such vars were, for example,
> > renamed to 'XXOV2680_V2*'.  
> 
> Thank you for the explanations. I've read the article about ACPI and 
> have now a basic idea what it is.
> 
> I tried to figure out if the ACPI variable names changed ... in the ACPI 
> dump the variables seem to match the code (if I understood correctly). I 
> tried to scan the firmware file to check if there's a hint regarding a 
> changed variable:
> 
> $ strings shisp_2401a0_v21.bin | grep 2680
> $ strings shisp_2401a0_v21.bin | grep OV

No, you're looking at the wrong place. This should be at the system 
board's BIOS, and not at something that the driver would load.

Just run (as root):

	# dmidecode

and check the name of your board. It should be similar to this:

	...
	System Information
	        Manufacturer: Intel Corporation
	        Product Name: (something)

The "(something)" is the board name. The atomisp driver will seek for
it. So, you need to patch the driver (using the example I gave) in
order for it to look at the right DMI_MATCH() table. Right now,
the driver knows only those:

	$ git grep DMI_MATCH drivers/staging/media/atomisp/
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),

Your asus board should likely use "ASUS", "_ASUS_" or something similar.
So, you should take a look on the patch I sent you and modify it to
match whatever name dmidecode printed.

See for example this patch:

	https://www.spinics.net/lists/linux-media/msg126880.html

If it finds the right table, it should end by calling gmin_subdev_add(),
with should use DTST table, also from the ACPI table inside the system's BIOS.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
> Em Sun, 26 Apr 2020 13:38:19 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> On 25.04.20 13:22, Mauro Carvalho Chehab wrote:
>>> Hi Patrik,
>>>
>>> Em Fri, 24 Apr 2020 12:07:30 +0200
>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>   
>>>> On 24.04.20 11:10, Patrik Gfeller wrote:
>>>>> On 24.04.20 10:52, Patrik Gfeller wrote:
>>>>>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:
>>>>>>> Em Wed, 22 Apr 2020 19:56:56 +0200
>>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>>>      
>>>>>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:
>>>>>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
>>>>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>>>>>>>>> Me again ... sorry to ask such a basic question, but I can't get
>>>>>>>>>> your
>>>>>>>>>> modified source code. I get the following error:
>>>>>>>>>>        > git clone https://git.linuxtv.$ sudo make M=drivers/staging/media/atomisp/ modules_install
>>>>>>>>>> org/mchehab/experimental.git/
>>>>>>>>>> Cloning into 'experimental'...
>>>>>>>>>> warning: adding alternate object store:
>>>>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>>>>> warning: adding alternate object store:
>>>>>>>>>> https://git.linuxtv.org/git/media_tree.git/
>>>>>>>>>> warning: adding alternate object store:
>>>>>>>>>> https://git.linuxtv.org/git/linux.git/
>>>>>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
>>>>>>>>>> https://git.linuxtv.org/mchehab/experimental.git
>>>>>>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
>>>>>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
>>>>>>>>>> error: fetch failed.
>>>>>>>>>>
>>>>>>>>>> Do I use the wrong command?
>>>>>>>>> Better to use git:// url:
>>>>>>>>>
>>>>>>>>>       git clone git://git.linuxtv.org/mchehab/experimental.git/
>>>>>>>> I was able to download and compile the code. I installed the kernel
>>>>>>>> and
>>>>>>>> tried to boot; unfortunately it hangs with the message "Loading
>>>>>>>> initial
>>>>>>>> ramdisk ..." - after I start the old kernel I check kern.log and
>>>>>>>> syslog
>>>>>>>> - but I do not see entries from the failed boot attempt. I'll read
>>>>>>>> into
>>>>>>>> the topic and try around. This will take some time ... so there
>>>>>>>> will be
>>>>>>>> a dealy, but it's not that I do not care or lacking interest, I just
>>>>>>>> first have to sort this out.
>>>>>>> Well, try to build it first without the atomisp driver. This would
>>>>>>> allow
>>>>>>> you to see what's going on.
>>>>>> I was able to solve the problem I had with the ramdisk - I had to
>>>>>> strip the kernel modules, probably the ramdisk file was too big.
>>>>>>
>>>>>> It is possible to boot with the atomisp driver, but I can not see the
>>>>>> camera yet - but maybe that's due to missing firmware, as there were
>>>>>> warnings when I installed the kernel that firmware files are missing.
>>>> I've added the missing firmware files and now I do not have warnings
>>>> when I create the ramdisk. Unfortunately it makes no difference - the
>>>> device does not work yet (dmesg looks the same).
>>>>>> The following I found in dmesg:
>>>>>>
>>>>>> [    9.331011] kernel: atomisp_ov2680: module is from the staging
>>>>>> directory, the quality is unknown, you have been warned.
>>>>>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
>>>>>> atomisp module subdev data.PMIC ID 1
>>>>>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>>>> OVTI2680:00_CamClk
>>>>>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>>>> OVTI2680:00_ClkSrc
>>>>>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>>>> OVTI2680:00_CsiPort
>>>>>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable
>>>>>> OVTI2680:00_CsiLanes
>>>>>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not
>>>>>> found, using dummy regulator
>>>>>> [    ...
>>>>>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not
>>>>>> found, using dummy regulator
>>>>>> [    ...
>>>>>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
>>>>>> found, using dummy regulator
>>>>>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
>>>>>> found, using dummy regulator
>>>>>> [   ...'
>>>>>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>>>>>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
>>>>>> lanes: 1 order: 00000002
>>>>>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
>>>>>> 0x2680, rev= 0
>>>>>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
>>>>>> module type 1
>>>>>>
>>>>>> The first signs of live :-) ... I'll try to find the firmware files
>>>>>> to see if it makes a difference.
>>> Atomisp driver uses ACPI to detect the camera configuration. As you
>>> can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:
>>>
>>> 	static const struct acpi_device_id ov2680_acpi_match[] = {
>>> 	        {"XXOV2680"},
>>> 	        {"OVTI2680"},
>>> 	        {},
>>> 	};
>>> 	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
>>>
>>> The regulator data is parsed at
>>> drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:
>>>
>>>           if (pmic_id == PMIC_REGULATOR) {
>>>                   gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
>>>                   gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
>>>                   gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
>>>                   gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");
>>>
>>>                   /* Note: ideally we would initialize v[12]p8_on to the
>>>                    * output of regulator_is_enabled(), but sadly that
>>>                    * API is broken with the current drivers, returning
>>>                    * "1" for a regulator that will then emit a
>>>                    * "unbalanced disable" WARNing if we try to disable
>>>                    * it.
>>>                    */
>>>           }
>>>
>>> There are two things that could be the cause of this issue:
>>>
>>> 1) Some patch could have broken support for it.
>>>
>>> Doing a:
>>>
>>> 	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>>>
>>> will allow you to check the changes on this file.
>>>
>>> 2) Maybe recent BIOSes may have changed the names of the ACPI variables.
>>>
>>> For instance, from the code, the driver should be seeking for those
>>> variables for OV2680 (and several others that seem to be common among
>>> multiple combinations):
>>>
>>> 	XXOV2680:00_CsiPort
>>> 	XXOV2680:00_CsiLanes
>>> 	XXOV2680:00_CamClk
>>>
>>> It would be possible, that, on a modern BIOS, such vars were, for example,
>>> renamed to 'XXOV2680_V2*'.
>> Thank you for the explanations. I've read the article about ACPI and
>> have now a basic idea what it is.
>>
>> I tried to figure out if the ACPI variable names changed ... in the ACPI
>> dump the variables seem to match the code (if I understood correctly). I
>> tried to scan the firmware file to check if there's a hint regarding a
>> changed variable:
>>
>> $ strings shisp_2401a0_v21.bin | grep 2680
>> $ strings shisp_2401a0_v21.bin | grep OV
> No, you're looking at the wrong place. This should be at the system
> board's BIOS, and not at something that the driver would load.
>
> Just run (as root):
>
> 	# dmidecode
>
> and check the name of your board. It should be similar to this:
>
> 	...
> 	System Information
> 	        Manufacturer: Intel Corporation
> 	        Product Name: (something)
>
> The "(something)" is the board name. The atomisp driver will seek for
> it. So, you need to patch the driver (using the example I gave) in
> order for it to look at the right DMI_MATCH() table. Right now,
> the driver knows only those:
>
> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
>
> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
> So, you should take a look on the patch I sent you and modify it to
> match whatever name dmidecode printed.
>
> See for example this patch:
>
> 	https://www.spinics.net/lists/linux-media/msg126880.html
>
> If it finds the right table, it should end by calling gmin_subdev_add(),
> with should use DTST table, also from the ACPI table inside the system's BIOS.
Now I understood :-). I've made the modifications as you explained and 
indeed the errors regarding

OVTI2680:00_CamClk
OVTI2680:00_ClkSrc
OVTI2680:00_CsiPort
OVTI2680:00_CsiLanes

are gone. Now we have the following in dmesg:

[    8.815960] kernel: mc: Linux media interface: v0.10
[    8.858458] kernel: videodev: Linux video capture interface: v2.00
[    8.876864] kernel: input: Intel HID events as 
/devices/pci0000:00/INT33D5:00/input/input16
[    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40, 
base_baud = 2764800) is a 16550A
[    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 
channels
[    8.929818] kernel: atomisp_ov2680: module is from the staging 
directory, the quality is unknown, you have been warned.
[    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
atomisp module subdev data.PMIC ID 1
[    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found, 
using dummy regulator
[    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found, 
using dummy regulator
[    8.989977] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
using dummy regulator
[    8.989998] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
using dummy regulator
[    9.033505] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.061511] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
lanes: 1 order: 00000002
[    9.065178] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
0x2680, rev= 0
[    9.071095] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
module type 1

Laurent explained me how to enable internal debug messages. I'll read 
more about this to understand how to use it and hope this will give a 
more detailed insight.


great to see some progress :-),

thanks and kind regards,

Patrik


>
> Thanks,
> Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Mon, 27 Apr 2020 20:31:31 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
> > Em Sun, 26 Apr 2020 13:38:19 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >  
> >> On 25.04.20 13:22, Mauro Carvalho Chehab wrote:  
> >>> Hi Patrik,
> >>>
> >>> Em Fri, 24 Apr 2020 12:07:30 +0200
> >>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>>     
> >>>> On 24.04.20 11:10, Patrik Gfeller wrote:  
> >>>>> On 24.04.20 10:52, Patrik Gfeller wrote:  
> >>>>>> On 22.04.20 21:13, Mauro Carvalho Chehab wrote:  
> >>>>>>> Em Wed, 22 Apr 2020 19:56:56 +0200
> >>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>>>>>>        
> >>>>>>>> On 20.04.20 22:47, Mauro Carvalho Chehab wrote:  
> >>>>>>>>> Em Mon, 20 Apr 2020 20:27:25 +0200
> >>>>>>>>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:  
> >>>>>>>>>> Me again ... sorry to ask such a basic question, but I can't get
> >>>>>>>>>> your
> >>>>>>>>>> modified source code. I get the following error:
> >>>>>>>>>>        > git clone https://git.linuxtv.$ sudo make M=drivers/staging/media/atomisp/ modules_install
> >>>>>>>>>> org/mchehab/experimental.git/
> >>>>>>>>>> Cloning into 'experimental'...
> >>>>>>>>>> warning: adding alternate object store:
> >>>>>>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>>>>>> warning: adding alternate object store:
> >>>>>>>>>> https://git.linuxtv.org/git/media_tree.git/
> >>>>>>>>>> warning: adding alternate object store:
> >>>>>>>>>> https://git.linuxtv.org/git/linux.git/
> >>>>>>>>>> error: Unable to find fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f under
> >>>>>>>>>> https://git.linuxtv.org/mchehab/experimental.git
> >>>>>>>>>> Cannot obtain needed object fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f
> >>>>>>>>>> while processing commit 6d80bfc14608f4bb5514b79721d30b486f50c987.
> >>>>>>>>>> error: fetch failed.
> >>>>>>>>>>
> >>>>>>>>>> Do I use the wrong command?  
> >>>>>>>>> Better to use git:// url:
> >>>>>>>>>
> >>>>>>>>>       git clone git://git.linuxtv.org/mchehab/experimental.git/  
> >>>>>>>> I was able to download and compile the code. I installed the kernel
> >>>>>>>> and
> >>>>>>>> tried to boot; unfortunately it hangs with the message "Loading
> >>>>>>>> initial
> >>>>>>>> ramdisk ..." - after I start the old kernel I check kern.log and
> >>>>>>>> syslog
> >>>>>>>> - but I do not see entries from the failed boot attempt. I'll read
> >>>>>>>> into
> >>>>>>>> the topic and try around. This will take some time ... so there
> >>>>>>>> will be
> >>>>>>>> a dealy, but it's not that I do not care or lacking interest, I just
> >>>>>>>> first have to sort this out.  
> >>>>>>> Well, try to build it first without the atomisp driver. This would
> >>>>>>> allow
> >>>>>>> you to see what's going on.  
> >>>>>> I was able to solve the problem I had with the ramdisk - I had to
> >>>>>> strip the kernel modules, probably the ramdisk file was too big.
> >>>>>>
> >>>>>> It is possible to boot with the atomisp driver, but I can not see the
> >>>>>> camera yet - but maybe that's due to missing firmware, as there were
> >>>>>> warnings when I installed the kernel that firmware files are missing.  
> >>>> I've added the missing firmware files and now I do not have warnings
> >>>> when I create the ramdisk. Unfortunately it makes no difference - the
> >>>> device does not work yet (dmesg looks the same).  
> >>>>>> The following I found in dmesg:
> >>>>>>
> >>>>>> [    9.331011] kernel: atomisp_ov2680: module is from the staging
> >>>>>> directory, the quality is unknown, you have been warned.
> >>>>>> [    9.402456] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
> >>>>>> atomisp module subdev data.PMIC ID 1
> >>>>>> [    9.421113] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>>>> OVTI2680:00_CamClk
> >>>>>> [    9.433478] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>>>> OVTI2680:00_ClkSrc
> >>>>>> [    9.443146] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>>>> OVTI2680:00_CsiPort
> >>>>>> [    9.456677] kernel: acpi OVTI2680:00: Failed to find gmin variable
> >>>>>> OVTI2680:00_CsiLanes
> >>>>>> [    9.479411] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not
> >>>>>> found, using dummy regulator
> >>>>>> [    ...
> >>>>>> [    9.510282] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not
> >>>>>> found, using dummy regulator
> >>>>>> [    ...
> >>>>>> [    9.532284] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> >>>>>> found, using dummy regulator
> >>>>>> [    9.536200] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> >>>>>> found, using dummy regulator
> >>>>>> [   ...'
> >>>>>> [    9.592064] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> >>>>>> [    9.623628] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
> >>>>>> lanes: 1 order: 00000002
> >>>>>> [    9.628258] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
> >>>>>> 0x2680, rev= 0
> >>>>>> [    9.636582] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
> >>>>>> module type 1
> >>>>>>
> >>>>>> The first signs of live :-) ... I'll try to find the firmware files
> >>>>>> to see if it makes a difference.  
> >>> Atomisp driver uses ACPI to detect the camera configuration. As you
> >>> can see at drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:
> >>>
> >>> 	static const struct acpi_device_id ov2680_acpi_match[] = {
> >>> 	        {"XXOV2680"},
> >>> 	        {"OVTI2680"},
> >>> 	        {},
> >>> 	};
> >>> 	MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
> >>>
> >>> The regulator data is parsed at
> >>> drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:
> >>>
> >>>           if (pmic_id == PMIC_REGULATOR) {
> >>>                   gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
> >>>                   gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
> >>>                   gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
> >>>                   gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");
> >>>
> >>>                   /* Note: ideally we would initialize v[12]p8_on to the
> >>>                    * output of regulator_is_enabled(), but sadly that
> >>>                    * API is broken with the current drivers, returning
> >>>                    * "1" for a regulator that will then emit a
> >>>                    * "unbalanced disable" WARNing if we try to disable
> >>>                    * it.
> >>>                    */
> >>>           }
> >>>
> >>> There are two things that could be the cause of this issue:
> >>>
> >>> 1) Some patch could have broken support for it.
> >>>
> >>> Doing a:
> >>>
> >>> 	git diff a49d25364dfb drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >>>
> >>> will allow you to check the changes on this file.
> >>>
> >>> 2) Maybe recent BIOSes may have changed the names of the ACPI variables.
> >>>
> >>> For instance, from the code, the driver should be seeking for those
> >>> variables for OV2680 (and several others that seem to be common among
> >>> multiple combinations):
> >>>
> >>> 	XXOV2680:00_CsiPort
> >>> 	XXOV2680:00_CsiLanes
> >>> 	XXOV2680:00_CamClk
> >>>
> >>> It would be possible, that, on a modern BIOS, such vars were, for example,
> >>> renamed to 'XXOV2680_V2*'.  
> >> Thank you for the explanations. I've read the article about ACPI and
> >> have now a basic idea what it is.
> >>
> >> I tried to figure out if the ACPI variable names changed ... in the ACPI
> >> dump the variables seem to match the code (if I understood correctly). I
> >> tried to scan the firmware file to check if there's a hint regarding a
> >> changed variable:
> >>
> >> $ strings shisp_2401a0_v21.bin | grep 2680
> >> $ strings shisp_2401a0_v21.bin | grep OV  
> > No, you're looking at the wrong place. This should be at the system
> > board's BIOS, and not at something that the driver would load.
> >
> > Just run (as root):
> >
> > 	# dmidecode
> >
> > and check the name of your board. It should be similar to this:
> >
> > 	...
> > 	System Information
> > 	        Manufacturer: Intel Corporation
> > 	        Product Name: (something)
> >
> > The "(something)" is the board name. The atomisp driver will seek for
> > it. So, you need to patch the driver (using the example I gave) in
> > order for it to look at the right DMI_MATCH() table. Right now,
> > the driver knows only those:
> >
> > 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
> >
> > Your asus board should likely use "ASUS", "_ASUS_" or something similar.
> > So, you should take a look on the patch I sent you and modify it to
> > match whatever name dmidecode printed.
> >
> > See for example this patch:
> >
> > 	https://www.spinics.net/lists/linux-media/msg126880.html
> >
> > If it finds the right table, it should end by calling gmin_subdev_add(),
> > with should use DTST table, also from the ACPI table inside the system's BIOS.  
> Now I understood :-). I've made the modifications as you explained and 
> indeed the errors regarding
> 
> OVTI2680:00_CamClk
> OVTI2680:00_ClkSrc
> OVTI2680:00_CsiPort
> OVTI2680:00_CsiLanes
> 
> are gone.

Great! Could you please submit the exact patch you applied? I'll place 
it on my experimental tree:

> Now we have the following in dmesg:
> 
> [    8.815960] kernel: mc: Linux media interface: v0.10
> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
> [    8.876864] kernel: input: Intel HID events as 
> /devices/pci0000:00/INT33D5:00/input/input16
> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40, 
> base_baud = 2764800) is a 16550A
> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 
> channels
> [    8.929818] kernel: atomisp_ov2680: module is from the staging 
> directory, the quality is unknown, you have been warned.
> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
> atomisp module subdev data.PMIC ID 1
> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found, 
> using dummy regulator
> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found, 
> using dummy regulator

Did you apply this patch also?

	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940

I guess this would get rid of the two above warnings.


> [    8.989977] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
> using dummy regulator
> [    8.989998] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
> using dummy regulator
> [    9.033505] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> [    9.061511] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0 
> lanes: 1 order: 00000002
> [    9.065178] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
> 0x2680, rev= 0
> [    9.071095] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
> module type 1

We need to double check if everything is ok on the above.

That's said, with the current code, I don't expect ISP2401 to work out
of the box, as the Kernel is set for ISP2400. I'm trying to address
this on my spare time.

> Laurent explained me how to enable internal debug messages. I'll read 
> more about this to understand how to use it and hope this will give a 
> more detailed insight.
> 
> 
> great to see some progress :-),

Yes!

> thanks and kind regards,
> 
> Patrik
> 
> 
> >
> > Thanks,
> > Mauro  



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

[-- Attachment #1: Type: text/plain, Size: 7228 bytes --]


On 27.04.20 23:50, Mauro Carvalho Chehab wrote:
> Em Mon, 27 Apr 2020 20:31:31 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
>>> No, you're looking at the wrong place. This should be at the system
>>> board's BIOS, and not at something that the driver would load.
>>>
>>> Just run (as root):
>>>
>>> 	# dmidecode
>>>
>>> and check the name of your board. It should be similar to this:
>>>
>>> 	...
>>> 	System Information
>>> 	        Manufacturer: Intel Corporation
>>> 	        Product Name: (something)
>>>
>>> The "(something)" is the board name. The atomisp driver will seek for
>>> it. So, you need to patch the driver (using the example I gave) in
>>> order for it to look at the right DMI_MATCH() table. Right now,
>>> the driver knows only those:
>>>
>>> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
>>>
>>> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
>>> So, you should take a look on the patch I sent you and modify it to
>>> match whatever name dmidecode printed.
>>>
>>> See for example this patch:
>>>
>>> 	https://www.spinics.net/lists/linux-media/msg126880.html
>>>
>>> If it finds the right table, it should end by calling gmin_subdev_add(),
>>> with should use DTST table, also from the ACPI table inside the system's BIOS.
>> Now I understood :-). I've made the modifications as you explained and
>> indeed the errors regarding
>>
>> OVTI2680:00_CamClk
>> OVTI2680:00_ClkSrc
>> OVTI2680:00_CsiPort
>> OVTI2680:00_CsiLanes
>>
>> are gone.
> Great! Could you please submit the exact patch you applied? I'll place
> it on my experimental tree:

Here is the patch for the change I made:

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index eef7123a586f..081f9be6ec29 100644
--- 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
      {},
  };

+static struct gmin_cfg_var asus_vars[] = {
+    {"OVTI2680:00_CsiPort", "0"},
+    {"OVTI2680:00_CsiLanes", "1"},
+    {"OVTI2680:00_CsiFmt", "15"},
+    {"OVTI2680:00_CsiBayer", "0"},
+    {"OVTI2680:00_CamClk", "1"},
+    {},
+};
+
  static const struct dmi_system_id gmin_vars[] = {
      {
          .ident = "BYT-T FFD8",
@@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
          },
          .driver_data = i8880_vars,
      },
+    {
+        .ident = "T101HA",
+        .matches = {
+            DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
+        },
+        .driver_data = asus_vars,
+    },
      {}
  };

>> Now we have the following in dmesg:
>>
>> [    8.815960] kernel: mc: Linux media interface: v0.10
>> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
>> [    8.876864] kernel: input: Intel HID events as
>> /devices/pci0000:00/INT33D5:00/input/input16
>> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40,
>> base_baud = 2764800) is a 16550A
>> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
>> channels
>> [    8.929818] kernel: atomisp_ov2680: module is from the staging
>> directory, the quality is unknown, you have been warned.
>> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
>> atomisp module subdev data.PMIC ID 1
>> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found,
>> using dummy regulator
>> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found,
>> using dummy regulator
> Did you apply this patch also?
>
> 	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940
>
> I guess this would get rid of the two above warnings.
>
The patch was already applied when I did the test width the driver - the 
warnings are also present with it.

But if I read the code correctly this is expected, as we try to get 
those regulators in any case - only if we have an error on two of them 
we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings 
for those two regulators I assume this worked.

f (pmic_id == PMIC_REGULATOR) {
         gmin_subdevs[i].v1p8_reg = regulator_get(dev, "V1P8SX");
         gmin_subdevs[i].v2p8_reg = regulator_get(dev, "V2P8SX");
         gmin_subdevs[i].v1p2_reg = regulator_get(dev, "V1P2A");
         gmin_subdevs[i].v2p8_vcm_reg = regulator_get(dev, "VPROG4B");

         /*
          * Based on DTST dumps on newer Atom E3800 devices, it seems that
          * the regulators data now have new names.
          */
         if (IS_ERR(gmin_subdevs[i].v1p8_reg))
             gmin_subdevs[i].v1p8_reg = regulator_get(dev, "Regulator1p8v");

         if (IS_ERR(gmin_subdevs[i].v2p8_reg))
             gmin_subdevs[i].v2p8_reg = regulator_get(dev, "Regulator2p8v");

>> [    8.989977] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found,
>> using dummy regulator
>> [    8.989998] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found,
>> using dummy regulator
>> [    9.033505] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>> [    9.061511] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 0
>> lanes: 1 order: 00000002
>> [    9.065178] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id =
>> 0x2680, rev= 0
>> [    9.071095] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c
>> module type 1
> We need to double check if everything is ok on the above.
>
> That's said, with the current code, I don't expect ISP2401 to work out
> of the box, as the Kernel is set for ISP2400. I'm trying to address
> this on my spare time.
Thanks - just let me know if I shall test anything on my side.
>> Laurent explained me how to enable internal debug messages. I'll read
>> more about this to understand how to use it and hope this will give a
>> more detailed insight.
>>
>>
>> great to see some progress :-),
> Yes!
>
>> thanks and kind regards,
>>
>> Patrik
>>
>>
>>> Thanks,
>>> Mauro
>
>
> Thanks,
> Mauro

with kind regards,

Patrik


[-- Attachment #2: asus.patch --]
[-- Type: text/x-patch, Size: 980 bytes --]

diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index eef7123a586f..081f9be6ec29 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
 	{},
 };
 
+static struct gmin_cfg_var asus_vars[] = {
+	{"OVTI2680:00_CsiPort", "0"},
+	{"OVTI2680:00_CsiLanes", "1"},
+	{"OVTI2680:00_CsiFmt", "15"},
+	{"OVTI2680:00_CsiBayer", "0"},
+	{"OVTI2680:00_CamClk", "1"},
+	{},
+};
+
 static const struct dmi_system_id gmin_vars[] = {
 	{
 		.ident = "BYT-T FFD8",
@@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
 		},
 		.driver_data = i8880_vars,
 	},
+	{
+		.ident = "T101HA",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
+		},
+		.driver_data = asus_vars,
+	},
 	{}
 };
 

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Tue, 28 Apr 2020 19:59:28 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 27.04.20 23:50, Mauro Carvalho Chehab wrote:
> > Em Mon, 27 Apr 2020 20:31:31 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:  
> >> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:  
> >>> No, you're looking at the wrong place. This should be at the system
> >>> board's BIOS, and not at something that the driver would load.
> >>>
> >>> Just run (as root):
> >>>
> >>> 	# dmidecode
> >>>
> >>> and check the name of your board. It should be similar to this:
> >>>
> >>> 	...
> >>> 	System Information
> >>> 	        Manufacturer: Intel Corporation
> >>> 	        Product Name: (something)
> >>>
> >>> The "(something)" is the board name. The atomisp driver will seek for
> >>> it. So, you need to patch the driver (using the example I gave) in
> >>> order for it to look at the right DMI_MATCH() table. Right now,
> >>> the driver knows only those:
> >>>
> >>> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
> >>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
> >>>
> >>> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
> >>> So, you should take a look on the patch I sent you and modify it to
> >>> match whatever name dmidecode printed.
> >>>
> >>> See for example this patch:
> >>>
> >>> 	https://www.spinics.net/lists/linux-media/msg126880.html
> >>>
> >>> If it finds the right table, it should end by calling gmin_subdev_add(),
> >>> with should use DTST table, also from the ACPI table inside the system's BIOS.  
> >> Now I understood :-). I've made the modifications as you explained and
> >> indeed the errors regarding
> >>
> >> OVTI2680:00_CamClk
> >> OVTI2680:00_ClkSrc
> >> OVTI2680:00_CsiPort
> >> OVTI2680:00_CsiLanes
> >>
> >> are gone.  
> > Great! Could you please submit the exact patch you applied? I'll place
> > it on my experimental tree:  
> 
> Here is the patch for the change I made:
> 
> diff --git 
> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> index eef7123a586f..081f9be6ec29 100644
> --- 
> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> +++ 
> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
>       {},
>   };
> 
> +static struct gmin_cfg_var asus_vars[] = {
> +    {"OVTI2680:00_CsiPort", "0"},
> +    {"OVTI2680:00_CsiLanes", "1"},
> +    {"OVTI2680:00_CsiFmt", "15"},
> +    {"OVTI2680:00_CsiBayer", "0"},
> +    {"OVTI2680:00_CamClk", "1"},
> +    {},
> +};
> +
>   static const struct dmi_system_id gmin_vars[] = {
>       {
>           .ident = "BYT-T FFD8",
> @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
>           },
>           .driver_data = i8880_vars,
>       },
> +    {
> +        .ident = "T101HA",
> +        .matches = {
> +            DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
> +        },
> +        .driver_data = asus_vars,
> +    },
>       {}
>   };

Thanks for testing it. Just applied this patch upstream, together with a
bunch of other cleanup patches.

> >> Now we have the following in dmesg:
> >>
> >> [    8.815960] kernel: mc: Linux media interface: v0.10
> >> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
> >> [    8.876864] kernel: input: Intel HID events as
> >> /devices/pci0000:00/INT33D5:00/input/input16
> >> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40,
> >> base_baud = 2764800) is a 16550A
> >> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
> >> channels
> >> [    8.929818] kernel: atomisp_ov2680: module is from the staging
> >> directory, the quality is unknown, you have been warned.
> >> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
> >> atomisp module subdev data.PMIC ID 1
> >> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found,
> >> using dummy regulator
> >> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found,
> >> using dummy regulator  
> > Did you apply this patch also?
> >
> > 	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940
> >
> > I guess this would get rid of the two above warnings.
> >  
> The patch was already applied when I did the test width the driver - the 
> warnings are also present with it.

Ok. Yet, I found an issue on that patch. Just merged an improvement.

Could you please test it again?

> 
> But if I read the code correctly this is expected, as we try to get 
> those regulators in any case - only if we have an error on two of them 
> we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings 
> for those two regulators I assume this worked.

No. It probably returned a valid "dummy" regulator. That's not what
we want.

There are still some things that could be missing for it to work
properly with ISP2401. I'm trying to do some cleanups in order to
be sure that everything needed for isp2401 will be there.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 29.04.20 01:13, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Apr 2020 19:59:28 +0200
> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>
>> On 27.04.20 23:50, Mauro Carvalho Chehab wrote:
>>> Em Mon, 27 Apr 2020 20:31:31 +0200
>>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>>>> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
>>>>> No, you're looking at the wrong place. This should be at the system
>>>>> board's BIOS, and not at something that the driver would load.
>>>>>
>>>>> Just run (as root):
>>>>>
>>>>> 	# dmidecode
>>>>>
>>>>> and check the name of your board. It should be similar to this:
>>>>>
>>>>> 	...
>>>>> 	System Information
>>>>> 	        Manufacturer: Intel Corporation
>>>>> 	        Product Name: (something)
>>>>>
>>>>> The "(something)" is the board name. The atomisp driver will seek for
>>>>> it. So, you need to patch the driver (using the example I gave) in
>>>>> order for it to look at the right DMI_MATCH() table. Right now,
>>>>> the driver knows only those:
>>>>>
>>>>> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
>>>>>
>>>>> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
>>>>> So, you should take a look on the patch I sent you and modify it to
>>>>> match whatever name dmidecode printed.
>>>>>
>>>>> See for example this patch:
>>>>>
>>>>> 	https://www.spinics.net/lists/linux-media/msg126880.html
>>>>>
>>>>> If it finds the right table, it should end by calling gmin_subdev_add(),
>>>>> with should use DTST table, also from the ACPI table inside the system's BIOS.
>>>> Now I understood :-). I've made the modifications as you explained and
>>>> indeed the errors regarding
>>>>
>>>> OVTI2680:00_CamClk
>>>> OVTI2680:00_ClkSrc
>>>> OVTI2680:00_CsiPort
>>>> OVTI2680:00_CsiLanes
>>>>
>>>> are gone.
>>> Great! Could you please submit the exact patch you applied? I'll place
>>> it on my experimental tree:
>> Here is the patch for the change I made:
>>
>> diff --git
>> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>> index eef7123a586f..081f9be6ec29 100644
>> ---
>> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>> +++
>> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
>>        {},
>>    };
>>
>> +static struct gmin_cfg_var asus_vars[] = {
>> +    {"OVTI2680:00_CsiPort", "0"},
>> +    {"OVTI2680:00_CsiLanes", "1"},
>> +    {"OVTI2680:00_CsiFmt", "15"},
>> +    {"OVTI2680:00_CsiBayer", "0"},
>> +    {"OVTI2680:00_CamClk", "1"},
>> +    {},
>> +};
>> +
>>    static const struct dmi_system_id gmin_vars[] = {
>>        {
>>            .ident = "BYT-T FFD8", @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] 
>> = {          },          .driver_data = i8880_vars,      }, +    { 
>> +        .ident = "T101HA",
>> +        .matches = {
>> +            DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
>> +        },
>> +        .driver_data = asus_vars,
>> +    },
>>        {}
>>    };
> Thanks for testing it. Just applied this patch upstream, together with a
> bunch of other cleanup patches.
>
>>>> Now we have the following in dmesg:
>>>>
>>>> [    8.815960] kernel: mc: Linux media interface: v0.10
>>>> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
>>>> [    8.876864] kernel: input: Intel HID events as
>>>> /devices/pci0000:00/INT33D5:00/input/input16
>>>> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40,
>>>> base_baud = 2764800) is a 16550A
>>>> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
>>>> channels
>>>> [    8.929818] kernel: atomisp_ov2680: module is from the staging
>>>> directory, the quality is unknown, you have been warned.
>>>> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
>>>> atomisp module subdev data.PMIC ID 1
>>>> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found,
>>>> using dummy regulator
>>>> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found,
>>>> using dummy regulator
>>> Did you apply this patch also?
>>>
>>> 	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940
>>>
>>> I guess this would get rid of the two above warnings.
>>>   
>> The patch was already applied when I did the test width the driver - the
>> warnings are also present with it.
> Ok. Yet, I found an issue on that patch. Just merged an improvement.
>
> Could you please test it again?

Of course - I pulled the changes and recompiled the kernel. This is  
what we see if I reboot the system:

Apr 29 19:49:04 ASUS kernel: [    8.821277] atomisp_ov2680: loading 
out-of-tree module taints kernel.
Apr 29 19:49:04 ASUS kernel: [    8.824016] atomisp_ov2680: module is 
from the staging directory, the quality is unknown, you have been warned.
Apr 29 19:49:04 ASUS kernel: [    8.945856] ov2680 i2c-OVTI2680:00: 
gmin: initializing atomisp module subdev data.PMIC ID 1
Apr 29 19:49:04 ASUS kernel: [    8.949070] ov2680 i2c-OVTI2680:00: 
supply V1P8SX not found, using dummy regulator
Apr 29 19:49:04 ASUS kernel: [    8.952036] ov2680 i2c-OVTI2680:00: 
supply V2P8SX not found, using dummy regulator
Apr 29 19:49:04 ASUS kernel: [    8.954893] ov2680 i2c-OVTI2680:00: 
supply V1P2A not found, using dummy regulator
Apr 29 19:49:04 ASUS kernel: [    8.957849] ov2680 i2c-OVTI2680:00: 
supply VPROG4B not found, using dummy regulator
Apr 29 19:49:04 ASUS kernel: [    9.013717] ov2680 i2c-OVTI2680:00: 
unable to set PMC rate 1
Apr 29 19:49:04 ASUS kernel: [    9.041777] ov2680 i2c-OVTI2680:00: 
camera pdata: port: 0 lanes: 1 order: 00000002
Apr 29 19:49:04 ASUS kernel: [    9.048368] ov2680 i2c-OVTI2680:00: 
sensor_revision id = 0x2680, rev= 0
Apr 29 19:49:04 ASUS kernel: [    9.051525] ov2680 i2c-OVTI2680:00: 
register atomisp i2c module type 1

I've also added the following boot parameter to make sure we get all 
debug messages from the module: dyndbg="module atomisp_ov2680 +pm" (as 
explained by Laurent)

I've checked the code of atomisp_ov2680 and there are some dev_dbg 
calls, but either I did the configuration not correct, or we do not 
reach those lines yet (or I looked at the wrong place; I checked dmesg 
and kern.log).

>> But if I read the code correctly this is expected, as we try to get
>> those regulators in any case - only if we have an error on two of them
>> we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings
>> for those two regulators I assume this worked.
> No. It probably returned a valid "dummy" regulator. That's not what
> we want.
>
> There are still some things that could be missing for it to work
> properly with ISP2401. I'm trying to do some cleanups in order to
> be sure that everything needed for isp2401 will be there.
Just let me know if I shall try something.
>
> Thanks,
> Mauro

kind regards,
Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Wed, 29 Apr 2020 19:56:49 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 29.04.20 01:13, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Apr 2020 19:59:28 +0200
> > Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
> >  
> >> On 27.04.20 23:50, Mauro Carvalho Chehab wrote:  
> >>> Em Mon, 27 Apr 2020 20:31:31 +0200
> >>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:  
> >>>> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:  
> >>>>> No, you're looking at the wrong place. This should be at the system
> >>>>> board's BIOS, and not at something that the driver would load.
> >>>>>
> >>>>> Just run (as root):
> >>>>>
> >>>>> 	# dmidecode
> >>>>>
> >>>>> and check the name of your board. It should be similar to this:
> >>>>>
> >>>>> 	...
> >>>>> 	System Information
> >>>>> 	        Manufacturer: Intel Corporation
> >>>>> 	        Product Name: (something)
> >>>>>
> >>>>> The "(something)" is the board name. The atomisp driver will seek for
> >>>>> it. So, you need to patch the driver (using the example I gave) in
> >>>>> order for it to look at the right DMI_MATCH() table. Right now,
> >>>>> the driver knows only those:
> >>>>>
> >>>>> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
> >>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
> >>>>>
> >>>>> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
> >>>>> So, you should take a look on the patch I sent you and modify it to
> >>>>> match whatever name dmidecode printed.
> >>>>>
> >>>>> See for example this patch:
> >>>>>
> >>>>> 	https://www.spinics.net/lists/linux-media/msg126880.html
> >>>>>
> >>>>> If it finds the right table, it should end by calling gmin_subdev_add(),
> >>>>> with should use DTST table, also from the ACPI table inside the system's BIOS.  
> >>>> Now I understood :-). I've made the modifications as you explained and
> >>>> indeed the errors regarding
> >>>>
> >>>> OVTI2680:00_CamClk
> >>>> OVTI2680:00_ClkSrc
> >>>> OVTI2680:00_CsiPort
> >>>> OVTI2680:00_CsiLanes
> >>>>
> >>>> are gone.  
> >>> Great! Could you please submit the exact patch you applied? I'll place
> >>> it on my experimental tree:  
> >> Here is the patch for the change I made:
> >>
> >> diff --git
> >> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >> index eef7123a586f..081f9be6ec29 100644
> >> ---
> >> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >> +++
> >> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> >> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
> >>        {},
> >>    };
> >>
> >> +static struct gmin_cfg_var asus_vars[] = {
> >> +    {"OVTI2680:00_CsiPort", "0"},
> >> +    {"OVTI2680:00_CsiLanes", "1"},
> >> +    {"OVTI2680:00_CsiFmt", "15"},
> >> +    {"OVTI2680:00_CsiBayer", "0"},
> >> +    {"OVTI2680:00_CamClk", "1"},
> >> +    {},
> >> +};
> >> +
> >>    static const struct dmi_system_id gmin_vars[] = {
> >>        {
> >>            .ident = "BYT-T FFD8", @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] 
> >> = {          },          .driver_data = i8880_vars,      }, +    { 
> >> +        .ident = "T101HA",
> >> +        .matches = {
> >> +            DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
> >> +        },
> >> +        .driver_data = asus_vars,
> >> +    },
> >>        {}
> >>    };  
> > Thanks for testing it. Just applied this patch upstream, together with a
> > bunch of other cleanup patches.
> >  
> >>>> Now we have the following in dmesg:
> >>>>
> >>>> [    8.815960] kernel: mc: Linux media interface: v0.10
> >>>> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
> >>>> [    8.876864] kernel: input: Intel HID events as
> >>>> /devices/pci0000:00/INT33D5:00/input/input16
> >>>> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40,
> >>>> base_baud = 2764800) is a 16550A
> >>>> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
> >>>> channels
> >>>> [    8.929818] kernel: atomisp_ov2680: module is from the staging
> >>>> directory, the quality is unknown, you have been warned.
> >>>> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
> >>>> atomisp module subdev data.PMIC ID 1
> >>>> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found,
> >>>> using dummy regulator
> >>>> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found,
> >>>> using dummy regulator  
> >>> Did you apply this patch also?
> >>>
> >>> 	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940
> >>>
> >>> I guess this would get rid of the two above warnings.
> >>>     
> >> The patch was already applied when I did the test width the driver - the
> >> warnings are also present with it.  
> > Ok. Yet, I found an issue on that patch. Just merged an improvement.
> >
> > Could you please test it again?  
> 
> Of course - I pulled the changes and recompiled the kernel. This is  
> what we see if I reboot the system:
> 
> Apr 29 19:49:04 ASUS kernel: [    8.821277] atomisp_ov2680: loading 
> out-of-tree module taints kernel.
> Apr 29 19:49:04 ASUS kernel: [    8.824016] atomisp_ov2680: module is 
> from the staging directory, the quality is unknown, you have been warned.
> Apr 29 19:49:04 ASUS kernel: [    8.945856] ov2680 i2c-OVTI2680:00: 
> gmin: initializing atomisp module subdev data.PMIC ID 1
> Apr 29 19:49:04 ASUS kernel: [    8.949070] ov2680 i2c-OVTI2680:00: 
> supply V1P8SX not found, using dummy regulator
> Apr 29 19:49:04 ASUS kernel: [    8.952036] ov2680 i2c-OVTI2680:00: 
> supply V2P8SX not found, using dummy regulator

The above don't sound right. 

I changed the logic to use regulator_get_optional():

               gmin_subdevs[i].v1p8_reg = regulator_get_optional(dev, "V1P8SX");
               gmin_subdevs[i].v2p8_reg = regulator_get_optional(dev, "V2P8SX");

With that, probing to "V1P8SX" and "V2P8SX" wouldn't print any messages.

So, I suspect that either you're missing patches on your tree or
you booted an older Kernel.

The last patch on my tree is currently this one:

	commit 4c922df10252f4bd3f28187eba36056aa3c3c06e (experimental/atomisp)
	Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
	Date:   Wed Apr 29 11:50:52 2020 +0200

	    media: atomisp2: get rid of ia_css_sc_param.h version dependency

> Apr 29 19:49:04 ASUS kernel: [    8.954893] ov2680 i2c-OVTI2680:00: 
> supply V1P2A not found, using dummy regulator
> Apr 29 19:49:04 ASUS kernel: [    8.957849] ov2680 i2c-OVTI2680:00: 
> supply VPROG4B not found, using dummy regulator
> Apr 29 19:49:04 ASUS kernel: [    9.013717] ov2680 i2c-OVTI2680:00: 
> unable to set PMC rate 1
> Apr 29 19:49:04 ASUS kernel: [    9.041777] ov2680 i2c-OVTI2680:00: 
> camera pdata: port: 0 lanes: 1 order: 00000002
> Apr 29 19:49:04 ASUS kernel: [    9.048368] ov2680 i2c-OVTI2680:00: 
> sensor_revision id = 0x2680, rev= 0
> Apr 29 19:49:04 ASUS kernel: [    9.051525] ov2680 i2c-OVTI2680:00: 
> register atomisp i2c module type 1
> 
> I've also added the following boot parameter to make sure we get all 
> debug messages from the module: dyndbg="module atomisp_ov2680 +pm" (as 
> explained by Laurent)
> 
> I've checked the code of atomisp_ov2680 and there are some dev_dbg 
> calls, but either I did the configuration not correct, or we do not 
> reach those lines yet (or I looked at the wrong place; I checked dmesg 
> and kern.log).

Maybe you built your Kernel without dyndbg support. The kernel needs
this at .config:

CONFIG_DYNAMIC_DEBUG=y

This depends on those symbols:
	CONFIG_PRINTK [=y] && (CONFIG_DEBUG_FS [=y] || CONFIG_PROC_FS [=y])    
	

> 
> >> But if I read the code correctly this is expected, as we try to get
> >> those regulators in any case - only if we have an error on two of them
> >> we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings
> >> for those two regulators I assume this worked.  
> > No. It probably returned a valid "dummy" regulator. That's not what
> > we want.
> >
> > There are still some things that could be missing for it to work
> > properly with ISP2401. I'm trying to do some cleanups in order to
> > be sure that everything needed for isp2401 will be there.  
> Just let me know if I shall try something.

Sure.


Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 29.04.20 20:17, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Apr 2020 19:56:49 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> On 29.04.20 01:13, Mauro Carvalho Chehab wrote:
>>> Em Tue, 28 Apr 2020 19:59:28 +0200
>>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>>>   
>>>> On 27.04.20 23:50, Mauro Carvalho Chehab wrote:
>>>>> Em Mon, 27 Apr 2020 20:31:31 +0200
>>>>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>>>>>> On 26.04.20 18:50, Mauro Carvalho Chehab wrote:
>>>>>>> No, you're looking at the wrong place. This should be at the system
>>>>>>> board's BIOS, and not at something that the driver would load.
>>>>>>>
>>>>>>> Just run (as root):
>>>>>>>
>>>>>>> 	# dmidecode
>>>>>>>
>>>>>>> and check the name of your board. It should be similar to this:
>>>>>>>
>>>>>>> 	...
>>>>>>> 	System Information
>>>>>>> 	        Manufacturer: Intel Corporation
>>>>>>> 	        Product Name: (something)
>>>>>>>
>>>>>>> The "(something)" is the board name. The atomisp driver will seek for
>>>>>>> it. So, you need to patch the driver (using the example I gave) in
>>>>>>> order for it to look at the right DMI_MATCH() table. Right now,
>>>>>>> the driver knows only those:
>>>>>>>
>>>>>>> 	$ git grep DMI_MATCH drivers/staging/media/atomisp/
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "TABLET"),	
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
>>>>>>> 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:                       DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
>>>>>>>
>>>>>>> Your asus board should likely use "ASUS", "_ASUS_" or something similar.
>>>>>>> So, you should take a look on the patch I sent you and modify it to
>>>>>>> match whatever name dmidecode printed.
>>>>>>>
>>>>>>> See for example this patch:
>>>>>>>
>>>>>>> 	https://www.spinics.net/lists/linux-media/msg126880.html
>>>>>>>
>>>>>>> If it finds the right table, it should end by calling gmin_subdev_add(),
>>>>>>> with should use DTST table, also from the ACPI table inside the system's BIOS.
>>>>>> Now I understood :-). I've made the modifications as you explained and
>>>>>> indeed the errors regarding
>>>>>>
>>>>>> OVTI2680:00_CamClk
>>>>>> OVTI2680:00_ClkSrc
>>>>>> OVTI2680:00_CsiPort
>>>>>> OVTI2680:00_CsiLanes
>>>>>>
>>>>>> are gone.
>>>>> Great! Could you please submit the exact patch you applied? I'll place
>>>>> it on my experimental tree:
>>>> Here is the patch for the change I made:
>>>>
>>>> diff --git
>>>> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>>>> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>>>> index eef7123a586f..081f9be6ec29 100644
>>>> ---
>>>> a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>>>> +++
>>>> b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
>>>> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
>>>>         {},
>>>>     };
>>>>
>>>> +static struct gmin_cfg_var asus_vars[] = {
>>>> +    {"OVTI2680:00_CsiPort", "0"},
>>>> +    {"OVTI2680:00_CsiLanes", "1"},
>>>> +    {"OVTI2680:00_CsiFmt", "15"},
>>>> +    {"OVTI2680:00_CsiBayer", "0"},
>>>> +    {"OVTI2680:00_CamClk", "1"},
>>>> +    {},
>>>> +};
>>>> +
>>>>     static const struct dmi_system_id gmin_vars[] = {
>>>>         {
>>>>             .ident = "BYT-T FFD8", @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[]
>>>> = {          },          .driver_data = i8880_vars,      }, +    {
>>>> +        .ident = "T101HA",
>>>> +        .matches = {
>>>> +            DMI_MATCH(DMI_BOARD_NAME, "T101HA"),
>>>> +        },
>>>> +        .driver_data = asus_vars,
>>>> +    },
>>>>         {}
>>>>     };
>>> Thanks for testing it. Just applied this patch upstream, together with a
>>> bunch of other cleanup patches.
>>>   
>>>>>> Now we have the following in dmesg:
>>>>>>
>>>>>> [    8.815960] kernel: mc: Linux media interface: v0.10
>>>>>> [    8.858458] kernel: videodev: Linux video capture interface: v2.00
>>>>>> [    8.876864] kernel: input: Intel HID events as
>>>>>> /devices/pci0000:00/INT33D5:00/input/input16
>>>>>> [    8.887625] kernel: 8086228A:01: ttyS5 at MMIO 0x91a1f000 (irq = 40,
>>>>>> base_baud = 2764800) is a 16550A
>>>>>> [    8.894655] kernel: dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
>>>>>> channels
>>>>>> [    8.929818] kernel: atomisp_ov2680: module is from the staging
>>>>>> directory, the quality is unknown, you have been warned.
>>>>>> [    8.989630] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing
>>>>>> atomisp module subdev data.PMIC ID 1
>>>>>> [    8.989887] kernel: ov2680 i2c-OVTI2680:00: supply V1P8SX not found,
>>>>>> using dummy regulator
>>>>>> [    8.989954] kernel: ov2680 i2c-OVTI2680:00: supply V2P8SX not found,
>>>>>> using dummy regulator
>>>>> Did you apply this patch also?
>>>>>
>>>>> 	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp&id=898564642042fdd136a16c3ee120a00061c13940
>>>>>
>>>>> I guess this would get rid of the two above warnings.
>>>>>      
>>>> The patch was already applied when I did the test width the driver - the
>>>> warnings are also present with it.
>>> Ok. Yet, I found an issue on that patch. Just merged an improvement.
>>>
>>> Could you please test it again?
>> Of course - I pulled the changes and recompiled the kernel. This is
>> what we see if I reboot the system:
>>
>> Apr 29 19:49:04 ASUS kernel: [    8.821277] atomisp_ov2680: loading
>> out-of-tree module taints kernel.
>> Apr 29 19:49:04 ASUS kernel: [    8.824016] atomisp_ov2680: module is
>> from the staging directory, the quality is unknown, you have been warned.
>> Apr 29 19:49:04 ASUS kernel: [    8.945856] ov2680 i2c-OVTI2680:00:
>> gmin: initializing atomisp module subdev data.PMIC ID 1
>> Apr 29 19:49:04 ASUS kernel: [    8.949070] ov2680 i2c-OVTI2680:00:
>> supply V1P8SX not found, using dummy regulator
>> Apr 29 19:49:04 ASUS kernel: [    8.952036] ov2680 i2c-OVTI2680:00:
>> supply V2P8SX not found, using dummy regulator
> The above don't sound right.
>
> I changed the logic to use regulator_get_optional():
>
>                 gmin_subdevs[i].v1p8_reg = regulator_get_optional(dev, "V1P8SX");
>                 gmin_subdevs[i].v2p8_reg = regulator_get_optional(dev, "V2P8SX");
>
> With that, probing to "V1P8SX" and "V2P8SX" wouldn't print any messages.
>
> So, I suspect that either you're missing patches on your tree or
> you booted an older Kernel.
>
> The last patch on my tree is currently this one:
>
> 	commit 4c922df10252f4bd3f28187eba36056aa3c3c06e (experimental/atomisp)
> 	Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> 	Date:   Wed Apr 29 11:50:52 2020 +0200
>
> 	    media: atomisp2: get rid of ia_css_sc_param.h version dependency
For my first test tried to re-compile to module, without the whole 
kernel. That was a mistake, as I mixed something up, probably it loaded 
an old version of the module ... to be on the save side the steps I used 
this time (in case we see something unexpected and for my later reference):

$ git log --oneline
4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid 
of ia_css_sc_param.h version dependency
...

$ make -j4 clean
$ make -j4
$ sudo make modules_install INSTALL_MOD_STRIP=1
$ sudo make install

I configured the following boot parameters:
linux    /boot/vmlinuz-5.7.0-rc1+ 
root=UUID=7c547d86-dd95-4cb2-b7ad-e46368c8eed3 ro  ignore_loglevel 
verbose fbcon=rotate:1 module_blacklist=intel_atomisp2_pm dyndbg="module 
atomisp_ov2680 +pm; module atomisp +pm"

This produces the following log:

[    9.111674] kernel: mc: Linux media interface: v0.10
[    9.177076] kernel: videodev: Linux video capture interface: v2.00
[    9.248302] kernel: atomisp_ov2680: module is from the staging 
directory, the quality is unknown, you have been warned.
[    9.303134] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
atomisp module subdev data.PMIC ID 1
[    9.309529] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
using dummy regulator
[    9.312532] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
using dummy regulator
[    9.317966] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v not 
found, using dummy regulator
[    9.321119] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v not 
found, using dummy regulator
[    9.378805] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.406807] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 1 
lanes: 1 order: 00000002
[    9.410458] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
0x2680, rev= 0
[    9.414680] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
module type 1

Strange that it did not find the regulators 1p8v and 2p8v; as they are 
in the ACPI information:

Local0 = Package (0x12)
                         {
                             "CamId",
                             "ov2680",
                             "CamType",
                             "1",
                             "CsiPort",
                             "0",
                             "CsiLanes",
                             "1",
                             "CsiFmt",
                             "15",
                             "CsiBayer",
                             "0",
                             "CamClk",
                             "1",
                             "Regulator1p8v",
                             "0",
                             "Regulator2p8v",
                             "0"
                         }
>> Apr 29 19:49:04 ASUS kernel: [    8.954893] ov2680 i2c-OVTI2680:00:
>> supply V1P2A not found, using dummy regulator
>> Apr 29 19:49:04 ASUS kernel: [    8.957849] ov2680 i2c-OVTI2680:00:
>> supply VPROG4B not found, using dummy regulator
>> Apr 29 19:49:04 ASUS kernel: [    9.013717] ov2680 i2c-OVTI2680:00:
>> unable to set PMC rate 1
>> Apr 29 19:49:04 ASUS kernel: [    9.041777] ov2680 i2c-OVTI2680:00:
>> camera pdata: port: 0 lanes: 1 order: 00000002
>> Apr 29 19:49:04 ASUS kernel: [    9.048368] ov2680 i2c-OVTI2680:00:
>> sensor_revision id = 0x2680, rev= 0
>> Apr 29 19:49:04 ASUS kernel: [    9.051525] ov2680 i2c-OVTI2680:00:
>> register atomisp i2c module type 1
>>
>> I've also added the following boot parameter to make sure we get all
>> debug messages from the module: dyndbg="module atomisp_ov2680 +pm" (as
>> explained by Laurent)
>>
>> I've checked the code of atomisp_ov2680 and there are some dev_dbg
>> calls, but either I did the configuration not correct, or we do not
>> reach those lines yet (or I looked at the wrong place; I checked dmesg
>> and kern.log).
> Maybe you built your Kernel without dyndbg support. The kernel needs
> this at .config:
>
> CONFIG_DYNAMIC_DEBUG=y
>
> This depends on those symbols:
> 	CONFIG_PRINTK [=y] && (CONFIG_DEBUG_FS [=y] || CONFIG_PROC_FS [=y])
> 	

I checked the dynamic debug configuration - looks ok to me:

$ sudo cat /sys/kernel/debug/dynamic_debug/control | grep ov2680
...
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:329 
[atomisp_ov2680]ov2680_get_intg_factor =_ "++++ov2680_get_intg_factor\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:314 
[atomisp_ov2680]ov2680_g_bin_factor_y =_ "++++ov2680_g_bin_factor_y\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:302 
[atomisp_ov2680]ov2680_g_bin_factor_x =_ "++++ov2680_g_bin_factor_x\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:255 
[atomisp_ov2680]ov2680_write_reg_array =_ "+++ov2680_write_reg_array 
reg=%x->%x\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:239 
[atomisp_ov2680]ov2680_write_reg_array =_ "++++write reg array\012"

So I assume it accepted the boot parameter and we just do not hit debug 
calls yet. I'll try to add a test debug call a suggested by Laurent 
(I've sine details to figure out first on what the 1st parameter is).

>>>> But if I read the code correctly this is expected, as we try to get
>>>> those regulators in any case - only if we have an error on two of them
>>>> we try the "Regulator1p8v" & "Regulator2p8v". As we do not see warnings
>>>> for those two regulators I assume this worked.
>>> No. It probably returned a valid "dummy" regulator. That's not what
>>> we want.
>>>
>>> There are still some things that could be missing for it to work
>>> properly with ISP2401. I'm trying to do some cleanups in order to
>>> be sure that everything needed for isp2401 will be there.
>> Just let me know if I shall try something.
> Sure.
>
>
> Thanks,
> Mauro

with kind regards,

Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Thu, 30 Apr 2020 09:56:53 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> For my first test tried to re-compile to module, without the whole 
> kernel. That was a mistake, as I mixed something up, probably it loaded 
> an old version of the module ... to be on the save side the steps I used 
> this time (in case we see something unexpected and for my later reference):
> 
> $ git log --oneline
> 4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid 
> of ia_css_sc_param.h version dependency
> ...
> 
> $ make -j4 clean
> $ make -j4
> $ sudo make modules_install INSTALL_MOD_STRIP=1
> $ sudo make install

Please try to build from this branch:

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

You'll need to setup a new config var there. So, please run this before
make clean. So, for building it, you will do:

	$ ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make -j modules_prepare
	$ make -j4 clean && make -j4
	$ sudo make modules_install INSTALL_MOD_STRIP=1 && sudo make install

This won't change the regulator detection, but it should hopefully use
the ISP2401-specific code, with seems to be needed for your device.

Ah, when replying, could you please use an emailer that won't be breaking
long lines? Your emailer is currently breaking lines longer than 80 columns,
with is quite annoying when checking log results ;-)

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]


Am 4/30/2020 um 12:55 PM schrieb Mauro Carvalho Chehab:
> Em Thu, 30 Apr 2020 09:56:53 +0200
> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>
>> For my first test tried to re-compile to module, without the whole
>> kernel. That was a mistake, as I mixed something up, probably it loaded
>> an old version of the module ... to be on the save side the steps I used
>> this time (in case we see something unexpected and for my later reference):
>>
>> $ git log --oneline
>> 4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid
>> of ia_css_sc_param.h version dependency
>> ...
>>
>> $ make -j4 clean
>> $ make -j4
>> $ sudo make modules_install INSTALL_MOD_STRIP=1
>> $ sudo make install
> Please try to build from this branch:
>
> 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2
>
> You'll need to setup a new config var there. So, please run this before
> make clean. So, for building it, you will do:
>
> 	$ ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make -j modules_prepare
> 	$ make -j4 clean && make -j4
> 	$ sudo make modules_install INSTALL_MOD_STRIP=1 && sudo make install
>
> This won't change the regulator detection, but it should hopefully use
> the ISP2401-specific code, with seems to be needed for your device.

I've updated to the latest source (git checkout atomisp_v2 && git pull) 
and compiled using the instructions above. Compilation worked well, but 
the linker had some problems (full log attached):

...
ld: 
drivers/staging/media/atomisp/pci/css_2401_system/hive_isp_css_2401_system_generated/ia_css_isp_states.o:(.data+0x0): 
multiple definition of `ia_css_kernel_init_state'; 
drivers/staging/media/atomisp/pci/css_2401_csi2p_system/hive_isp_css_2401_system_csi2p_generated/ia_css_isp_states.o:(.data+0x0): 
first defined here
...

Not sure if I can help with that. Sounds like we have to remove 
definitions - which I might be able to do. But I would need to know 
where the right place is to keep the definitions. If a code generator is 
involved (one of the paths looks like it) it will be more difficult for 
me. But with some hints I'm of course willing to give it a shot. Please 
give me an example of a definition) and a hint in case we deal with 
generated code.

> Ah, when replying, could you please use an emailer that won't be breaking
> long lines? Your emailer is currently breaking lines longer than 80 columns,
> with is quite annoying when checking log results ;-)
I changed the configuration of my mail client; a test message looked ok. 
Let me know if the problem persists.
>
> Thanks,
> Mauro

with kind regards
Patrik


[-- Attachment #2: linker.txt.tar.gz --]
[-- Type: application/gzip, Size: 1539 bytes --]

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Thu, 30 Apr 2020 17:09:48 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> Am 4/30/2020 um 12:55 PM schrieb Mauro Carvalho Chehab:
> > Em Thu, 30 Apr 2020 09:56:53 +0200
> > Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
> >  
> >> For my first test tried to re-compile to module, without the whole
> >> kernel. That was a mistake, as I mixed something up, probably it loaded
> >> an old version of the module ... to be on the save side the steps I used
> >> this time (in case we see something unexpected and for my later reference):
> >>
> >> $ git log --oneline
> >> 4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid
> >> of ia_css_sc_param.h version dependency
> >> ...
> >>
> >> $ make -j4 clean
> >> $ make -j4
> >> $ sudo make modules_install INSTALL_MOD_STRIP=1
> >> $ sudo make install  
> > Please try to build from this branch:
> >
> > 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2
> >
> > You'll need to setup a new config var there. So, please run this before
> > make clean. So, for building it, you will do:
> >
> > 	$ ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make -j modules_prepare
> > 	$ make -j4 clean && make -j4
> > 	$ sudo make modules_install INSTALL_MOD_STRIP=1 && sudo make install
> >
> > This won't change the regulator detection, but it should hopefully use
> > the ISP2401-specific code, with seems to be needed for your device.  
> 
> I've updated to the latest source (git checkout atomisp_v2 && git pull) 
> and compiled using the instructions above. Compilation worked well, but 
> the linker had some problems (full log attached):
> 
> ...
> ld: 
> drivers/staging/media/atomisp/pci/css_2401_system/hive_isp_css_2401_system_generated/ia_css_isp_states.o:(.data+0x0): 
> multiple definition of `ia_css_kernel_init_state'; 
> drivers/staging/media/atomisp/pci/css_2401_csi2p_system/hive_isp_css_2401_system_csi2p_generated/ia_css_isp_states.o:(.data+0x0): 
> first defined here
> ...

Ok. That's because there are two "hive" variants. the building system
should use either one of them (but not both at the same time).

I didn't get the error before because I was just building a module
(that speeds up the development). Such errors only happen on a full 
build.

Fixed.

As I did a git rebase (in order to have something that we could
upstream later), you'll need to use this procedure to update:

	$ git remote update
	$ git reset --hard origin/atomisp_v2

There's no need to clean your last build. Just run:

	$ make -j4 

And it should build fine this time.

> 
> Not sure if I can help with that. Sounds like we have to remove 
> definitions - which I might be able to do. But I would need to know 
> where the right place is to keep the definitions.

> If a code generator is 
> involved (one of the paths looks like it) it will be more difficult for 
> me.

Intel seems to use some code generator internally. Basically, for each
specific device, it can remove/add/change things. Don't mind about that.

For us, we're seeing just the generated code and working to simplify it
and making it more generic.

> But with some hints I'm of course willing to give it a shot. Please 
> give me an example of a definition) and a hint in case we deal with 
> generated code.
> 
> > Ah, when replying, could you please use an emailer that won't be breaking
> > long lines? Your emailer is currently breaking lines longer than 80 columns,
> > with is quite annoying when checking log results ;-)  
> I changed the configuration of my mail client; a test message looked ok. 
> Let me know if the problem persists.

Yeah, is is fine now. Thanks!

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 01.05.20 00:25, Mauro Carvalho Chehab wrote:
> Em Thu, 30 Apr 2020 17:09:48 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> Am 4/30/2020 um 12:55 PM schrieb Mauro Carvalho Chehab:
>>> Em Thu, 30 Apr 2020 09:56:53 +0200
>>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
>>>   
>>>> For my first test tried to re-compile to module, without the whole
>>>> kernel. That was a mistake, as I mixed something up, probably it loaded
>>>> an old version of the module ... to be on the save side the steps I used
>>>> this time (in case we see something unexpected and for my later reference):
>>>>
>>>> $ git log --oneline
>>>> 4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid
>>>> of ia_css_sc_param.h version dependency
>>>> ...
>>>>
>>>> $ make -j4 clean
>>>> $ make -j4
>>>> $ sudo make modules_install INSTALL_MOD_STRIP=1
>>>> $ sudo make install
>>> Please try to build from this branch:
>>>
>>> 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2
>>>
>>> You'll need to setup a new config var there. So, please run this before
>>> make clean. So, for building it, you will do:
>>>
>>> 	$ ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make -j modules_prepare
>>> 	$ make -j4 clean && make -j4
>>> 	$ sudo make modules_install INSTALL_MOD_STRIP=1 && sudo make install
>>>
>>> This won't change the regulator detection, but it should hopefully use
>>> the ISP2401-specific code, with seems to be needed for your device.
>> I've updated to the latest source (git checkout atomisp_v2 && git pull)
>> and compiled using the instructions above. Compilation worked well, but
>> the linker had some problems (full log attached):
>>
>> ...
>> ld:
>> drivers/staging/media/atomisp/pci/css_2401_system/hive_isp_css_2401_system_generated/ia_css_isp_states.o:(.data+0x0):
>> multiple definition of `ia_css_kernel_init_state';
>> drivers/staging/media/atomisp/pci/css_2401_csi2p_system/hive_isp_css_2401_system_csi2p_generated/ia_css_isp_states.o:(.data+0x0):
>> first defined here
>> ...
> Ok. That's because there are two "hive" variants. the building system
> should use either one of them (but not both at the same time).
>
> I didn't get the error before because I was just building a module
> (that speeds up the development). Such errors only happen on a full
> build.
>
> Fixed.
>
> As I did a git rebase (in order to have something that we could
> upstream later), you'll need to use this procedure to update:
>
> 	$ git remote update
> 	$ git reset --hard origin/atomisp_v2
>
> There's no need to clean your last build. Just run:
>
> 	$ make -j4
>
> And it should build fine this time.

Compiled and linked :-). We get some more output this time:

[    9.120066] kernel: videodev: Linux video capture interface: v2.00

[    9.141554] kernel: atomisp_ov2680: module is from the staging 
directory, the quality is unknown, you have been warned.
[    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
atomisp module subdev data.PMIC ID 1
[    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
using dummy regulator
[    9.189966] kernel: proc_thermal 0000:00:0b.0: enabling device (0000 
-> 0002)
[    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
using dummy regulator
[    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v not 
found, using dummy regulator
[    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs group 
for PROC_THERMAL_PCI
[    9.238185] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v not 
found, using dummy regulator
[    9.337925] kernel: atomisp: module is from the staging directory, 
the quality is unknown, you have been warned.
[    9.404666] kernel: atomisp-isp2 0000:00:03.0: enabling device (0000 
-> 0002)
[    9.408680] kernel: atomisp-isp2 0000:00:03.0: ISP HPLL frequency 
base = 1600 MHz
[    9.412197] kernel: atomisp-isp2 0000:00:03.0: Unsupported 
hw_revision 0x2010
[    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed with 
error -2
[    9.419377] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.458987] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 1 
lanes: 1 order: 00000002
[    9.460049] kernel: atomisp_ov2680: module is from the staging 
directory, the quality is unknown, you have been warned.
[    9.463221] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 
0x2680, rev= 0
[    9.503230] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c 
module type 1
>> Not sure if I can help with that. Sounds like we have to remove
>> definitions - which I might be able to do. But I would need to know
>> where the right place is to keep the definitions.
>> If a code generator is
>> involved (one of the paths looks like it) it will be more difficult for
>> me.
> Intel seems to use some code generator internally. Basically, for each
> specific device, it can remove/add/change things. Don't mind about that.
>
> For us, we're seeing just the generated code and working to simplify it
> and making it more generic.
So the original code is from intel itself? I currently have an open 
support request to get access to the information we need. Maybe it is 
helpful if I can let them know the code was from them in the first 
place. I'll check the history to find who from intel contributed.
>
>> But with some hints I'm of course willing to give it a shot. Please
>> give me an example of a definition) and a hint in case we deal with
>> generated code.
>>
>>> Ah, when replying, could you please use an emailer that won't be breaking
>>> long lines? Your emailer is currently breaking lines longer than 80 columns,
>>> with is quite annoying when checking log results ;-)
>> I changed the configuration of my mail client; a test message looked ok.
>> Let me know if the problem persists.
> Yeah, is is fine now. Thanks!
>
> Thanks,
> Mauro

with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Fri, 1 May 2020 10:54:18 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 01.05.20 00:25, Mauro Carvalho Chehab wrote:
> > Em Thu, 30 Apr 2020 17:09:48 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >  
> >> Am 4/30/2020 um 12:55 PM schrieb Mauro Carvalho Chehab:  
> >>> Em Thu, 30 Apr 2020 09:56:53 +0200
> >>> Patrik Gfeller<patrik.gfeller@gmail.com>  escreveu:
> >>>     
> >>>> For my first test tried to re-compile to module, without the whole
> >>>> kernel. That was a mistake, as I mixed something up, probably it loaded
> >>>> an old version of the module ... to be on the save side the steps I used
> >>>> this time (in case we see something unexpected and for my later reference):
> >>>>
> >>>> $ git log --oneline
> >>>> 4c922df10252 (HEAD -> atomisp, origin/atomisp) media: atomisp2: get rid
> >>>> of ia_css_sc_param.h version dependency
> >>>> ...
> >>>>
> >>>> $ make -j4 clean
> >>>> $ make -j4
> >>>> $ sudo make modules_install INSTALL_MOD_STRIP=1
> >>>> $ sudo make install  
> >>> Please try to build from this branch:
> >>>
> >>> 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2
> >>>
> >>> You'll need to setup a new config var there. So, please run this before
> >>> make clean. So, for building it, you will do:
> >>>
> >>> 	$ ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make -j modules_prepare
> >>> 	$ make -j4 clean && make -j4
> >>> 	$ sudo make modules_install INSTALL_MOD_STRIP=1 && sudo make install
> >>>
> >>> This won't change the regulator detection, but it should hopefully use
> >>> the ISP2401-specific code, with seems to be needed for your device.  
> >> I've updated to the latest source (git checkout atomisp_v2 && git pull)
> >> and compiled using the instructions above. Compilation worked well, but
> >> the linker had some problems (full log attached):
> >>
> >> ...
> >> ld:
> >> drivers/staging/media/atomisp/pci/css_2401_system/hive_isp_css_2401_system_generated/ia_css_isp_states.o:(.data+0x0):
> >> multiple definition of `ia_css_kernel_init_state';
> >> drivers/staging/media/atomisp/pci/css_2401_csi2p_system/hive_isp_css_2401_system_csi2p_generated/ia_css_isp_states.o:(.data+0x0):
> >> first defined here
> >> ...  
> > Ok. That's because there are two "hive" variants. the building system
> > should use either one of them (but not both at the same time).
> >
> > I didn't get the error before because I was just building a module
> > (that speeds up the development). Such errors only happen on a full
> > build.
> >
> > Fixed.
> >
> > As I did a git rebase (in order to have something that we could
> > upstream later), you'll need to use this procedure to update:
> >
> > 	$ git remote update
> > 	$ git reset --hard origin/atomisp_v2
> >
> > There's no need to clean your last build. Just run:
> >
> > 	$ make -j4
> >
> > And it should build fine this time.  
> 
> Compiled and linked :-). We get some more output this time:

Good!

> 
> [    9.120066] kernel: videodev: Linux video capture interface: v2.00
> 
> [    9.141554] kernel: atomisp_ov2680: module is from the staging 
> directory, the quality is unknown, you have been warned.

Hmm.. your e-mailer is breaking long lines again  :-(

> [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing 
> atomisp module subdev data.PMIC ID 1
> [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, 
> using dummy regulator
> [    9.189966] kernel: proc_thermal 0000:00:0b.0: enabling device (0000 
> -> 0002)  
> [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, 
> using dummy regulator
> [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v not 
> found, using dummy regulator

I'll check this.

> [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs group 
> for PROC_THERMAL_PCI
> [    9.238185] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v not 
> found, using dummy regulator
> [    9.337925] kernel: atomisp: module is from the staging directory, 
> the quality is unknown, you have been warned.
> [    9.404666] kernel: atomisp-isp2 0000:00:03.0: enabling device (0000 
> -> 0002)  
> [    9.408680] kernel: atomisp-isp2 0000:00:03.0: ISP HPLL frequency 
> base = 1600 MHz
> [    9.412197] kernel: atomisp-isp2 0000:00:03.0: Unsupported 
> hw_revision 0x2010

This is related to firmware load stuff. The code use those macros:

	#define ATOMISP_HW_REVISION_MASK	0x0000ff00
	#define ATOMISP_HW_REVISION_SHIFT	8
	#define ATOMISP_HW_REVISION_ISP2300	0x00
	#define ATOMISP_HW_REVISION_ISP2400	0x10
	#define ATOMISP_HW_REVISION_ISP2401_LEGACY 0x11
	#define ATOMISP_HW_REVISION_ISP2401	0x20

	#define ATOMISP_HW_STEPPING_MASK	0x000000ff
	#define ATOMISP_HW_STEPPING_A0		0x00
	#define ATOMISP_HW_STEPPING_B0		0x10

According with the above, 0x2010 would mean ISP2401-B0.

The code itself check those macros in order to load the right firmware:

        if (isp->media_dev.hw_revision ==
            ((ATOMISP_HW_REVISION_ISP2401 << ATOMISP_HW_REVISION_SHIFT)
             | ATOMISP_HW_STEPPING_A0))
                fw_path = "shisp_2401a0_v21.bin";

        if (isp->media_dev.hw_revision ==
            ((ATOMISP_HW_REVISION_ISP2401_LEGACY << ATOMISP_HW_REVISION_SHIFT)
             | ATOMISP_HW_STEPPING_A0))
                fw_path = "shisp_2401a0_legacy_v21.bin";

        if (isp->media_dev.hw_revision ==
            ((ATOMISP_HW_REVISION_ISP2400 << ATOMISP_HW_REVISION_SHIFT)
             | ATOMISP_HW_STEPPING_B0))
                fw_path = "shisp_2400b0_v21.bin";

        if (!fw_path) {
                dev_err(isp->dev, "Unsupported hw_revision 0x%x\n",
                        isp->media_dev.hw_revision);
                return NULL;
        }

It sounds that we need to add:

        if (isp->media_dev.hw_revision ==
            ((ATOMISP_HW_REVISION_ISP2401 << ATOMISP_HW_REVISION_SHIFT)
             | ATOMISP_HW_STEPPING_B0))
                fw_path = "shisp_2401b0_v21.bin";

Eventually, other changes may be needed, depending on how different is
this B0 revision from A0.

Patch for it pushed. Please notice that it will seek for a firmware
named "shisp_2401b0_v21.bin".

This driver will also check if the firmware version is:

	"irci_ecr - master_20150911_0724"

As far as I know, the firmware is linked to the driver's code. 
So, supporting a different firmware version will likely require
changes at the driver.

> [    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed with 
> error -2

That's because it didn't load the firmware.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

[-- Attachment #1: Type: text/plain, Size: 10224 bytes --]

On Fri, 1 May 2020 11:38:12 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Em Fri, 1 May 2020 10:54:18 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> > 
> > Compiled and linked :-). We get some more output this time:  
> 
> Good!
> 
>  [...]  
> 
> Hmm.. your e-mailer is breaking long lines again  :-(

Ok - then the configuration option I used is not reliable. I've now switched to Claws Mail; I hope this resolves the problem.

> 
> > [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
> > [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> > found, using dummy regulator [    9.189966] kernel: proc_thermal
> > 0000:00:0b.0: enabling device (0000 -> 0002)    
> > [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> > found, using dummy regulator
> > [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v
> > not found, using dummy regulator  
> 
> I'll check this.
> 
> > [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs
> > group for PROC_THERMAL_PCI
> > [    9.238185] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v
> > not found, using dummy regulator
> > [    9.337925] kernel: atomisp: module is from the staging
> > directory, the quality is unknown, you have been warned.
> > [    9.404666] kernel: atomisp-isp2 0000:00:03.0: enabling device
> > (0000 -> 0002)    
> > [    9.408680] kernel: atomisp-isp2 0000:00:03.0: ISP HPLL
> > frequency base = 1600 MHz
> > [    9.412197] kernel: atomisp-isp2 0000:00:03.0: Unsupported 
> > hw_revision 0x2010  
> 
> This is related to firmware load stuff. The code use those macros:
> 
> 	#define ATOMISP_HW_REVISION_MASK	0x0000ff00
> 	#define ATOMISP_HW_REVISION_SHIFT	8
> 	#define ATOMISP_HW_REVISION_ISP2300	0x00
> 	#define ATOMISP_HW_REVISION_ISP2400	0x10
> 	#define ATOMISP_HW_REVISION_ISP2401_LEGACY 0x11
> 	#define ATOMISP_HW_REVISION_ISP2401	0x20
> 
> 	#define ATOMISP_HW_STEPPING_MASK	0x000000ff
> 	#define ATOMISP_HW_STEPPING_A0		0x00
> 	#define ATOMISP_HW_STEPPING_B0		0x10
> 
> According with the above, 0x2010 would mean ISP2401-B0.
> 
> The code itself check those macros in order to load the right
> firmware:
> 
>         if (isp->media_dev.hw_revision ==
>             ((ATOMISP_HW_REVISION_ISP2401 <<
> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_A0))
>                 fw_path = "shisp_2401a0_v21.bin";
> 
>         if (isp->media_dev.hw_revision ==
>             ((ATOMISP_HW_REVISION_ISP2401_LEGACY <<
> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_A0))
>                 fw_path = "shisp_2401a0_legacy_v21.bin";
> 
>         if (isp->media_dev.hw_revision ==
>             ((ATOMISP_HW_REVISION_ISP2400 <<
> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
>                 fw_path = "shisp_2400b0_v21.bin";
> 
>         if (!fw_path) {
>                 dev_err(isp->dev, "Unsupported hw_revision 0x%x\n",
>                         isp->media_dev.hw_revision);
>                 return NULL;
>         }
> 
> It sounds that we need to add:
> 
>         if (isp->media_dev.hw_revision ==
>             ((ATOMISP_HW_REVISION_ISP2401 <<
> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
>                 fw_path = "shisp_2401b0_v21.bin";
> 
> Eventually, other changes may be needed, depending on how different is
> this B0 revision from A0.
> 
> Patch for it pushed. Please notice that it will seek for a firmware
> named "shisp_2401b0_v21.bin".

Unfortunately I was not able to find "shisp_2401b0_v21.bin"; so I changed the values in the code and tried with "shisp_2401a0_v21.bin, irci_master_20140707_0622". I contacted Intel to see if they are willing to provide the newer firmware. Alan Cox mentioned in a commit message, that the drivers can be extracted from an "upgrade kit":

   "... The firmware files will usually be found in /etc/firmware on an Android
   device but can also be extracted from the upgrade kit if you've managed
   to lose them somehow. ..."

But I did not yet figure out what this kit is.

There is also an open support request with Intel to get some hardware/firmware documentation. But this will be difficult (as expected by you and Laurent) - their process only supports requests from companies that sign an NDA. But I opened a ticket as well to see if there's a way to get access to their developer network someway, or if it is possible that they send only the documents required. 

I also sent an Mail to the original authors of the drivers at Intel. Two of them no longer work there (mail was rejected), but one went trough. Let's see...

> 
> This driver will also check if the firmware version is:
> 
> 	"irci_ecr - master_20150911_0724"
> 
> As far as I know, the firmware is linked to the driver's code. 
> So, supporting a different firmware version will likely require
> changes at the driver.
> 
> > [    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed
> > with error -2  

With the older firmware it does not look good (full dmesg output attached):
[    9.416329] ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
[    9.425878] ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
[    9.471140] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
[    9.476362] proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002)
[    9.478540] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.493784] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    9.495675] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
[    9.501274] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    9.510963] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
[    9.515507] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
[    9.519100] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
[    9.530607] proc_thermal 0000:00:0b.0: Creating sysfs group for PROC_THERMAL_PCI
[    9.585233] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
[    9.591623] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input18
[    9.603063] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=2 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input19
[    9.688254] ------------[ cut here ]------------
[    9.691775] cpu_latency_qos_update_request called for unknown object
[    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
[    9.698826] Modules linked in: snd_soc_acpi_intel_match snd_rawmidi snd_soc_acpi snd_soc_rl6231 snd_soc_core ath mac80211 snd_compress snd_hdmi_lpe_audio ac97_bus hid_sensor_accel_3d snd_pcm_dmaengine hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common processor_thermal_device industrialio cfg80211 snd_pcm snd_seq intel_rapl_common atomisp(C+) libarc4 intel_soc_dts_iosf cros_ec_ishtp intel_xhci_usb_role_switch mei_txe cros_ec videobuf_vmalloc mei roles atomisp_ov2680(C) videobuf_core snd_seq_device snd_timer spi_pxa2xx_platform videodev snd mc dw_dmac intel_hid dw_dmac_core 8250_dw soundcore int3406_thermal int3400_thermal intel_int0002_vgpio acpi_pad acpi_thermal_rel soc_button_array int3403_thermal int340x_thermal_zone mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_ishtp_hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 mmc_block i2c_algo_bit
[    9.698885]  aesni_intel crypto_simd drm_kms_helper cryptd syscopyarea sysfillrect glue_helper sysimgblt fb_sys_fops cec intel_ish_ipc drm lpc_ich intel_ishtp hid_asus intel_soc_pmic_chtdc_ti asus_wmi i2c_hid sparse_keymap sdhci_acpi wmi video sdhci hid_generic usbhid hid
[    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
[    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
[    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
[    9.750615] Code: 89 e5 41 55 41 54 41 89 f4 53 48 89 fb 48 81 7f 28 e0 7f c6 9e 74 1c 48 c7 c6 60 f3 65 9e 48 c7 c7 e8 a9 99 9e e8 b2 a6 f9 ff <0f> 0b 5b 41 5c 41 5d 5d c3 0f 1f 44 00 00 44 3b 23 74 ef 44 89 e2
[    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
[    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
[    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
[    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
[    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
[    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
[    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
[    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
[    9.802126] Call Trace:
[    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
[    9.811441]  local_pci_probe+0x47/0x80
[    9.816085]  pci_device_probe+0xff/0x1b0
[    9.820706]  really_probe+0x1c8/0x3e0
[    9.825247]  driver_probe_device+0xd9/0x120
[    9.829769]  device_driver_attach+0x58/0x60
[    9.834294]  __driver_attach+0x8f/0x150
[    9.838782]  ? device_driver_attach+0x60/0x60
[    9.843205]  ? device_driver_attach+0x60/0x60
[    9.847634]  bus_for_each_dev+0x79/0xc0
[    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
[    9.856462]  driver_attach+0x1e/0x20

Well - It did more things than before. But my fear is that we really depend on the rev b firmware, which is very difficult to get hold of :-(.

> 
> That's because it didn't load the firmware.
> 
> Thanks,
> Mauro

with kind regards,
Patrik


[-- Attachment #2: dmesg.01.05.2020-atomisp.txt.tar.gz --]
[-- Type: application/gzip, Size: 22247 bytes --]

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Fri, 1 May 2020 19:31:05 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On Fri, 1 May 2020 11:38:12 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> > Em Fri, 1 May 2020 10:54:18 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> > 
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]    
> > > 
> > > Compiled and linked :-). We get some more output this time:    
> > 
> > Good!
> > 
> >  [...]  
> > 
> > Hmm.. your e-mailer is breaking long lines again  :-(  
> 
> Ok - then the configuration option I used is not reliable. I've now switched to Claws Mail; I hope this resolves the problem.

Yeah, that's what I use here. I actually manually break my lines
when I'm closed to the 80 column, as most people do on mailing
lists (some people read those upstream MLs with emacs).

> 
> >   
> > > [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
> > > [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> > > found, using dummy regulator [    9.189966] kernel: proc_thermal
> > > 0000:00:0b.0: enabling device (0000 -> 0002)    
> > > [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> > > found, using dummy regulator
> > > [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v
> > > not found, using dummy regulator    
> > 
> > I'll check this.
> >   
> > > [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs
> > > group for PROC_THERMAL_PCI
> > > [    9.238185] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v
> > > not found, using dummy regulator
> > > [    9.337925] kernel: atomisp: module is from the staging
> > > directory, the quality is unknown, you have been warned.
> > > [    9.404666] kernel: atomisp-isp2 0000:00:03.0: enabling device
> > > (0000 -> 0002)    
> > > [    9.408680] kernel: atomisp-isp2 0000:00:03.0: ISP HPLL
> > > frequency base = 1600 MHz
> > > [    9.412197] kernel: atomisp-isp2 0000:00:03.0: Unsupported 
> > > hw_revision 0x2010    
> > 
> > This is related to firmware load stuff. The code use those macros:
> > 
> > 	#define ATOMISP_HW_REVISION_MASK	0x0000ff00
> > 	#define ATOMISP_HW_REVISION_SHIFT	8
> > 	#define ATOMISP_HW_REVISION_ISP2300	0x00
> > 	#define ATOMISP_HW_REVISION_ISP2400	0x10
> > 	#define ATOMISP_HW_REVISION_ISP2401_LEGACY 0x11
> > 	#define ATOMISP_HW_REVISION_ISP2401	0x20
> > 
> > 	#define ATOMISP_HW_STEPPING_MASK	0x000000ff
> > 	#define ATOMISP_HW_STEPPING_A0		0x00
> > 	#define ATOMISP_HW_STEPPING_B0		0x10
> > 
> > According with the above, 0x2010 would mean ISP2401-B0.
> > 
> > The code itself check those macros in order to load the right
> > firmware:
> > 
> >         if (isp->media_dev.hw_revision ==
> >             ((ATOMISP_HW_REVISION_ISP2401 <<
> > ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_A0))
> >                 fw_path = "shisp_2401a0_v21.bin";
> > 
> >         if (isp->media_dev.hw_revision ==
> >             ((ATOMISP_HW_REVISION_ISP2401_LEGACY <<
> > ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_A0))
> >                 fw_path = "shisp_2401a0_legacy_v21.bin";
> > 
> >         if (isp->media_dev.hw_revision ==
> >             ((ATOMISP_HW_REVISION_ISP2400 <<
> > ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
> >                 fw_path = "shisp_2400b0_v21.bin";
> > 
> >         if (!fw_path) {
> >                 dev_err(isp->dev, "Unsupported hw_revision 0x%x\n",
> >                         isp->media_dev.hw_revision);
> >                 return NULL;
> >         }
> > 
> > It sounds that we need to add:
> > 
> >         if (isp->media_dev.hw_revision ==
> >             ((ATOMISP_HW_REVISION_ISP2401 <<
> > ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
> >                 fw_path = "shisp_2401b0_v21.bin";
> > 
> > Eventually, other changes may be needed, depending on how different is
> > this B0 revision from A0.
> > 
> > Patch for it pushed. Please notice that it will seek for a firmware
> > named "shisp_2401b0_v21.bin".  
> 
> Unfortunately I was not able to find "shisp_2401b0_v21.bin"; 

Yeah, I also searched for it. Was unable to find it. I suspect that the
B0 version could be newer than the atomisp driver that got merged.

> so I changed the values in the code and tried with "shisp_2401a0_v21.bin, irci_master_20140707_0622".

Yeah, I suspect that this is the next best thing.

> I contacted Intel to see if they are willing to provide the newer firmware. Alan Cox mentioned in a commit message, that the drivers can be extracted from an "upgrade kit":
> 
>    "... The firmware files will usually be found in /etc/firmware on an Android
>    device but can also be extracted from the upgrade kit if you've managed
>    to lose them somehow. ..."
> 
> But I did not yet figure out what this kit is.

The firmware should be there somewhere at the BSP for Android
(for hardware that came originally with it). It should also be
present on Windows and other OSes that support, although the
version could be different.

> 
> There is also an open support request with Intel to get some hardware/firmware documentation. But this will be difficult (as expected by you and Laurent) - their process only supports requests from companies that sign an NDA. But I opened a ticket as well to see if there's a way to get access to their developer network someway, or if it is possible that they send only the documents required. 

Yeah, I suspect that they would open this only for companies
with signed NDAs.

> 
> I also sent an Mail to the original authors of the drivers at Intel. Two of them no longer work there (mail was rejected), but one went trough. Let's see...

Ok. Btw, there is a driver for Atomisp on an yocto tree:

	https://github.com/intel-aero/meta-intel-aero.git

It got removed back in 2018, but if you checkout this changeset:

	Merge: db1df368eb58 08f476112708
	Author: Lucas De Marchi <lucas.demarchi@intel.com>
	Date:   Tue Apr 4 11:51:42 2017 -0700

	    Merge pull request #70 from zehortigoza/jam
    
You would be able to see it. Unfortunately, the driver there
also came with shisp_2401a0_v21.bin.

The driver there forces this specific version, disabling the 
firmware version checking:

recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch:+ccflags-y += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DATOMISP_FWNAME=\"shisp_2401a0_v21.bin\" -DISP2401 -DISP2401_NEW_INPUT_SYSTEM

I also found a firmware for some other Asus Transformer device:

	https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware

That's said, there's also a firmware for it inside this:
	https://dlcdnets.asus.com/pub/ASUS/nb/DriversForWin10/Chipset/Chipset_Intel_CherryTrail_T_Win10_64_VER110.zip

Probably it is a different version, but it could be worth renaming it and
try it. The firmware load code should check if the firmware version is the
right one.

Also, the .INF file seems to point to the right PCI ID:

	[Device.NTamd64]
	%iacamera.DeviceDesc%=iacamera,VIDEO\INT22B8

drivers/staging/media/atomisp/pci/atomisp_v4l2.c:       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x22b8), .driver_data = HW_IS_ISP2401},

The inf file also contains this:

	DriverVer=03/02/2016,21.10586.6069.2007

So, it sounds to be Version 21. If it is the right one or
something else, I dunno.

> 
> > 
> > This driver will also check if the firmware version is:
> > 
> > 	"irci_ecr - master_20150911_0724"
> > 
> > As far as I know, the firmware is linked to the driver's code. 
> > So, supporting a different firmware version will likely require
> > changes at the driver.
> >   
> > > [    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed
> > > with error -2    
> 
> With the older firmware it does not look good (full dmesg output attached):
> [    9.416329] ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
> [    9.425878] ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
> [    9.471140] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
> [    9.476362] proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002)
> [    9.478540] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> [    9.493784] cfg80211: Loading compiled-in X.509 certificates for regulatory database
> [    9.495675] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
> [    9.501274] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [    9.510963] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
> [    9.515507] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
> [    9.519100] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
> [    9.530607] proc_thermal 0000:00:0b.0: Creating sysfs group for PROC_THERMAL_PCI
> [    9.585233] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
> [    9.591623] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input18
> [    9.603063] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=2 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input19
> [    9.688254] ------------[ cut here ]------------
> [    9.691775] cpu_latency_qos_update_request called for unknown object
> [    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
> [    9.698826] Modules linked in: snd_soc_acpi_intel_match snd_rawmidi snd_soc_acpi snd_soc_rl6231 snd_soc_core ath mac80211 snd_compress snd_hdmi_lpe_audio ac97_bus hid_sensor_accel_3d snd_pcm_dmaengine hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common processor_thermal_device industrialio cfg80211 snd_pcm snd_seq intel_rapl_common atomisp(C+) libarc4 intel_soc_dts_iosf cros_ec_ishtp intel_xhci_usb_role_switch mei_txe cros_ec videobuf_vmalloc mei roles atomisp_ov2680(C) videobuf_core snd_seq_device snd_timer spi_pxa2xx_platform videodev snd mc dw_dmac intel_hid dw_dmac_core 8250_dw soundcore int3406_thermal int3400_thermal intel_int0002_vgpio acpi_pad acpi_thermal_rel soc_button_array int3403_thermal int340x_thermal_zone mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_ishtp_hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 mmc_block i2c_algo_bit
> [    9.698885]  aesni_intel crypto_simd drm_kms_helper cryptd syscopyarea sysfillrect glue_helper sysimgblt fb_sys_fops cec intel_ish_ipc drm lpc_ich intel_ishtp hid_asus intel_soc_pmic_chtdc_ti asus_wmi i2c_hid sparse_keymap sdhci_acpi wmi video sdhci hid_generic usbhid hid
> [    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
> [    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
> [    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
> [    9.750615] Code: 89 e5 41 55 41 54 41 89 f4 53 48 89 fb 48 81 7f 28 e0 7f c6 9e 74 1c 48 c7 c6 60 f3 65 9e 48 c7 c7 e8 a9 99 9e e8 b2 a6 f9 ff <0f> 0b 5b 41 5c 41 5d 5d c3 0f 1f 44 00 00 44 3b 23 74 ef 44 89 e2
> [    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
> [    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
> [    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
> [    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
> [    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
> [    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
> [    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
> [    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
> [    9.802126] Call Trace:
> [    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
> [    9.811441]  local_pci_probe+0x47/0x80
> [    9.816085]  pci_device_probe+0xff/0x1b0
> [    9.820706]  really_probe+0x1c8/0x3e0
> [    9.825247]  driver_probe_device+0xd9/0x120
> [    9.829769]  device_driver_attach+0x58/0x60
> [    9.834294]  __driver_attach+0x8f/0x150
> [    9.838782]  ? device_driver_attach+0x60/0x60
> [    9.843205]  ? device_driver_attach+0x60/0x60
> [    9.847634]  bus_for_each_dev+0x79/0xc0
> [    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
> [    9.856462]  driver_attach+0x1e/0x20
> 
> Well - It did more things than before. 

Actually, it looked a lot better for me, as the driver is now trying to 
do something ;-)

> But my fear is that we really depend on the rev b firmware, which is very difficult to get hold of :-(.
> 
> > 
> > That's because it didn't load the firmware.
> > 
> > Thanks,
> > Mauro  
> 
> with kind regards,
> Patrik
> 



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Fri, 1 May 2020 21:30:23 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Em Fri, 1 May 2020 19:31:05 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
> > On Fri, 1 May 2020 11:38:12 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > 
> > [...] 
> > 
> > > Hmm.. your e-mailer is breaking long lines again  :-(  
> > 
> > Ok - then the configuration option I used is not reliable. I've now switched to Claws Mail; I hope this resolves the problem.
> 
> Yeah, that's what I use here. I actually manually break my lines
> when I'm closed to the 80 column, as most people do on mailing
> lists (some people read those upstream MLs with emacs).
> 
> > 
> > >   
> > > > [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
> > > > [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> > > > found, using dummy regulator [    9.189966] kernel: proc_thermal
> > > > 0000:00:0b.0: enabling device (0000 -> 0002)    
> > > > [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> > > > found, using dummy regulator
> > > > [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v
> > > > not found, using dummy regulator    
> > > 
> > > I'll check this.
> > >   
> > > > [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs
> > > > group for PROC_THERMAL_PCI
> > > [...]
> > > 
> > > It sounds that we need to add:
> > > 
> > >         if (isp->media_dev.hw_revision ==
> > >             ((ATOMISP_HW_REVISION_ISP2401 <<
> > > ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
> > >                 fw_path = "shisp_2401b0_v21.bin";
> > > 
> > > Eventually, other changes may be needed, depending on how different is
> > > this B0 revision from A0.
> > > 
> > > Patch for it pushed. Please notice that it will seek for a firmware
> > > named "shisp_2401b0_v21.bin".  
> > 
> > Unfortunately I was not able to find "shisp_2401b0_v21.bin"; 
> 
> Yeah, I also searched for it. Was unable to find it. I suspect that the
> B0 version could be newer than the atomisp driver that got merged.
> 
> > so I changed the values in the code and tried with "shisp_2401a0_v21.bin, irci_master_20140707_0622".
> 
> Yeah, I suspect that this is the next best thing.
> 
> > I contacted Intel to see if they are willing to provide the newer firmware. Alan Cox mentioned in a commit message, that the drivers can be extracted from an "upgrade kit":
> > 
> >    "... The firmware files will usually be found in /etc/firmware on an Android
> >    device but can also be extracted from the upgrade kit if you've managed
> >    to lose them somehow. ..."
> > 
> > But I did not yet figure out what this kit is.
> 
> The firmware should be there somewhere at the BSP for Android
> (for hardware that came originally with it). It should also be
> present on Windows and other OSes that support, although the
> version could be different.
> 
> > 
> > There is also an open support request with Intel to get some hardware/firmware documentation. But this will be difficult (as expected by you and Laurent) - their process only supports requests from companies that sign an NDA. But I opened a ticket as well to see if there's a way to get access to their developer network someway, or if it is possible that they send only the documents required. 
> 
> Yeah, I suspect that they would open this only for companies
> with signed NDAs.
> 
> > 
> > I also sent an Mail to the original authors of the drivers at Intel. Two of them no longer work there (mail was rejected), but one went trough. Let's see...
> 
> Ok. Btw, there is a driver for Atomisp on an yocto tree:
> 
> 	https://github.com/intel-aero/meta-intel-aero.git
> 
> It got removed back in 2018, but if you checkout this changeset:
> 
> 	Merge: db1df368eb58 08f476112708
> 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
> 	Date:   Tue Apr 4 11:51:42 2017 -0700
> 
> 	    Merge pull request #70 from zehortigoza/jam
>     

Cool, the code might give additional information. I've also send a
request regarding the firmware and HW documentation to the author and
the engineers that signed the patch. The firmware in the patch has a
different version string and the size is surprisingly a few MB bigger
than the one I used for the first experiment. I'll give that one a try
as well.

> You would be able to see it. Unfortunately, the driver there
> also came with shisp_2401a0_v21.bin.
> 
> The driver there forces this specific version, disabling the 
> firmware version checking:
> 
> recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch:+ccflags-y += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DATOMISP_FWNAME=\"shisp_2401a0_v21.bin\" -DISP2401 -DISP2401_NEW_INPUT_SYSTEM
> 
> I also found a firmware for some other Asus Transformer device:
> 
> 	https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware
> 

It looks a this firmware is for the 2400 variant; I could also not
extract the irci version string. Thus I'll not try them for the moment
to perform experiments.

> That's said, there's also a firmware for it inside this:
> 	https://dlcdnets.asus.com/pub/ASUS/nb/DriversForWin10/Chipset/Chipset_Intel_CherryTrail_T_Win10_64_VER110.zip
> 
> Probably it is a different version, but it could be worth renaming it and
> try it. The firmware load code should check if the firmware version is the
> right one.

It identifies itself as irci_stable_bw10p_0518_20150801_0537; I'll give
that one a try first. As usual it will unfortunately take some time
until I get back to you with the results, as every experiment takes
many hours (building the kernel on what is essentially a tablet takes
time).

> 
> Also, the .INF file seems to point to the right PCI ID:
> 
> 	[Device.NTamd64]
> 	%iacamera.DeviceDesc%=iacamera,VIDEO\INT22B8
> 
> drivers/staging/media/atomisp/pci/atomisp_v4l2.c:       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x22b8), .driver_data = HW_IS_ISP2401},
> 
> The inf file also contains this:
> 
> 	DriverVer=03/02/2016,21.10586.6069.2007
> 
> So, it sounds to be Version 21. If it is the right one or
> something else, I dunno.
> 
> > 
> > > 
> > > This driver will also check if the firmware version is:
> > > 
> > > 	"irci_ecr - master_20150911_0724"
> > > 
> > > As far as I know, the firmware is linked to the driver's code. 
> > > So, supporting a different firmware version will likely require
> > > changes at the driver.
> > >   
> > > > [    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed
> > > > with error -2    
> > 
> > With the older firmware it does not look good (full dmesg output attached):
> > [    9.416329] ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
> > [    9.425878] ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
> > [    9.471140] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
> > [    9.476362] proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002)
> > [    9.478540] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> > [    9.493784] cfg80211: Loading compiled-in X.509 certificates for regulatory database
> > [    9.495675] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
> > [    9.501274] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> > [    9.510963] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
> > [    9.515507] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
> > [    9.519100] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
> > [    9.530607] proc_thermal 0000:00:0b.0: Creating sysfs group for PROC_THERMAL_PCI
> > [    9.585233] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
> > [    9.591623] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input18
> > [    9.603063] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=2 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input19
> > [    9.688254] ------------[ cut here ]------------
> > [    9.691775] cpu_latency_qos_update_request called for unknown object
> > [    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
> > [    9.698826] Modules linked in: snd_soc_acpi_intel_match [...]
> > [    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
> > [    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
> > [    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
> > [    9.750615] Code: [...]
> > [    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
> > [    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
> > [    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
> > [    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
> > [    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
> > [    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
> > [    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
> > [    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
> > [    9.802126] Call Trace:
> > [    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
> > [    9.811441]  local_pci_probe+0x47/0x80
> > [    9.816085]  pci_device_probe+0xff/0x1b0
> > [    9.820706]  really_probe+0x1c8/0x3e0
> > [    9.825247]  driver_probe_device+0xd9/0x120
> > [    9.829769]  device_driver_attach+0x58/0x60
> > [    9.834294]  __driver_attach+0x8f/0x150
> > [    9.838782]  ? device_driver_attach+0x60/0x60
> > [    9.843205]  ? device_driver_attach+0x60/0x60
> > [    9.847634]  bus_for_each_dev+0x79/0xc0
> > [    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
> > [    9.856462]  driver_attach+0x1e/0x20
> > 
> > Well - It did more things than before. 
> 
> Actually, it looked a lot better for me, as the driver is now trying to 
> do something ;-)
> 
> > But my fear is that we really depend on the rev b firmware, which is very difficult to get hold of :-(.
> > 
> > > 
> > > That's because it didn't load the firmware.
> > > 
> > > Thanks,
> > > Mauro  
> > 
> > with kind regards,
> > Patrik
> > 
> 
> Thanks,
> Mauro

with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 02.05.20 10:15, Patrik Gfeller wrote:
> On Fri, 1 May 2020 21:30:23 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
>> Em Fri, 1 May 2020 19:31:05 +0200
>> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>>
>>> On Fri, 1 May 2020 11:38:12 +0200
>>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>>>
>>> [...] 
>>>
>>>> Hmm.. your e-mailer is breaking long lines again  :-(  
>>> Ok - then the configuration option I used is not reliable. I've now switched to Claws Mail; I hope this resolves the problem.
>> Yeah, that's what I use here. I actually manually break my lines
>> when I'm closed to the 80 column, as most people do on mailing
>> lists (some people read those upstream MLs with emacs).
>>
Sorry - I use my old mailer for this message - as I suddenly do not see
sent messages anymore
in claws and can this not follow up on my last sent mail. I'll try to
fix this and use claws again.

>>>>   
>>>>> [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
>>>>> [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
>>>>> found, using dummy regulator [    9.189966] kernel: proc_thermal
>>>>> 0000:00:0b.0: enabling device (0000 -> 0002)    
>>>>> [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
>>>>> found, using dummy regulator
>>>>> [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v
>>>>> not found, using dummy regulator    
>>>> I'll check this.
>>>>   
>>>>> [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs
>>>>> group for PROC_THERMAL_PCI
>>>> [...]
>>>>
>>>> It sounds that we need to add:
>>>>
>>>>         if (isp->media_dev.hw_revision ==
>>>>             ((ATOMISP_HW_REVISION_ISP2401 <<
>>>> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
>>>>                 fw_path = "shisp_2401b0_v21.bin";
>>>>
>>>> Eventually, other changes may be needed, depending on how different is
>>>> this B0 revision from A0.
>>>>
>>>> Patch for it pushed. Please notice that it will seek for a firmware
>>>> named "shisp_2401b0_v21.bin".  
>>> Unfortunately I was not able to find "shisp_2401b0_v21.bin"; 
>> Yeah, I also searched for it. Was unable to find it. I suspect that the
>> B0 version could be newer than the atomisp driver that got merged.
>>
>>> so I changed the values in the code and tried with "shisp_2401a0_v21.bin, irci_master_20140707_0622".
>> Yeah, I suspect that this is the next best thing.
>>
>>> I contacted Intel to see if they are willing to provide the newer firmware. Alan Cox mentioned in a commit message, that the drivers can be extracted from an "upgrade kit":
>>>
>>>    "... The firmware files will usually be found in /etc/firmware on an Android
>>>    device but can also be extracted from the upgrade kit if you've managed
>>>    to lose them somehow. ..."
>>>
>>> But I did not yet figure out what this kit is.
>> The firmware should be there somewhere at the BSP for Android
>> (for hardware that came originally with it). It should also be
>> present on Windows and other OSes that support, although the
>> version could be different.
>>
>>> There is also an open support request with Intel to get some hardware/firmware documentation. But this will be difficult (as expected by you and Laurent) - their process only supports requests from companies that sign an NDA. But I opened a ticket as well to see if there's a way to get access to their developer network someway, or if it is possible that they send only the documents required. 
>> Yeah, I suspect that they would open this only for companies
>> with signed NDAs.
>>
>>> I also sent an Mail to the original authors of the drivers at Intel. Two of them no longer work there (mail was rejected), but one went trough. Let's see...
>> Ok. Btw, there is a driver for Atomisp on an yocto tree:
>>
>> 	https://github.com/intel-aero/meta-intel-aero.git
>>
>> It got removed back in 2018, but if you checkout this changeset:
>>
>> 	Merge: db1df368eb58 08f476112708
>> 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
>> 	Date:   Tue Apr 4 11:51:42 2017 -0700
>>
>> 	    Merge pull request #70 from zehortigoza/jam
>>     
> Cool, the code might give additional information. I've also send a
> request regarding the firmware and HW documentation to the author and
> the engineers that signed the patch. The firmware in the patch has a
> different version string and the size is surprisingly a few MB bigger
> than the one I used for the first experiment. I'll give that one a try
> as well.
>
>> You would be able to see it. Unfortunately, the driver there
>> also came with shisp_2401a0_v21.bin.
>>
>> The driver there forces this specific version, disabling the 
>> firmware version checking:
>>
>> recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch:+ccflags-y += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DATOMISP_FWNAME=\"shisp_2401a0_v21.bin\" -DISP2401 -DISP2401_NEW_INPUT_SYSTEM
>>
>> I also found a firmware for some other Asus Transformer device:
>>
>> 	https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware
>>
> It looks a this firmware is for the 2400 variant; I could also not
> extract the irci version string. Thus I'll not try them for the moment
> to perform experiments.

I've a problem with the build; I've pulled the latest changes from the
repository - and at least some
of your changes are lost. I also checked via the web page and there I
can also not see them
anymore:

https://git.linuxtv.org/mchehab/experimental.git/tree/drivers/staging/media/atomisp/atomisp_v4l2.c?h=atomisp_v2

const struct firmware *
atomisp_load_firmware(struct atomisp_device *isp)
{
    const struct firmware *fw;
    int rc;
    char *fw_path = NULL;

    if (skip_fwload)
        return NULL;

    if (isp->media_dev.hw_revision ==
        ((ATOMISP_HW_REVISION_ISP2401 << ATOMISP_HW_REVISION_SHIFT)
         | ATOMISP_HW_STEPPING_A0))
        fw_path = "shisp_2401a0_v21.bin";

    if (isp->media_dev.hw_revision ==
        ((ATOMISP_HW_REVISION_ISP2401_LEGACY << ATOMISP_HW_REVISION_SHIFT)
         | ATOMISP_HW_STEPPING_A0))
        fw_path = "shisp_2401a0_legacy_v21.bin";

    if (isp->media_dev.hw_revision ==
        ((ATOMISP_HW_REVISION_ISP2400 << ATOMISP_HW_REVISION_SHIFT)
         | ATOMISP_HW_STEPPING_B0))
        fw_path = "shisp_2400b0_v21.bin";

    if (!fw_path) {
        dev_err(isp->dev, "Unsupported hw_revision 0x%x\n",
            isp->media_dev.hw_revision);
        return NULL;
    }

    rc = request_firmware(&fw, fw_path, isp->dev);
    if (rc) {
        dev_err(isp->dev,
            "atomisp: Error %d while requesting firmware %s\n",
            rc, fw_path);
        return NULL;
    }

    return fw;
}

It also does not build properly anymore (uses the old API again). Do you
know what
I'm doing wrong here?

>
>> That's said, there's also a firmware for it inside this:
>> 	https://dlcdnets.asus.com/pub/ASUS/nb/DriversForWin10/Chipset/Chipset_Intel_CherryTrail_T_Win10_64_VER110.zip
>>
>> Probably it is a different version, but it could be worth renaming it and
>> try it. The firmware load code should check if the firmware version is the
>> right one.
> It identifies itself as irci_stable_bw10p_0518_20150801_0537; I'll give
> that one a try first. As usual it will unfortunately take some time
> until I get back to you with the results, as every experiment takes
> many hours (building the kernel on what is essentially a tablet takes
> time).
>
>> Also, the .INF file seems to point to the right PCI ID:
>>
>> 	[Device.NTamd64]
>> 	%iacamera.DeviceDesc%=iacamera,VIDEO\INT22B8
>>
>> drivers/staging/media/atomisp/pci/atomisp_v4l2.c:       {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x22b8), .driver_data = HW_IS_ISP2401},
>>
>> The inf file also contains this:
>>
>> 	DriverVer=03/02/2016,21.10586.6069.2007
>>
>> So, it sounds to be Version 21. If it is the right one or
>> something else, I dunno.
>>
>>>> This driver will also check if the firmware version is:
>>>>
>>>> 	"irci_ecr - master_20150911_0724"
>>>>
>>>> As far as I know, the firmware is linked to the driver's code. 
>>>> So, supporting a different firmware version will likely require
>>>> changes at the driver.
>>>>   
>>>>> [    9.416174] kernel: atomisp-isp2: probe of 0000:00:03.0 failed
>>>>> with error -2    
>>> With the older firmware it does not look good (full dmesg output attached):
>>> [    9.416329] ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
>>> [    9.425878] ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
>>> [    9.471140] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
>>> [    9.476362] proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002)
>>> [    9.478540] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
>>> [    9.493784] cfg80211: Loading compiled-in X.509 certificates for regulatory database
>>> [    9.495675] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
>>> [    9.501274] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>>> [    9.510963] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
>>> [    9.515507] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
>>> [    9.519100] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
>>> [    9.530607] proc_thermal 0000:00:0b.0: Creating sysfs group for PROC_THERMAL_PCI
>>> [    9.585233] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
>>> [    9.591623] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input18
>>> [    9.603063] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=2 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input19
>>> [    9.688254] ------------[ cut here ]------------
>>> [    9.691775] cpu_latency_qos_update_request called for unknown object
>>> [    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
>>> [    9.698826] Modules linked in: snd_soc_acpi_intel_match [...]
>>> [    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
>>> [    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
>>> [    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
>>> [    9.750615] Code: [...]
>>> [    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
>>> [    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
>>> [    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
>>> [    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
>>> [    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
>>> [    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
>>> [    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
>>> [    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
>>> [    9.802126] Call Trace:
>>> [    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
>>> [    9.811441]  local_pci_probe+0x47/0x80
>>> [    9.816085]  pci_device_probe+0xff/0x1b0
>>> [    9.820706]  really_probe+0x1c8/0x3e0
>>> [    9.825247]  driver_probe_device+0xd9/0x120
>>> [    9.829769]  device_driver_attach+0x58/0x60
>>> [    9.834294]  __driver_attach+0x8f/0x150
>>> [    9.838782]  ? device_driver_attach+0x60/0x60
>>> [    9.843205]  ? device_driver_attach+0x60/0x60
>>> [    9.847634]  bus_for_each_dev+0x79/0xc0
>>> [    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
>>> [    9.856462]  driver_attach+0x1e/0x20
>>>
>>> Well - It did more things than before. 
>> Actually, it looked a lot better for me, as the driver is now trying to 
>> do something ;-)
>>
>>> But my fear is that we really depend on the rev b firmware, which is very difficult to get hold of :-(.
>>>
>>>> That's because it didn't load the firmware.
>>>>
>>>> Thanks,
>>>> Mauro  
>>> with kind regards,
>>> Patrik
>>>
>> Thanks,
>> Mauro
> with kind regards,
> Patrik

with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 2 May 2020 11:20:04 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On 02.05.20 10:15, Patrik Gfeller wrote:
> > On Fri, 1 May 2020 21:30:23 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >  
> >> Em Fri, 1 May 2020 19:31:05 +0200
> >> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >>  
> >>> On Fri, 1 May 2020 11:38:12 +0200
> >>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >>>
> >>> [...] 
> >>>  
> >>>> Hmm.. your e-mailer is breaking long lines again  :-(    
> >>> Ok - then the configuration option I used is not reliable. I've now switched to Claws Mail; I hope this resolves the problem.  
> >> Yeah, that's what I use here. I actually manually break my lines
> >> when I'm closed to the 80 column, as most people do on mailing
> >> lists (some people read those upstream MLs with emacs).
> >>  
> Sorry - I use my old mailer for this message - as I suddenly do not see
> sent messages anymore
> in claws and can this not follow up on my last sent mail. I'll try to
> fix this and use claws again.
> 
> >>>>     
> >>>>> [    9.175421] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
> >>>>> [    9.178755] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not
> >>>>> found, using dummy regulator [    9.189966] kernel: proc_thermal
> >>>>> 0000:00:0b.0: enabling device (0000 -> 0002)    
> >>>>> [    9.212704] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not
> >>>>> found, using dummy regulator
> >>>>> [    9.235024] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v
> >>>>> not found, using dummy regulator      
> >>>> I'll check this.
> >>>>     
> >>>>> [    9.235057] kernel: proc_thermal 0000:00:0b.0: Creating sysfs
> >>>>> group for PROC_THERMAL_PCI  
> >>>> [...]
> >>>>
> >>>> It sounds that we need to add:
> >>>>
> >>>>         if (isp->media_dev.hw_revision ==
> >>>>             ((ATOMISP_HW_REVISION_ISP2401 <<
> >>>> ATOMISP_HW_REVISION_SHIFT) | ATOMISP_HW_STEPPING_B0))
> >>>>                 fw_path = "shisp_2401b0_v21.bin";
> >>>>
> >>>> Eventually, other changes may be needed, depending on how different is
> >>>> this B0 revision from A0.
> >>>>
> >>>> Patch for it pushed. Please notice that it will seek for a firmware
> >>>> named "shisp_2401b0_v21.bin".    
> >>> Unfortunately I was not able to find "shisp_2401b0_v21.bin";   
> >> Yeah, I also searched for it. Was unable to find it. I suspect that the
> >> B0 version could be newer than the atomisp driver that got merged.
> >>  
> >>> so I changed the values in the code and tried with "shisp_2401a0_v21.bin, irci_master_20140707_0622".  
> >> Yeah, I suspect that this is the next best thing.
> >>  
> >>> I contacted Intel to see if they are willing to provide the newer firmware. Alan Cox mentioned in a commit message, that the drivers can be extracted from an "upgrade kit":
> >>>
> >>>    "... The firmware files will usually be found in /etc/firmware on an Android
> >>>    device but can also be extracted from the upgrade kit if you've managed
> >>>    to lose them somehow. ..."
> >>>
> >>> But I did not yet figure out what this kit is.  
> >> The firmware should be there somewhere at the BSP for Android
> >> (for hardware that came originally with it). It should also be
> >> present on Windows and other OSes that support, although the
> >> version could be different.
> >>  
> >>> There is also an open support request with Intel to get some hardware/firmware documentation. But this will be difficult (as expected by you and Laurent) - their process only supports requests from companies that sign an NDA. But I opened a ticket as well to see if there's a way to get access to their developer network someway, or if it is possible that they send only the documents required.   
> >> Yeah, I suspect that they would open this only for companies
> >> with signed NDAs.
> >>  
> >>> I also sent an Mail to the original authors of the drivers at Intel. Two of them no longer work there (mail was rejected), but one went trough. Let's see...  
> >> Ok. Btw, there is a driver for Atomisp on an yocto tree:
> >>
> >> 	https://github.com/intel-aero/meta-intel-aero.git
> >>
> >> It got removed back in 2018, but if you checkout this changeset:
> >>
> >> 	Merge: db1df368eb58 08f476112708
> >> 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
> >> 	Date:   Tue Apr 4 11:51:42 2017 -0700
> >>
> >> 	    Merge pull request #70 from zehortigoza/jam
> >>       
> > Cool, the code might give additional information. I've also send a
> > request regarding the firmware and HW documentation to the author and
> > the engineers that signed the patch. The firmware in the patch has a
> > different version string and the size is surprisingly a few MB bigger
> > than the one I used for the first experiment. I'll give that one a try
> > as well.
> >  
> >> You would be able to see it. Unfortunately, the driver there
> >> also came with shisp_2401a0_v21.bin.
> >>
> >> The driver there forces this specific version, disabling the 
> >> firmware version checking:
> >>
> >> recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch:+ccflags-y += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DATOMISP_FWNAME=\"shisp_2401a0_v21.bin\" -DISP2401 -DISP2401_NEW_INPUT_SYSTEM
> >>
> >> I also found a firmware for some other Asus Transformer device:
> >>
> >> 	https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware
> >>  
> > It looks a this firmware is for the 2400 variant; I could also not
> > extract the irci version string. Thus I'll not try them for the moment
> > to perform experiments.  
> 
> I've a problem with the build; I've pulled the latest changes from the
> repository - and at least some
> of your changes are lost. I also checked via the web page and there I
> can also not see them
> anymore:
> 
> https://git.linuxtv.org/mchehab/experimental.git/tree/drivers/staging/media/atomisp/atomisp_v4l2.c?h=atomisp_v2
> 
> const struct firmware *
> atomisp_load_firmware(struct atomisp_device *isp)
> {
>     const struct firmware *fw;
>     int rc;
>     char *fw_path = NULL;
> 
>     if (skip_fwload)
>         return NULL;
> 
>     if (isp->media_dev.hw_revision ==
>         ((ATOMISP_HW_REVISION_ISP2401 << ATOMISP_HW_REVISION_SHIFT)
>          | ATOMISP_HW_STEPPING_A0))
>         fw_path = "shisp_2401a0_v21.bin";
> 
>     if (isp->media_dev.hw_revision ==
>         ((ATOMISP_HW_REVISION_ISP2401_LEGACY << ATOMISP_HW_REVISION_SHIFT)
>          | ATOMISP_HW_STEPPING_A0))
>         fw_path = "shisp_2401a0_legacy_v21.bin";
> 
>     if (isp->media_dev.hw_revision ==
>         ((ATOMISP_HW_REVISION_ISP2400 << ATOMISP_HW_REVISION_SHIFT)
>          | ATOMISP_HW_STEPPING_B0))
>         fw_path = "shisp_2400b0_v21.bin";
> 
>     if (!fw_path) {
>         dev_err(isp->dev, "Unsupported hw_revision 0x%x\n",
>             isp->media_dev.hw_revision);
>         return NULL;
>     }
> 
>     rc = request_firmware(&fw, fw_path, isp->dev);
>     if (rc) {
>         dev_err(isp->dev,
>             "atomisp: Error %d while requesting firmware %s\n",
>             rc, fw_path);
>         return NULL;
>     }
> 
>     return fw;
> }
> 
> It also does not build properly anymore (uses the old API again). Do you
> know what
> I'm doing wrong here?

My fault, sorry. There were something wrong on my .git/config, making
it to push a wrong branch to my experimental tree. Just did a forced
push. You should be able to build the atomisp driver there again.

Just be sure to do something like:

	$ git remote update && git reset --HARD origin/atomisp_v2

(This will get rid of any other patch or changes you might have
 applied)

Regards,
Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 2 May 2020 10:15:42 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On Fri, 1 May 2020 21:30:23 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> > Em Fri, 1 May 2020 19:31:05 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >   

> > Ok. Btw, there is a driver for Atomisp on an yocto tree:
> > 
> > 	https://github.com/intel-aero/meta-intel-aero.git
> > 
> > It got removed back in 2018, but if you checkout this changeset:
> > 
> > 	Merge: db1df368eb58 08f476112708
> > 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
> > 	Date:   Tue Apr 4 11:51:42 2017 -0700
> > 
> > 	    Merge pull request #70 from zehortigoza/jam
> >       
> 
> Cool, the code might give additional information.

Yes. And, as it was released from Intel for a specific device,
it should very likely work for the model supported there (with
the Yocto 4.4 Kernel). So, it could be valuable to help identifying
if some of the cleanup patches would have broken something.

ON a quick look, it sounds that such build was is targeted for
ISP2401:

	+++ b/drivers/media/pci/atomisp/Makefile
	@@ -0,0 +1 @@
	+obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/

> I've also send a
> request regarding the firmware and HW documentation to the author and
> the engineers that signed the patch. The firmware in the patch has a
> different version string and the size is surprisingly a few MB bigger
> than the one I used for the first experiment. 

There are some vendors that generate a firmware together with a source
code. This could be the case here. That's my feeling when looking into
a file like:

	drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c

Which contains lots of addresses that it is different betwen 2401 and
2400.

If so, using a different firmware version will likely cause at least
some parts of the driver to fail.


> I'll give that one a try as well.
> 
> > You would be able to see it. Unfortunately, the driver there
> > also came with shisp_2401a0_v21.bin.
> > 
> > The driver there forces this specific version, disabling the 
> > firmware version checking:
> > 
> > recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch:+ccflags-y += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DATOMISP_FWNAME=\"shisp_2401a0_v21.bin\" -DISP2401 -DISP2401_NEW_INPUT_SYSTEM
> > 
> > I also found a firmware for some other Asus Transformer device:
> > 
> > 	https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware
> >   
> 
> It looks a this firmware is for the 2400 variant; I could also not
> extract the irci version string. Thus I'll not try them for the moment
> to perform experiments.

Ok.

> > That's said, there's also a firmware for it inside this:
> > 	https://dlcdnets.asus.com/pub/ASUS/nb/DriversForWin10/Chipset/Chipset_Intel_CherryTrail_T_Win10_64_VER110.zip
> > 
> > Probably it is a different version, but it could be worth renaming it and
> > try it. The firmware load code should check if the firmware version is the
> > right one.  
> 
> It identifies itself as irci_stable_bw10p_0518_20150801_0537; 

Same year as what we had. Just a little older. Yeah, some things there
could work.

> I'll give
> that one a try first. As usual it will unfortunately take some time
> until I get back to you with the results, as every experiment takes
> many hours (building the kernel on what is essentially a tablet takes
> time).

I would suggest you to build on some other machine. Btw, you don't need
to build everything every time. If you build atomisp as a module, you
could do, instead:

	$ make modules_prepare && make M=drivers/staging/media/atomisp

This will build just the new module(s).

> > > [    9.691775] cpu_latency_qos_update_request called for unknown object

Btw, the patch I send earlier today should fix this issue.

-

I need to understand a little bit more about how ACPI is supposed to
detect and register regulators. While using regulators with DT is very
common, not many places use it for ACPI. 

I'm suspecting that, before being able of calling regulator_get(),
the code should use some match logic to get the regulators on this
board and call regulator_register().

Please run this command on your tablet:

	$ sudo cat /sys/kernel/debug/regulator/supply_map

If this returns nothing - as I suspect - then calling regulator_get()
won't be doing anything. 

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Sat, 2 May 2020 11:34:14 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Em Sat, 2 May 2020 10:15:42 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
>  [...]  
>  [...]  
> 
> > > Ok. Btw, there is a driver for Atomisp on an yocto tree:
> > > 
> > > 	https://github.com/intel-aero/meta-intel-aero.git
> > > 
> > > It got removed back in 2018, but if you checkout this changeset:
> > > 
> > > 	Merge: db1df368eb58 08f476112708
> > > 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
> > > 	Date:   Tue Apr 4 11:51:42 2017 -0700
> > > 
> > > 	    Merge pull request #70 from zehortigoza/jam
> > >         
> > 
> > Cool, the code might give additional information.  
> 
> Yes. And, as it was released from Intel for a specific device,
> it should very likely work for the model supported there (with
> the Yocto 4.4 Kernel). So, it could be valuable to help identifying
> if some of the cleanup patches would have broken something.
> 
> ON a quick look, it sounds that such build was is targeted for
> ISP2401:
> 
> 	+++ b/drivers/media/pci/atomisp/Makefile
> 	@@ -0,0 +1 @@
> 	+obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/
> 
> > I've also send a
> > request regarding the firmware and HW documentation to the author and
> > the engineers that signed the patch. The firmware in the patch has a
> > different version string and the size is surprisingly a few MB bigger
> > than the one I used for the first experiment.   
> 
> There are some vendors that generate a firmware together with a source
> code. This could be the case here. That's my feeling when looking into
> a file like:
> 
> 	drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c
> 
> Which contains lots of addresses that it is different betwen 2401 and
> 2400.
> 
> If so, using a different firmware version will likely cause at least
> some parts of the driver to fail.
> 
> 
>  [...]  
>  [...]  
> > 
> > It looks a this firmware is for the 2400 variant; I could also not
> > extract the irci version string. Thus I'll not try them for the moment
> > to perform experiments.  
> 
> Ok.
> 
>  [...]  
> > 
> > It identifies itself as irci_stable_bw10p_0518_20150801_0537;   
> 
> Same year as what we had. Just a little older. Yeah, some things there
> could work.

Below the result from the test with
irci_stable_bw10p_0518_20150801_0537 - looks like it loaded the
firmare; I got an a message when the file was not present, or the
version did not add up. I tried to cleanup the dmesg output a little
(removed what was unrelated to atom-isp):

[    9.072291] mc: Linux media interface: v0.10
[    9.156498] videodev: Linux video capture interface: v2.00
[    9.237603] atomisp_ov2680: loading out-of-tree module taints kernel.
[    9.240478] atomisp_ov2680: module is from the staging directory, the quality is unknown, you have been warned.
[    9.323975] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
[    9.334204] ov2680 i2c-OVTI2680:00: supply V1P2A not found, using dummy regulator
[    9.346739] ov2680 i2c-OVTI2680:00: supply VPROG4B not found, using dummy regulator
[    9.357528] ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
[    9.373085] ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
[    9.418879] atomisp_ov2680: module is from the staging directory, the quality is unknown, you have been warned.
[    9.446467] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.474456] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
[    9.474533] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
[    9.483924] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
[    9.491798] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
[    9.549017] atomisp: module is from the staging directory, the quality is unknown, you have been warned.
[    9.738785] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
[    9.802937] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
[   10.052114] atomisp-isp2 0000:00:03.0: Subdev OVTI2680:00 successfully register
[   10.056691] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port0 was not initialized!
[   10.061721] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port1 was not initialized!
[   10.071887] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port2 was not initialized!
[   10.071901] atomisp-isp2 0000:00:03.0: Entity type for entity file_input_subdev was not initialized!
[   10.080785] atomisp-isp2 0000:00:03.0: Entity type for entity tpg_subdev was not initialized!
[   10.084988] atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_0 was not initialized!
[   10.089196] ------------[ cut here ]------------
[   10.093225] WARNING: CPU: 1 PID: 503 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]
[   10.097258] Modules linked in: irqbypass snd_intel_sst_acpi(+) snd_seq_midi punit_atom_debug snd_intel_sst_core snd_seq_midi_event snd_soc_sst_atom_hifi2_platform intel_cstate snd_soc_acpi_intel_match snd_soc_acpi snd_soc_rt5645(+) ath10k_pci joydev snd_soc_rl6231 ath10k_core snd_soc_core snd_rawmidi asus_nb_wmi efi_pstore hid_sensor_gyro_3d atomisp(CO+) snd_compress hid_sensor_accel_3d hid_sensor_trigger intel_chtdc_ti_pwrbtn ath industrialio_triggered_buffer ac97_bus mac80211 snd_hdmi_lpe_audio kfifo_buf snd_pcm_dmaengine hid_sensor_iio_common hid_multitouch intel_xhci_usb_role_switch cfg80211 industrialio snd_pcm libarc4 roles cros_ec_ishtp mei_txe processor_thermal_device cros_ec atomisp_ov2680(CO) intel_rapl_common mei snd_seq videobuf_vmalloc intel_soc_dts_iosf videobuf_core snd_seq_device snd_timer snd videodev mc intel_hid 8250_dw spi_pxa2xx_platform soundcore int3400_thermal acpi_thermal_rel int3403_thermal soc_button_array acpi_pad int3406_thermal dw_dmac int340x_thermal
 _zone
[   10.097306]  dw_dmac_core intel_int0002_vgpio mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_ishtp_hid hid_asus asus_wmi sparse_keymap crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mmc_block hid_generic i915 aesni_intel i2c_algo_bit crypto_simd drm_kms_helper cryptd glue_helper syscopyarea sysfillrect sysimgblt fb_sys_fops usbhid cec lpc_ich drm intel_ish_ipc intel_ishtp wmi i2c_hid intel_soc_pmic_chtdc_ti video hid sdhci_acpi sdhci
[   10.144416] CPU: 1 PID: 503 Comm: systemd-udevd Tainted: G         C O      5.7.0-rc1+ #2
[   10.144429] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000
[   10.148909] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
[   10.148930] RIP: 0010:__video_register_device+0x93e/0x1120 [videodev]
[   10.148936] Code: 00 76 54 83 f8 04 0f 84 b9 06 00 00 0f 82 9b 00 00 00 83 f8 05 0f 85 ee 00 00 00 c7 43 2c 01 00 01 00 41 bc 05 02 00 00 eb 4b <0f> 0b 41 bd ea ff ff ff 48 8b 7d d0 65 48 33 3c 25 28 00 00 00 44
[   10.148938] RSP: 0018:ffffbb0b0065b940 EFLAGS: 00010246
[   10.148941] RAX: ffff982c6a80c028 RBX: ffff982c771a0fd0 RCX: 0000000000000000
[   10.148948] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffff982c771a0fd0
[   10.186454] RBP: ffffbb0b0065b990 R08: ffffffffc0ccaf40 R09: 0000000000000000
[   10.191217] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
[   10.195989] R13: ffffffffc0ccaf40 R14: 0000000000000000 R15: 0000000000000001
[   10.200763] FS:  00007fc84cccd880(0000) GS:ffff982c7be80000(0000) knlGS:0000000000000000
[   10.205557] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.210325] CR2: 000055d999a9a998 CR3: 00000001704be000 CR4: 00000000001006e0
[   10.215153] Call Trace:
[   10.219992]  atomisp_video_register+0x33/0x50 [atomisp]
[   10.224839]  atomisp_subdev_register_entities+0x39/0xd0 [atomisp]
[   10.224887]  atomisp_pci_probe.cold.19+0x71a/0x116f [atomisp]
[   10.234924]  local_pci_probe+0x47/0x80
[   10.234928]  pci_device_probe+0xff/0x1b0
[   10.234935]  really_probe+0x1c8/0x3e0
[   10.234942]  driver_probe_device+0xd9/0x120
[   10.245045]  device_driver_attach+0x58/0x60
[   10.245049]  __driver_attach+0x8f/0x150
[   10.245053]  ? device_driver_attach+0x60/0x60
[   10.245056]  ? device_driver_attach+0x60/0x60
[   10.245061]  bus_for_each_dev+0x79/0xc0
[   10.293310]  ? kmem_cache_alloc_trace+0x167/0x230
[   10.298004]  driver_attach+0x1e/0x20
[   10.302623]  bus_add_driver+0x154/0x1f0
[   10.307229]  ? 0xffffffffc0bf6000
[   10.311819]  driver_register+0x70/0xc0
[   10.316432]  ? 0xffffffffc0bf6000
[   10.316435]  __pci_register_driver+0x54/0x60
[   10.316476]  atomisp_pci_driver_init+0x23/0x1000 [atomisp]
[   10.316480]  do_one_initcall+0x4a/0x200
[   10.316484]  ? kfree+0x22e/0x250
[   10.316488]  ? _cond_resched+0x19/0x30
[   10.316491]  ? kmem_cache_alloc_trace+0x167/0x230
[   10.316496]  do_init_module+0x60/0x230
[   10.316499]  load_module+0x224a/0x24e0
[   10.316506]  __do_sys_finit_module+0xbd/0x120
[   10.316509]  ? __do_sys_finit_module+0xbd/0x120
[   10.316513]  __x64_sys_finit_module+0x1a/0x20
[   10.316517]  do_syscall_64+0x57/0x1b0
[   10.316521]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.316524] RIP: 0033:0x7fc84d24194d
[   10.316528] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 13 e5 0c 00 f7 d8 64 89 01 48
[   10.316529] RSP: 002b:00007fffd0506a88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   10.316532] RAX: ffffffffffffffda RBX: 000055d999a78560 RCX: 00007fc84d24194d
[   10.316534] RDX: 0000000000000000 RSI: 00007fc84d11ecad RDI: 000000000000000f
[   10.316535] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
[   10.316537] R10: 000000000000000f R11: 0000000000000246 R12: 00007fc84d11ecad
[   10.316538] R13: 0000000000000000 R14: 000055d999a8b4c0 R15: 000055d999a78560
[   10.316543] ---[ end trace 7f4c17cfaa1f3f65 ]---
[   10.316618] atomisp-isp2 0000:00:03.0: atomisp_video_register: could not register video device (-22)
[   10.333529] atomisp-isp2 0000:00:03.0: atomisp_subdev_register_entities fail
[   10.366495] atomisp-isp2 0000:00:03.0: atomisp_register_entities failed (-22)

> 
> > I'll give
> > that one a try first. As usual it will unfortunately take some time
> > until I get back to you with the results, as every experiment takes
> > many hours (building the kernel on what is essentially a tablet takes
> > time).  
> 
> I would suggest you to build on some other machine. Btw, you don't need
> to build everything every time. If you build atomisp as a module, you
> could do, instead:
> 
> 	$ make modules_prepare && make M=drivers/staging/media/atomisp
> 
> This will build just the new module(s).

Thanks; that is a huge time saver.

> 
> > > > [    9.691775] cpu_latency_qos_update_request called for unknown object  
> 
> Btw, the patch I send earlier today should fix this issue.
> 

Yep - looks like this one is gone :-).

> 
> I need to understand a little bit more about how ACPI is supposed to
> detect and register regulators. While using regulators with DT is very
> common, not many places use it for ACPI. 
> 
> I'm suspecting that, before being able of calling regulator_get(),
> the code should use some match logic to get the regulators on this
> board and call regulator_register().
> 
> Please run this command on your tablet:
> 
> 	$ sudo cat /sys/kernel/debug/regulator/supply_map
> 
> If this returns nothing - as I suspect - then calling regulator_get()
> won't be doing anything. 

The statement to read the supply_map did return nothing, as you'd
expected.

> 
> Thanks,
> Mauro

with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 2 May 2020 16:29:51 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On Sat, 2 May 2020 11:34:14 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> > Em Sat, 2 May 2020 10:15:42 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> > 
> >  [...]  
> >  [...]  
> >   
> > > > Ok. Btw, there is a driver for Atomisp on an yocto tree:
> > > > 
> > > > 	https://github.com/intel-aero/meta-intel-aero.git
> > > > 
> > > > It got removed back in 2018, but if you checkout this changeset:
> > > > 
> > > > 	Merge: db1df368eb58 08f476112708
> > > > 	Author: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > 	Date:   Tue Apr 4 11:51:42 2017 -0700
> > > > 
> > > > 	    Merge pull request #70 from zehortigoza/jam
> > > >           
> > > 
> > > Cool, the code might give additional information.    
> > 
> > Yes. And, as it was released from Intel for a specific device,
> > it should very likely work for the model supported there (with
> > the Yocto 4.4 Kernel). So, it could be valuable to help identifying
> > if some of the cleanup patches would have broken something.
> > 
> > ON a quick look, it sounds that such build was is targeted for
> > ISP2401:
> > 
> > 	+++ b/drivers/media/pci/atomisp/Makefile
> > 	@@ -0,0 +1 @@
> > 	+obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/
> >   
> > > I've also send a
> > > request regarding the firmware and HW documentation to the author and
> > > the engineers that signed the patch. The firmware in the patch has a
> > > different version string and the size is surprisingly a few MB bigger
> > > than the one I used for the first experiment.     
> > 
> > There are some vendors that generate a firmware together with a source
> > code. This could be the case here. That's my feeling when looking into
> > a file like:
> > 
> > 	drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c
> > 
> > Which contains lots of addresses that it is different betwen 2401 and
> > 2400.
> > 
> > If so, using a different firmware version will likely cause at least
> > some parts of the driver to fail.
> > 
> > 
> >  [...]  
> >  [...]    
> > > 
> > > It looks a this firmware is for the 2400 variant; I could also not
> > > extract the irci version string. Thus I'll not try them for the moment
> > > to perform experiments.    
> > 
> > Ok.
> > 
> >  [...]    
> > > 
> > > It identifies itself as irci_stable_bw10p_0518_20150801_0537;     
> > 
> > Same year as what we had. Just a little older. Yeah, some things there
> > could work.  
> 
> Below the result from the test with
> irci_stable_bw10p_0518_20150801_0537 - looks like it loaded the
> firmare; I got an a message when the file was not present, or the
> version did not add up. I tried to cleanup the dmesg output a little
> (removed what was unrelated to atom-isp):

> [   10.089196] ------------[ cut here ]------------
> [   10.093225] WARNING: CPU: 1 PID: 503 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]

That's due to a change at the media core that added this test:

	/* the device_caps field MUST be set for all but subdevs */
	if (WARN_ON(type != VFL_TYPE_SUBDEV && !vdev->device_caps))
		return -EINVAL;

Added on this patch:

	commit 3c1350501c21db8e3b1a38d9e97db29694305c3b
	Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
	Date:   Tue Jul 23 04:21:25 2019 -0400

	    media: v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results
    
	    Now that all V4L2 drivers set device_caps in struct video_device, we can add
	    a check for this to ensure all future drivers fill this in.

Fixing it is simple. Just sent a patch.

> > I'm suspecting that, before being able of calling regulator_get(),
> > the code should use some match logic to get the regulators on this
> > board and call regulator_register().
> > 
> > Please run this command on your tablet:
> > 
> > 	$ sudo cat /sys/kernel/debug/regulator/supply_map
> > 
> > If this returns nothing - as I suspect - then calling regulator_get()
> > won't be doing anything.   
> 
> The statement to read the supply_map did return nothing, as you'd
> expected.

Ok. That explains why register_get() failed ;-)

If this time the probing part works, I guess the next step would
be to use some tools from https://git.linuxtv.org/v4l-utils.git/,
in order to test the stuff that doesn't depend on the sensors,
as, without the regulator settings, it won't be turned on.

The simplest test would be to run:

	$ v4l2-ctl --all -d /dev/video0

(and the same for the other /dev/video? nodes created by the driver)

-

A more complete test would be to run v4l2-compliance (without
enabling streaming), but let's first check if v4l2-ctl won't
hit any Kernel bugs.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Sat, 2 May 2020 18:28:37 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Em Sat, 2 May 2020 16:29:51 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
> > On Sat, 2 May 2020 11:34:14 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >    
>  [...]  
> > 
> > Below the result from the test with
> > irci_stable_bw10p_0518_20150801_0537 - looks like it loaded the
> > firmare; I got an a message when the file was not present, or the
> > version did not add up. I tried to cleanup the dmesg output a little
> > (removed what was unrelated to atom-isp):  
> 
> > [   10.089196] ------------[ cut here ]------------
> > [   10.093225] WARNING: CPU: 1 PID: 503 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]  
> 
> That's due to a change at the media core that added this test:
> 
> 	/* the device_caps field MUST be set for all but subdevs */
> 	if (WARN_ON(type != VFL_TYPE_SUBDEV && !vdev->device_caps))
> 		return -EINVAL;
> 
> Added on this patch:
> 
> 	commit 3c1350501c21db8e3b1a38d9e97db29694305c3b
> 	Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> 	Date:   Tue Jul 23 04:21:25 2019 -0400
> 
> 	    media: v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results
>     
> 	    Now that all V4L2 drivers set device_caps in struct video_device, we can add
> 	    a check for this to ensure all future drivers fill this in.
> 
> Fixing it is simple. Just sent a patch.

I applied your patch; here the resulting messages (did not compile full kernel, but only the module):
[    9.261205] kernel: videodev: Linux video capture interface: v2.00
[    9.285172] kernel: atomisp_ov2680: loading out-of-tree module taints kernel.
[    9.287930] kernel: atomisp_ov2680: module is from the staging directory, the quality is unknown, you have been warned.
[    9.337584] kernel: ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data.PMIC ID 1
[    9.342193] kernel: ov2680 i2c-OVTI2680:00: supply V1P2A not found, using dummy regulator
[    9.346278] kernel: ov2680 i2c-OVTI2680:00: supply VPROG4B not found, using dummy regulator
[    9.350419] kernel: ov2680 i2c-OVTI2680:00: supply Regulator1p8v not found, using dummy regulator
[    9.354530] kernel: ov2680 i2c-OVTI2680:00: supply Regulator2p8v not found, using dummy regulator
[    9.375913] kernel: proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002)
[    9.405529] kernel: ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[    9.427136] kernel: atomisp: module is from the staging directory, the quality is unknown, you have been warned.
[    9.433835] kernel: ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
[    9.438446] kernel: ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
[    9.441739] kernel: ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
[    9.544474] kernel: atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
[    9.573919] kernel: atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
[    9.829161] kernel: atomisp-isp2 0000:00:03.0: Subdev OVTI2680:00 successfully register
[    9.833264] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port0 was not initialized!
[    9.852847] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port1 was not initialized!
[    9.894230] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port2 was not initialized!
[    9.899609] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity file_input_subdev was not initialized!
[    9.909981] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity tpg_subdev was not initialized!
[    9.914186] kernel: atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_0 was not initialized!
[    9.941592] kernel: ------------[ cut here ]------------
[    9.945885] kernel: WARNING: CPU: 2 PID: 515 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]
[    9.950250] kernel: Modules linked in: irqbypass snd_seq_midi punit_atom_debug snd_compress intel_cstate ac97_bus mac80211(+) snd_pcm_dmaengine snd_seq_midi_event asus_nb_wmi snd_rawmidi snd_hdmi_lpe_audio(+) efi_pstore hid_sensor_gyro_3d hid_sensor_accel_3d intel_chtdc_ti_pwrbtn hid_sensor_trigger industrialio_triggered_buffer kfifo_buf snd_pcm snd_seq hid_multitouch(+) cfg80211 hid_sensor_iio_common atomisp(CO+) industrialio mei_txe videobuf_vmalloc snd_seq_device processor_thermal_device intel_rapl_common libarc4 videobuf_core cros_ec_ishtp snd_timer intel_soc_dts_iosf intel_xhci_usb_role_switch cros_ec mei atomisp_ov2680(CO) roles videodev snd spi_pxa2xx_platform mc intel_hid 8250_dw dw_dmac soundcore dw_dmac_core int3400_thermal soc_button_array int3403_thermal acpi_thermal_rel intel_int0002_vgpio int3406_thermal int340x_thermal_zone acpi_pad mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_i
 shtp_hid hid_asus
[    9.950303] kernel:  asus_wmi sparse_keymap crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 hid_generic mmc_block i2c_algo_bit aesni_intel drm_kms_helper crypto_simd syscopyarea sysfillrect sysimgblt cryptd fb_sys_fops glue_helper cec usbhid intel_ish_ipc drm wmi lpc_ich intel_ishtp video i2c_hid intel_soc_pmic_chtdc_ti hid sdhci_acpi sdhci
[    9.999137] kernel: CPU: 2 PID: 515 Comm: systemd-udevd Tainted: G         C O      5.7.0-rc1+ #2
[   10.004479] kernel: Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
[   10.009868] kernel: RIP: 0010:__video_register_device+0x93e/0x1120 [videodev]
[   10.015264] kernel: Code: 00 76 54 83 f8 04 0f 84 b9 06 00 00 0f 82 9b 00 00 00 83 f8 05 0f 85 ee 00 00 00 c7 43 2c 01 00 01 00 41 bc 05 02 00 00 eb 4b <0f> 0b 41 bd ea ff ff ff 48 8b 7d d0 65 48 33 3c 25 28 00 00 00 44
[   10.026427] kernel: RSP: 0018:ffffb3fe00713940 EFLAGS: 00010246
[   10.032023] kernel: RAX: ffff94f8e9eb4028 RBX: ffff94f8ed863310 RCX: 0000000000000000
[   10.037660] kernel: RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffff94f8ed863310
[   10.043308] kernel: RBP: ffffb3fe00713990 R08: ffffffffc07c4f40 R09: ffff94f8fb403500
[   10.048952] kernel: R10: ffffffffffffe002 R11: 0000000000000000 R12: 00000000ffffffff
[   10.054589] kernel: R13: ffffffffc07c4f40 R14: 0000000000000000 R15: 0000000000000001
[   10.060175] kernel: FS:  00007f0f204f6880(0000) GS:ffff94f8fbf00000(0000) knlGS:0000000000000000
[   10.065821] kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   10.071389] kernel: CR2: 00007f0f20aee421 CR3: 000000016b600000 CR4: 00000000001006e0
[   10.076891] kernel: Call Trace:
[   10.082382] kernel:  atomisp_acc_register+0x33/0x50 [atomisp]
[   10.087791] kernel:  atomisp_subdev_register_entities+0x91/0xd0 [atomisp]
[   10.093106] kernel:  atomisp_pci_probe.cold.19+0x71a/0x116f [atomisp]
[   10.098279] kernel:  local_pci_probe+0x47/0x80
[   10.103406] kernel:  pci_device_probe+0xff/0x1b0
[   10.108443] kernel:  really_probe+0x1c8/0x3e0
[   10.113376] kernel:  driver_probe_device+0xd9/0x120
[   10.118297] kernel:  device_driver_attach+0x58/0x60
[   10.123219] kernel:  __driver_attach+0x8f/0x150
[   10.128146] kernel:  ? device_driver_attach+0x60/0x60
[   10.132994] kernel:  ? device_driver_attach+0x60/0x60
[   10.137715] kernel:  bus_for_each_dev+0x79/0xc0
[   10.142440] kernel:  ? kmem_cache_alloc_trace+0x167/0x230
[   10.147147] kernel:  driver_attach+0x1e/0x20
[   10.151807] kernel:  bus_add_driver+0x154/0x1f0
[   10.156372] kernel:  ? 0xffffffffc07ff000
[   10.160844] kernel:  driver_register+0x70/0xc0
[   10.165248] kernel:  ? 0xffffffffc07ff000
[   10.169579] kernel:  __pci_register_driver+0x54/0x60
[   10.173966] kernel:  atomisp_pci_driver_init+0x23/0x1000 [atomisp]
[   10.178334] kernel:  do_one_initcall+0x4a/0x200
[   10.182676] kernel:  ? kfree+0x22e/0x250
[   10.186913] kernel:  ? _cond_resched+0x19/0x30
[   10.191055] kernel:  ? kmem_cache_alloc_trace+0x167/0x230
[   10.195131] kernel:  do_init_module+0x60/0x230
[   10.199083] kernel:  load_module+0x224a/0x24e0
[   10.201809] kernel: hid-multitouch 0018:0457:11ED.0003: input,hidraw2: I2C HID v1.00 Device [SIS0457:00 0457:11ED] on i2c-SIS0457:00
[   10.202893] kernel:  __do_sys_finit_module+0xbd/0x120
[   10.210562] kernel:  ? __do_sys_finit_module+0xbd/0x120
[   10.214169] kernel:  __x64_sys_finit_module+0x1a/0x20
[   10.217634] kernel:  do_syscall_64+0x57/0x1b0
[   10.220961] kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   10.224188] kernel: RIP: 0033:0x7f0f20a6a94d
[   10.227270] kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 13 e5 0c 00 f7 d8 64 89 01 48
[   10.233595] kernel: RSP: 002b:00007fff22cf5488 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   10.236770] kernel: RAX: ffffffffffffffda RBX: 00005599a433b560 RCX: 00007f0f20a6a94d
[   10.239918] kernel: RDX: 0000000000000000 RSI: 00007f0f20947cad RDI: 0000000000000010
[   10.242986] kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
[   10.242988] kernel: R10: 0000000000000010 R11: 0000000000000246 R12: 00007f0f20947cad
[   10.242990] kernel: R13: 0000000000000000 R14: 00005599a43820d0 R15: 00005599a433b560
[   10.243000] kernel: ---[ end trace c4f253dd02f49f40 ]---
[   10.254587] kernel: atomisp-isp2 0000:00:03.0: atomisp_acc_register: could not register video device (-22)

I always fear I load the wrong version. Is there a way I could add a
version (which I would increase for each patch) that then can be
checked, e.g. by modinfo?

> 
>  [...]  
> > 
> > The statement to read the supply_map did return nothing, as you'd
> > expected.  
> 
> Ok. That explains why register_get() failed ;-)
> 
> If this time the probing part works, I guess the next step would
> be to use some tools from https://git.linuxtv.org/v4l-utils.git/,
> in order to test the stuff that doesn't depend on the sensors,
> as, without the regulator settings, it won't be turned on.
> 
> The simplest test would be to run:
> 
> 	$ v4l2-ctl --all -d /dev/video0
> 
> (and the same for the other /dev/video? nodes created by the driver)
> 

Unfortunately I'm not sure if the driver already creates the devices, 
"$ ls /dev | grep video" did not return anything. Anyway - I'll download
the tools to be prepared. I will try your command - maybe I
misunderstand and the ctl call creates the device nodes.

> -
> 
> A more complete test would be to run v4l2-compliance (without
> enabling streaming), but let's first check if v4l2-ctl won't
> hit any Kernel bugs.
> 
> Thanks,
> Mauro

with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Sat, 2 May 2020 11:34:14 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Em Sat, 2 May 2020 10:15:42 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
> > On Fri, 1 May 2020 21:30:23 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >   
>  [...]  
> 
>  [...]  
> > 
> > Cool, the code might give additional information.  
> 
> Yes. And, as it was released from Intel for a specific device,
> it should very likely work for the model supported there (with
> the Yocto 4.4 Kernel). So, it could be valuable to help identifying
> if some of the cleanup patches would have broken something.
> 
> ON a quick look, it sounds that such build was is targeted for
> ISP2401:
> 
> 	+++ b/drivers/media/pci/atomisp/Makefile
> 	@@ -0,0 +1 @@
> 	+obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/
> 
> > I've also send a
> > request regarding the firmware and HW documentation to the author and
> > the engineers that signed the patch. The firmware in the patch has a
> > different version string and the size is surprisingly a few MB bigger
> > than the one I used for the first experiment.   
> 
> There are some vendors that generate a firmware together with a source
> code. This could be the case here. That's my feeling when looking into
> a file like:
> 
> 	drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c
> 
> Which contains lots of addresses that it is different betwen 2401 and
> 2400.
> 
> If so, using a different firmware version will likely cause at least
> some parts of the driver to fail.
> 
> 
> > I'll give that one a try as well.
> >   
>  [...]  
> > 
> > It looks a this firmware is for the 2400 variant; I could also not
> > extract the irci version string. Thus I'll not try them for the moment
> > to perform experiments.  
> 
> Ok.
> 
>  [...]  
> > 
> > It identifies itself as irci_stable_bw10p_0518_20150801_0537;   
> 
> Same year as what we had. Just a little older. Yeah, some things there
> could work.

I found another place where the irci_stable_bw10p_0518_20150801_0537
firmware is used together with patches for atomisp 2401. So I assume the
code there matches this firmware. Eventually some of the patches listed
there can be used as information source:

https://github.com/croutor/atomisp2401

> 
> > I'll give
> > that one a try first. As usual it will unfortunately take some time
> > until I get back to you with the results, as every experiment takes
> > many hours (building the kernel on what is essentially a tablet takes
> > time).  
> 
> I would suggest you to build on some other machine. Btw, you don't need
> to build everything every time. If you build atomisp as a module, you
> could do, instead:
> 
> 	$ make modules_prepare && make M=drivers/staging/media/atomisp
> 
> This will build just the new module(s).
> 
>  [...]  
> 
> Btw, the patch I send earlier today should fix this issue.
> 
> -
> 
> I need to understand a little bit more about how ACPI is supposed to
> detect and register regulators. While using regulators with DT is very
> common, not many places use it for ACPI. 
> 
> I'm suspecting that, before being able of calling regulator_get(),
> the code should use some match logic to get the regulators on this
> board and call regulator_register().
> 
> Please run this command on your tablet:
> 
> 	$ sudo cat /sys/kernel/debug/regulator/supply_map
> 
> If this returns nothing - as I suspect - then calling regulator_get()
> won't be doing anything. 
> 
> Thanks,
> Mauro

with kind regards,
Patrik

[PATCH] media: atomisp: use add_qos_request instead of update

[Mauro Carvalho Chehab]

It doesn't make senst to update a request that was not
created. So, instead of using cpu_latency_qos_update_request(),
let's use, instead cpu_latency_qos_add_request() at device
probing code.

This should fix this issue:

[    9.691775] cpu_latency_qos_update_request called for unknown object
[    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
[    9.698826] Modules linked in: snd_soc_acpi_intel_match snd_rawmidi snd_soc_acpi snd_soc_rl6231 snd_soc_core ath mac80211 snd_compress snd_hdmi_lpe_audio ac97_bus hid_sensor_accel_3d snd_pcm_dmaengine hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common processor_thermal_device industrialio cfg80211 snd_pcm snd_seq intel_rapl_common atomisp(C+) libarc4 intel_soc_dts_iosf cros_ec_ishtp intel_xhci_usb_role_switch mei_txe cros_ec videobuf_vmalloc mei roles atomisp_ov2680(C) videobuf_core snd_seq_device snd_timer spi_pxa2xx_platform videodev snd mc dw_dmac intel_hid dw_dmac_core 8250_dw soundcore int3406_thermal int3400_thermal intel_int0002_vgpio acpi_pad acpi_thermal_rel soc_button_array int3403_thermal int340x_thermal_zone mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_ishtp_hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 mmc_block
  i2c_algo_bit
[    9.698885]  aesni_intel crypto_simd drm_kms_helper cryptd syscopyarea sysfillrect glue_helper sysimgblt fb_sys_fops cec intel_ish_ipc drm lpc_ich intel_ishtp hid_asus intel_soc_pmic_chtdc_ti asus_wmi i2c_hid sparse_keymap sdhci_acpi wmi video sdhci hid_generic usbhid hid
[    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
[    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
[    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
[    9.750615] Code: 89 e5 41 55 41 54 41 89 f4 53 48 89 fb 48 81 7f 28 e0 7f c6 9e 74 1c 48 c7 c6 60 f3 65 9e 48 c7 c7 e8 a9 99 9e e8 b2 a6 f9 ff <0f> 0b 5b 41 5c 41 5d 5d c3 0f 1f 44 00 00 44 3b 23 74 ef 44 89 e2
[    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
[    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
[    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
[    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
[    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
[    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
[    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
[    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
[    9.802126] Call Trace:
[    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
[    9.811441]  local_pci_probe+0x47/0x80
[    9.816085]  pci_device_probe+0xff/0x1b0
[    9.820706]  really_probe+0x1c8/0x3e0
[    9.825247]  driver_probe_device+0xd9/0x120
[    9.829769]  device_driver_attach+0x58/0x60
[    9.834294]  __driver_attach+0x8f/0x150
[    9.838782]  ? device_driver_attach+0x60/0x60
[    9.843205]  ? device_driver_attach+0x60/0x60
[    9.847634]  bus_for_each_dev+0x79/0xc0
[    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
[    9.856462]  driver_attach+0x1e/0x20

Reported-by: Patrik Gfeller <patrik.gfeller@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 drivers/staging/media/atomisp/pci/atomisp_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
index 297f55a01b1b..f1bae9712720 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c
@@ -1751,7 +1751,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
 
 	atomisp_msi_irq_init(isp, dev);
 
-	cpu_latency_qos_update_request(&isp->pm_qos, PM_QOS_DEFAULT_VALUE);
+	cpu_latency_qos_add_request(&isp->pm_qos, PM_QOS_DEFAULT_VALUE);
 
 	/*
 	 * for MRFLD, Software/firmware needs to write a 1 to bit 0 of
-- 
2.25.4

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 18.04.20 17:25, Mauro Carvalho Chehab wrote:
> Em Sat, 18 Apr 2020 16:39:25 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
>
>> 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.
> There are simply too many things there to be fixed, and nobody without
> time for it. Also, the last reports we had is that the driver was not
> working.
>
> Unfortunately, I don't have myself any atomisp hardware, otherwise I
> could try fixing it on my spare time.

Thanks for your reply ... I would be glad to donate a device for this 
project :-). Please send me the contact data (maybe to my private 
eMail), then I'll take care to send one to you.

>
>> 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!
>>
>> All the best and stay healthy.
>>
>> With kind regards,
>>
>> Patrik Gfeller <patrik.gfeller@gmail.com>
>>
>
>
> Thanks,
> Mauro

Re: atomisp kernel driver(s)

[Laurent Pinchart]

Hi Patrik,

(CC'ing Sakari Ailus)

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

Re: atomisp kernel driver(s)

[Patrik Gfeller]

Hi Laurent,

thank you for your comprehensive answer.

On 25.04.20 04:39, Laurent Pinchart wrote:
> Hi Patrik,
>
> (CC'ing Sakari Ailus)
>
> 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.

Bad news indeed, this doesn't sound promising at all. I can confirm that 
the driver does not work out of the box in its current state (many 
thanks to Mauro for making this test possible). With all those obstacles 
I'm surprised that work on such a driver was even started. My only hope 
is, that the ISP 2 is better documented and less complex than ISP 3 ...

I'll try to get hold of hardware documentation from Intel, and check if 
there is any kind of community support program in place (it is at least 
worth a try :-) ) - that hopefully would allow to assess if there is a 
possibility to fix the driver and how much post processing would be 
needed in user space (what raw format that thing delivers). 
Unfortunately I would depend on others to do the judgment (I do not have 
the technical skills necessary). I'll also try to find out who initiated 
the original implementation to find out on what documentation it was 
based (or if it was all reverse engineering) and what was the rational 
to asses such an implementation as possible.

What I've found already is a public document about the ISP2-Registers of 
the x5-Z8350:

https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf 
(page 972 ff.) - not sure if this is of any help.

What kind of documentation would be needed? What I understood so far is 
that details of ACPI format are important.

As already mentioned: I would also sponsor a device or two to developers 
with a reputation as you and Mauro have (preferably the same device I 
have :-), they are quite cheap today - and that is a way I could support 
the efforts).

>> 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 :-)

with kind regards,

Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 25 Apr 2020 12:36:18 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> Hi Laurent,
> 
> thank you for your comprehensive answer.
> 
> On 25.04.20 04:39, Laurent Pinchart wrote:
> > Hi Patrik,
> >
> > (CC'ing Sakari Ailus)
> >
> > 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.

I decoded the ACPI table that Patrik provided. It is on Intel format:

 * Original Table Header:
 *     Signature        "DSDT"
 *     Length           0x0001A0BD (106685)
 *     Revision         0x02
 *     Checksum         0x76
 *     OEM ID           "_ASUS_"
 *     OEM Table ID     "Notebook"
 *     OEM Revision     0x01072009 (17244169)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20120913 (538052883)

> > - 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.

Yes, this is indeed something to consider: in order to get good quality
images, it would need to run some proprietary software, at least while
someone doesn't develop support for it under libcamera.

> > - 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.

Well, staging can accept crap code, provided that someone would be
working to address its problems.

> > I'm sorry for the bad news, we need to be more vocal blaming hardware
> > vendors for this type of mess.  
> 
> Bad news indeed, this doesn't sound promising at all. I can confirm that 
> the driver does not work out of the box in its current state (many 
> thanks to Mauro for making this test possible). With all those obstacles 
> I'm surprised that work on such a driver was even started. My only hope 
> is, that the ISP 2 is better documented and less complex than ISP 3 ...
> 
> I'll try to get hold of hardware documentation from Intel, and check if 
> there is any kind of community support program in place (it is at least 
> worth a try :-) ) - that hopefully would allow to assess if there is a 
> possibility to fix the driver and how much post processing would be 
> needed in user space (what raw format that thing delivers). 
> Unfortunately I would depend on others to do the judgment (I do not have 
> the technical skills necessary). I'll also try to find out who initiated 
> the original implementation to find out on what documentation it was 
> based (or if it was all reverse engineering) and what was the rational 
> to asses such an implementation as possible.
> 
> What I've found already is a public document about the ISP2-Registers of 
> the x5-Z8350:
> 
> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf 
> (page 972 ff.) - not sure if this is of any help.
> 
> What kind of documentation would be needed? What I understood so far is 
> that details of ACPI format are important.
> 
> As already mentioned: I would also sponsor a device or two to developers 
> with a reputation as you and Mauro have (preferably the same device I 
> have :-), they are quite cheap today - and that is a way I could support 
> the efforts).

Don't give up just yet. At least for the probing part, getting the right
ACPI values seem easily fixable, as the table is at Intel format.

Something like the enclosed patch, on the top of the last patches on my
experimental tree should make the device specific ACPI data visible to 
the code that retrieves some ACPI data. Yet, this line:

	DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),

May need some changes, depending on the result of "dmidecode" command.

Thanks,
Mauro

[PATCH] media: atomisp: add Asus ACPI vars

Those were extracted from an ACPI dump:

 * Original Table Header:
 *     Signature        "DSDT"
 *     Length           0x0001A0BD (106685)
 *     Revision         0x02
 *     Checksum         0x76
 *     OEM ID           "_ASUS_"
 *     OEM Table ID     "Notebook"
 *     OEM Revision     0x01072009 (17244169)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20120913 (538052883)
 */
DefinitionBlock ("", "DSDT", 2, "_ASUS_", "Notebook", 0x01072009)
...
                    Local0 = Package (0x12)
                        {
                            "CamId",
                            "ov2680",
                            "CamType",
                            "1",
                            "CsiPort",
                            "0",
                            "CsiLanes",
                            "1",
                            "CsiFmt",
                            "15",
                            "CsiBayer",
                            "0",
                            "CamClk",
                            "1",
                            "Regulator1p8v",
                            "0",
                            "Regulator2p8v",
                            "0"
                        }

Note: the DMI_MATCH() line probably needs to be tweaked.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index eef7123a586f..a5cd9ac7396b 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
 	{},
 };
 
+static struct gmin_cfg_var asus_vars[] = {
+	{"OVTI2680:00_CsiPort", "1"},
+	{"OVTI2680:00_CsiLanes", "1"},
+	{"OVTI2680:00_CsiFmt", "15"},
+	{"OVTI2680:00_CsiBayer", "0"},
+	{"OVTI2680:00_CamClk", "0"},
+	{},
+};
+
 static const struct dmi_system_id gmin_vars[] = {
 	{
 		.ident = "BYT-T FFD8",
@@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
 		},
 		.driver_data = i8880_vars,
 	},
+	{
+		.ident = "_ASUS_",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),
+		},
+		.driver_data = asus_vars,
+	},
 	{}
 };
 

Re: atomisp kernel driver(s)

[Laurent Pinchart]

Hi Mauro,

On Sat, Apr 25, 2020 at 02:19:24PM +0200, Mauro Carvalho Chehab wrote:
> Em Sat, 25 Apr 2020 12:36:18 +0200 Patrik Gfeller escreveu:
> > 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.
> 
> I decoded the ACPI table that Patrik provided. It is on Intel format:
> 
>  * Original Table Header:
>  *     Signature        "DSDT"
>  *     Length           0x0001A0BD (106685)
>  *     Revision         0x02
>  *     Checksum         0x76
>  *     OEM ID           "_ASUS_"
>  *     OEM Table ID     "Notebook"
>  *     OEM Revision     0x01072009 (17244169)
>  *     Compiler ID      "INTL"
>  *     Compiler Version 0x20120913 (538052883)

What do you mean by Intel format ? The DSDT is a standard ACPI table,
and INTL here refers to which compiler was used to generate the table,
not to the format of the table itself.

> > > - 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.
> 
> Yes, this is indeed something to consider: in order to get good quality
> images, it would need to run some proprietary software, at least while
> someone doesn't develop support for it under libcamera.

I'm not sure that's an option though, as I'm not sure there's a binary
provided by Intel that could be easily sourced and integrated in a
regular Linux distribution. Vendors usually supports Android only. I
haven't checked though, and I may be wrong, but I suspect that the best
way forward would be to work on an open implementation (which will be
time consuming and full of challenges, I don't want to give false
hopes).

> > > - 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.
> 
> Well, staging can accept crap code, provided that someone would be
> working to address its problems.

We'll need to find someone willing to do that :-) As I said, this would
actually be the easiest of all the problems we have to solve, so I'm not
concerned.

> > > I'm sorry for the bad news, we need to be more vocal blaming hardware
> > > vendors for this type of mess.  
> > 
> > Bad news indeed, this doesn't sound promising at all. I can confirm that 
> > the driver does not work out of the box in its current state (many 
> > thanks to Mauro for making this test possible). With all those obstacles 
> > I'm surprised that work on such a driver was even started. My only hope 
> > is, that the ISP 2 is better documented and less complex than ISP 3 ...
> > 
> > I'll try to get hold of hardware documentation from Intel, and check if 
> > there is any kind of community support program in place (it is at least 
> > worth a try :-) ) - that hopefully would allow to assess if there is a 
> > possibility to fix the driver and how much post processing would be 
> > needed in user space (what raw format that thing delivers). 
> > Unfortunately I would depend on others to do the judgment (I do not have 
> > the technical skills necessary). I'll also try to find out who initiated 
> > the original implementation to find out on what documentation it was 
> > based (or if it was all reverse engineering) and what was the rational 
> > to asses such an implementation as possible.
> > 
> > What I've found already is a public document about the ISP2-Registers of 
> > the x5-Z8350:
> > 
> > https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf 
> > (page 972 ff.) - not sure if this is of any help.
> > 
> > What kind of documentation would be needed? What I understood so far is 
> > that details of ACPI format are important.
> > 
> > As already mentioned: I would also sponsor a device or two to developers 
> > with a reputation as you and Mauro have (preferably the same device I 
> > have :-), they are quite cheap today - and that is a way I could support 
> > the efforts).
> 
> Don't give up just yet. At least for the probing part, getting the right
> ACPI values seem easily fixable, as the table is at Intel format.
> 
> Something like the enclosed patch, on the top of the last patches on my
> experimental tree should make the device specific ACPI data visible to 
> the code that retrieves some ACPI data. Yet, this line:
> 
> 	DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),
> 
> May need some changes, depending on the result of "dmidecode" command.
> 
> Thanks,
> Mauro
> 
> [PATCH] media: atomisp: add Asus ACPI vars
> 
> Those were extracted from an ACPI dump:
> 
>  * Original Table Header:
>  *     Signature        "DSDT"
>  *     Length           0x0001A0BD (106685)
>  *     Revision         0x02
>  *     Checksum         0x76
>  *     OEM ID           "_ASUS_"
>  *     OEM Table ID     "Notebook"
>  *     OEM Revision     0x01072009 (17244169)
>  *     Compiler ID      "INTL"
>  *     Compiler Version 0x20120913 (538052883)
>  */
> DefinitionBlock ("", "DSDT", 2, "_ASUS_", "Notebook", 0x01072009)
> ...
>                     Local0 = Package (0x12)
>                         {
>                             "CamId",
>                             "ov2680",
>                             "CamType",
>                             "1",
>                             "CsiPort",
>                             "0",
>                             "CsiLanes",
>                             "1",
>                             "CsiFmt",
>                             "15",
>                             "CsiBayer",
>                             "0",
>                             "CamClk",
>                             "1",
>                             "Regulator1p8v",
>                             "0",
>                             "Regulator2p8v",
>                             "0"
>                         }

This data is part of \_SB.PCI0.I2C3.CAM1, which is related to the camera
sensor. It should be parsed by the ov2680 driver, which needs to be
ported from the atomisp-specific implementation to a V4L2 subdev. We'll
likely need to add ACPI-specific code to the driver as the ACPI data
isn't compatible with the fwnode interface as far as I can tell. Sakari
has more knowledge than me here, and it may be possible to extend the
fwnode implementation with support for atomisp-specific ACPI data,
although I'm not sure all atomisp-based systems use the same format
(there's way less standardization of device-specific data in ACPI than
there is in the DT world, despite the false promises of ACPI to provide
true interoperability - anyone reading this can guess what I think about
the ACPI on ARM64 lie).

Another challenge is to locate the camera sensor connected to the
atomisp. There's ACPI data for the atomisp itself (in
\_SB.PCI0.GFX0.ISP0), but as far as I can tell, there's nothing there
that would link to \_SB.PCI0.I2C3.CAM, and nothing in \_SB.PCI0.I2C3.CAM
that would link to \_SB.PCI0.GFX0.ISP0. We could have DMI-based tables
in the driver to link the two, but that just doesn't scale, and we need
to figure out something better. The IPU3 ACPI tables used by Windows
suffer for the same problem. If we can't figure out an automatic way
with reasonable heuristics, we'll need board code to provide that
information. Another broken promise of ACPI :-)

All this is doable, but is quite a bit of work. What I'm not sure about
is whether all the information that the drivers would need are present
in ACPI (the CSI-2 bus configuration is at least partly described,
that's a good sign), or if some data would be missing, which would then
really require board code.

> Note: the DMI_MATCH() line probably needs to be tweaked.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> 
> diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> index eef7123a586f..a5cd9ac7396b 100644
> --- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> +++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
>  	{},
>  };
>  
> +static struct gmin_cfg_var asus_vars[] = {
> +	{"OVTI2680:00_CsiPort", "1"},
> +	{"OVTI2680:00_CsiLanes", "1"},
> +	{"OVTI2680:00_CsiFmt", "15"},
> +	{"OVTI2680:00_CsiBayer", "0"},
> +	{"OVTI2680:00_CamClk", "0"},
> +	{},
> +};
> +
>  static const struct dmi_system_id gmin_vars[] = {
>  	{
>  		.ident = "BYT-T FFD8",
> @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
>  		},
>  		.driver_data = i8880_vars,
>  	},
> +	{
> +		.ident = "_ASUS_",
> +		.matches = {
> +			DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),
> +		},
> +		.driver_data = asus_vars,
> +	},
>  	{}
>  };

This is acceptable as an interim solution in order to experiment, but
the driver should really parse the ACPI data instead.

-- 
Regards,

Laurent Pinchart

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sun, 26 Apr 2020 22:07:08 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Sat, Apr 25, 2020 at 02:19:24PM +0200, Mauro Carvalho Chehab wrote:
> > Em Sat, 25 Apr 2020 12:36:18 +0200 Patrik Gfeller escreveu:  
> > > 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.  
> > 
> > I decoded the ACPI table that Patrik provided. It is on Intel format:
> > 
> >  * Original Table Header:
> >  *     Signature        "DSDT"
> >  *     Length           0x0001A0BD (106685)
> >  *     Revision         0x02
> >  *     Checksum         0x76
> >  *     OEM ID           "_ASUS_"
> >  *     OEM Table ID     "Notebook"
> >  *     OEM Revision     0x01072009 (17244169)
> >  *     Compiler ID      "INTL"
> >  *     Compiler Version 0x20120913 (538052883)  
> 
> What do you mean by Intel format ? The DSDT is a standard ACPI table,
> and INTL here refers to which compiler was used to generate the table,
> not to the format of the table itself.

Yeah, I meant to say that it was built using Intel compiler. 

Also, from what I checked, I suspect that the DSDT table is parseable
by the current code, with minimal changes.

> > > > - 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.  
> > 
> > Yes, this is indeed something to consider: in order to get good quality
> > images, it would need to run some proprietary software, at least while
> > someone doesn't develop support for it under libcamera.  
> 
> I'm not sure that's an option though, as I'm not sure there's a binary
> provided by Intel that could be easily sourced and integrated in a
> regular Linux distribution. Vendors usually supports Android only. I
> haven't checked though, and I may be wrong, but I suspect that the best
> way forward would be to work on an open implementation (which will be
> time consuming and full of challenges, I don't want to give false
> hopes).

Yeah, I understand your point. 

I would love to see some feedback weather this driver works or not,
in order to know if it would be worth touching it.

> > > > - 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.  
> > 
> > Well, staging can accept crap code, provided that someone would be
> > working to address its problems.  
> 
> We'll need to find someone willing to do that :-) As I said, this would
> actually be the easiest of all the problems we have to solve, so I'm not
> concerned.

Right now, I can probably do that, if I can get some hardware on my hands.

It sounds an interesting challenge, although I'd like to know what happens
after getting the driver properly probing the devices, before taking
any decision.

> 
> > > > I'm sorry for the bad news, we need to be more vocal blaming hardware
> > > > vendors for this type of mess.    
> > > 
> > > Bad news indeed, this doesn't sound promising at all. I can confirm that 
> > > the driver does not work out of the box in its current state (many 
> > > thanks to Mauro for making this test possible). With all those obstacles 
> > > I'm surprised that work on such a driver was even started. My only hope 
> > > is, that the ISP 2 is better documented and less complex than ISP 3 ...
> > > 
> > > I'll try to get hold of hardware documentation from Intel, and check if 
> > > there is any kind of community support program in place (it is at least 
> > > worth a try :-) ) - that hopefully would allow to assess if there is a 
> > > possibility to fix the driver and how much post processing would be 
> > > needed in user space (what raw format that thing delivers). 
> > > Unfortunately I would depend on others to do the judgment (I do not have 
> > > the technical skills necessary). I'll also try to find out who initiated 
> > > the original implementation to find out on what documentation it was 
> > > based (or if it was all reverse engineering) and what was the rational 
> > > to asses such an implementation as possible.
> > > 
> > > What I've found already is a public document about the ISP2-Registers of 
> > > the x5-Z8350:
> > > 
> > > https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf 
> > > (page 972 ff.) - not sure if this is of any help.
> > > 
> > > What kind of documentation would be needed? What I understood so far is 
> > > that details of ACPI format are important.
> > > 
> > > As already mentioned: I would also sponsor a device or two to developers 
> > > with a reputation as you and Mauro have (preferably the same device I 
> > > have :-), they are quite cheap today - and that is a way I could support 
> > > the efforts).  
> > 
> > Don't give up just yet. At least for the probing part, getting the right
> > ACPI values seem easily fixable, as the table is at Intel format.
> > 
> > Something like the enclosed patch, on the top of the last patches on my
> > experimental tree should make the device specific ACPI data visible to 
> > the code that retrieves some ACPI data. Yet, this line:
> > 
> > 	DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),
> > 
> > May need some changes, depending on the result of "dmidecode" command.
> > 
> > Thanks,
> > Mauro
> > 
> > [PATCH] media: atomisp: add Asus ACPI vars
> > 
> > Those were extracted from an ACPI dump:
> > 
> >  * Original Table Header:
> >  *     Signature        "DSDT"
> >  *     Length           0x0001A0BD (106685)
> >  *     Revision         0x02
> >  *     Checksum         0x76
> >  *     OEM ID           "_ASUS_"
> >  *     OEM Table ID     "Notebook"
> >  *     OEM Revision     0x01072009 (17244169)
> >  *     Compiler ID      "INTL"
> >  *     Compiler Version 0x20120913 (538052883)
> >  */
> > DefinitionBlock ("", "DSDT", 2, "_ASUS_", "Notebook", 0x01072009)
> > ...
> >                     Local0 = Package (0x12)
> >                         {
> >                             "CamId",
> >                             "ov2680",
> >                             "CamType",
> >                             "1",
> >                             "CsiPort",
> >                             "0",
> >                             "CsiLanes",
> >                             "1",
> >                             "CsiFmt",
> >                             "15",
> >                             "CsiBayer",
> >                             "0",
> >                             "CamClk",
> >                             "1",
> >                             "Regulator1p8v",
> >                             "0",
> >                             "Regulator2p8v",
> >                             "0"
> >                         }  
> 
> This data is part of \_SB.PCI0.I2C3.CAM1, which is related to the camera
> sensor. It should be parsed by the ov2680 driver, which needs to be
> ported from the atomisp-specific implementation to a V4L2 subdev. We'll
> likely need to add ACPI-specific code to the driver as the ACPI data
> isn't compatible with the fwnode interface as far as I can tell. 

The atomisp driver has already an ACPI parser. it is actually a single
ACPI parser for all supported sensors.

Actually, the code there requires a struct dmi_system_id table, with
contains the name of the supported systems, plus the names of the
variables that would be read from the CAM1 table (with may vary from
system to system).

Once it gets the values, the atomisp core sets the corresponding data
and passes it to the subdevs.

Yeah, one of the cleanup tasks would be to change its model for it to
work the same way as other V4L2 subdevs work, but this is something
that could happen with the driver on staging.

> Sakari
> has more knowledge than me here, and it may be possible to extend the
> fwnode implementation with support for atomisp-specific ACPI data,
> although I'm not sure all atomisp-based systems use the same format
> (there's way less standardization of device-specific data in ACPI than
> there is in the DT world, despite the false promises of ACPI to provide
> true interoperability - anyone reading this can guess what I think about
> the ACPI on ARM64 lie).

I really doubt that we'll get rid of different ACPI implementations.

Maybe the only way for such drivers to work on PC would be to have
something outside the subdev drivers that would contain some
ACPI parsers that would use a model similar to the ones we have with
PCI and USB devices, passing sensor-specific configuration via
platform_data.

In any case, we're not there yet. We should first ensure that
the driver produces video streams from sensor data.

Then, look on how to make it produce reasonable good images.

Only when we get there, we can go forward and work to cleanup the 
driver and integrate with libcamera.

Btw, up to some point, that's the same problem with IPU3 driver:
until today it doesn't work with PC hardware, and I'm not seeing
much efforts trying to solve its problems.

> Another challenge is to locate the camera sensor connected to the
> atomisp. There's ACPI data for the atomisp itself (in
> \_SB.PCI0.GFX0.ISP0), but as far as I can tell, there's nothing there
> that would link to \_SB.PCI0.I2C3.CAM, and nothing in \_SB.PCI0.I2C3.CAM
> that would link to \_SB.PCI0.GFX0.ISP0. We could have DMI-based tables
> in the driver to link the two, but that just doesn't scale, and we need
> to figure out something better.

Well, we do that for PCI boards already. I don't think we'll be able to
run away for that, as a change there would require BIOS changes.

Ok, we could eventually define a format for a firmware file that could
be loaded by the driver, but that will also require someone to maintain
those firmware files. Implementing it on Kernel or on userspace won't
make any easier to maintain it.

> The IPU3 ACPI tables used by Windows
> suffer for the same problem. If we can't figure out an automatic way
> with reasonable heuristics, we'll need board code to provide that
> information. Another broken promise of ACPI :-)

Yeah, I strongly suspect that, for IPU3, we'll end by needing DMI_MATCH
tables, as different vendors will implement things on different ways.

> All this is doable, but is quite a bit of work. What I'm not sure about
> is whether all the information that the drivers would need are present
> in ACPI (the CSI-2 bus configuration is at least partly described,
> that's a good sign), or if some data would be missing, which would then
> really require board code.

IMHO, a good sign is that there's just one part of the atomisp driver
that has DMI_MATCH entries. Probably there aren't much board-specific
deviations from the model, but maybe I'm just too much optimistic.

> 
> > Note: the DMI_MATCH() line probably needs to be tweaked.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > 
> > diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > index eef7123a586f..a5cd9ac7396b 100644
> > --- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > +++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > @@ -269,6 +269,15 @@ static struct gmin_cfg_var i8880_vars[] = {
> >  	{},
> >  };
> >  
> > +static struct gmin_cfg_var asus_vars[] = {
> > +	{"OVTI2680:00_CsiPort", "1"},
> > +	{"OVTI2680:00_CsiLanes", "1"},
> > +	{"OVTI2680:00_CsiFmt", "15"},
> > +	{"OVTI2680:00_CsiBayer", "0"},
> > +	{"OVTI2680:00_CamClk", "0"},
> > +	{},
> > +};
> > +
> >  static const struct dmi_system_id gmin_vars[] = {
> >  	{
> >  		.ident = "BYT-T FFD8",
> > @@ -306,6 +315,13 @@ static const struct dmi_system_id gmin_vars[] = {
> >  		},
> >  		.driver_data = i8880_vars,
> >  	},
> > +	{
> > +		.ident = "_ASUS_",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BOARD_NAME, "_ASUS_"),
> > +		},
> > +		.driver_data = asus_vars,
> > +	},
> >  	{}
> >  };  
> 
> This is acceptable as an interim solution in order to experiment, but
> the driver should really parse the ACPI data instead.

Agreed.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Laurent Pinchart]

Hi Patrik,

On Sat, Apr 25, 2020 at 12:36:18PM +0200, Patrik Gfeller wrote:
> 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.
> 
> Bad news indeed, this doesn't sound promising at all. I can confirm that 
> the driver does not work out of the box in its current state (many 
> thanks to Mauro for making this test possible). With all those obstacles 
> I'm surprised that work on such a driver was even started. My only hope 
> is, that the ISP 2 is better documented and less complex than ISP 3 ...
> 
> I'll try to get hold of hardware documentation from Intel, and check if 
> there is any kind of community support program in place (it is at least 
> worth a try :-) ) - that hopefully would allow to assess if there is a 
> possibility to fix the driver and how much post processing would be 
> needed in user space (what raw format that thing delivers). 
> Unfortunately I would depend on others to do the judgment (I do not have 
> the technical skills necessary). I'll also try to find out who initiated 

It could also be an interesting project to acquire those technical
skills ;-) It's often said that the best way forward with free software
development is to scratch your own itch.

> the original implementation to find out on what documentation it was 
> based (or if it was all reverse engineering) and what was the rational 
> to asses such an implementation as possible.
> 
> What I've found already is a public document about the ISP2-Registers of 
> the x5-Z8350:
> 
> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf 
> (page 972 ff.) - not sure if this is of any help.
> 
> What kind of documentation would be needed? What I understood so far is 
> that details of ACPI format are important.

The ACPI format is important, and after a quick glance it seems that
some data at least is encoded in a readable way. There's however

\_SB_.PCI0.I2C3.CAM1._DSM bothers me. It's a device-specific method that
returns device-specific data in an undocumented format. Some of it is
human-readable (the package returned when Arg0 is
dc2f6c4f-045b-4f1d-97b9-882a6860a4be for instance), but some of it isn't
(f486d39f-d657-484b-84a6-42a565712b92 for instance). I haven't seen any
call to the _DSM method in the atomisp driver, so we can't figure out
what it contains from the driver code. Maybe we won't need that data at
all. We also don't know whether we would need data that is not available
in the DSDT.

Beside the ACPI format, we need to know how to communicate with the
device, and with its firmware. Documentation of hardware registers
helps, but I would expect most of that to already be handled in the
atomisp driver. The part that worries me the most is the communication
with the firmware. The firmware takes a very large number of ISP
configuration parameters at runtime. They are defined in
drivers/staging/media/atomisp/include/linux, but under-documented, so
it's not clear how most of them work.

> As already mentioned: I would also sponsor a device or two to developers 
> with a reputation as you and Mauro have (preferably the same device I 
> have :-), they are quite cheap today - and that is a way I could support 
> the efforts).
> 
> >> 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

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 26.04.20 21:33, Laurent Pinchart wrote:
> Hi Patrik,
>
> On Sat, Apr 25, 2020 at 12:36:18PM +0200, Patrik Gfeller wrote:
>> 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.
>> Bad news indeed, this doesn't sound promising at all. I can confirm that
>> the driver does not work out of the box in its current state (many
>> thanks to Mauro for making this test possible). With all those obstacles
>> I'm surprised that work on such a driver was even started. My only hope
>> is, that the ISP 2 is better documented and less complex than ISP 3 ...
>>
>> I'll try to get hold of hardware documentation from Intel, and check if
>> there is any kind of community support program in place (it is at least
>> worth a try :-) ) - that hopefully would allow to assess if there is a
>> possibility to fix the driver and how much post processing would be
>> needed in user space (what raw format that thing delivers).
>> Unfortunately I would depend on others to do the judgment (I do not have
>> the technical skills necessary). I'll also try to find out who initiated
> It could also be an interesting project to acquire those technical
> skills ;-) It's often said that the best way forward with free software
> development is to scratch your own itch.

That's definitely a true statement & I'll do my best to help. But 
without C & Linux background I can not directly contribute to the code - 
who knows, maybe some day. I try to read, learn and understand - first I 
try to get used to the operating system and to be able to perform basic 
tasks as collecting data, build kernel & learn about the utilities 
required (didn't know modprobe, insmod, dmesg and alike a few weeks ago).

>
>> the original implementation to find out on what documentation it was
>> based (or if it was all reverse engineering) and what was the rational
>> to asses such an implementation as possible.
>>
>> What I've found already is a public document about the ISP2-Registers of
>> the x5-Z8350:
>>
>> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf
>> (page 972 ff.) - not sure if this is of any help.
>>
>> What kind of documentation would be needed? What I understood so far is
>> that details of ACPI format are important.
> The ACPI format is important, and after a quick glance it seems that
> some data at least is encoded in a readable way. There's however
>
> \_SB_.PCI0.I2C3.CAM1._DSM bothers me. It's a device-specific method that
> returns device-specific data in an undocumented format. Some of it is
> human-readable (the package returned when Arg0 is
> dc2f6c4f-045b-4f1d-97b9-882a6860a4be for instance), but some of it isn't
> (f486d39f-d657-484b-84a6-42a565712b92 for instance). I haven't seen any
> call to the _DSM method in the atomisp driver, so we can't figure out
> what it contains from the driver code. Maybe we won't need that data at
> all. We also don't know whether we would need data that is not available
> in the DSDT.
>
> Beside the ACPI format, we need to know how to communicate with the
> device, and with its firmware. Documentation of hardware registers
> helps, but I would expect most of that to already be handled in the
> atomisp driver. The part that worries me the most is the communication
> with the firmware. The firmware takes a very large number of ISP
> configuration parameters at runtime. They are defined in
> drivers/staging/media/atomisp/include/linux, but under-documented, so
> it's not clear how most of them work.
I understand. I'll approach Intel to see if there is any chance that we 
get something useful in terms of documentation from them.
>
>> As already mentioned: I would also sponsor a device or two to developers
>> with a reputation as you and Mauro have (preferably the same device I
>> have :-), they are quite cheap today - and that is a way I could support
>> the efforts).
>>
>>>> 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 :-)

Re: atomisp kernel driver(s)

[Patrik Gfeller]

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?

thanks and kind regards,
Patrik

On 25.04.20 04:39, Laurent Pinchart wrote:
> Hi Patrik,
>
> (CC'ing Sakari Ailus)
>
> 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 :-)
>

Re: atomisp kernel driver(s)

[Laurent Pinchart]

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

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 26.04.20 21:17, Laurent Pinchart wrote:
> 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.

Thanks, That was exactly what I was looking for. I've made sure that 
dynamic debug support was enabled and re-compiled the kernel. Then I've 
added to the following boot parameter: dyndbg="module atomisp_ov2680 +pm".

I do not see debug messages in dmesg or kern.log - but maybe we do not 
reach those lines yet.

>> 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 :-)

Re: atomisp kernel driver(s)

[Laurent Pinchart]

Hi Patrik,

On Wed, Apr 29, 2020 at 07:59:23PM +0200, Patrik Gfeller wrote:
> On 26.04.20 21:17, Laurent Pinchart wrote:
> > 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.
> 
> Thanks, That was exactly what I was looking for. I've made sure that 
> dynamic debug support was enabled and re-compiled the kernel. Then I've 
> added to the following boot parameter: dyndbg="module atomisp_ov2680 +pm".

Can you try

atomisp_ov2680.dyndbg=+p

? I haven't tested the plain dyndbg argument myself. Make sure it gets
to the kernel with

cat /proc/cmdline

> I do not see debug messages in dmesg or kern.log - but maybe we do not 
> reach those lines yet.

You can add a dev_dbg() at the beginning of the probe function and see
if that one gets printed.

> >> 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

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On 29.04.20 20:19, Laurent Pinchart wrote:
> Hi Patrik,
>
> On Wed, Apr 29, 2020 at 07:59:23PM +0200, Patrik Gfeller wrote:
>> On 26.04.20 21:17, Laurent Pinchart wrote:
>>> 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.
>> Thanks, That was exactly what I was looking for. I've made sure that
>> dynamic debug support was enabled and re-compiled the kernel. Then I've
>> added to the following boot parameter: dyndbg="module atomisp_ov2680 +pm".
> Can you try
>
> atomisp_ov2680.dyndbg=+p
>
> ? I haven't tested the plain dyndbg argument myself. Make sure it gets
> to the kernel with
>
> cat /proc/cmdline

First I checked my current configuration again (did some more reading) - 
does not look ok:

$ cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-5.7.0-rc1+ 
root=UUID=7c547d86-dd95-4cb2-b7ad-e46368c8eed3 ro ignore_loglevel 
verbose fbcon=rotate:1 module_blacklist=intel_atomisp2_pm "dyndbg=module 
atomisp_ov2680 +pm; module atomisp +pm"

$ sudo cat /sys/kernel/debug/dynamic_debug/control | grep ov2680

...
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:329 
[atomisp_ov2680]ov2680_get_intg_factor =_ "++++ov2680_get_intg_factor\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:314 
[atomisp_ov2680]ov2680_g_bin_factor_y =_ "++++ov2680_g_bin_factor_y\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:302 
[atomisp_ov2680]ov2680_g_bin_factor_x =_ "++++ov2680_g_bin_factor_x\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:255 
[atomisp_ov2680]ov2680_write_reg_array =_ "+++ov2680_write_reg_array 
reg=%x->%x\012"
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:239 
[atomisp_ov2680]ov2680_write_reg_array =_ "++++write reg array\012"

...

But of course I tried your options as well:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.7.0-rc1+ 
root=UUID=7c547d86-dd95-4cb2-b7ad-e46368c8eed3 ro ignore_loglevel 
verbose fbcon=rotate:1 module_blacklist=intel_atomisp2_pm 
atomisp_ov2680.dyndbg=+p

$ sudo cat /sys/kernel/debug/dynamic_debug/control | grep ov2680

Control looks the same as with the first try; so this works as well (as 
expected).

I do not see debug messages yet - but I checked the code, and from what 
I understand we most likely do not reach them yet.
>> I do not see debug messages in dmesg or kern.log - but maybe we do not
>> reach those lines yet.
> You can add a dev_dbg() at the beginning of the probe function and see
> if that one gets printed.
I'll try this tomorrow (have time, as we have a holiday :-) ). Will have 
to find the probe function - but if I do not find it I'll just add the 
statement prior to a line that already shows some logging (e.g. where it 
does not find the regulators).
>
>>>> 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 :-)

Re: atomisp kernel driver(s)

[Andy Shevchenko]

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.

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

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 Best Regards,
Andy Shevchenko

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Hi Andy,

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

> 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.

I found a driver that is probably working:
	https://github.com/intel-aero/meta-intel-aero.git

It is for an Intel Mobile Aero AUV platform. I suspect that his one
should likely work. 

> My achievements end with no getting IRQ from the driver (and I was
> experimenting on MRD-7 CRB).
> 
> P.S. I also have some (semi-) debug patches I can share. 
> Perhaps they will give some more ideas.

Anything you can share will be welcomed.

> Btw, based on this discussion I think that
> it can be power issues with sensors that possible affect IRQ
> generation inside SiliconHive vector processor.

Yeah, the current issue sounds simple to solve, but I need to understand
how an ACPI-based device would be calling regulator_register(). Using
regulators with ACPI is new to me. I suspect that this should be done
by ./arch/x86/platform/intel-mid, with of course doesn't have the needed
bits for this board. Also, there is a dummy regulator driver for atomisp
based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could
be causing some issues too.

The atomisp driver uses regulator_get() to turn on the sensors.

In order for regulator_get() to work, regulator_dev_lookup() should
be capable of finding a regulator either via DT or via the
regulator_map_list.

The contents of the regulator_map_list should visible on a configfs
node (/sys/kernel/debug/regulator/supply_map).

Yet, those aren't visible (probably because the ACPI data was written
for Windows). So, the atomisp code should very likely call 
regulator_register() for the regulators with the atomisp driver
need, in order to setup the regulator list.


> In IPU3 the dedicated
> PMIC is used for camera devices, and I have no idea of the design for
> old ones.

I have here a Dell notebook with IPU3 on it (marketed for MS windows):

	ipu3_imgu: module is from the staging directory, the quality is unknown, you have been warned.
	ipu3-imgu 0000:00:05.0: enabling device (0000 -> 0002)
	ipu3-imgu 0000:00:05.0: device 0x1919 (rev: 0x1)
	ipu3-imgu 0000:00:05.0: physical base address 0x00000000ec000000, 4194304 bytes
	ipu3-imgu 0000:00:05.0: loaded firmware version irci_irci_ecr-master_20161208_0213_20170112_1500, 17 binaries, 1212984 bytes
	ipu3-cio2 0000:00:14.3: enabling device (0000 -> 0002)
	ipu3-cio2 0000:00:14.3: device 0x9d32 (rev: 0x1)

This command:

	# cat /sys/kernel/debug/regulator/supply_map

Returns nothing. So, it seems that the very same issue may also be
happening on IPU3-based laptops that won't have BIOSes designed to
work on Linux.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Andy Shevchenko]

On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> Em Sat, 2 May 2020 19:08:36 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
>
> > 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.
>
> I found a driver that is probably working:
>         https://github.com/intel-aero/meta-intel-aero.git
>
> It is for an Intel Mobile Aero AUV platform. I suspect that his one
> should likely work.

So, have anybody tried to build and get a picture (raw is very good
start for it) out of that sources and respective firmware?

> > My achievements end with no getting IRQ from the driver (and I was
> > experimenting on MRD-7 CRB).
> >
> > P.S. I also have some (semi-) debug patches I can share.
> > Perhaps they will give some more ideas.
>
> Anything you can share will be welcomed.

https://paste.debian.net/1144410/

No SoB from me (despite patches have them).

> > Btw, based on this discussion I think that
> > it can be power issues with sensors that possible affect IRQ
> > generation inside SiliconHive vector processor.
>
> Yeah, the current issue sounds simple to solve, but I need to understand
> how an ACPI-based device would be calling regulator_register(). Using
> regulators with ACPI is new to me. I suspect that this should be done
> by ./arch/x86/platform/intel-mid, with of course doesn't have the needed
> bits for this board. Also, there is a dummy regulator driver for atomisp
> based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could
> be causing some issues too.
>
> The atomisp driver uses regulator_get() to turn on the sensors.

It should use PMIC to get them.

> In order for regulator_get() to work, regulator_dev_lookup() should
> be capable of finding a regulator either via DT or via the
> regulator_map_list.
>
> The contents of the regulator_map_list should visible on a configfs
> node (/sys/kernel/debug/regulator/supply_map).
>
> Yet, those aren't visible (probably because the ACPI data was written
> for Windows). So, the atomisp code should very likely call
> regulator_register() for the regulators with the atomisp driver
> need, in order to setup the regulator list.
>
>
> > In IPU3 the dedicated
> > PMIC is used for camera devices, and I have no idea of the design for
> > old ones.
>
> I have here a Dell notebook with IPU3 on it (marketed for MS windows):
>
>         ipu3_imgu: module is from the staging directory, the quality is unknown, you have been warned.
>         ipu3-imgu 0000:00:05.0: enabling device (0000 -> 0002)
>         ipu3-imgu 0000:00:05.0: device 0x1919 (rev: 0x1)
>         ipu3-imgu 0000:00:05.0: physical base address 0x00000000ec000000, 4194304 bytes
>         ipu3-imgu 0000:00:05.0: loaded firmware version irci_irci_ecr-master_20161208_0213_20170112_1500, 17 binaries, 1212984 bytes
>         ipu3-cio2 0000:00:14.3: enabling device (0000 -> 0002)
>         ipu3-cio2 0000:00:14.3: device 0x9d32 (rev: 0x1)
>
> This command:
>
>         # cat /sys/kernel/debug/regulator/supply_map
>
> Returns nothing. So, it seems that the very same issue may also be
> happening on IPU3-based laptops that won't have BIOSes designed to
> work on Linux.

Because you have to have an OpRegion in ACPI for the camera PMIC (see
this driver
https://elixir.bootlin.com/linux/latest/source/drivers/acpi/pmic/tps68470_pmic.c).

AFAIU ISPv2 uses the generic Atom PMIC (see other drivers in the above
mentioned folder).

-- 
With Best Regards,
Andy Shevchenko

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 2 May 2020 20:33:14 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> > I found a driver that is probably working:
> >         https://github.com/intel-aero/meta-intel-aero.git
> >
> > It is for an Intel Mobile Aero AUV platform. I suspect that his one
> > should likely work.  
> 
> So, have anybody tried to build and get a picture (raw is very good
> start for it) out of that sources and respective firmware?

Not yet.

> 
> > > My achievements end with no getting IRQ from the driver (and I was
> > > experimenting on MRD-7 CRB).
> > >
> > > P.S. I also have some (semi-) debug patches I can share.
> > > Perhaps they will give some more ideas.  
> >
> > Anything you can share will be welcomed.  
> 
> https://paste.debian.net/1144410/
> 
> No SoB from me (despite patches have them).

Not sure what you meant by "no SoB". Can't I use the SoB on the
patches you sent, if I pick some of them on my tree?

> 
> > > Btw, based on this discussion I think that
> > > it can be power issues with sensors that possible affect IRQ
> > > generation inside SiliconHive vector processor.  
> >
> > Yeah, the current issue sounds simple to solve, but I need to understand
> > how an ACPI-based device would be calling regulator_register(). Using
> > regulators with ACPI is new to me. I suspect that this should be done
> > by ./arch/x86/platform/intel-mid, with of course doesn't have the needed
> > bits for this board. Also, there is a dummy regulator driver for atomisp
> > based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could
> > be causing some issues too.
> >
> > The atomisp driver uses regulator_get() to turn on the sensors.  
> 
> It should use PMIC to get them.

Ah, ok!

> 
> > In order for regulator_get() to work, regulator_dev_lookup() should
> > be capable of finding a regulator either via DT or via the
> > regulator_map_list.
> >
> > The contents of the regulator_map_list should visible on a configfs
> > node (/sys/kernel/debug/regulator/supply_map).
> >
> > Yet, those aren't visible (probably because the ACPI data was written
> > for Windows). So, the atomisp code should very likely call
> > regulator_register() for the regulators with the atomisp driver
> > need, in order to setup the regulator list.
> >
> >  
> > > In IPU3 the dedicated
> > > PMIC is used for camera devices, and I have no idea of the design for
> > > old ones.  
> >
> > I have here a Dell notebook with IPU3 on it (marketed for MS windows):
> >
> >         ipu3_imgu: module is from the staging directory, the quality is unknown, you have been warned.
> >         ipu3-imgu 0000:00:05.0: enabling device (0000 -> 0002)
> >         ipu3-imgu 0000:00:05.0: device 0x1919 (rev: 0x1)
> >         ipu3-imgu 0000:00:05.0: physical base address 0x00000000ec000000, 4194304 bytes
> >         ipu3-imgu 0000:00:05.0: loaded firmware version irci_irci_ecr-master_20161208_0213_20170112_1500, 17 binaries, 1212984 bytes
> >         ipu3-cio2 0000:00:14.3: enabling device (0000 -> 0002)
> >         ipu3-cio2 0000:00:14.3: device 0x9d32 (rev: 0x1)
> >
> > This command:
> >
> >         # cat /sys/kernel/debug/regulator/supply_map
> >
> > Returns nothing. So, it seems that the very same issue may also be
> > happening on IPU3-based laptops that won't have BIOSes designed to
> > work on Linux.  
> 
> Because you have to have an OpRegion in ACPI for the camera PMIC (see
> this driver
> https://elixir.bootlin.com/linux/latest/source/drivers/acpi/pmic/tps68470_pmic.c).

Thanks! I'll do some tests here on my IPU3 laptop in order to better
understand how PMIC is supposed to work.

> AFAIU ISPv2 uses the generic Atom PMIC (see other drivers in the above
> mentioned folder).

Yeah, I saw some code on other atomisp trees that have some code to
touch PMIC, but I didn't associate it with regulators.

Thanks for the help!

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sat, 2 May 2020 20:33:14 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > Em Sat, 2 May 2020 19:08:36 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> > Yeah, the current issue sounds simple to solve, but I need to understand
> > how an ACPI-based device would be calling regulator_register(). Using
> > regulators with ACPI is new to me. I suspect that this should be done
> > by ./arch/x86/platform/intel-mid, with of course doesn't have the needed
> > bits for this board. Also, there is a dummy regulator driver for atomisp
> > based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could
> > be causing some issues too.
> >
> > The atomisp driver uses regulator_get() to turn on the sensors.  
> 
> It should use PMIC to get them.

It took a while to make it right, but at least for PMIC TI, this is now
working with this patch:

	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=6c026db444d097d6df99597e07eb3575242e680e

It turns that I needed to pick some missing bits from Yocto's tree,
as the driver at staging was missing the parts for non-regulator PMICs.

I suspect that the original idea there were to use the regulator
framework for all power management (with IMHO, makes a lot of sense).

I also had to enable the PMIC ACPI OpRegion with:

	CONFIG_CHT_DC_TI_PMIC_OPREGION=y

And fix the PMIC region for PMIC TI.

I didn't test the other types of PMIC supported by the driver.
So, maybe some additional adjustments might be needed for
other types.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Andy Shevchenko]

On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
>
> Em Sat, 2 May 2020 20:33:14 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
>
> > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > Em Sat, 2 May 2020 19:08:36 +0300
> > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
>
> > > Yeah, the current issue sounds simple to solve, but I need to understand
> > > how an ACPI-based device would be calling regulator_register(). Using
> > > regulators with ACPI is new to me. I suspect that this should be done
> > > by ./arch/x86/platform/intel-mid, with of course doesn't have the needed
> > > bits for this board. Also, there is a dummy regulator driver for atomisp
> > > based boards (drivers/platform/x86/intel_atomisp2_pm.c). This one could
> > > be causing some issues too.
> > >
> > > The atomisp driver uses regulator_get() to turn on the sensors.
> >
> > It should use PMIC to get them.
>
> It took a while to make it right, but at least for PMIC TI, this is now
> working with this patch:
>
>         https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=6c026db444d097d6df99597e07eb3575242e680e
>
> It turns that I needed to pick some missing bits from Yocto's tree,
> as the driver at staging was missing the parts for non-regulator PMICs.
>
> I suspect that the original idea there were to use the regulator
> framework for all power management (with IMHO, makes a lot of sense).
>
> I also had to enable the PMIC ACPI OpRegion with:
>
>         CONFIG_CHT_DC_TI_PMIC_OPREGION=y
>
> And fix the PMIC region for PMIC TI.
>
> I didn't test the other types of PMIC supported by the driver.
> So, maybe some additional adjustments might be needed for
> other types.

Thanks! It makes sense.

Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
is incorrect approach. Look closer what PCI does in case when
pcim_enable_device() has been called.


-- 
With Best Regards,
Andy Shevchenko

Re: atomisp kernel driver(s)

[Andy Shevchenko]

On Tue, May 12, 2020 at 2:12 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
> <mchehab@kernel.org> wrote:
> > Em Sat, 2 May 2020 20:33:14 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > > Em Sat, 2 May 2020 19:08:36 +0300
> > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

...

> Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
> is incorrect approach. Look closer what PCI does in case when
> pcim_enable_device() has been called.

This has resource leaks
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=88b03de5d705f5f46a896dbd21ef9472030bb8d3

Easier just to acpi_handle_info(ACPI_HANDLE(...), ...);

We don't enumerate them w/o ACPI IIRC.

P.S. Yes, I understand that is WIP, but better to get rid  of
unnecessary / incorrect work from the day 1 :-)

-- 
With Best Regards,
Andy Shevchenko

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Tue, 12 May 2020 14:21:49 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> On Tue, May 12, 2020 at 2:12 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
> > <mchehab@kernel.org> wrote:
> > > Em Sat, 2 May 2020 20:33:14 +0300
> > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > > > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > > > Em Sat, 2 May 2020 19:08:36 +0300
> > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> 
> ...
> 
> > Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
> > is incorrect approach. Look closer what PCI does in case when
> > pcim_enable_device() has been called.
> 
> This has resource leaks
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=88b03de5d705f5f46a896dbd21ef9472030bb8d3
> 
> Easier just to acpi_handle_info(ACPI_HANDLE(...), ...);
> 
> We don't enumerate them w/o ACPI IIRC.

Well, at least while in staging, it would be good to know more details
about the probing issues on different hardware that people might be
testing it.

avoiding to use a get_device() here is not possible, because the
prints will use the adev to return some info we may need:

	ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680

This, together with the DMI product ID on this message:

	atomisp-isp2 0000:00:03.0: Detected Cherrytrail version 54 (ISP2401) on T101HA

may help to avoid users to run acpixtract/iasl/dmidecode when adding
new entries to the dmi match tables. Not 100%, since BIOSes may 
still use different names for the sensor data.

> 
> P.S. Yes, I understand that is WIP, but better to get rid  of
> unnecessary / incorrect work from the day 1 :-)

Agreed.

I added a call to "acpi_dev_put(adev)" after using the info, in order
to avoid the leak.

Btw, I guess we got some progress with the current version:

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

This is what it outputs to dmesg:

[   78.131669] atomisp-isp2 0000:00:03.0: Detected Cherrytrail version 54 (ISP2401) on T101HA
[   78.131684] atomisp-isp2 0000:00:03.0: enabling device (0000 -> 0002)
[   78.131924] atomisp-isp2 0000:00:03.0: start: 0x91000000
[   78.132121] atomisp-isp2 0000:00:03.0: base: 00000000e25c1a2a
[   78.132124] atomisp-isp2 0000:00:03.0: atomisp_io_base: 00000000e25c1a2a
[   78.132135] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
[   78.236722] atomisp-isp2 0000:00:03.0: Firmware version may not be compatible with this driver
[   78.236735] atomisp-isp2 0000:00:03.0: Expecting version 'irci_ecr - master_20150911_0724', but firmware is 'irci_stable_bw10p_0518_20150801_0537'.
[   79.533784] atomisp-isp2 0000:00:03.0: no camera attached or fail to detect
[   79.533829] atomisp-isp2 0000:00:03.0: atomisp_csi_lane_config: the portconfig is 4-1-0, CSI_CONTROL is 0x000000FC
[   79.533845] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port0 was not initialized!
[   79.533872] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port1 was not initialized!
[   79.533889] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port2 was not initialized!
[   79.533905] atomisp-isp2 0000:00:03.0: Entity type for entity file_input_subdev was not initialized!
[   79.533923] atomisp-isp2 0000:00:03.0: Entity type for entity tpg_subdev was not initialized!
[   79.533938] atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_0 was not initialized!
[   79.537195] atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_1 was not initialized!
[   79.538732] atomisp-isp2 0000:00:03.0: FILE_INPUT enable, camera_cnt: 0
[   79.538746] atomisp-isp2 0000:00:03.0: TPG detected, camera_cnt: 1
[   79.540979] atomisp-isp2 0000:00:03.0: atomisp_save_iunit_reg
[   79.541096] atomisp-isp2 0000:00:03.0: DFS target frequency=100.
[   79.541107] atomisp-isp2 0000:00:03.0: Programming DFS frequency to 100
[   79.541133] atomisp-isp2 0000:00:03.0: waiting for ISPSSPM1 valid bit to be 0.
[   79.541247] atomisp-isp2 0000:00:03.0: atomisp_ospm_dphy_down
[   79.541282] atomisp-isp2 0000:00:03.0: IUNIT power-off.
[   79.546938] atomisp-isp2 0000:00:03.0: Firmware version may not be compatible with this driver
[   79.546946] atomisp-isp2 0000:00:03.0: Expecting version 'irci_ecr - master_20150911_0724', but firmware is 'irci_stable_bw10p_0518_20150801_0537'.
[   79.590508] atomisp_ov2680: module is from the staging directory, the quality is unknown, you have been warned.
[   79.591775] atomisp-isp2 0000:00:03.0: IUNIT power-off timeout.
[   79.602168] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
[   79.604503] ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680
[   79.604545] ov2680 i2c-OVTI2680:00: found 'INT33F5:00' at address 0x5e, adapter 6
[   79.604550] ov2680 i2c-OVTI2680:00: gmin: power management provided via Dollar Cove TI PMIC (i2c addr 0x5e)
[   79.604566] ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CamClk'
[   79.604573] ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_ClkSrc'
[   79.604577] ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CsiPort'
[   79.604582] ov2680 i2c-OVTI2680:00: Found DMI entry for 'OVTI2680:00_CsiLanes'
[   79.604816] ov2680 i2c-OVTI2680:00: Found DMI entry for 'gmin_V1P8GPIO'
[   79.604823] ov2680 i2c-OVTI2680:00: Found DMI entry for 'gmin_V2P8GPIO'
[   79.604829] ov2680 i2c-OVTI2680:00: I2C write, addr: 0x5e, reg: 0x4a, value: 0x59, mask: 0xff
[   79.606914] ov2680 i2c-OVTI2680:00: I2C write, addr: 0x5e, reg: 0x49, value: 0x2f, mask: 0xff
[   79.611351] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
[   79.617114] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.617128] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.617539] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.617909] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.618020] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.625849] ------------[ cut here ]------------
[   79.625858] virt_to_cache: Object is not a Slab page!
[   79.625894] WARNING: CPU: 0 PID: 1396 at mm/slab.h:475 cache_from_obj+0xab/0xf0
[   79.625897] Modules linked in: atomisp_ov2680(CE+) atomisp(CE) videobuf_vmalloc(E) videobuf_core(E) videodev(E) mc(E) ccm(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) libcrc32c(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ip_set(E) nf_tables(E) nfnetlink(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) cmac(E) bnep(E) sunrpc(E) vfat(E) fat(E) snd_soc_sst_cht_bsw_rt5645(E) mei_hdcp(E) gpio_keys(E) intel_rapl_msr(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) intel_cstate(E) asus_nb_wmi(E) wdat_wdt(E) pcspkr(E) ath10k_pci(E) ath10k_core(E) intel_chtdc_ti_pwrbtn(E) ath(E) mac80211(E) btusb(E) btrtl(E) joydev(E) btbcm(E) btintel(E)
[   79.625960]  bluetooth(E) ecdh_generic(E) libarc4(E) ecc(E) cfg80211(E) hid_sensor_accel_3d(E) hid_sensor_gyro_3d(E) hid_sensor_trigger(E) hid_sensor_iio_common(E) industrialio_triggered_buffer(E) kfifo_buf(E) industrialio(E) snd_soc_rt5645(E) snd_soc_rl6231(E) snd_intel_sst_acpi(E) snd_intel_sst_core(E) intel_hid(E) snd_soc_sst_atom_hifi2_platform(E) snd_soc_acpi_intel_match(E) snd_soc_acpi(E) spi_pxa2xx_platform(E) snd_soc_core(E) snd_compress(E) dw_dmac(E) int3406_thermal(E) int3403_thermal(E) snd_hdmi_lpe_audio(E) int3400_thermal(E) acpi_thermal_rel(E) snd_seq(E) intel_int0002_vgpio(E) soc_button_array(E) acpi_pad(E) snd_seq_device(E) intel_xhci_usb_role_switch(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) mei_txe(E) lpc_ich(E) mei(E) processor_thermal_device(E) intel_soc_dts_iosf(E) intel_rapl_common(E) int340x_thermal_zone(E) ip_tables(E) hid_sensor_hub(E) intel_ishtp_loader(E) intel_ishtp_hid(E) mmc_block(E) hid_multitouch(E) crc32c_intel(E) i915(E) i2c_algo_bit(E) hid_asus(E)
[   79.626014]  drm_kms_helper(E) asus_wmi(E) sparse_keymap(E) rfkill(E) intel_ish_ipc(E) intel_ishtp(E) drm(E) wmi(E) video(E) i2c_hid(E) pwm_lpss_platform(E) pwm_lpss(E) sdhci_acpi(E) sdhci(E) mmc_core(E) fuse(E)
[   79.626038] CPU: 0 PID: 1396 Comm: v4l_id Tainted: G         C  E     5.7.0-rc2+ #40
[   79.626041] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019
[   79.626047] RIP: 0010:cache_from_obj+0xab/0xf0
[   79.626053] Code: c3 31 c0 80 3d 1c 38 72 01 00 75 f0 48 c7 c6 20 12 06 b4 48 c7 c7 10 f3 37 b4 48 89 04 24 c6 05 01 38 72 01 01 e8 2c 99 e0 ff <0f> 0b 48 8b 04 24 eb ca 48 8b 57 58 48 8b 48 58 48 c7 c6 30 12 06
[   79.626056] RSP: 0018:ffffac0540febb10 EFLAGS: 00010282
[   79.626060] RAX: 0000000000000029 RBX: 0000000000000048 RCX: 0000000000000007
[   79.626063] RDX: 00000000fffffff8 RSI: 0000000000000082 RDI: ffff99ad7bc19cc0
[   79.626065] RBP: 0000000000c49000 R08: 00000000000003d8 R09: ffffac0540feb9a0
[   79.626068] R10: 0000000000000005 R11: 0000000000000000 R12: ffffffffc133ca80
[   79.626071] R13: ffff99ac6e040000 R14: 0000000000c49000 R15: ffff99ac6e040000
[   79.626075] FS:  00007f542c0f0b80(0000) GS:ffff99ad7bc00000(0000) knlGS:0000000000000000
[   79.626078] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   79.626080] CR2: 0000563de87ab268 CR3: 00000001455f6000 CR4: 00000000001006f0
[   79.626083] Call Trace:
[   79.626097]  kmem_cache_free+0x19/0x180
[   79.626167]  mmu_l2_unmap+0xd1/0x100 [atomisp]
[   79.626213]  mmu_unmap+0xd0/0xf0 [atomisp]
[   79.626257]  hmm_bo_unbind+0x62/0xb0 [atomisp]
[   79.626304]  hmm_free+0x44/0x60 [atomisp]
[   79.626345]  ia_css_spctrl_unload_fw+0x30/0x50 [atomisp]
[   79.626387]  ia_css_uninit+0x3a/0x90 [atomisp]
[   79.626428]  atomisp_open+0x501/0x5c0 [atomisp]
[   79.626458]  v4l2_open+0x85/0xf0 [videodev]
[   79.626468]  chrdev_open+0xdd/0x210
[   79.626473]  ? cdev_device_add+0xc0/0xc0
[   79.626479]  do_dentry_open+0x13a/0x380
[   79.626484]  path_openat+0xa9a/0xfe0
[   79.626491]  do_filp_open+0x75/0x100
[   79.626496]  ? __check_object_size+0x12e/0x13c
[   79.626501]  ? __alloc_fd+0x44/0x150
[   79.626506]  do_sys_openat2+0x8a/0x130
[   79.626512]  __x64_sys_openat+0x46/0x70
[   79.626519]  do_syscall_64+0x5b/0xf0
[   79.626528]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   79.626533] RIP: 0033:0x7f542d23229b
[   79.626539] Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 2b 0c 25
[   79.626542] RSP: 002b:00007fff3f8f7ca0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
[   79.626547] RAX: ffffffffffffffda RBX: 00007fff3f8f7e98 RCX: 00007f542d23229b
[   79.626549] RDX: 0000000000000000 RSI: 00007fff3f8f8f2f RDI: 00000000ffffff9c
[   79.626552] RBP: 00007fff3f8f8f2f R08: 0000000000000000 R09: 0000000000000000
[   79.626555] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[   79.626557] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[   79.626562] ---[ end trace 29196eb433c515e0 ]---
[   79.631279] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.634585] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.634598] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.634947] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.635314] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.635487] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.636878] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.646387] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIDEO output
[   79.678237] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP PREVIEW output
[   79.680037] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.680051] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.681501] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.681871] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.681983] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.683462] ov2680 i2c-OVTI2680:00: camera pdata: port: 1 lanes: 1 order: 00000002
[   79.684028] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680, rev= 0
[   79.684060] ov2680 i2c-OVTI2680:00: I2C write, addr: 0x5e, reg: 0x4a, value: 0x58, mask: 0xff
[   79.687202] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.687620] ov2680 i2c-OVTI2680:00: I2C write, addr: 0x5e, reg: 0x49, value: 0x2e, mask: 0xff
[   79.692369] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
[   79.740187] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIEWFINDER output
[   79.742596] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.743030] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.743430] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.743799] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.743909] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.745403] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.749602] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.749617] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.749964] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.750332] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.750484] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.753638] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.776839] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIDEO output
[   79.779316] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP MEMORY input
[   79.780289] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.780302] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.780678] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.781046] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.781155] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.782329] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.790926] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.790946] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.791294] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.791702] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.791814] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.794120] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.807736] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP ACC
[   79.811965] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.811979] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.812327] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.812746] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.812858] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.813675] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP ACC
[   79.815783] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.819828] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.819842] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.820190] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.820617] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.820729] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.821054] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP PREVIEW output
[   79.821828] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.826462] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP VIEWFINDER output
[   79.827449] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.827462] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.827812] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.828188] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.828299] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.830094] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[   79.842812] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[   79.842830] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[   79.843724] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[   79.845134] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[   79.845760] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[   79.847366] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
[  146.677485] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
[  146.687599] sh_css_hrt_system_is_idle() 44: warning: SP not idle
[  146.687611] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
[  146.687991] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
[  146.688359] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
[  146.688478] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
[  146.689792] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff

From the above, it sounds that both the ISP and the sensors got power,
although there are still some things to be fixed there, at the "pre_power"
part.

The memory alloc code has bugs, and it may have issues due to the
incompatibility between the firmware I used and the one used to
generate this driver's version.

Trying to open a video devnode returns error and produce those logs:

	[ 3262.961623] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
	[ 3262.971350] sh_css_hrt_system_is_idle() 44: warning: SP not idle
	[ 3262.971364] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
	[ 3262.971712] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
	[ 3262.972079] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
	[ 3262.972188] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
	[ 3262.974982] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Andy Shevchenko]

On Tue, May 12, 2020 at 5:56 PM Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
> Em Tue, 12 May 2020 14:21:49 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > On Tue, May 12, 2020 at 2:12 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
> > > <mchehab@kernel.org> wrote:
> > > > Em Sat, 2 May 2020 20:33:14 +0300
> > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > > > > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > > > > Em Sat, 2 May 2020 19:08:36 +0300
> > > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> >
> > ...
> >
> > > Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
> > > is incorrect approach. Look closer what PCI does in case when
> > > pcim_enable_device() has been called.
> >
> > This has resource leaks
> > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=88b03de5d705f5f46a896dbd21ef9472030bb8d3
> >
> > Easier just to acpi_handle_info(ACPI_HANDLE(...), ...);
> >
> > We don't enumerate them w/o ACPI IIRC.
>
> Well, at least while in staging, it would be good to know more details
> about the probing issues on different hardware that people might be
> testing it.
>
> avoiding to use a get_device() here is not possible, because the
> prints will use the adev to return some info we may need:
>
>         ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680

Why do you need get_device()? Are you expecting device may have gone?
acpi_handle_*() / dev_*() are not enough?

> This, together with the DMI product ID on this message:
>
>         atomisp-isp2 0000:00:03.0: Detected Cherrytrail version 54 (ISP2401) on T101HA
>
> may help to avoid users to run acpixtract/iasl/dmidecode when adding
> new entries to the dmi match tables. Not 100%, since BIOSes may
> still use different names for the sensor data.

> Trying to open a video devnode returns error and produce those logs:
>
>         [ 3262.961623] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
>         [ 3262.971350] sh_css_hrt_system_is_idle() 44: warning: SP not idle
>         [ 3262.971364] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
>         [ 3262.971712] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
>         [ 3262.972079] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
>         [ 3262.972188] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
>         [ 3262.974982] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff

In my case when I tried with 2015-04 / 2015-05 firmware for ISP2400 I
got to no crashes, but no IRQs, presumably due to absence of PMIC
integration.

-- 
With Best Regards,
Andy Shevchenko

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Tue, 12 May 2020 19:01:22 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, May 12, 2020 at 5:56 PM Mauro Carvalho Chehab
> <mchehab@kernel.org> wrote:
> > Em Tue, 12 May 2020 14:21:49 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > > On Tue, May 12, 2020 at 2:12 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
> > > > <mchehab@kernel.org> wrote:
> > > > > Em Sat, 2 May 2020 20:33:14 +0300
> > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > > > > > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> > > > > > > Em Sat, 2 May 2020 19:08:36 +0300
> > > > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:
> > >
> > > ...
> > >
> > > > Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
> > > > is incorrect approach. Look closer what PCI does in case when
> > > > pcim_enable_device() has been called.
> > >
> > > This has resource leaks
> > > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=88b03de5d705f5f46a896dbd21ef9472030bb8d3
> > >
> > > Easier just to acpi_handle_info(ACPI_HANDLE(...), ...);
> > >
> > > We don't enumerate them w/o ACPI IIRC.
> >
> > Well, at least while in staging, it would be good to know more details
> > about the probing issues on different hardware that people might be
> > testing it.
> >
> > avoiding to use a get_device() here is not possible, because the
> > prints will use the adev to return some info we may need:
> >
> >         ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680
> 
> Why do you need get_device()? Are you expecting device may have gone?
> acpi_handle_*() / dev_*() are not enough?
> 
> > This, together with the DMI product ID on this message:
> >
> >         atomisp-isp2 0000:00:03.0: Detected Cherrytrail version 54 (ISP2401) on T101HA
> >
> > may help to avoid users to run acpixtract/iasl/dmidecode when adding
> > new entries to the dmi match tables. Not 100%, since BIOSes may
> > still use different names for the sensor data.
> 
> > Trying to open a video devnode returns error and produce those logs:
> >
> >         [ 3262.961623] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
> >         [ 3262.971350] sh_css_hrt_system_is_idle() 44: warning: SP not idle
> >         [ 3262.971364] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
> >         [ 3262.971712] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
> >         [ 3262.972079] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
> >         [ 3262.972188] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
> >         [ 3262.974982] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff
> 
> In my case when I tried with 2015-04 / 2015-05 firmware for ISP2400 I
> got to no crashes, but no IRQs, presumably due to absence of PMIC
> integration.
> 

Do you have the 2015-04 / 2015-05 firmware still available? I would
like to try them as well. 

-- 
with kind regards,
Patrik

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Tue, 12 May 2020 19:01:22 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> On Tue, May 12, 2020 at 5:56 PM Mauro Carvalho Chehab
> <mchehab@kernel.org> wrote:
> > Em Tue, 12 May 2020 14:21:49 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:  
> > > On Tue, May 12, 2020 at 2:12 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:  
> > > > On Tue, May 12, 2020 at 1:21 PM Mauro Carvalho Chehab
> > > > <mchehab@kernel.org> wrote:  
> > > > > Em Sat, 2 May 2020 20:33:14 +0300
> > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:  
> > > > > > On Sat, May 2, 2020 at 8:04 PM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:  
> > > > > > > Em Sat, 2 May 2020 19:08:36 +0300
> > > > > > > Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:  
> > >
> > > ...
> > >  
> > > > Btw, https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=65608aa8d34ea274600ab2cf6f0cf54ee86d8fd1
> > > > is incorrect approach. Look closer what PCI does in case when
> > > > pcim_enable_device() has been called.  
> > >
> > > This has resource leaks
> > > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=88b03de5d705f5f46a896dbd21ef9472030bb8d3
> > >
> > > Easier just to acpi_handle_info(ACPI_HANDLE(...), ...);
> > >
> > > We don't enumerate them w/o ACPI IIRC.  
> >
> > Well, at least while in staging, it would be good to know more details
> > about the probing issues on different hardware that people might be
> > testing it.
> >
> > avoiding to use a get_device() here is not possible, because the
> > prints will use the adev to return some info we may need:
> >
> >         ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680  
> 
> Why do you need get_device()? Are you expecting device may have gone?
> acpi_handle_*() / dev_*() are not enough?

Sorry for not answering this earlier. Got sidetracked by other things.

That's my miss-understanding: when I saw the name acpi_bus_get_device()
and looked at the code, where there is a function called
acpi_bus_put_acpi_device() that it is just a wrapper for 
put_device(&adev->dev), I just assumed that this function would be
internally calling get_device.

So, calling "put_device(&adev->dev)" or calling acpi_dev_put() would
get rid of any memory leaks.

After checking it better, that doesn't seem the case.

Anyway, for now, I'll just keep a call for acpi_bus_get_device() there,
as this is really helpful for debugging purposes. I'll add a notice
about potential memory leaks there, for us to address if/when porting
them to be generic I2C drivers.

If you have some suggestions about how to avoid memory leaks when
using it, feel free to suggest (or send us a patch).

There's zero chance of those sensor drivers to leave staging as-is.

A *major* re-work would be needed - and some drivers will just be
replaced by the upstream ones (like ov2680).

They have several stuff there with are specific to atomisp, including
the entire ACPI binding. We'll need to work on a different way to
do that outside staging.

> > This, together with the DMI product ID on this message:
> >
> >         atomisp-isp2 0000:00:03.0: Detected Cherrytrail version 54 (ISP2401) on T101HA
> >
> > may help to avoid users to run acpixtract/iasl/dmidecode when adding
> > new entries to the dmi match tables. Not 100%, since BIOSes may
> > still use different names for the sensor data.  
> 
> > Trying to open a video devnode returns error and produce those logs:
> >
> >         [ 3262.961623] atomisp-isp2 0000:00:03.0: open device ATOMISP ISP CAPTURE output
> >         [ 3262.971350] sh_css_hrt_system_is_idle() 44: warning: SP not idle
> >         [ 3262.971364] sh_css_hrt_system_is_idle() 49: warning: ISP not idle
> >         [ 3262.971712] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 12 is not empty
> >         [ 3262.972079] sh_css_hrt_system_is_idle() 56: warning: FIFO channel 26 is not empty
> >         [ 3262.972188] atomisp-isp2 0000:00:03.0: css init failed --- bad firmware?
> >         [ 3262.974982] atomisp-isp2 0000:00:03.0: atomisp_mrfld_pre_power_down: error in iunit interrupt. status reg=0xffffffff  
> 
> In my case when I tried with 2015-04 / 2015-05 firmware for ISP2400 I
> got to no crashes, but no IRQs, presumably due to absence of PMIC
> integration.

Yeah, maybe. With the current version, I'm getting IRQs telling
that the frames are ready:

	[ 3635.285469] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.285494] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 97, asd 0
	[ 3635.285600] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.285625] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 98, asd 0
	[ 3635.285734] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.285750] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 99, asd 0
	[ 3635.285861] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.285879] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 100, asd 0
	[ 3635.285990] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.286005] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 101, asd 0
	[ 3635.286120] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.286135] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 102, asd 0
	[ 3635.286251] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.286265] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 103, asd 0
	[ 3635.286384] atomisp-isp2 0000:00:03.0: irq:0x200000
	[ 3635.286401] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 104, asd 0

What is funny is that those events are producing v4l2 events, instead of
being written to the dqbuf directly.

I suspect that the userspace code should do something with such
events, before the driver release the buffers to userspace via DQBUF.

Btw, if you still have your isp2400 hardware, it would be worth if you
could check if the current driver produces some result there.

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Tue, 12 May 2020 16:56:44 +0200
Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:

> [   79.625858] virt_to_cache: Object is not a Slab page!

Solved this issue:

	https://git.linuxtv.org/mchehab/experimental.git/commit/?h=atomisp_v2.1&id=c916263a340ef1c4cc187ad6267302bdd4298514

Yet, I'm not happy with the code inside the hmm/ dir, nor the code at
isp_mmu.c. There are too many dirty memory-management magic there, including
some forks from upstream /mm code inside it. 

Changing it may not be an easy task, as it currently uses three different
VMA areas (dynamic, reserved, and "normal"). Touching it without knowing more 
about the atomisp or being able to test the driver seems risky. 

Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

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 

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sun, 3 May 2020 10:46:12 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> 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.

Wow, that sounds promising! Did you find where the Kernel patches
and userspace applications are stored?

> > 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 
> 



Thanks,
Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Sun, 3 May 2020 12:23:50 +0200
Mauro Carvalho Chehab <mchehab@kernel.org> wrote:

> Em Sun, 3 May 2020 10:46:12 +0200
> Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> 
> > On Sat, 2 May 2020 19:08:36 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > 
> > Hi Andy,
> >   
>  [...]  
>  [...]  
>  [...]  
> > 
> > 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.  
> 
> Wow, that sounds promising! Did you find where the Kernel patches
> and userspace applications are stored?

 
I've downloaded the Fedora 18 .iso file, unfortunately the USB stick
created is not able to boot. According to wikipedia the kernel used in
Fedora 18 is 3.6.10. I've downloaded the source an scanned it for
"atomisp" and "ov2680" - but did not find anything. After some more
research I've found a forum post about a patched kernel from timesys:

  "... I have got a copy of atomisp driver from Timesys, which named
  kernel-3.8.0-1.src.rpm. The driver be written by intel. But the
  driver can not be correctly work on my platfrom(E3827). So i come to
  be suspicious of the compatibility. And i want to know whether the
  driver can be suitable for my platfrom?

  Drivers infomation as blow:
  - The version of atomisp driver: BYT_LSP_3.8_ISP_2013-12-06.patch
  - The version of atomisp firmware: iaisp_2400_css.bin ..."

It looks as if this src.rpm is available here:
http://repository.timesys.com/buildsources/fedora/18/x86_64/source/ 

I'll now figure out how to open the .rpm package to have a look if
there is something about atomisp.

> 
>  [...]  
> > 
> > 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.
> >   
>  [...]  
> > 
> > with kind regards,
> > Patrik 
> >   
> 
> 
> 
> Thanks,
> Mauro

Re: atomisp kernel driver(s)

[Patrik Gfeller]

On Sun, 3 May 2020 14:31:20 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> wrote:

> On Sun, 3 May 2020 12:23:50 +0200
> Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> 
> > Em Sun, 3 May 2020 10:46:12 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >   
>  [...]     
>  [...]  
> > 
> > Wow, that sounds promising! Did you find where the Kernel patches
> > and userspace applications are stored?  
> 
>  
> I've downloaded the Fedora 18 .iso file, unfortunately the USB stick
> created is not able to boot. According to wikipedia the kernel used in
> Fedora 18 is 3.6.10. I've downloaded the source an scanned it for
> "atomisp" and "ov2680" - but did not find anything. After some more
> research I've found a forum post about a patched kernel from timesys:
> 
>   "... I have got a copy of atomisp driver from Timesys, which named
>   kernel-3.8.0-1.src.rpm. The driver be written by intel. But the
>   driver can not be correctly work on my platfrom(E3827). So i come to
>   be suspicious of the compatibility. And i want to know whether the
>   driver can be suitable for my platfrom?
> 
>   Drivers infomation as blow:
>   - The version of atomisp driver: BYT_LSP_3.8_ISP_2013-12-06.patch
>   - The version of atomisp firmware: iaisp_2400_css.bin ..."
> 
> It looks as if this src.rpm is available here:
> http://repository.timesys.com/buildsources/fedora/18/x86_64/source/ 
> 
> I'll now figure out how to open the .rpm package to have a look if
> there is something about atomisp.
> 

The patches have different names (ISP_) than mentioned in the intel
forum post, but there are a lot of changes. When I searched
ISP_3_01.DRIVER.patch for "+++ b/drivers/media/atomisp2/" 
I have 536 hits. I did not find references to ov2680 tough.

But I hope it is something useful.

> > 
> > Thanks,
> > Mauro  
> 

Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab]

Em Sun, 3 May 2020 14:31:20 +0200
Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:

> On Sun, 3 May 2020 12:23:50 +0200
> Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
> 
> > Em Sun, 3 May 2020 10:46:12 +0200
> > Patrik Gfeller <patrik.gfeller@gmail.com> escreveu:
> >   
> > > On Sat, 2 May 2020 19:08:36 +0300
> > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > 
> > > Hi Andy,
> > >     
> >  [...]  
> >  [...]  
> >  [...]    
> > > 
> > > 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.    
> > 
> > Wow, that sounds promising! Did you find where the Kernel patches
> > and userspace applications are stored?  
> 
>  
> I've downloaded the Fedora 18 .iso file, unfortunately the USB stick
> created is not able to boot. According to wikipedia the kernel used in
> Fedora 18 is 3.6.10. I've downloaded the source an scanned it for
> "atomisp" and "ov2680" - but did not find anything. After some more
> research I've found a forum post about a patched kernel from timesys:
> 
>   "... I have got a copy of atomisp driver from Timesys, which named
>   kernel-3.8.0-1.src.rpm. The driver be written by intel. But the
>   driver can not be correctly work on my platfrom(E3827). So i come to
>   be suspicious of the compatibility. And i want to know whether the
>   driver can be suitable for my platfrom?
> 
>   Drivers infomation as blow:
>   - The version of atomisp driver: BYT_LSP_3.8_ISP_2013-12-06.patch
>   - The version of atomisp firmware: iaisp_2400_css.bin ..."
> 
> It looks as if this src.rpm is available here:
> http://repository.timesys.com/buildsources/fedora/18/x86_64/source/ 
> 
> I'll now figure out how to open the .rpm package to have a look if
> there is something about atomisp.

A .rpm package can be opened either with "rpm" or with "alien". 
Yet, this is how binary packages are distributed, although I saw a few
rpm files that would be building something dynamically when installed.

Something like:

	$ alien emgd-ddx-2.0-3685.i686.rpm -t 
	Warning: alien is not running as root!
	Warning: Ownerships of files in the generated packages will probably be wrong.
	emgd-ddx-2.0.tgz generated
	$ tar xvf ../emgd-ddx-2.0.tgz 
	./
	./usr/
	./usr/lib/
	./usr/lib/xorg/
	./usr/lib/xorg/modules/
	./usr/lib/xorg/modules/drivers/
	./usr/lib/xorg/modules/drivers/emgd_drv.so

Thanks,
Mauro