Re: atomisp kernel driver(s)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2 May 2020 11:34:14 +0200
Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:

> Em Sat, 2 May 2020 10:15:42 +0200
> Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu:
> 
> > On Fri, 1 May 2020 21:30:23 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:
> >   
>  [...]  
> 
>  [...]  
> > 
> > Cool, the code might give additional information.  
> 
> Yes. And, as it was released from Intel for a specific device,
> it should very likely work for the model supported there (with
> the Yocto 4.4 Kernel). So, it could be valuable to help identifying
> if some of the cleanup patches would have broken something.
> 
> ON a quick look, it sounds that such build was is targeted for
> ISP2401:
> 
> 	+++ b/drivers/media/pci/atomisp/Makefile
> 	@@ -0,0 +1 @@
> 	+obj-$(CONFIG_VIDEO_ATOMISP) += css2401a0_v21_build/
> 
> > I've also send a
> > request regarding the firmware and HW documentation to the author and
> > the engineers that signed the patch. The firmware in the patch has a
> > different version string and the size is surprisingly a few MB bigger
> > than the one I used for the first experiment.   
> 
> There are some vendors that generate a firmware together with a source
> code. This could be the case here. That's my feeling when looking into
> a file like:
> 
> 	drivers/staging/media/atomisp/pci/css_2401_system/spmem_dump.c
> 
> Which contains lots of addresses that it is different betwen 2401 and
> 2400.
> 
> If so, using a different firmware version will likely cause at least
> some parts of the driver to fail.
> 
> 
> > I'll give that one a try as well.
> >   
>  [...]  
> > 
> > It looks a this firmware is for the 2400 variant; I could also not
> > extract the irci version string. Thus I'll not try them for the moment
> > to perform experiments.  
> 
> Ok.
> 
>  [...]  
> > 
> > It identifies itself as irci_stable_bw10p_0518_20150801_0537;   
> 
> Same year as what we had. Just a little older. Yeah, some things there
> could work.

I found another place where the irci_stable_bw10p_0518_20150801_0537
firmware is used together with patches for atomisp 2401. So I assume the
code there matches this firmware. Eventually some of the patches listed
there can be used as information source:

https://github.com/croutor/atomisp2401

> 
> > I'll give
> > that one a try first. As usual it will unfortunately take some time
> > until I get back to you with the results, as every experiment takes
> > many hours (building the kernel on what is essentially a tablet takes
> > time).  
> 
> I would suggest you to build on some other machine. Btw, you don't need
> to build everything every time. If you build atomisp as a module, you
> could do, instead:
> 
> 	$ make modules_prepare && make M=drivers/staging/media/atomisp
> 
> This will build just the new module(s).
> 
>  [...]  
> 
> Btw, the patch I send earlier today should fix this issue.
> 
> -
> 
> I need to understand a little bit more about how ACPI is supposed to
> detect and register regulators. While using regulators with DT is very
> common, not many places use it for ACPI. 
> 
> I'm suspecting that, before being able of calling regulator_get(),
> the code should use some match logic to get the regulators on this
> board and call regulator_register().
> 
> Please run this command on your tablet:
> 
> 	$ sudo cat /sys/kernel/debug/regulator/supply_map
> 
> If this returns nothing - as I suspect - then calling regulator_get()
> won't be doing anything. 
> 
> Thanks,
> Mauro

with kind regards,
Patrik



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux