* atomisp kernel driver(s) @ 2020-04-18 14:39 Patrik Gfeller 2020-04-18 15:25 ` Mauro Carvalho Chehab ` (2 more replies) 0 siblings, 3 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-18 14:39 UTC (permalink / raw) To: linux-media, mchehab 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> ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 14:39 atomisp kernel driver(s) Patrik Gfeller @ 2020-04-18 15:25 ` Mauro Carvalho Chehab 2020-04-18 15:26 ` Mauro Carvalho Chehab 2020-04-18 15:29 ` atomisp kernel driver(s) Patrik Gfeller 2020-04-25 2:39 ` Laurent Pinchart 2020-05-02 16:08 ` Andy Shevchenko 2 siblings, 2 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-18 15:25 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 15:25 ` Mauro Carvalho Chehab @ 2020-04-18 15:26 ` Mauro Carvalho Chehab 2020-04-18 15:37 ` Patrik Gfeller 2020-04-18 15:29 ` atomisp kernel driver(s) Patrik Gfeller 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-18 15:26 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 15:26 ` Mauro Carvalho Chehab @ 2020-04-18 15:37 ` Patrik Gfeller 2020-04-19 23:31 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-18 15:37 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 15:37 ` Patrik Gfeller @ 2020-04-19 23:31 ` Mauro Carvalho Chehab 2020-04-20 17:48 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-19 23:31 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-19 23:31 ` Mauro Carvalho Chehab @ 2020-04-20 17:48 ` Patrik Gfeller 2020-04-20 18:27 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-20 17:48 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-20 17:48 ` Patrik Gfeller @ 2020-04-20 18:27 ` Patrik Gfeller 2020-04-20 20:47 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-20 18:27 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 > ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-20 18:27 ` Patrik Gfeller @ 2020-04-20 20:47 ` Mauro Carvalho Chehab 2020-04-22 17:56 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-20 20:47 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-20 20:47 ` Mauro Carvalho Chehab @ 2020-04-22 17:56 ` Patrik Gfeller 2020-04-22 19:13 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-22 17:56 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-22 17:56 ` Patrik Gfeller @ 2020-04-22 19:13 ` Mauro Carvalho Chehab 2020-04-24 8:52 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-22 19:13 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-22 19:13 ` Mauro Carvalho Chehab @ 2020-04-24 8:52 ` Patrik Gfeller 2020-04-24 9:10 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-24 8:52 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-24 8:52 ` Patrik Gfeller @ 2020-04-24 9:10 ` Patrik Gfeller 2020-04-24 10:07 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-24 9:10 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 > ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-24 9:10 ` Patrik Gfeller @ 2020-04-24 10:07 ` Patrik Gfeller 2020-04-24 13:58 ` Patrik Gfeller 2020-04-25 11:22 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-24 10:07 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 >> ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-24 10:07 ` Patrik Gfeller @ 2020-04-24 13:58 ` Patrik Gfeller 2020-04-25 11:22 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-24 13:58 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media [-- 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 --] ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-24 10:07 ` Patrik Gfeller 2020-04-24 13:58 ` Patrik Gfeller @ 2020-04-25 11:22 ` Mauro Carvalho Chehab 2020-04-26 11:38 ` Patrik Gfeller 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-25 11:22 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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) } } ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 11:22 ` Mauro Carvalho Chehab @ 2020-04-26 11:38 ` Patrik Gfeller 2020-04-26 16:50 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-26 11:38 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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) > } > } > > > > > ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 11:38 ` Patrik Gfeller @ 2020-04-26 16:50 ` Mauro Carvalho Chehab 2020-04-27 18:31 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-26 16:50 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 16:50 ` Mauro Carvalho Chehab @ 2020-04-27 18:31 ` Patrik Gfeller 2020-04-27 21:50 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-27 18:31 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-27 18:31 ` Patrik Gfeller @ 2020-04-27 21:50 ` Mauro Carvalho Chehab 2020-04-28 17:59 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-27 21:50 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-27 21:50 ` Mauro Carvalho Chehab @ 2020-04-28 17:59 ` Patrik Gfeller 2020-04-28 23:13 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-28 17:59 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media [-- 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, + }, {} }; ^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-28 17:59 ` Patrik Gfeller @ 2020-04-28 23:13 ` Mauro Carvalho Chehab 2020-04-29 17:56 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-28 23:13 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-28 23:13 ` Mauro Carvalho Chehab @ 2020-04-29 17:56 ` Patrik Gfeller 2020-04-29 18:17 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-29 17:56 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-29 17:56 ` Patrik Gfeller @ 2020-04-29 18:17 ` Mauro Carvalho Chehab 2020-04-30 7:56 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-29 18:17 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-29 18:17 ` Mauro Carvalho Chehab @ 2020-04-30 7:56 ` Patrik Gfeller 2020-04-30 10:55 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-30 7:56 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-30 7:56 ` Patrik Gfeller @ 2020-04-30 10:55 ` Mauro Carvalho Chehab 2020-04-30 15:09 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-30 10:55 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-30 10:55 ` Mauro Carvalho Chehab @ 2020-04-30 15:09 ` Patrik Gfeller 2020-04-30 22:25 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-30 15:09 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media [-- 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 --] ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-30 15:09 ` Patrik Gfeller @ 2020-04-30 22:25 ` Mauro Carvalho Chehab 2020-05-01 8:54 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-30 22:25 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-30 22:25 ` Mauro Carvalho Chehab @ 2020-05-01 8:54 ` Patrik Gfeller 2020-05-01 9:38 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-05-01 8:54 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-01 8:54 ` Patrik Gfeller @ 2020-05-01 9:38 ` Mauro Carvalho Chehab 2020-05-01 17:31 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-01 9:38 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-01 9:38 ` Mauro Carvalho Chehab @ 2020-05-01 17:31 ` Patrik Gfeller 2020-05-01 19:30 ` Mauro Carvalho Chehab 2020-05-01 20:56 ` [PATCH] media: atomisp: use add_qos_request instead of update Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-01 17:31 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media [-- 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 --] ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-01 17:31 ` Patrik Gfeller @ 2020-05-01 19:30 ` Mauro Carvalho Chehab 2020-05-02 8:15 ` Patrik Gfeller 2020-05-01 20:56 ` [PATCH] media: atomisp: use add_qos_request instead of update Mauro Carvalho Chehab 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-01 19:30 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-01 19:30 ` Mauro Carvalho Chehab @ 2020-05-02 8:15 ` Patrik Gfeller 2020-05-02 9:20 ` Patrik Gfeller 2020-05-02 9:34 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-02 8:15 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 8:15 ` Patrik Gfeller @ 2020-05-02 9:20 ` Patrik Gfeller 2020-05-02 10:00 ` Mauro Carvalho Chehab 2020-05-02 9:34 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-05-02 9:20 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 9:20 ` Patrik Gfeller @ 2020-05-02 10:00 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-02 10:00 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 8:15 ` Patrik Gfeller 2020-05-02 9:20 ` Patrik Gfeller @ 2020-05-02 9:34 ` Mauro Carvalho Chehab 2020-05-02 14:29 ` Patrik Gfeller 2020-05-02 14:50 ` Patrik Gfeller 1 sibling, 2 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-02 9:34 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 9:34 ` Mauro Carvalho Chehab @ 2020-05-02 14:29 ` Patrik Gfeller 2020-05-02 16:28 ` Mauro Carvalho Chehab 2020-05-02 14:50 ` Patrik Gfeller 1 sibling, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-05-02 14:29 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 14:29 ` Patrik Gfeller @ 2020-05-02 16:28 ` Mauro Carvalho Chehab 2020-05-02 18:23 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-02 16:28 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 16:28 ` Mauro Carvalho Chehab @ 2020-05-02 18:23 ` Patrik Gfeller 0 siblings, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-02 18:23 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 9:34 ` Mauro Carvalho Chehab 2020-05-02 14:29 ` Patrik Gfeller @ 2020-05-02 14:50 ` Patrik Gfeller 1 sibling, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-02 14:50 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] media: atomisp: use add_qos_request instead of update 2020-05-01 17:31 ` Patrik Gfeller 2020-05-01 19:30 ` Mauro Carvalho Chehab @ 2020-05-01 20:56 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-01 20:56 UTC (permalink / raw) Cc: devel, Mauro Carvalho Chehab, Greg Kroah-Hartman, Sakari Ailus, Patrik Gfeller, Alan Cox 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 ^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 15:25 ` Mauro Carvalho Chehab 2020-04-18 15:26 ` Mauro Carvalho Chehab @ 2020-04-18 15:29 ` Patrik Gfeller 1 sibling, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-18 15:29 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 14:39 atomisp kernel driver(s) Patrik Gfeller 2020-04-18 15:25 ` Mauro Carvalho Chehab @ 2020-04-25 2:39 ` Laurent Pinchart 2020-04-25 10:36 ` Patrik Gfeller 2020-04-26 7:44 ` Patrik Gfeller 2020-05-02 16:08 ` Andy Shevchenko 2 siblings, 2 replies; 70+ messages in thread From: Laurent Pinchart @ 2020-04-25 2:39 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media, mchehab, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 2:39 ` Laurent Pinchart @ 2020-04-25 10:36 ` Patrik Gfeller 2020-04-25 12:19 ` Mauro Carvalho Chehab 2020-04-26 19:33 ` Laurent Pinchart 2020-04-26 7:44 ` Patrik Gfeller 1 sibling, 2 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-25 10:36 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, mchehab, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 10:36 ` Patrik Gfeller @ 2020-04-25 12:19 ` Mauro Carvalho Chehab 2020-04-26 19:07 ` Laurent Pinchart 2020-04-26 19:33 ` Laurent Pinchart 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-25 12:19 UTC (permalink / raw) To: Patrik Gfeller; +Cc: Laurent Pinchart, linux-media, Sakari Ailus 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, + }, {} }; ^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 12:19 ` Mauro Carvalho Chehab @ 2020-04-26 19:07 ` Laurent Pinchart 2020-04-26 20:51 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Laurent Pinchart @ 2020-04-26 19:07 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Patrik Gfeller, linux-media, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 19:07 ` Laurent Pinchart @ 2020-04-26 20:51 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-04-26 20:51 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Patrik Gfeller, linux-media, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 10:36 ` Patrik Gfeller 2020-04-25 12:19 ` Mauro Carvalho Chehab @ 2020-04-26 19:33 ` Laurent Pinchart 2020-04-28 18:13 ` Patrik Gfeller 1 sibling, 1 reply; 70+ messages in thread From: Laurent Pinchart @ 2020-04-26 19:33 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media, mchehab, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 19:33 ` Laurent Pinchart @ 2020-04-28 18:13 ` Patrik Gfeller 0 siblings, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-28 18:13 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, mchehab, Sakari Ailus 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 :-) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-25 2:39 ` Laurent Pinchart 2020-04-25 10:36 ` Patrik Gfeller @ 2020-04-26 7:44 ` Patrik Gfeller 2020-04-26 19:17 ` Laurent Pinchart 1 sibling, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-26 7:44 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, mchehab, Sakari Ailus 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 :-) > ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 7:44 ` Patrik Gfeller @ 2020-04-26 19:17 ` Laurent Pinchart 2020-04-29 17:59 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Laurent Pinchart @ 2020-04-26 19:17 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media, mchehab, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-26 19:17 ` Laurent Pinchart @ 2020-04-29 17:59 ` Patrik Gfeller 2020-04-29 18:19 ` Laurent Pinchart 0 siblings, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-04-29 17:59 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, mchehab, Sakari Ailus 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 :-) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-29 17:59 ` Patrik Gfeller @ 2020-04-29 18:19 ` Laurent Pinchart 2020-04-30 15:28 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Laurent Pinchart @ 2020-04-29 18:19 UTC (permalink / raw) To: Patrik Gfeller; +Cc: linux-media, mchehab, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-29 18:19 ` Laurent Pinchart @ 2020-04-30 15:28 ` Patrik Gfeller 0 siblings, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-04-30 15:28 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media, mchehab, Sakari Ailus 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 :-) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-04-18 14:39 atomisp kernel driver(s) Patrik Gfeller 2020-04-18 15:25 ` Mauro Carvalho Chehab 2020-04-25 2:39 ` Laurent Pinchart @ 2020-05-02 16:08 ` Andy Shevchenko 2020-05-02 17:04 ` Mauro Carvalho Chehab 2020-05-03 8:46 ` Patrik Gfeller 2 siblings, 2 replies; 70+ messages in thread From: Andy Shevchenko @ 2020-05-02 16:08 UTC (permalink / raw) To: Patrik Gfeller; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 16:08 ` Andy Shevchenko @ 2020-05-02 17:04 ` Mauro Carvalho Chehab 2020-05-02 17:33 ` Andy Shevchenko 2020-05-03 8:46 ` Patrik Gfeller 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-02 17:04 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 17:04 ` Mauro Carvalho Chehab @ 2020-05-02 17:33 ` Andy Shevchenko 2020-05-03 10:18 ` Mauro Carvalho Chehab 2020-05-12 10:20 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Andy Shevchenko @ 2020-05-02 17:33 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 17:33 ` Andy Shevchenko @ 2020-05-03 10:18 ` Mauro Carvalho Chehab 2020-05-12 10:20 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-03 10:18 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 17:33 ` Andy Shevchenko 2020-05-03 10:18 ` Mauro Carvalho Chehab @ 2020-05-12 10:20 ` Mauro Carvalho Chehab 2020-05-12 11:12 ` Andy Shevchenko 1 sibling, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-12 10:20 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 10:20 ` Mauro Carvalho Chehab @ 2020-05-12 11:12 ` Andy Shevchenko 2020-05-12 11:21 ` Andy Shevchenko 0 siblings, 1 reply; 70+ messages in thread From: Andy Shevchenko @ 2020-05-12 11:12 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 11:12 ` Andy Shevchenko @ 2020-05-12 11:21 ` Andy Shevchenko 2020-05-12 14:56 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 70+ messages in thread From: Andy Shevchenko @ 2020-05-12 11:21 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 11:21 ` Andy Shevchenko @ 2020-05-12 14:56 ` Mauro Carvalho Chehab 2020-05-12 16:01 ` Andy Shevchenko 2020-05-13 9:56 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-12 14:56 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 14:56 ` Mauro Carvalho Chehab @ 2020-05-12 16:01 ` Andy Shevchenko 2020-05-13 18:36 ` Patrik Gfeller 2020-05-20 8:04 ` Mauro Carvalho Chehab 2020-05-13 9:56 ` Mauro Carvalho Chehab 1 sibling, 2 replies; 70+ messages in thread From: Andy Shevchenko @ 2020-05-12 16:01 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 16:01 ` Andy Shevchenko @ 2020-05-13 18:36 ` Patrik Gfeller 2020-05-20 8:04 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-13 18:36 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 16:01 ` Andy Shevchenko 2020-05-13 18:36 ` Patrik Gfeller @ 2020-05-20 8:04 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-20 8:04 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Patrik Gfeller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-12 14:56 ` Mauro Carvalho Chehab 2020-05-12 16:01 ` Andy Shevchenko @ 2020-05-13 9:56 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-13 9:56 UTC (permalink / raw) To: Linux Media Mailing List; +Cc: Andy Shevchenko, Patrik Gfeller 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-02 16:08 ` Andy Shevchenko 2020-05-02 17:04 ` Mauro Carvalho Chehab @ 2020-05-03 8:46 ` Patrik Gfeller 2020-05-03 10:23 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 70+ messages in thread From: Patrik Gfeller @ 2020-05-03 8:46 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-03 8:46 ` Patrik Gfeller @ 2020-05-03 10:23 ` Mauro Carvalho Chehab 2020-05-03 12:31 ` Patrik Gfeller 0 siblings, 1 reply; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-03 10:23 UTC (permalink / raw) To: Patrik Gfeller; +Cc: Andy Shevchenko, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-03 10:23 ` Mauro Carvalho Chehab @ 2020-05-03 12:31 ` Patrik Gfeller 2020-05-03 13:36 ` Patrik Gfeller 2020-05-03 14:43 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-03 12:31 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Andy Shevchenko, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-03 12:31 ` Patrik Gfeller @ 2020-05-03 13:36 ` Patrik Gfeller 2020-05-03 14:43 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Patrik Gfeller @ 2020-05-03 13:36 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Andy Shevchenko, Linux Media Mailing List 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 > ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: atomisp kernel driver(s) 2020-05-03 12:31 ` Patrik Gfeller 2020-05-03 13:36 ` Patrik Gfeller @ 2020-05-03 14:43 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 70+ messages in thread From: Mauro Carvalho Chehab @ 2020-05-03 14:43 UTC (permalink / raw) To: Patrik Gfeller; +Cc: Andy Shevchenko, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2020-05-20 8:05 UTC | newest] Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-18 14:39 atomisp kernel driver(s) Patrik Gfeller 2020-04-18 15:25 ` Mauro Carvalho Chehab 2020-04-18 15:26 ` Mauro Carvalho Chehab 2020-04-18 15:37 ` Patrik Gfeller 2020-04-19 23:31 ` Mauro Carvalho Chehab 2020-04-20 17:48 ` Patrik Gfeller 2020-04-20 18:27 ` Patrik Gfeller 2020-04-20 20:47 ` Mauro Carvalho Chehab 2020-04-22 17:56 ` Patrik Gfeller 2020-04-22 19:13 ` Mauro Carvalho Chehab 2020-04-24 8:52 ` Patrik Gfeller 2020-04-24 9:10 ` Patrik Gfeller 2020-04-24 10:07 ` Patrik Gfeller 2020-04-24 13:58 ` Patrik Gfeller 2020-04-25 11:22 ` Mauro Carvalho Chehab 2020-04-26 11:38 ` Patrik Gfeller 2020-04-26 16:50 ` Mauro Carvalho Chehab 2020-04-27 18:31 ` Patrik Gfeller 2020-04-27 21:50 ` Mauro Carvalho Chehab 2020-04-28 17:59 ` Patrik Gfeller 2020-04-28 23:13 ` Mauro Carvalho Chehab 2020-04-29 17:56 ` Patrik Gfeller 2020-04-29 18:17 ` Mauro Carvalho Chehab 2020-04-30 7:56 ` Patrik Gfeller 2020-04-30 10:55 ` Mauro Carvalho Chehab 2020-04-30 15:09 ` Patrik Gfeller 2020-04-30 22:25 ` Mauro Carvalho Chehab 2020-05-01 8:54 ` Patrik Gfeller 2020-05-01 9:38 ` Mauro Carvalho Chehab 2020-05-01 17:31 ` Patrik Gfeller 2020-05-01 19:30 ` Mauro Carvalho Chehab 2020-05-02 8:15 ` Patrik Gfeller 2020-05-02 9:20 ` Patrik Gfeller 2020-05-02 10:00 ` Mauro Carvalho Chehab 2020-05-02 9:34 ` Mauro Carvalho Chehab 2020-05-02 14:29 ` Patrik Gfeller 2020-05-02 16:28 ` Mauro Carvalho Chehab 2020-05-02 18:23 ` Patrik Gfeller 2020-05-02 14:50 ` Patrik Gfeller 2020-05-01 20:56 ` [PATCH] media: atomisp: use add_qos_request instead of update Mauro Carvalho Chehab 2020-04-18 15:29 ` atomisp kernel driver(s) Patrik Gfeller 2020-04-25 2:39 ` Laurent Pinchart 2020-04-25 10:36 ` Patrik Gfeller 2020-04-25 12:19 ` Mauro Carvalho Chehab 2020-04-26 19:07 ` Laurent Pinchart 2020-04-26 20:51 ` Mauro Carvalho Chehab 2020-04-26 19:33 ` Laurent Pinchart 2020-04-28 18:13 ` Patrik Gfeller 2020-04-26 7:44 ` Patrik Gfeller 2020-04-26 19:17 ` Laurent Pinchart 2020-04-29 17:59 ` Patrik Gfeller 2020-04-29 18:19 ` Laurent Pinchart 2020-04-30 15:28 ` Patrik Gfeller 2020-05-02 16:08 ` Andy Shevchenko 2020-05-02 17:04 ` Mauro Carvalho Chehab 2020-05-02 17:33 ` Andy Shevchenko 2020-05-03 10:18 ` Mauro Carvalho Chehab 2020-05-12 10:20 ` Mauro Carvalho Chehab 2020-05-12 11:12 ` Andy Shevchenko 2020-05-12 11:21 ` Andy Shevchenko 2020-05-12 14:56 ` Mauro Carvalho Chehab 2020-05-12 16:01 ` Andy Shevchenko 2020-05-13 18:36 ` Patrik Gfeller 2020-05-20 8:04 ` Mauro Carvalho Chehab 2020-05-13 9:56 ` Mauro Carvalho Chehab 2020-05-03 8:46 ` Patrik Gfeller 2020-05-03 10:23 ` Mauro Carvalho Chehab 2020-05-03 12:31 ` Patrik Gfeller 2020-05-03 13:36 ` Patrik Gfeller 2020-05-03 14:43 ` Mauro Carvalho Chehab
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.