Re: atomisp kernel driver(s)

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

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

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

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

Just be sure to do something like:

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

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

Regards,
Mauro