Message ID | 1514476996.7000.437.camel@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
+Cc Hans. On Thu, 2017-12-28 at 18:03 +0200, Andy Shevchenko wrote: > On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote: > > On 12/21/2017 03:23 PM, Andy Shevchenko wrote: I spend more time on investigating some additional stuff Sakari gave me, but no result so far. So, the verbose debug output is here: https://pastebin.com/RUV8gsUJ Can anyone tell what's going on? Note the idle state between 803s - 806s. I pressed Ctrl+C there since no expected IRQ came. So, was it ever tested on Baytrail??? Who can debug this properly? For now it's a quite waste of time. I doubt I want to do anything anymore for this. Consider I'm in postponed state until there will be a *proven* way to test it. Otherwise, I'm voting 10x times to remove this driver from upstream for good. P.S. Happy New Year, everyone!
> AFAIR Alan has CHT hardware he is developing / testing on. I have a loaned board from the company Vincent (who did the intial patches) works for. At the moment it's loading firmware, finding cameras doing power management but not transferring images. Unfortunately because of the design of the driver and firmware at the moment we are reduced to analyzing all the structs by hand between multiple different driver releases, and playing games to try and find out why various things are not matching up (assuming the firmware we have will actually work with the Windows tablet in question in the first place). It's nasty because there are complex structs shared between the firmware and the OS, and in at least one spot the supposedly 'pristine' CHT driver that was used for the merge we now know could never have worked because it mismatched its own firmware ! On BYT I can't currently do much as my latest Intel Android tablet has died and it's getting hard to find more because I guess the rest of those made have also died. > > [ 21.120554] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not > > found, using dummy regulator > > [ 21.120587] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd > > not > > found, using dummy regulator It couldn't figure out how to power managed some of the components. > > [ 21.145141] intel_sst_acpi 808622A8:00: LPE base: 0x91400000 > > size:0x200000 > > [ 21.145146] intel_sst_acpi 808622A8:00: IRAM base: 0x914c0000 > > [ 21.145241] intel_sst_acpi 808622A8:00: DRAM base: 0x91500000 > > [ 21.145250] intel_sst_acpi 808622A8:00: SHIM base: 0x91540000 > > [ 21.145262] intel_sst_acpi 808622A8:00: Mailbox base: 0x91544000 > > [ 21.145269] intel_sst_acpi 808622A8:00: DDR base: 0x20000000 > > [ 21.145403] intel_sst_acpi 808622A8:00: Got drv data max stream 25 > > [ 21.892310] atomisp-isp2 0000:00:03.0: Refused to change power > > state, > > currently in D3 > > [ 21.904537] OVTI2680:00: > > ov2680_s_parm:run_mode :2000 > > [ 21.919743] atomisp-isp2 0000:00:03.0: Refused to change power > > state, > > currently in D3 > > [ 21.930399] OVTI2680:00: > > ov2680_s_parm:run_mode :2000 > > [ 21.956479] atomisp-isp2 0000:00:03.0: Refused to change power > > state, > > currently in D3 The D3 warnings you can ignore I think. PCI D3 is busted but the native power management should be looking after it. Alan
On 12/28/2017 05:03 PM, Andy Shevchenko wrote: > On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote: >> On 12/21/2017 03:23 PM, Andy Shevchenko wrote: >>> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote: >>>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote: >>>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: >>>>>> Cc Alan and Andy. >>>>>> >>>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke >>>>>> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 >>>>>>> (Atom >>>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680. >>>>>>> With >> >> CherryTrail >>>>> WRT to the messages below it seems we have no platform data for >>>>> that >>>>> device. It needs to be added. >>>>> >> >> I tried to do exactly this. Extracted some values from >> acpidump/acpixtract and dmidecode, but unsure I nailed it. > > Can you share somewhere it (pastebin.com, gist.github.com, etc)? > https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f dmidecode gives me Handle 0x0002, DMI type 2, 17 bytes Base Board Information Manufacturer: LENOVO Product Name: LNVNB161216 Version: SDK0J91196WIN what I assume works as identifier in: DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216") diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c index 87216bc35648..716be4ace60e 100644 --- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c +++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c @@ -503,6 +503,18 @@ static struct gmin_cfg_var cht_cr_vars[] = { {}, }; +static struct gmin_cfg_var miix320_vars[] = { + {"OVTI2680:00_CamType", "1"}, + {"OVTI2680:00_CsiPort", "0"}, + {"OVTI2680:00_CsiLanes", "1"}, + {"OVTI2680:00_CsiFmt", "15"}, + {"OVTI2680:00_CsiBayer", "0"}, + {"OVTI2680:00_CamClk", "1"}, + {"OVTI2680:00_Regulator1p8v", "0"}, + {"OVTI2680:00_Regulator2p8v", "0"}, + {}, +}; + static struct gmin_cfg_var mrd7_vars[] = { {"INT33F8:00_CamType", "1"}, {"INT33F8:00_CsiPort", "1"}, @@ -566,6 +578,13 @@ static const struct dmi_system_id gmin_vars[] = { }, .driver_data = cht_cr_vars, }, + { + .ident = "MIIX320", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"), + }, + .driver_data = miix320_vars, + }, { .ident = "MRD7", .matches = { >> After your set of patches I applied the CherryTrail support I found >> here >> https://github.com/croutor/atomisp2401 >> > > I have few hacks on top of this. > > First of all, take a base as atomisp branch of sakari's media_tree > repository: > > https://git.linuxtv.org/sailus/media_tree.git/ > I updated the mentioned patches by Vincent Hervieux to apply cleanly on the media_tree atomisp branch. https://github.com/jdkbx/atomisp2401 > Second, apply > > --- a/drivers/staging/media/atomisp/platform/intel- > mid/atomisp_gmin_platform.c > +++ b/drivers/staging/media/atomisp/platform/intel- > mid/atomisp_gmin_platform.c > @@ -499,6 +499,7 @@ static int gmin_v1p8_ctrl(struct v4l2_subdev > *subdev, int on) > return regulator_disable(gs->v1p8_reg); > } > > +return 0; > return -EINVAL; > } > > @@ -535,6 +536,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev > *subdev, int on) > return regulator_disable(gs->v2p8_reg); > } > > +return 0; > return -EINVAL; > } > > --- > a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c > +++ > b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c > @@ -184,6 +184,7 @@ sh_css_check_firmware_version(const char *fw_data) > firmware_header = (struct firmware_header *)fw_data; > file_header = &firmware_header->file_header; > > +return true; > if (strcmp(file_header->version, release_version) != 0) { > return false; > > --- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile > +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile > @@ -348,6 +348,8 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST > -DHRT_USE_VIR_ADDRS -D__HOST__ > #DEFINES += -DPUNIT_CAMERA_BUSY > #DEFINES += -DUSE_KMEM_CACHE > > +DEFINES += -DDEBUG > + > DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0 > > For CHT you have to change define in this file to 2401 here and line > below AFAIU (never did this). > > Third, you need to change pmic_id to be PMIC_AXP (I have longer patch > for this, that's why don't post here). Just hard code it for now in gmin > file. > I assume the given patch set does already what you suggest here, apart from the DDEBUG DEFINE. > Fourth, you have to be sure the clock rate is chosen correctly > (currently there is a bug in clk_set_rate() where parameter is clock > source index instead of frequency!). I think you need to hardcode > 19200000 there instead of gs->clock_src. I found nothing about this in the patch set, so I will do this manually. >> I am still not sure the FW gets loaded, and there is still no >> /dev/camera, but it looks promising. > > You may add a debug print in necessary function inside ->probe (in > atomisp_v4l2.c). I dont't remember if -DDEBUG will enable something like > that. Perhaps. Thats what I will do next. > You are expecting /dev/video<N> nodes. /dev/camera is usually a udev's > alias against one of /dev/video<N> nodes. As described by Alan in a later mail, this actually gives me 10 /dev/video[0-10] nodes, but none producing any images. video4 and video10 cause a kernel oops when opened. [ 425.667704] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8 [ 425.667761] IP: atomisp_g_parm+0x4a/0x80 [atomisp] [ 425.667765] PGD 0 P4D 0 [ 425.667771] Oops: 0000 [#1] SMP [ 425.667776] Modules linked in: rfcomm bnep snd_soc_sst_cht_bsw_rt5645 wmi_bmof cmdlinepart intel_spi_platform intel_spi spi_nor mtd snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_atom_hifi2_platform snd_soc_acpi snd_soc_rt5645 snd_soc_acpi_intel_match gpio_keys snd_soc_rl6231 nls_iso8859_1 intel_rapl intel_powerclamp coretemp punit_atom_debug intel_cstate iwlmvm mac80211 axp288_fuel_gauge extcon_axp288 axp288_charger axp288_adc axp20x_pek cdc_mbim cdc_wdm cdc_ncm usbnet joydev mii hid_multitouch iwlwifi input_leds btusb btrtl btbcm btintel atomisp(C) bluetooth cfg80211 mei_txe mei lpc_ich videobuf_vmalloc processor_thermal_device shpchp videobuf_core intel_soc_dts_iosf snd_seq_midi snd_seq_midi_event snd_rawmidi snd_soc_core snd_seq snd_compress ac97_bus snd_pcm_dmaengine bmc150_accel_i2c dw_dmac [ 425.667850] bmc150_accel_core dw_dmac_core industrialio_triggered_buffer snd_pcm kfifo_buf industrialio atomisp_ov2680(C) snd_seq_device v4l2_common snd_timer videodev snd media soundcore pwm_lpss_platform 8250_dw tpm_crb spi_pxa2xx_platform pwm_lpss wmi acpi_pad int3403_thermal int3400_thermal int340x_thermal_zone acpi_thermal_rel soc_button_array intel_int0002_vgpio parport_pc ppdev lp parport ip_tables x_tables hid_generic usbhid dm_crypt mmc_block i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm video i2c_hid hid sdhci_acpi sdhci [ 425.667909] CPU: 1 PID: 2385 Comm: mplayer Tainted: G C 4.15.0-rc3 #5 [ 425.667912] Hardware name: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW 09/11/2017 [ 425.667949] RIP: 0010:atomisp_g_parm+0x4a/0x80 [atomisp] [ 425.667952] RSP: 0018:ffffaca6c2917c90 EFLAGS: 00010246 [ 425.667957] RAX: 0000000000000000 RBX: ffff9b50343aeea0 RCX: ffffffffc0a872c0 [ 425.667960] RDX: ffff9b4ff816c140 RSI: 0000000000000000 RDI: ffff9b50343aeea0 [ 425.667963] RBP: ffff9b5036075200 R08: ffffffffc0a87200 R09: ffff9b5038843300 [ 425.667965] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b5038843c80 [ 425.667968] R13: 0000000000000000 R14: 00000000000000cc R15: ffff9b50332d5e00 [ 425.667972] FS: 00007fbc6ba72440(0000) GS:ffff9b503fc80000(0000) knlGS:0000000000000000 [ 425.667976] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 425.667979] CR2: 00000000000000b8 CR3: 0000000175f4b000 CR4: 00000000001006e0 [ 425.667982] Call Trace: [ 425.668001] ? v4l_g_parm+0x54/0xd0 [videodev] [ 425.668014] ? __video_do_ioctl+0x34d/0x360 [videodev] [ 425.668022] ? path_openat+0x5bb/0x1620 [ 425.668028] ? _cond_resched+0x15/0x40 [ 425.668034] ? __kmalloc_node+0x1ea/0x2a0 [ 425.668046] ? video_ioctl2+0x20/0x20 [videodev] [ 425.668058] ? video_usercopy+0x97/0x5b0 [videodev] [ 425.668071] ? v4l2_ioctl+0xbb/0xe0 [videodev] [ 425.668076] ? do_vfs_ioctl+0xa4/0x630 [ 425.668081] ? SyS_ioctl+0x7c/0x90 [ 425.668087] ? entry_SYSCALL_64_fastpath+0x1e/0x81 [ 425.668091] Code: 01 4c 8b a0 78 09 00 00 48 8b 9b 50 02 00 00 75 2f 48 81 c3 88 0e 00 00 48 89 df e8 f1 51 d6 ec 49 8b 84 24 c0 44 00 00 48 8d 3b <8b> 80 b8 00 00 00 89 45 08 e8 78 4d d6 ec 31 c0 5b 5d 41 5c c3 [ 425.668185] RIP: atomisp_g_parm+0x4a/0x80 [atomisp] RSP: ffffaca6c2917c90 [ 425.668188] CR2: 00000000000000b8 [ 425.668237] ---[ end trace fb76f36afd55319e ]--- [ 425.672735] ------------[ cut here ]------------ [ 425.672748] rtmutex deadlock detected [ 425.672767] WARNING: CPU: 1 PID: 2385 at kernel/locking/rtmutex.h:28 rt_mutex_slowlock+0x176/0x1e0 [ 425.672771] Modules linked in: rfcomm bnep snd_soc_sst_cht_bsw_rt5645 wmi_bmof cmdlinepart intel_spi_platform intel_spi spi_nor mtd snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_atom_hifi2_platform snd_soc_acpi snd_soc_rt5645 snd_soc_acpi_intel_match gpio_keys snd_soc_rl6231 nls_iso8859_1 intel_rapl intel_powerclamp coretemp punit_atom_debug intel_cstate iwlmvm mac80211 axp288_fuel_gauge extcon_axp288 axp288_charger axp288_adc axp20x_pek cdc_mbim cdc_wdm cdc_ncm usbnet joydev mii hid_multitouch iwlwifi input_leds btusb btrtl btbcm btintel atomisp(C) bluetooth cfg80211 mei_txe mei lpc_ich videobuf_vmalloc processor_thermal_device shpchp videobuf_core intel_soc_dts_iosf snd_seq_midi snd_seq_midi_event snd_rawmidi snd_soc_core snd_seq snd_compress ac97_bus snd_pcm_dmaengine bmc150_accel_i2c dw_dmac [ 425.672845] bmc150_accel_core dw_dmac_core industrialio_triggered_buffer snd_pcm kfifo_buf industrialio atomisp_ov2680(C) snd_seq_device v4l2_common snd_timer videodev snd media soundcore pwm_lpss_platform 8250_dw tpm_crb spi_pxa2xx_platform pwm_lpss wmi acpi_pad int3403_thermal int3400_thermal int340x_thermal_zone acpi_thermal_rel soc_button_array intel_int0002_vgpio parport_pc ppdev lp parport ip_tables x_tables hid_generic usbhid dm_crypt mmc_block i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm video i2c_hid hid sdhci_acpi sdhci [ 425.672906] CPU: 1 PID: 2385 Comm: mplayer Tainted: G D C 4.15.0-rc3 #5 [ 425.672909] Hardware name: LENOVO 80XF/LNVNB161216, BIOS 5HCN31WW 09/11/2017 [ 425.672913] RIP: 0010:rt_mutex_slowlock+0x176/0x1e0 [ 425.672916] RSP: 0018:ffffaca6c2917c88 EFLAGS: 00010046 [ 425.672921] RAX: 0000000000000000 RBX: ffff9b50343aeea0 RCX: 0000000000000006 [ 425.672924] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff9b503fc8cdd0 [ 425.672927] RBP: ffffaca6c2917ca0 R08: 0000000000000382 R09: 000000000000000f [ 425.672930] R10: 0000000000000000 R11: ffffffffae3e0e0d R12: 0000000000000000 [ 425.672933] R13: 0000000000000002 R14: 00000000ffffffdd R15: 0000000000000000 [ 425.672937] FS: 0000000000000000(0000) GS:ffff9b503fc80000(0000) knlGS:0000000000000000 [ 425.672945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 425.672948] CR2: 00000000000000b8 CR3: 0000000167808000 CR4: 00000000001006e0 [ 425.672951] Call Trace: [ 425.673008] ? atomisp_release+0x8f/0x520 [atomisp] [ 425.673016] ? kmem_cache_free+0x195/0x1c0 [ 425.673033] ? v4l2_release+0x30/0x80 [videodev] [ 425.673038] ? __fput+0xd8/0x210 [ 425.673046] ? task_work_run+0x89/0xb0 [ 425.673052] ? do_exit+0x2ed/0xb30 [ 425.673058] ? rewind_stack_do_exit+0x17/0x20 [ 425.673062] Code: 48 8d 75 00 48 8d 3b e8 f9 09 3f ff 41 83 fe dd 0f 85 70 ff ff ff 45 85 ff 0f 85 67 ff ff ff 48 c7 c7 99 04 bb ad e8 9a f5 39 ff <0f> ff 48 c7 44 24 10 01 00 00 00 65 48 8b 14 25 40 c4 00 00 48 [ 425.673123] ---[ end trace fb76f36afd55319f ]--- >> Am I on the right track here, or am >> I wasting my (and your) time? > > It's both: track is right and it's waste of time. > I see your point, Still it feels, as if this could go somewhere. Anyway, thanks for your explanations and the time you invested into this. Happy New Year to everyone.
On Sun, Dec 31, 2017 at 5:19 PM, Kristian Beilke <beilke@posteo.de> wrote: > On 12/28/2017 05:03 PM, Andy Shevchenko wrote: >> On Sat, 2017-12-23 at 01:31 +0100, Kristian Beilke wrote: >>> On 12/21/2017 03:23 PM, Andy Shevchenko wrote: >>>> On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote: >>>>> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote: >>>>>> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote: >>>>>>> Cc Alan and Andy. >>>>>>> >>>>>>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke >>>>>>> wrote: >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 >>>>>>>> (Atom >>>>>>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680. >>>>>>>> With >>> >>> CherryTrail > >>>>>> WRT to the messages below it seems we have no platform data for >>>>>> that >>>>>> device. It needs to be added. >>>>>> >>> >>> I tried to do exactly this. Extracted some values from >>> acpidump/acpixtract and dmidecode, but unsure I nailed it. >> >> Can you share somewhere it (pastebin.com, gist.github.com, etc)? >> > > https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f > > dmidecode gives me > > Handle 0x0002, DMI type 2, 17 bytes > Base Board Information > Manufacturer: LENOVO > Product Name: LNVNB161216 > Version: SDK0J91196WIN > > what I assume works as identifier in: > DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216") > > diff --git > a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > index 87216bc35648..716be4ace60e 100644 > --- > a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > +++ > b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c > @@ -503,6 +503,18 @@ static struct gmin_cfg_var cht_cr_vars[] = { > {}, > }; > > +static struct gmin_cfg_var miix320_vars[] = { > + {"OVTI2680:00_CamType", "1"}, > + {"OVTI2680:00_CsiPort", "0"}, > + {"OVTI2680:00_CsiLanes", "1"}, > + {"OVTI2680:00_CsiFmt", "15"}, > + {"OVTI2680:00_CsiBayer", "0"}, > + {"OVTI2680:00_CamClk", "1"}, > + {"OVTI2680:00_Regulator1p8v", "0"}, > + {"OVTI2680:00_Regulator2p8v", "0"}, > + {}, > +}; > + > static struct gmin_cfg_var mrd7_vars[] = { > {"INT33F8:00_CamType", "1"}, > {"INT33F8:00_CsiPort", "1"}, > @@ -566,6 +578,13 @@ static const struct dmi_system_id gmin_vars[] = { > }, > .driver_data = cht_cr_vars, > }, > + { > + .ident = "MIIX320", > + .matches = { > + DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"), > + }, > + .driver_data = miix320_vars, > + }, > { > .ident = "MRD7", > .matches = { > >>> After your set of patches I applied the CherryTrail support I found >>> here >>> https://github.com/croutor/atomisp2401 Hmm... Missed this URL. Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a little confusion. The PMIC driver should work via ACPI OpRegion macro (and should be enabled in kernel configuration). That's how it supposed to work. The patch seems redundant. Anyway, nice finding, I guess we need to include Vincent to this discussion. >> Second, apply >> Third, you need to change pmic_id to be PMIC_AXP (I have longer patch >> for this, that's why don't post here). Just hard code it for now in gmin >> file. > I assume the given patch set does already what you suggest here, apart > from the DDEBUG DEFINE. No, those are completely ugly hacks to prevent driver fail on probing. >> Fourth, you have to be sure the clock rate is chosen correctly >> (currently there is a bug in clk_set_rate() where parameter is clock >> source index instead of frequency!). I think you need to hardcode >> 19200000 there instead of gs->clock_src. > > I found nothing about this in the patch set, so I will do this manually. Yep, there is none in the wild to address this issue. >> You are expecting /dev/video<N> nodes. /dev/camera is usually a udev's >> alias against one of /dev/video<N> nodes. > > As described by Alan in a later mail, this actually gives me 10 > /dev/video[0-10] nodes, but none producing any images. video4 and > video10 cause a kernel oops when opened. The most interesting one is /dev/video0 (capture, i.e. photo). >>> Am I on the right track here, or am >>> I wasting my (and your) time? >> It's both: track is right and it's waste of time. > I see your point, Still it feels, as if this could go somewhere. I hope so, though I didn't try CherryTrail and according to Alan that is what he had tried on. > Anyway, > thanks for your explanations and the time you invested into this. You are welcome!
> Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a > little confusion. > The PMIC driver should work via ACPI OpRegion macro (and should be > enabled in kernel configuration). That's how it supposed to work. > The patch seems redundant. I am fairly sure it is meant to work that way - but it doesn't. At least not at the moment. > > I see your point, Still it feels, as if this could go somewhere. > > I hope so, though I didn't try CherryTrail and according to Alan that > is what he had tried on. It's what we are currently trying on. I can fire up the ISP and actually get interrupts from it, but not much more at this point. Alan
On Tue, 2018-01-02 at 18:31 +0000, Alan Cox wrote: > > Patch 0003-atomisp_gmin_platform-tweak-to-drive-axp288.patch gives a > > little confusion. > > The PMIC driver should work via ACPI OpRegion macro (and should be > > enabled in kernel configuration). That's how it supposed to work. > > The patch seems redundant. > > I am fairly sure it is meant to work that way - but it doesn't. At > least > not at the moment. Hmm... At least I see writes to PMIC on my side through OpRegion driver. (Assuming my ugly hack patches applied) > > > I see your point, Still it feels, as if this could go somewhere. > > > > I hope so, though I didn't try CherryTrail and according to Alan > > that > > is what he had tried on. > > It's what we are currently trying on. I can fire up the ISP and > actually > get interrupts from it, but not much more at this point. Seems you are ahead of everyone who is trying AtomISP till now.
On Sat, 2017-12-30 at 21:10 +0000, Alan Cox wrote: > > AFAIR Alan has CHT hardware he is developing / testing on. > > I have a loaned board from the company Vincent (who did the intial > patches) works for. At the moment it's loading firmware, finding > cameras > doing power management but not transferring images. > > Unfortunately because of the design of the driver and firmware at the > moment we are reduced to analyzing all the structs by hand between > multiple different driver releases, and playing games to try and find > out > why various things are not matching up (assuming the firmware we have > will actually work with the Windows tablet in question in the first > place). Maybe we need start over, i.e. find a (presumable old) kernel with driver _and_ corresponding firmware _and_ hardware it supports to start with... > It's nasty because there are complex structs shared between the > firmware > and the OS, and in at least one spot the supposedly 'pristine' CHT > driver > that was used for the merge we now know could never have worked > because > it mismatched its own firmware ! Argh! > On BYT I can't currently do much as my latest Intel Android tablet has > died and it's getting hard to find more because I guess the rest of > those > made have also died. I have MRD7 with some BIOS on it I even don't know if there is any newer still available inside.
> Maybe we need start over, i.e. find a (presumable old) kernel with > driver _and_ corresponding firmware _and_ hardware it supports to > start > with... You can do that with Intel aero and then in theory port the relevant headers into the updated driver. I've actually been closely comparing them to see what ships but for the past few months I got dragged off it for the most part onto the security work. Alan
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile @@ -348,6 +348,8 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST -DHRT_USE_VIR_ADDRS -D__HOST__ #DEFINES += -DPUNIT_CAMERA_BUSY #DEFINES += -DUSE_KMEM_CACHE +DEFINES += -DDEBUG + DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0 For CHT you have to change define in this file to 2401 here and line