Em Sat, 2 May 2020 11:20:04 +0200 Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu: > On 02.05.20 10:15, Patrik Gfeller wrote: > > On Fri, 1 May 2020 21:30:23 +0200 > > Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > > > >> Em Fri, 1 May 2020 19:31:05 +0200 > >> Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu: > >> > >>> On Fri, 1 May 2020 11:38:12 +0200 > >>> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> 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@xxxxxxxxx> > >> 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
