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: > > > Em Fri, 1 May 2020 19:31:05 +0200 > > Patrik Gfeller <patrik.gfeller@xxxxxxxxx> escreveu: > > > > 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. 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. > > > 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. Ok. > > 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; Same year as what we had. Just a little older. Yeah, some things there could work. > 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). > > > [ 9.691775] cpu_latency_qos_update_request called for unknown object 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
