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
