All of lore.kernel.org
 help / color / mirror / Atom feed
* [BUG] atomisp_ov2680 not initializing correctly
@ 2017-12-16 15:50 Kristian Beilke
  2017-12-19 12:00 ` Sakari Ailus
  0 siblings, 1 reply; 18+ messages in thread
From: Kristian Beilke @ 2017-12-16 15:50 UTC (permalink / raw)
  To: linux-media

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

Dear all,

I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
x5-Z8350 BayTrail) to work. The front camera is an ov2680. With kernel
4.14.4 and 4.15rc3 I see the following dmesg output:


[   21.469907] ov2680: module is from the staging directory, the quality
 is unknown, you have been warned.
[   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module
subdev data.PMIC ID 1
[   21.492891] acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CamClk
[   21.492974] acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_ClkSrc
[   21.493090] acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CsiPort
[   21.493209] acpi OVTI2680:00: Failed to find gmin variable
OVTI2680:00_CsiLanes
[   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX not
found, using dummy regulator
[   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX not
found, using dummy regulator
[   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A not
found, using dummy regulator
[   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply VPROG4B
not found, using dummy regulator
[   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1
order: 00000002
[   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error -121
[   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0xffff
[   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
[   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed

Afterwards I do not get a camera device.

Am I missing some firmware or dependency? Can I somehow help to improve
the driver?

Regards

Kristian


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4978 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-16 15:50 [BUG] atomisp_ov2680 not initializing correctly Kristian Beilke
@ 2017-12-19 12:00 ` Sakari Ailus
  2017-12-19 20:37   ` Andy Shevchenko
  0 siblings, 1 reply; 18+ messages in thread
From: Sakari Ailus @ 2017-12-19 12:00 UTC (permalink / raw)
  To: Kristian Beilke; +Cc: linux-media, alan, andriy.shevchenko

Cc Alan and Andy.

On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> Dear all,
> 
> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> x5-Z8350 BayTrail) to work. The front camera is an ov2680. With kernel
> 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> 
> [   21.469907] ov2680: module is from the staging directory, the quality
>  is unknown, you have been warned.
> [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module
> subdev data.PMIC ID 1
> [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CamClk
> [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_ClkSrc
> [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CsiPort
> [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CsiLanes
> [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX not
> found, using dummy regulator
> [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX not
> found, using dummy regulator
> [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A not
> found, using dummy regulator
> [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply VPROG4B
> not found, using dummy regulator
> [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1
> order: 00000002
> [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error -121
> [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0xffff
> [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> 
> Afterwards I do not get a camera device.
> 
> Am I missing some firmware or dependency? Can I somehow help to improve
> the driver?
> 
> Regards
> 
> Kristian
> 



-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-19 12:00 ` Sakari Ailus
@ 2017-12-19 20:37   ` Andy Shevchenko
  2017-12-20  7:13     ` Kristian Beilke
                       ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Andy Shevchenko @ 2017-12-19 20:37 UTC (permalink / raw)
  To: Sakari Ailus, Kristian Beilke; +Cc: linux-media, alan

On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> Cc Alan and Andy.
> 
> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > Dear all,
> > 
> > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > kernel
> > 4.14.4 and 4.15rc3 I see the following dmesg output:

It seems I forgot to send the rest of the patches I did while ago
against AtomISP code.

It includes switch to normal DMI matching instead of the crap we have
there right now.

WRT to the messages below it seems we have no platform data for that
device. It needs to be added.

In any case, I have no firmware to test BayTrail hardware I have (MRD7).

The driver claims it needs:

Firmware file: shisp_2400b0_v21.bin
Version string: irci_stable_candrpv_0415_20150521_0458

What I have is:

Version string: irci_stable_candrpv_0415_20150423_1753
SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin

> > [   21.469907] ov2680: module is from the staging directory, the
> > quality
> >  is unknown, you have been warned.
> > [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
> > module
> > subdev data.PMIC ID 1
> > [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CamClk
> > [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_ClkSrc
> > [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CsiPort
> > [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CsiLanes
> > [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
> > not
> > found, using dummy regulator
> > [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
> > not
> > found, using dummy regulator
> > [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
> > not
> > found, using dummy regulator
> > [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
> > VPROG4B
> > not found, using dummy regulator
> > [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
> > 1
> > order: 00000002
> > [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
> > -121
> > [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0xffff
> > [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> > [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> > 
> > Afterwards I do not get a camera device.
> > 
> > Am I missing some firmware or dependency?

See above.

> >  Can I somehow help to improve
> > the driver?

Yes, definitely, but first of all we need to find at least one device
and corresponding firmware where it actually works.

For me it doesn't generate any interrupt (after huge hacking to make
that firmware loaded and settings / platform data applied).

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-19 20:37   ` Andy Shevchenko
@ 2017-12-20  7:13     ` Kristian Beilke
  2017-12-21 12:54     ` Kristian Beilke
  2017-12-30 20:57     ` Alan Cox
  2 siblings, 0 replies; 18+ messages in thread
From: Kristian Beilke @ 2017-12-20  7:13 UTC (permalink / raw)
  To: Andy Shevchenko, Sakari Ailus; +Cc: linux-media, alan

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

On 12/19/2017 09:37 PM, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>> Cc Alan and Andy.
>>
>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
>>> Dear all,
>>>
>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
>>> kernel
>>> 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> It seems I forgot to send the rest of the patches I did while ago
> against AtomISP code.
> 
> It includes switch to normal DMI matching instead of the crap we have
> there right now.
> 
> WRT to the messages below it seems we have no platform data for that
> device. It needs to be added.
> 
> In any case, I have no firmware to test BayTrail hardware I have (MRD7).

My mistake here, meant to write CherryTrail, but that probably does not
make a difference for the next steps.

> The driver claims it needs:
> 
> Firmware file: shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150521_0458
> 
> What I have is:
> 
> Version string: irci_stable_candrpv_0415_20150423_1753
> SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin

From what I read here:
https://www.spinics.net/lists/linux-media/msg116382.html
They are supposedly compatible.

For CherryTrail I need shisp_2401a0_v21.bin it seems.

>>> [   21.469907] ov2680: module is from the staging directory, the
>>> quality
>>>  is unknown, you have been warned.
>>> [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
>>> module
>>> subdev data.PMIC ID 1
>>> [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CamClk
>>> [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_ClkSrc
>>> [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CsiPort
>>> [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CsiLanes
>>> [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
>>> not
>>> found, using dummy regulator
>>> [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
>>> not
>>> found, using dummy regulator
>>> [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
>>> not
>>> found, using dummy regulator
>>> [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
>>> VPROG4B
>>> not found, using dummy regulator
>>> [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
>>> 1
>>> order: 00000002
>>> [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
>>> -121
>>> [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0xffff
>>> [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
>>> [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
>>>
>>> Afterwards I do not get a camera device.
>>>
>>> Am I missing some firmware or dependency?
> 
> See above.
> 
>>>  Can I somehow help to improve
>>> the driver?
> 
> Yes, definitely, but first of all we need to find at least one device
> and corresponding firmware where it actually works.
> 
> For me it doesn't generate any interrupt (after huge hacking to make
> that firmware loaded and settings / platform data applied).

I guess I will apply your patches, add the firmware and see what happens.
Finding one device and firmware where it works? What do you have in
mind? Android?


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4978 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-19 20:37   ` Andy Shevchenko
  2017-12-20  7:13     ` Kristian Beilke
@ 2017-12-21 12:54     ` Kristian Beilke
  2017-12-21 14:23       ` Andy Shevchenko
  2017-12-30 20:57     ` Alan Cox
  2 siblings, 1 reply; 18+ messages in thread
From: Kristian Beilke @ 2017-12-21 12:54 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Sakari Ailus, linux-media, alan

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

On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > Cc Alan and Andy.
> > 
> > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > > Dear all,
> > > 
> > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > kernel
> > > 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> It seems I forgot to send the rest of the patches I did while ago
> against AtomISP code.
> 
> It includes switch to normal DMI matching instead of the crap we have
> there right now.
> 
> WRT to the messages below it seems we have no platform data for that
> device. It needs to be added.
> 
> In any case, I have no firmware to test BayTrail hardware I have (MRD7).
> 
> The driver claims it needs:
> 
> Firmware file: shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150521_0458
> 
> What I have is:
> 
> Version string: irci_stable_candrpv_0415_20150423_1753
> SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
>

I am a bit at a loss here. The TODO file says

7. The ISP code depends on the exact FW version. The version defined in
   BYT:
   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
   static const char *release_version = STR(irci_stable_candrpv_0415_20150521_0458);
   CHT:
   drivers/staging/media/atomisp/pci/atomisp2/css/sh_css_firmware.c
   static const char *release_version = STR(irci_ecr-master_20150911_0724);

The different files obviously have been merged into the first:

/* The string STR is a place holder
 * which will be replaced with the actual RELEASE_VERSION
 * during package generation. Please do not modify  */
#ifndef ISP2401
static const char *release_version = STR(irci_stable_candrpv_0415_20150521_0458);
#else
static const char *release_version = STR(irci_ecr-master_20150911_0724);
#endif

Trying to find the firmware files I came up with:

strings shisp_2400b0_v21.bin | grep irci
irci_stable_candrpv_0415_20150423_1753

strings shisp_2401a0_v21.bin | grep irci
irci_stable_candrpv_0415_20150521_0458

which seems to be an odd match. The CherryTrail FW is older than the one
expected, but I could not find a newer one. The BayTrail FW is the same
you have (but it should at least be compatible).
Any hints on where to find the expected FW files? As my hardware is
no android device, I can not look into an update kit.

> > > [   21.469907] ov2680: module is from the staging directory, the
> > > quality
> > >  is unknown, you have been warned.
> > > [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
> > > module
> > > subdev data.PMIC ID 1
> > > [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CamClk
> > > [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_ClkSrc
> > > [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CsiPort
> > > [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CsiLanes
> > > [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
> > > not
> > > found, using dummy regulator
> > > [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
> > > not
> > > found, using dummy regulator
> > > [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
> > > not
> > > found, using dummy regulator
> > > [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
> > > VPROG4B
> > > not found, using dummy regulator
> > > [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
> > > 1
> > > order: 00000002
> > > [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
> > > -121
> > > [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0xffff
> > > [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> > > [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> > > 
> > > Afterwards I do not get a camera device.
> > > 
> > > Am I missing some firmware or dependency?
> 
> See above.
> 
> > >  Can I somehow help to improve
> > > the driver?
> 
> Yes, definitely, but first of all we need to find at least one device
> and corresponding firmware where it actually works.
> 
> For me it doesn't generate any interrupt (after huge hacking to make
> that firmware loaded and settings / platform data applied).
> 

What exactly are you looking for? An Android device where the ov2680
works? Some x86_64 hardware, where the matching firmware is available and
the driver in 4.15 works?

> -- 
> Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Intel Finland Oy

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4624 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-21 12:54     ` Kristian Beilke
@ 2017-12-21 14:23       ` Andy Shevchenko
  2017-12-23  0:31         ` Kristian Beilke
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Shevchenko @ 2017-12-21 14:23 UTC (permalink / raw)
  To: Kristian Beilke; +Cc: Sakari Ailus, linux-media, alan

On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
> > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > > Cc Alan and Andy.
> > > 
> > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > > > Dear all,
> > > > 
> > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320
> > > > (Atom
> > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > > kernel
> > > > 4.14.4 and 4.15rc3 I see the following dmesg output:
> > 
> > It seems I forgot to send the rest of the patches I did while ago
> > against AtomISP code.
> > 
> > It includes switch to normal DMI matching instead of the crap we
> > have
> > there right now.
> > 
> > WRT to the messages below it seems we have no platform data for that
> > device. It needs to be added.
> > 
> > In any case, I have no firmware to test BayTrail hardware I have
> > (MRD7).
> > 
> > The driver claims it needs:
> > 
> > Firmware file: shisp_2400b0_v21.bin
> > Version string: irci_stable_candrpv_0415_20150521_0458
> > 
> > What I have is:
> > 
> > Version string: irci_stable_candrpv_0415_20150423_1753
> > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
> > 
> 
> I am a bit at a loss here. The TODO file says
> 
> 7. The ISP code depends on the exact FW version. The version defined
> in
>    BYT:
>    drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.
> c
>    static const char *release_version =
> STR(irci_stable_candrpv_0415_20150521_0458);
>    CHT:
>    drivers/staging/media/atomisp/pci/atomisp2/css/sh_css_firmware.c
>    static const char *release_version = STR(irci_ecr-
> master_20150911_0724);
> 
> The different files obviously have been merged into the first:
> 
> /* The string STR is a place holder
>  * which will be replaced with the actual RELEASE_VERSION
>  * during package generation. Please do not modify  */
> #ifndef ISP2401
> static const char *release_version =
> STR(irci_stable_candrpv_0415_20150521_0458);
> #else
> static const char *release_version = STR(irci_ecr-
> master_20150911_0724);
> #endif
> 
> Trying to find the firmware files I came up with:
> 
> strings shisp_2400b0_v21.bin | grep irci
> irci_stable_candrpv_0415_20150423_1753
> 
> strings shisp_2401a0_v21.bin | grep irci
> irci_stable_candrpv_0415_20150521_0458
> 
> which seems to be an odd match. The CherryTrail FW is older than the
> one
> expected, but I could not find a newer one. The BayTrail FW is the
> same
> you have (but it should at least be compatible).
> Any hints on where to find the expected FW files? As my hardware is
> no android device, I can not look into an update kit.

For now we are all using that firmware I mentioned (with, of course,
hack-patch applied to make driver swallow it).

>>>> Can I somehow help to improve
> > > > the driver?
> > 
> > Yes, definitely, but first of all we need to find at least one
> > device
> > and corresponding firmware where it actually works.
> > 
> > For me it doesn't generate any interrupt (after huge hacking to make
> > that firmware loaded and settings / platform data applied).
> > 
> 
> What exactly are you looking for?

For anything that *somehow* works.

>  An Android device where the ov2680
> works?

First of all, I most likely do not have hardware with such sensor.
Second, I'm using one of the prototype HW based on BayTrail with PCI
enumerable AtomISP.

>  Some x86_64 hardware, where the matching firmware is available and
> the driver in 4.15 works?

Yes, that's what I would like to have before moving forward with any new
sensor drivers, clean ups or alike type of changes to the driver.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-21 14:23       ` Andy Shevchenko
@ 2017-12-23  0:31         ` Kristian Beilke
  2017-12-28 16:03           ` Andy Shevchenko
  0 siblings, 1 reply; 18+ messages in thread
From: Kristian Beilke @ 2017-12-23  0:31 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Sakari Ailus, linux-media, alan

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

On 12/21/2017 03:23 PM, Andy Shevchenko wrote:
> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>>>> Cc Alan and Andy.
>>>>
>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
>>>>> Dear all,
>>>>>
>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320
>>>>> (Atom
>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680. With

CherryTrail

>>> WRT to the messages below it seems we have no platform data for that
>>> device. It needs to be added.
>>>

I tried to do exactly this. Extracted some values from
acpidump/acpixtract and dmidecode, but unsure I nailed it.

>>>>> Can I somehow help to improve
>>>>> the driver?
>>>
>>> Yes, definitely, but first of all we need to find at least one
>>> device
>>> and corresponding firmware where it actually works.
>>>
>>> For me it doesn't generate any interrupt (after huge hacking to make
>>> that firmware loaded and settings / platform data applied).
>>>
>>
>> What exactly are you looking for?
> 
> For anything that *somehow* works.
> 
>>  An Android device where the ov2680
>> works?
> 
> First of all, I most likely do not have hardware with such sensor.
> Second, I'm using one of the prototype HW based on BayTrail with PCI
> enumerable AtomISP.
> 
>>  Some x86_64 hardware, where the matching firmware is available and
>> the driver in 4.15 works?
> 
> Yes, that's what I would like to have before moving forward with any new
> sensor drivers, clean ups or alike type of changes to the driver.
> 

After your set of patches I applied the CherryTrail support I found here
https://github.com/croutor/atomisp2401

As a result I get:

[    0.000000] DMI: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW 09/11/2017
[    2.806685] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found
[    2.849606] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded
[   19.593200] media: Linux media interface: v0.10
[   19.627138] Linux video capture interface: v2.00
[   19.652771] atomisp_ov2680: module is from the staging directory, the
quality is unknown, you have been warned.
[   19.676093] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module
subdev data.PMIC ID 2
[   19.676097] ov2680 i2c-OVTI2680:00: suddev name = ov2680 0-0010
[   19.677548] gmin_v1p8_ctrl PMIC_AXP.
[   19.685261] axp_regulator_set success.
[   19.685428] axp_v1p8_on XXOV2680 00000010
[   19.691777] axp_regulator_set success.
[   19.708488] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[   19.752432] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
[   19.760507] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels
[   19.789335] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1
order: 00000002
[   19.793616] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680
[   19.793638] gmin_v1p8_ctrl PMIC_AXP.
[   19.802615] axp_regulator_set success.
[   19.806384] axp_regulator_set success.
[   19.806396] ov2680 i2c-OVTI2680:00: register atomisp i2c module type 1
[   19.859215] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   19.906592] atomisp: module is from the staging directory, the
quality is unknown, you have been warned.

[   19.910763] **********************************************************
[   19.910765] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[   19.910766] **                                                      **
[   19.910767] ** trace_printk() being used. Allocating extra memory.  **
[   19.910768] **                                                      **
[   19.910769] ** This means that this is a DEBUG kernel and it is     **
[   19.910770] ** unsafe for production use.                           **
[   19.910771] **                                                      **
[   19.910772] ** If you see this message and you are not debugging    **
[   19.910773] ** the kernel, report this immediately to your vendor!  **
[   19.910774] **                                                      **
[   19.910775] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[   19.910776] **********************************************************
[   19.923072] (NULL device *): hwmon_device_register() is deprecated.
Please convert the driver to use hwmon_device_register_with_info().
[   19.923219] (NULL device *): hwmon_device_register() is deprecated.
Please convert the driver to use hwmon_device_register_with_info().
[   19.932909] atomisp-isp2 0000:00:03.0: atomisp: device 000022B8
revision 54
[   19.932917] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 1600 MHz
[   20.133834] axp288_fuel_gauge axp288_fuel_gauge: axp288 not
configured by firmware
[   20.162738] atomisp-isp2 0000:00:03.0: Subdev OVTI2680:00
successfully register
[   20.162750] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
ISP CSI2-port0 was not initialized!
[   20.162753] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
ISP CSI2-port1 was not initialized!
[   20.162756] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
ISP CSI2-port2 was not initialized!
[   20.162759] atomisp-isp2 0000:00:03.0: Entity type for entity
file_input_subdev was not initialized!
[   20.162762] atomisp-isp2 0000:00:03.0: Entity type for entity
tpg_subdev was not initialized!
[   20.162765] atomisp-isp2 0000:00:03.0: Entity type for entity
ATOMISP_SUBDEV_0 was not initialized!
[   20.166183] atomisp-isp2 0000:00:03.0: Entity type for entity
ATOMISP_SUBDEV_1 was not initialized!
[   21.120554] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not
found, using dummy regulator
[   21.120587] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd not
found, using dummy regulator
[   21.145141] intel_sst_acpi 808622A8:00: LPE base: 0x91400000
size:0x200000
[   21.145146] intel_sst_acpi 808622A8:00: IRAM base: 0x914c0000
[   21.145241] intel_sst_acpi 808622A8:00: DRAM base: 0x91500000
[   21.145250] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000
[   21.145262] intel_sst_acpi 808622A8:00: Mailbox base: 0x91544000
[   21.145269] intel_sst_acpi 808622A8:00: DDR base: 0x20000000
[   21.145403] intel_sst_acpi 808622A8:00: Got drv data max stream 25
[   21.892310] atomisp-isp2 0000:00:03.0: Refused to change power state,
currently in D3
[   21.904537] OVTI2680:00:
               ov2680_s_parm:run_mode :2000
[   21.919743] atomisp-isp2 0000:00:03.0: Refused to change power state,
currently in D3
[   21.930399] OVTI2680:00:
               ov2680_s_parm:run_mode :2000
[   21.956479] atomisp-isp2 0000:00:03.0: Refused to change power state,
currently in D3

I am still not sure the FW gets loaded, and there is still no
/dev/camera, but it looks promising. Am I on the right track here, or am
I wasting my (and your) time?


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4978 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-23  0:31         ` Kristian Beilke
@ 2017-12-28 16:03           ` Andy Shevchenko
  2017-12-29 19:38             ` Andy Shevchenko
                               ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Andy Shevchenko @ 2017-12-28 16:03 UTC (permalink / raw)
  To: Kristian Beilke; +Cc: Sakari Ailus, linux-media, alan

On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote:
> On 12/21/2017 03:23 PM, Andy Shevchenko wrote:
> > On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
> > > On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
> > > > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > > > > Cc Alan and Andy.
> > > > > 
> > > > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke
> > > > > wrote:
> > > > > > Dear all,
> > > > > > 
> > > > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320
> > > > > > (Atom
> > > > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680.
> > > > > > With
> 
> CherryTrail

I didn't try even find a CherryTrail on hand that have AtomISP
enumerated by PCI with a camera sensor connected.

AFAIR Alan has CHT hardware he is developing / testing on.

> > > > WRT to the messages below it seems we have no platform data for
> > > > that
> > > > device. It needs to be added.
> > > > 
> 
> I tried to do exactly this. Extracted some values from
> acpidump/acpixtract and dmidecode, but unsure I nailed it.

Can you share somewhere it (pastebin.com, gist.github.com, etc)?

> > > > > > Can I somehow help to improve
> > > > > > the driver?
> > > > 
> > > > Yes, definitely, but first of all we need to find at least one
> > > > device
> > > > and corresponding firmware where it actually works.
> > > > 
> > > > For me it doesn't generate any interrupt (after huge hacking to
> > > > make
> > > > that firmware loaded and settings / platform data applied).
> > > > 
> > > 
> > > What exactly are you looking for?
> > 
> > For anything that *somehow* works.
> > 
> > >  An Android device where the ov2680
> > > works?
> > 
> > First of all, I most likely do not have hardware with such sensor.
> > Second, I'm using one of the prototype HW based on BayTrail with PCI
> > enumerable AtomISP.
> > 
> > >  Some x86_64 hardware, where the matching firmware is available
> > > and
> > > the driver in 4.15 works?
> > 
> > Yes, that's what I would like to have before moving forward with any
> > new
> > sensor drivers, clean ups or alike type of changes to the driver.
> > 
> 
> After your set of patches I applied the CherryTrail support I found
> here
> https://github.com/croutor/atomisp2401
> 
> As a result I get:
> 
> [    0.000000] DMI: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW 09/11/2017
> [    2.806685] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found
> [    2.849606] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded
> [   19.593200] media: Linux media interface: v0.10
> [   19.627138] Linux video capture interface: v2.00
> [   19.652771] atomisp_ov2680: module is from the staging directory,
> the
> quality is unknown, you have been warned.
> [   19.676093] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
> module
> subdev data.PMIC ID 2
> [   19.676097] ov2680 i2c-OVTI2680:00: suddev name = ov2680 0-0010
> [   19.677548] gmin_v1p8_ctrl PMIC_AXP.
> [   19.685261] axp_regulator_set success.
> [   19.685428] axp_v1p8_on XXOV2680 00000010
> [   19.691777] axp_regulator_set success.
> [   19.708488] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8
> channels
> [   19.752432] ov2680 i2c-OVTI2680:00: unable to set PMC rate 1
> [   19.760507] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8
> channels
> [   19.789335] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1
> order: 00000002
> [   19.793616] ov2680 i2c-OVTI2680:00: sensor_revision id = 0x2680
> [   19.793638] gmin_v1p8_ctrl PMIC_AXP.
> [   19.802615] axp_regulator_set success.
> [   19.806384] axp_regulator_set success.
> [   19.806396] ov2680 i2c-OVTI2680:00: register atomisp i2c module
> type 1
> [   19.859215] shpchp: Standard Hot Plug PCI Controller Driver
> version: 0.4
> [   19.906592] atomisp: module is from the staging directory, the
> quality is unknown, you have been warned.
> 
> [   19.910763]
> **********************************************************
> [   19.910765] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> NOTICE   **
> [   19.910766]
> **                                                      **
> [   19.910767] ** trace_printk() being used. Allocating extra
> memory.  **
> [   19.910768]
> **                                                      **
> [   19.910769] ** This means that this is a DEBUG kernel and it
> is     **
> [   19.910770] ** unsafe for production
> use.                           **
> [   19.910771]
> **                                                      **
> [   19.910772] ** If you see this message and you are not
> debugging    **
> [   19.910773] ** the kernel, report this immediately to your
> vendor!  **
> [   19.910774]
> **                                                      **
> [   19.910775] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
> NOTICE   **
> [   19.910776]
> **********************************************************
> [   19.923072] (NULL device *): hwmon_device_register() is deprecated.
> Please convert the driver to use hwmon_device_register_with_info().
> [   19.923219] (NULL device *): hwmon_device_register() is deprecated.
> Please convert the driver to use hwmon_device_register_with_info().
> [   19.932909] atomisp-isp2 0000:00:03.0: atomisp: device 000022B8
> revision 54
> [   19.932917] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base =
> 1600 MHz
> [   20.133834] axp288_fuel_gauge axp288_fuel_gauge: axp288 not
> configured by firmware
> [   20.162738] atomisp-isp2 0000:00:03.0: Subdev OVTI2680:00
> successfully register
> [   20.162750] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
> ISP CSI2-port0 was not initialized!
> [   20.162753] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
> ISP CSI2-port1 was not initialized!
> [   20.162756] atomisp-isp2 0000:00:03.0: Entity type for entity ATOM
> ISP CSI2-port2 was not initialized!
> [   20.162759] atomisp-isp2 0000:00:03.0: Entity type for entity
> file_input_subdev was not initialized!
> [   20.162762] atomisp-isp2 0000:00:03.0: Entity type for entity
> tpg_subdev was not initialized!
> [   20.162765] atomisp-isp2 0000:00:03.0: Entity type for entity
> ATOMISP_SUBDEV_0 was not initialized!
> [   20.166183] atomisp-isp2 0000:00:03.0: Entity type for entity
> ATOMISP_SUBDEV_1 was not initialized!
> [   21.120554] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not
> found, using dummy regulator
> [   21.120587] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd
> not
> found, using dummy regulator
> [   21.145141] intel_sst_acpi 808622A8:00: LPE base: 0x91400000
> size:0x200000
> [   21.145146] intel_sst_acpi 808622A8:00: IRAM base: 0x914c0000
> [   21.145241] intel_sst_acpi 808622A8:00: DRAM base: 0x91500000
> [   21.145250] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000
> [   21.145262] intel_sst_acpi 808622A8:00: Mailbox base: 0x91544000
> [   21.145269] intel_sst_acpi 808622A8:00: DDR base: 0x20000000
> [   21.145403] intel_sst_acpi 808622A8:00: Got drv data max stream 25
> [   21.892310] atomisp-isp2 0000:00:03.0: Refused to change power
> state,
> currently in D3
> [   21.904537] OVTI2680:00:
>                ov2680_s_parm:run_mode :2000
> [   21.919743] atomisp-isp2 0000:00:03.0: Refused to change power
> state,
> currently in D3
> [   21.930399] OVTI2680:00:
>                ov2680_s_parm:run_mode :2000
> [   21.956479] atomisp-isp2 0000:00:03.0: Refused to change power
> state,
> currently in D3

I have few hacks on top of this.

First of all, take a base as atomisp branch of sakari's media_tree
repository:

https://git.linuxtv.org/sailus/media_tree.git/

Second, apply

--- a/drivers/staging/media/atomisp/platform/intel-
mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-
mid/atomisp_gmin_platform.c
@@ -499,6 +499,7 @@ static int gmin_v1p8_ctrl(struct v4l2_subdev
*subdev, int on)
                        return regulator_disable(gs->v1p8_reg);
        }
 
+return 0;
        return -EINVAL;
 }
 
@@ -535,6 +536,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev
*subdev, int on)
                        return regulator_disable(gs->v2p8_reg);
        }
 
+return 0;
        return -EINVAL;
 }

---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
@@ -184,6 +184,7 @@ sh_css_check_firmware_version(const char *fw_data)
        firmware_header = (struct firmware_header *)fw_data;
        file_header = &firmware_header->file_header;
 
+return true;
        if (strcmp(file_header->version, release_version) != 0) {
                return false;

--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -348,6 +348,8 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST
-DHRT_USE_VIR_ADDRS -D__HOST__
 #DEFINES += -DPUNIT_CAMERA_BUSY
 #DEFINES += -DUSE_KMEM_CACHE
 
+DEFINES += -DDEBUG
+
 DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0

For CHT you have to change define in this file to 2401 here and line
below AFAIU (never did this).

Third, you need to change pmic_id to be PMIC_AXP (I have longer patch
for this, that's why don't post here). Just hard code it for now in gmin
file.

Fourth, you have to be sure the clock rate is chosen correctly
(currently there is a bug in clk_set_rate() where parameter is clock
source index instead of frequency!). I think you need to hardcode
19200000 there instead of gs->clock_src.

> I am still not sure the FW gets loaded, and there is still no
> /dev/camera, but it looks promising.

You may add a debug print in necessary function inside ->probe (in
atomisp_v4l2.c). I dont't remember if -DDEBUG will enable something like
that. Perhaps.

You are expecting /dev/video<N> nodes. /dev/camera is usually a udev's
alias against one of /dev/video<N> nodes.

>  Am I on the right track here, or am
> I wasting my (and your) time?

It's both: track is right and it's waste of time.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-28 16:03           ` Andy Shevchenko
@ 2017-12-29 19:38             ` Andy Shevchenko
  2017-12-30 21:10             ` Alan Cox
  2017-12-31 15:19             ` Kristian Beilke
  2 siblings, 0 replies; 18+ messages in thread
From: Andy Shevchenko @ 2017-12-29 19:38 UTC (permalink / raw)
  To: Kristian Beilke, Hans de Goede; +Cc: Sakari Ailus, linux-media, alan

+Cc Hans.

On Thu, 2017-12-28 at 18:03 +0200, Andy Shevchenko wrote:
> On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote:
> > On 12/21/2017 03:23 PM, Andy Shevchenko wrote:

I spend more time on investigating some additional stuff Sakari gave me, but no result so far.

So, the verbose debug output is here:
https://pastebin.com/RUV8gsUJ

Can anyone tell what's going on?

Note the idle state between 803s - 806s. I pressed Ctrl+C there since no expected IRQ came.

So, was it ever tested on Baytrail???

Who can debug this properly?

For now it's a quite waste of time. I doubt I want to do anything anymore
for this. Consider I'm in postponed state until there will be a *proven* way to test it.

Otherwise, I'm voting 10x times to remove this driver from upstream for good.

P.S. Happy New Year, everyone!

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-19 20:37   ` Andy Shevchenko
  2017-12-20  7:13     ` Kristian Beilke
  2017-12-21 12:54     ` Kristian Beilke
@ 2017-12-30 20:57     ` Alan Cox
  2018-01-04 17:58       ` Andy Shevchenko
  2 siblings, 1 reply; 18+ messages in thread
From: Alan Cox @ 2017-12-30 20:57 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Sakari Ailus, Kristian Beilke, linux-media, alan

On Tue, 19 Dec 2017 22:37:01 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > Cc Alan and Andy.
> > 
> > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:  
> > > Dear all,
> > > 
> > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > kernel
> > > 4.14.4 and 4.15rc3 I see the following dmesg output:  
> 
> It seems I forgot to send the rest of the patches I did while ago
> against AtomISP code.
> 
> It includes switch to normal DMI matching instead of the crap we have
> there right now.

The current code expects to be booted on an Android (or ex Android)
tablet. In which case the various values are buried in the EFI as you'd
expect.

The Windows devices seem to use a mix of ACPI, hardcoding and plain magic
in order to decide what hardware they have.

> WRT to the messages below it seems we have no platform data for that
> device. It needs to be added.

Or we need to learn how to parse the ACPI data - except that at least on
some devices the ACPI data is at least half fictional so it's not clear
what the Windows driver really does.

For CHT and maybe some BYT the Windows devices also use ACPI for the power
management to drive the PMIC opregion and thus the PMIC power lines.

> In any case, I have no firmware to test BayTrail hardware I have (MRD7).
> 
> The driver claims it needs:
> 
> Firmware file: shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150521_0458
> 
> What I have is:
> 
> Version string: irci_stable_candrpv_0415_20150423_1753
> SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin

I'll send you a copy: (unfortunately for non Intel people I've not
managed to get enough people to care about this to get permission to put
the firmware in the public repository ... yet.....)

Alan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-28 16:03           ` Andy Shevchenko
  2017-12-29 19:38             ` Andy Shevchenko
@ 2017-12-30 21:10             ` Alan Cox
  2018-01-04 17:52               ` Andy Shevchenko
  2017-12-31 15:19             ` Kristian Beilke
  2 siblings, 1 reply; 18+ messages in thread
From: Alan Cox @ 2017-12-30 21:10 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Kristian Beilke, Sakari Ailus, linux-media, alan

> AFAIR Alan has CHT hardware he is developing / testing on.

I have a loaned board from the company Vincent (who did the intial
patches) works for. At the moment it's loading firmware, finding cameras
doing power management but not transferring images.

Unfortunately because of the design of the driver and firmware at the
moment we are reduced to analyzing all the structs by hand between
multiple different driver releases, and playing games to try and find out
why various things are not matching up (assuming the firmware we have
will actually work with the Windows tablet in question in the first
place).

It's nasty because there are complex structs shared between the firmware
and the OS, and in at least one spot the supposedly 'pristine' CHT driver
that was used for the merge we now know could never have worked because
it mismatched its own firmware !

On BYT I can't currently do much as my latest Intel Android tablet has
died and it's getting hard to find more because I guess the rest of those
made have also died.

> > [   21.120554] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not
> > found, using dummy regulator
> > [   21.120587] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd
> > not
> > found, using dummy regulator

It couldn't figure out how to power managed some of the components.

> > [   21.145141] intel_sst_acpi 808622A8:00: LPE base: 0x91400000
> > size:0x200000
> > [   21.145146] intel_sst_acpi 808622A8:00: IRAM base: 0x914c0000
> > [   21.145241] intel_sst_acpi 808622A8:00: DRAM base: 0x91500000
> > [   21.145250] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000
> > [   21.145262] intel_sst_acpi 808622A8:00: Mailbox base: 0x91544000
> > [   21.145269] intel_sst_acpi 808622A8:00: DDR base: 0x20000000
> > [   21.145403] intel_sst_acpi 808622A8:00: Got drv data max stream 25
> > [   21.892310] atomisp-isp2 0000:00:03.0: Refused to change power
> > state,
> > currently in D3
> > [   21.904537] OVTI2680:00:
> >                ov2680_s_parm:run_mode :2000
> > [   21.919743] atomisp-isp2 0000:00:03.0: Refused to change power
> > state,
> > currently in D3
> > [   21.930399] OVTI2680:00:
> >                ov2680_s_parm:run_mode :2000
> > [   21.956479] atomisp-isp2 0000:00:03.0: Refused to change power
> > state,
> > currently in D3  

The D3 warnings you can ignore I think. PCI D3 is busted but the native
power management should be looking after it.

Alan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-28 16:03           ` Andy Shevchenko
  2017-12-29 19:38             ` Andy Shevchenko
  2017-12-30 21:10             ` Alan Cox
@ 2017-12-31 15:19             ` Kristian Beilke
  2018-01-01 12:42               ` Andy Shevchenko
  2 siblings, 1 reply; 18+ messages in thread
From: Kristian Beilke @ 2017-12-31 15:19 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Sakari Ailus, linux-media, alan, hdegoede

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

On 12/28/2017 05:03 PM, Andy Shevchenko wrote:
> On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote:
>> On 12/21/2017 03:23 PM, Andy Shevchenko wrote:
>>> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
>>>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
>>>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>>>>>> Cc Alan and Andy.
>>>>>>
>>>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke
>>>>>> wrote:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320
>>>>>>> (Atom
>>>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680.
>>>>>>> With
>>
>> CherryTrail

>>>>> WRT to the messages below it seems we have no platform data for
>>>>> that
>>>>> device. It needs to be added.
>>>>>
>>
>> I tried to do exactly this. Extracted some values from
>> acpidump/acpixtract and dmidecode, but unsure I nailed it.
> 
> Can you share somewhere it (pastebin.com, gist.github.com, etc)?
> 

https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f

dmidecode gives me

Handle 0x0002, DMI type 2, 17 bytes
Base Board Information
        Manufacturer: LENOVO
        Product Name: LNVNB161216
        Version: SDK0J91196WIN

what I assume works as identifier in:
DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216")

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 87216bc35648..716be4ace60e 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
@@ -503,6 +503,18 @@ static struct gmin_cfg_var cht_cr_vars[] = {
        {},
 };

+static struct gmin_cfg_var miix320_vars[] = {
+        {"OVTI2680:00_CamType", "1"},
+        {"OVTI2680:00_CsiPort", "0"},
+        {"OVTI2680:00_CsiLanes", "1"},
+        {"OVTI2680:00_CsiFmt", "15"},
+        {"OVTI2680:00_CsiBayer", "0"},
+        {"OVTI2680:00_CamClk", "1"},
+        {"OVTI2680:00_Regulator1p8v", "0"},
+        {"OVTI2680:00_Regulator2p8v", "0"},
+        {},
+};
+
 static struct gmin_cfg_var mrd7_vars[] = {
 	{"INT33F8:00_CamType", "1"},
 	{"INT33F8:00_CsiPort", "1"},
@@ -566,6 +578,13 @@ static const struct dmi_system_id gmin_vars[] = {
 		},
 		.driver_data = cht_cr_vars,
        	},
+	{
+                .ident = "MIIX320",
+                .matches = {
+                        DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
+                },
+                .driver_data = miix320_vars,
+        },
 	{
 		.ident = "MRD7",
 		.matches = {

>> After your set of patches I applied the CherryTrail support I found
>> here
>> https://github.com/croutor/atomisp2401
>>
> 
> I have few hacks on top of this.
> 
> First of all, take a base as atomisp branch of sakari's media_tree
> repository:
> 
> https://git.linuxtv.org/sailus/media_tree.git/
> 

I updated the mentioned patches by Vincent Hervieux to apply cleanly on
the media_tree atomisp branch.

https://github.com/jdkbx/atomisp2401

> Second, apply
> 
> --- a/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> +++ b/drivers/staging/media/atomisp/platform/intel-
> mid/atomisp_gmin_platform.c
> @@ -499,6 +499,7 @@ static int gmin_v1p8_ctrl(struct v4l2_subdev
> *subdev, int on)
>                         return regulator_disable(gs->v1p8_reg);
>         }
>  
> +return 0;
>         return -EINVAL;
>  }
>  
> @@ -535,6 +536,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev
> *subdev, int on)
>                         return regulator_disable(gs->v2p8_reg);
>         }
>  
> +return 0;
>         return -EINVAL;
>  }
> 
> ---
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -184,6 +184,7 @@ sh_css_check_firmware_version(const char *fw_data)
>         firmware_header = (struct firmware_header *)fw_data;
>         file_header = &firmware_header->file_header;
>  
> +return true;
>         if (strcmp(file_header->version, release_version) != 0) {
>                 return false;
> 
> --- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
> @@ -348,6 +348,8 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST
> -DHRT_USE_VIR_ADDRS -D__HOST__
>  #DEFINES += -DPUNIT_CAMERA_BUSY
>  #DEFINES += -DUSE_KMEM_CACHE
>  
> +DEFINES += -DDEBUG
> +
>  DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0
> 
> For CHT you have to change define in this file to 2401 here and line
> below AFAIU (never did this).
> 
> Third, you need to change pmic_id to be PMIC_AXP (I have longer patch
> for this, that's why don't post here). Just hard code it for now in gmin
> file.
> 

I assume the given patch set does already what you suggest here, apart
from the DDEBUG DEFINE.

> Fourth, you have to be sure the clock rate is chosen correctly
> (currently there is a bug in clk_set_rate() where parameter is clock
> source index instead of frequency!). I think you need to hardcode
> 19200000 there instead of gs->clock_src.

I found nothing about this in the patch set, so I will do this manually.

>> I am still not sure the FW gets loaded, and there is still no
>> /dev/camera, but it looks promising.
> 
> You may add a debug print in necessary function inside ->probe (in
> atomisp_v4l2.c). I dont't remember if -DDEBUG will enable something like
> that. Perhaps.

Thats what I will do next.

> You are expecting /dev/video<N> nodes. /dev/camera is usually a udev's
> alias against one of /dev/video<N> nodes.

As described by Alan in a later mail, this actually gives me 10
/dev/video[0-10] nodes, but none producing any images. video4 and
video10 cause a kernel oops when opened.

[  425.667704] BUG: unable to handle kernel NULL pointer dereference at
00000000000000b8
[  425.667761] IP: atomisp_g_parm+0x4a/0x80 [atomisp]
[  425.667765] PGD 0 P4D 0
[  425.667771] Oops: 0000 [#1] SMP
[  425.667776] Modules linked in: rfcomm bnep snd_soc_sst_cht_bsw_rt5645
wmi_bmof cmdlinepart intel_spi_platform intel_spi spi_nor mtd
snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_atom_hifi2_platform
snd_soc_acpi snd_soc_rt5645 snd_soc_acpi_intel_match gpio_keys
snd_soc_rl6231 nls_iso8859_1 intel_rapl intel_powerclamp coretemp
punit_atom_debug intel_cstate iwlmvm mac80211 axp288_fuel_gauge
extcon_axp288 axp288_charger axp288_adc axp20x_pek cdc_mbim cdc_wdm
cdc_ncm usbnet joydev mii hid_multitouch iwlwifi input_leds btusb btrtl
btbcm btintel atomisp(C) bluetooth cfg80211 mei_txe mei lpc_ich
videobuf_vmalloc processor_thermal_device shpchp videobuf_core
intel_soc_dts_iosf snd_seq_midi snd_seq_midi_event snd_rawmidi
snd_soc_core snd_seq snd_compress ac97_bus snd_pcm_dmaengine
bmc150_accel_i2c dw_dmac
[  425.667850]  bmc150_accel_core dw_dmac_core
industrialio_triggered_buffer snd_pcm kfifo_buf industrialio
atomisp_ov2680(C) snd_seq_device v4l2_common snd_timer videodev snd
media soundcore pwm_lpss_platform 8250_dw tpm_crb spi_pxa2xx_platform
pwm_lpss wmi acpi_pad int3403_thermal int3400_thermal
int340x_thermal_zone acpi_thermal_rel soc_button_array
intel_int0002_vgpio parport_pc ppdev lp parport ip_tables x_tables
hid_generic usbhid dm_crypt mmc_block i915 intel_gtt i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm video
i2c_hid hid sdhci_acpi sdhci
[  425.667909] CPU: 1 PID: 2385 Comm: mplayer Tainted: G         C
4.15.0-rc3 #5
[  425.667912] Hardware name: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW
09/11/2017
[  425.667949] RIP: 0010:atomisp_g_parm+0x4a/0x80 [atomisp]
[  425.667952] RSP: 0018:ffffaca6c2917c90 EFLAGS: 00010246
[  425.667957] RAX: 0000000000000000 RBX: ffff9b50343aeea0 RCX:
ffffffffc0a872c0
[  425.667960] RDX: ffff9b4ff816c140 RSI: 0000000000000000 RDI:
ffff9b50343aeea0
[  425.667963] RBP: ffff9b5036075200 R08: ffffffffc0a87200 R09:
ffff9b5038843300
[  425.667965] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff9b5038843c80
[  425.667968] R13: 0000000000000000 R14: 00000000000000cc R15:
ffff9b50332d5e00
[  425.667972] FS:  00007fbc6ba72440(0000) GS:ffff9b503fc80000(0000)
knlGS:0000000000000000
[  425.667976] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  425.667979] CR2: 00000000000000b8 CR3: 0000000175f4b000 CR4:
00000000001006e0
[  425.667982] Call Trace:
[  425.668001]  ? v4l_g_parm+0x54/0xd0 [videodev]
[  425.668014]  ? __video_do_ioctl+0x34d/0x360 [videodev]
[  425.668022]  ? path_openat+0x5bb/0x1620
[  425.668028]  ? _cond_resched+0x15/0x40
[  425.668034]  ? __kmalloc_node+0x1ea/0x2a0
[  425.668046]  ? video_ioctl2+0x20/0x20 [videodev]
[  425.668058]  ? video_usercopy+0x97/0x5b0 [videodev]
[  425.668071]  ? v4l2_ioctl+0xbb/0xe0 [videodev]
[  425.668076]  ? do_vfs_ioctl+0xa4/0x630
[  425.668081]  ? SyS_ioctl+0x7c/0x90
[  425.668087]  ? entry_SYSCALL_64_fastpath+0x1e/0x81
[  425.668091] Code: 01 4c 8b a0 78 09 00 00 48 8b 9b 50 02 00 00 75 2f
48 81 c3 88 0e 00 00 48 89 df e8 f1 51 d6 ec 49 8b 84 24 c0 44 00 00 48
8d 3b <8b> 80 b8 00 00 00 89 45 08 e8 78 4d d6 ec 31 c0 5b 5d 41 5c c3
[  425.668185] RIP: atomisp_g_parm+0x4a/0x80 [atomisp] RSP: ffffaca6c2917c90
[  425.668188] CR2: 00000000000000b8
[  425.668237] ---[ end trace fb76f36afd55319e ]---
[  425.672735] ------------[ cut here ]------------
[  425.672748] rtmutex deadlock detected
[  425.672767] WARNING: CPU: 1 PID: 2385 at kernel/locking/rtmutex.h:28
rt_mutex_slowlock+0x176/0x1e0
[  425.672771] Modules linked in: rfcomm bnep snd_soc_sst_cht_bsw_rt5645
wmi_bmof cmdlinepart intel_spi_platform intel_spi spi_nor mtd
snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_atom_hifi2_platform
snd_soc_acpi snd_soc_rt5645 snd_soc_acpi_intel_match gpio_keys
snd_soc_rl6231 nls_iso8859_1 intel_rapl intel_powerclamp coretemp
punit_atom_debug intel_cstate iwlmvm mac80211 axp288_fuel_gauge
extcon_axp288 axp288_charger axp288_adc axp20x_pek cdc_mbim cdc_wdm
cdc_ncm usbnet joydev mii hid_multitouch iwlwifi input_leds btusb btrtl
btbcm btintel atomisp(C) bluetooth cfg80211 mei_txe mei lpc_ich
videobuf_vmalloc processor_thermal_device shpchp videobuf_core
intel_soc_dts_iosf snd_seq_midi snd_seq_midi_event snd_rawmidi
snd_soc_core snd_seq snd_compress ac97_bus snd_pcm_dmaengine
bmc150_accel_i2c dw_dmac
[  425.672845]  bmc150_accel_core dw_dmac_core
industrialio_triggered_buffer snd_pcm kfifo_buf industrialio
atomisp_ov2680(C) snd_seq_device v4l2_common snd_timer videodev snd
media soundcore pwm_lpss_platform 8250_dw tpm_crb spi_pxa2xx_platform
pwm_lpss wmi acpi_pad int3403_thermal int3400_thermal
int340x_thermal_zone acpi_thermal_rel soc_button_array
intel_int0002_vgpio parport_pc ppdev lp parport ip_tables x_tables
hid_generic usbhid dm_crypt mmc_block i915 intel_gtt i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm video
i2c_hid hid sdhci_acpi sdhci
[  425.672906] CPU: 1 PID: 2385 Comm: mplayer Tainted: G      D  C
4.15.0-rc3 #5
[  425.672909] Hardware name: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW
09/11/2017
[  425.672913] RIP: 0010:rt_mutex_slowlock+0x176/0x1e0
[  425.672916] RSP: 0018:ffffaca6c2917c88 EFLAGS: 00010046
[  425.672921] RAX: 0000000000000000 RBX: ffff9b50343aeea0 RCX:
0000000000000006
[  425.672924] RDX: 0000000000000007 RSI: 0000000000000002 RDI:
ffff9b503fc8cdd0
[  425.672927] RBP: ffffaca6c2917ca0 R08: 0000000000000382 R09:
000000000000000f
[  425.672930] R10: 0000000000000000 R11: ffffffffae3e0e0d R12:
0000000000000000
[  425.672933] R13: 0000000000000002 R14: 00000000ffffffdd R15:
0000000000000000
[  425.672937] FS:  0000000000000000(0000) GS:ffff9b503fc80000(0000)
knlGS:0000000000000000
[  425.672945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  425.672948] CR2: 00000000000000b8 CR3: 0000000167808000 CR4:
00000000001006e0
[  425.672951] Call Trace:
[  425.673008]  ? atomisp_release+0x8f/0x520 [atomisp]
[  425.673016]  ? kmem_cache_free+0x195/0x1c0
[  425.673033]  ? v4l2_release+0x30/0x80 [videodev]
[  425.673038]  ? __fput+0xd8/0x210
[  425.673046]  ? task_work_run+0x89/0xb0
[  425.673052]  ? do_exit+0x2ed/0xb30
[  425.673058]  ? rewind_stack_do_exit+0x17/0x20
[  425.673062] Code: 48 8d 75 00 48 8d 3b e8 f9 09 3f ff 41 83 fe dd 0f
85 70 ff ff ff 45 85 ff 0f 85 67 ff ff ff 48 c7 c7 99 04 bb ad e8 9a f5
39 ff <0f> ff 48 c7 44 24 10 01 00 00 00 65 48 8b 14 25 40 c4 00 00 48
[  425.673123] ---[ end trace fb76f36afd55319f ]---

>>  Am I on the right track here, or am
>> I wasting my (and your) time?
> 
> It's both: track is right and it's waste of time.
> 

I see your point, Still it feels, as if this could go somewhere. Anyway,
thanks for your explanations and the time you invested into this.

Happy New Year to everyone.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4978 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-31 15:19             ` Kristian Beilke
@ 2018-01-01 12:42               ` Andy Shevchenko
  2018-01-02 18:31                 ` Alan Cox
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Shevchenko @ 2018-01-01 12:42 UTC (permalink / raw)
  To: Kristian Beilke
  Cc: Andy Shevchenko, Sakari Ailus, Linux Media Mailing List,
	Alan Cox, Hans de Goede

On Sun, Dec 31, 2017 at 5:19 PM, Kristian Beilke <beilke@posteo.de> wrote:
> On 12/28/2017 05:03 PM, Andy Shevchenko wrote:
>> On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote:
>>> On 12/21/2017 03:23 PM, Andy Shevchenko wrote:
>>>> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
>>>>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
>>>>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>>>>>>> Cc Alan and Andy.
>>>>>>>
>>>>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke
>>>>>>> wrote:
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320
>>>>>>>> (Atom
>>>>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680.
>>>>>>>> With
>>>
>>> CherryTrail
>
>>>>>> WRT to the messages below it seems we have no platform data for
>>>>>> that
>>>>>> device. It needs to be added.
>>>>>>
>>>
>>> I tried to do exactly this. Extracted some values from
>>> acpidump/acpixtract and dmidecode, but unsure I nailed it.
>>
>> Can you share somewhere it (pastebin.com, gist.github.com, etc)?
>>
>
> https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f
>
> dmidecode gives me
>
> Handle 0x0002, DMI type 2, 17 bytes
> Base Board Information
>         Manufacturer: LENOVO
>         Product Name: LNVNB161216
>         Version: SDK0J91196WIN
>
> what I assume works as identifier in:
> DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216")
>
> 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 87216bc35648..716be4ace60e 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
> @@ -503,6 +503,18 @@ static struct gmin_cfg_var cht_cr_vars[] = {
>         {},
>  };
>
> +static struct gmin_cfg_var miix320_vars[] = {
> +        {"OVTI2680:00_CamType", "1"},
> +        {"OVTI2680:00_CsiPort", "0"},
> +        {"OVTI2680:00_CsiLanes", "1"},
> +        {"OVTI2680:00_CsiFmt", "15"},
> +        {"OVTI2680:00_CsiBayer", "0"},
> +        {"OVTI2680:00_CamClk", "1"},
> +        {"OVTI2680:00_Regulator1p8v", "0"},
> +        {"OVTI2680:00_Regulator2p8v", "0"},
> +        {},
> +};
> +
>  static struct gmin_cfg_var mrd7_vars[] = {
>         {"INT33F8:00_CamType", "1"},
>         {"INT33F8:00_CsiPort", "1"},
> @@ -566,6 +578,13 @@ static const struct dmi_system_id gmin_vars[] = {
>                 },
>                 .driver_data = cht_cr_vars,
>                 },
> +       {
> +                .ident = "MIIX320",
> +                .matches = {
> +                        DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
> +                },
> +                .driver_data = miix320_vars,
> +        },
>         {
>                 .ident = "MRD7",
>                 .matches = {
>
>>> After your set of patches I applied the CherryTrail support I found
>>> here
>>> https://github.com/croutor/atomisp2401

Hmm... Missed this URL.

Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a
little confusion.
The PMIC driver should work via ACPI OpRegion macro (and should be
enabled in kernel configuration). That's how it supposed to work.
The patch seems redundant.

Anyway, nice finding, I guess we need to include Vincent to this discussion.

>> Second, apply

>> Third, you need to change pmic_id to be PMIC_AXP (I have longer patch
>> for this, that's why don't post here). Just hard code it for now in gmin
>> file.

> I assume the given patch set does already what you suggest here, apart
> from the DDEBUG DEFINE.

No, those are completely ugly hacks to prevent driver fail on probing.

>> Fourth, you have to be sure the clock rate is chosen correctly
>> (currently there is a bug in clk_set_rate() where parameter is clock
>> source index instead of frequency!). I think you need to hardcode
>> 19200000 there instead of gs->clock_src.
>
> I found nothing about this in the patch set, so I will do this manually.

Yep, there is none in the wild to address this issue.

>> You are expecting /dev/video<N> nodes. /dev/camera is usually a udev's
>> alias against one of /dev/video<N> nodes.
>
> As described by Alan in a later mail, this actually gives me 10
> /dev/video[0-10] nodes, but none producing any images. video4 and
> video10 cause a kernel oops when opened.

The most interesting one is /dev/video0 (capture, i.e. photo).

>>>  Am I on the right track here, or am
>>> I wasting my (and your) time?

>> It's both: track is right and it's waste of time.

> I see your point, Still it feels, as if this could go somewhere.

I hope so, though I didn't try CherryTrail and according to Alan that
is what he had tried on.

>  Anyway,
> thanks for your explanations and the time you invested into this.

You are welcome!

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2018-01-01 12:42               ` Andy Shevchenko
@ 2018-01-02 18:31                 ` Alan Cox
  2018-01-04 17:47                   ` Andy Shevchenko
  0 siblings, 1 reply; 18+ messages in thread
From: Alan Cox @ 2018-01-02 18:31 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Kristian Beilke, Andy Shevchenko, Sakari Ailus,
	Linux Media Mailing List, Alan Cox, Hans de Goede

> Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a
> little confusion.
> The PMIC driver should work via ACPI OpRegion macro (and should be
> enabled in kernel configuration). That's how it supposed to work.
> The patch seems redundant.

I am fairly sure it is meant to work that way - but it doesn't. At least
not at the moment.

> > I see your point, Still it feels, as if this could go somewhere.  
> 
> I hope so, though I didn't try CherryTrail and according to Alan that
> is what he had tried on.

It's what we are currently trying on. I can fire up the ISP and actually
get interrupts from it, but not much more at this point.

Alan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2018-01-02 18:31                 ` Alan Cox
@ 2018-01-04 17:47                   ` Andy Shevchenko
  0 siblings, 0 replies; 18+ messages in thread
From: Andy Shevchenko @ 2018-01-04 17:47 UTC (permalink / raw)
  To: Alan Cox, Andy Shevchenko
  Cc: Kristian Beilke, Sakari Ailus, Linux Media Mailing List,
	Alan Cox, Hans de Goede

On Tue, 2018-01-02 at 18:31 +0000, Alan Cox wrote:
> > Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a
> > little confusion.
> > The PMIC driver should work via ACPI OpRegion macro (and should be
> > enabled in kernel configuration). That's how it supposed to work.
> > The patch seems redundant.
> 
> I am fairly sure it is meant to work that way - but it doesn't. At
> least
> not at the moment.

Hmm... At least I see writes to PMIC on my side through OpRegion driver.

(Assuming my ugly hack patches applied)

> > > I see your point, Still it feels, as if this could go somewhere.  
> > 
> > I hope so, though I didn't try CherryTrail and according to Alan
> > that
> > is what he had tried on.
> 
> It's what we are currently trying on. I can fire up the ISP and
> actually
> get interrupts from it, but not much more at this point.

Seems you are ahead of everyone who is trying AtomISP till now.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-30 21:10             ` Alan Cox
@ 2018-01-04 17:52               ` Andy Shevchenko
  2018-01-17 13:52                 ` Alan Cox
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Shevchenko @ 2018-01-04 17:52 UTC (permalink / raw)
  To: Alan Cox; +Cc: Kristian Beilke, Sakari Ailus, linux-media, alan

On Sat, 2017-12-30 at 21:10 +0000, Alan Cox wrote:
> > AFAIR Alan has CHT hardware he is developing / testing on.
> 
> I have a loaned board from the company Vincent (who did the intial
> patches) works for. At the moment it's loading firmware, finding
> cameras
> doing power management but not transferring images.
> 
> Unfortunately because of the design of the driver and firmware at the
> moment we are reduced to analyzing all the structs by hand between
> multiple different driver releases, and playing games to try and find
> out
> why various things are not matching up (assuming the firmware we have
> will actually work with the Windows tablet in question in the first
> place).

Maybe we need start over, i.e. find a (presumable old) kernel with
driver _and_ corresponding firmware _and_ hardware it supports to start
with...

> It's nasty because there are complex structs shared between the
> firmware
> and the OS, and in at least one spot the supposedly 'pristine' CHT
> driver
> that was used for the merge we now know could never have worked
> because
> it mismatched its own firmware !

Argh!

> On BYT I can't currently do much as my latest Intel Android tablet has
> died and it's getting hard to find more because I guess the rest of
> those
> made have also died.

I have MRD7 with some BIOS on it I even don't know if there is any newer
still available inside.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2017-12-30 20:57     ` Alan Cox
@ 2018-01-04 17:58       ` Andy Shevchenko
  0 siblings, 0 replies; 18+ messages in thread
From: Andy Shevchenko @ 2018-01-04 17:58 UTC (permalink / raw)
  To: Alan Cox; +Cc: Sakari Ailus, Kristian Beilke, linux-media, alan

On Sat, 2017-12-30 at 20:57 +0000, Alan Cox wrote:
> On Tue, 19 Dec 2017 22:37:01 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:

> > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320
> > > > (Atom
> > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > > kernel
> > > > 4.14.4 and 4.15rc3 I see the following dmesg output:  
> > 
> > It seems I forgot to send the rest of the patches I did while ago
> > against AtomISP code.
> > 
> > It includes switch to normal DMI matching instead of the crap we
> > have
> > there right now.
> 
> The current code expects to be booted on an Android (or ex Android)
> tablet. In which case the various values are buried in the EFI as
> you'd
> expect.

Yes, the logic is left untouched, the code has been cleaned up and allow
to use more natural DMI matching table.

> > WRT to the messages below it seems we have no platform data for that
> > device. It needs to be added.
> 
> Or we need to learn how to parse the ACPI data - except that at least
> on
> some devices the ACPI data is at least half fictional so it's not
> clear
> what the Windows driver really does.

...if we have any specs inside how that ACPI table was being populated.


> > Version string: irci_stable_candrpv_0415_20150423_1753
> > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
> 
> I'll send you a copy: (unfortunately for non Intel people I've not
> managed to get enough people to care about this to get permission to
> put
> the firmware in the public repository ... yet.....)

I've tried firmware with a version that matches the driver, still same
result. I got only "statistics" IRQs (0x20 by value)

$ head -z -n1 shisp_2400b0_v21.bin
irci_stable_candrpv_0415_20150521_0458

$ sha1sum shisp_2400b0_v21.bin
358d7cd31b2e35b6f812c5bdfc0bc28cc23ce674 shisp_2400b0_v21.bin

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [BUG] atomisp_ov2680 not initializing correctly
  2018-01-04 17:52               ` Andy Shevchenko
@ 2018-01-17 13:52                 ` Alan Cox
  0 siblings, 0 replies; 18+ messages in thread
From: Alan Cox @ 2018-01-17 13:52 UTC (permalink / raw)
  To: Andy Shevchenko, Alan Cox; +Cc: Kristian Beilke, Sakari Ailus, linux-media


> Maybe we need start over, i.e. find a (presumable old) kernel with
> driver _and_ corresponding firmware _and_ hardware it supports to
> start
> with...

You can do that with Intel aero and then in theory port the relevant
headers into the updated driver. I've actually been closely comparing
them to see what ships but for the past few months I got dragged off it
for the most part onto the security work.

Alan

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2018-01-17 13:53 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-16 15:50 [BUG] atomisp_ov2680 not initializing correctly Kristian Beilke
2017-12-19 12:00 ` Sakari Ailus
2017-12-19 20:37   ` Andy Shevchenko
2017-12-20  7:13     ` Kristian Beilke
2017-12-21 12:54     ` Kristian Beilke
2017-12-21 14:23       ` Andy Shevchenko
2017-12-23  0:31         ` Kristian Beilke
2017-12-28 16:03           ` Andy Shevchenko
2017-12-29 19:38             ` Andy Shevchenko
2017-12-30 21:10             ` Alan Cox
2018-01-04 17:52               ` Andy Shevchenko
2018-01-17 13:52                 ` Alan Cox
2017-12-31 15:19             ` Kristian Beilke
2018-01-01 12:42               ` Andy Shevchenko
2018-01-02 18:31                 ` Alan Cox
2018-01-04 17:47                   ` Andy Shevchenko
2017-12-30 20:57     ` Alan Cox
2018-01-04 17:58       ` Andy Shevchenko

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.