All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrik Gfeller <patrik.gfeller@gmail.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linux-media@vger.kernel.org
Subject: Re: atomisp kernel driver(s)
Date: Sat, 2 May 2020 11:20:04 +0200	[thread overview]
Message-ID: <0241bafc-d392-3848-852a-b9ebca1664a0@gmail.com> (raw)
In-Reply-To: <20200502101542.2972010a@ASUS>


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


  reply	other threads:[~2020-05-02  9:20 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0241bafc-d392-3848-852a-b9ebca1664a0@gmail.com \
    --to=patrik.gfeller@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.