[{"id":20647,"web_url":"https://patchwork.libcamera.org/comment/20647/","msgid":"<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","date":"2021-11-01T16:02:58","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"On 10/29/21 13:50, Daniel Scally wrote:\n> Hi all\n> \n> \n> +CC linux-media and libcamera-devel, as it's probably a good time to\n> broaden this out. Also Andy because I'm hoping you can help :) The\n> background of the discussion is about how we identify and enumerate\n> (correctly, I.E. with a type matching the vcm driver's i2c_device_id,\n> and there are a few different vcm's in scope which seem encoded in the\n> SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3\n> centric ACPI tables. The I2C address for the device is just a second\n> I2cSerialBusV2 against the sensor's acpi device rather than a separate\n> one, which is no awkward. We also need to get firmware created for the\n> VCM such that the sensor will link to it via the lens-focus property.\n> \n> On 28/10/2021 09:57, Hans de Goede wrote:\n>> Hi,\n>>\n>> On 10/28/21 10:49, Laurent Pinchart wrote:\n>>> Hi Hans,\n>>>\n>>> On Thu, Oct 28, 2021 at 09:51:08AM +0200, Hans de Goede wrote:\n>>>> On 10/28/21 09:10, Daniel Scally wrote:\n>>>>> On 27/10/2021 15:16, Hans de Goede wrote:\n>>>>>> On 10/27/21 12:07, Daniel Scally wrote:\n>>>>>>> On 26/10/2021 11:14, Hans de Goede wrote:\n>>>>>>>>>> So yesterday I already sorta guessed it would be the DW9714 because of\n>>>>>>>>>> the 0x0c address and I tried:\n>>>>>>>>>>\n>>>>>>>>>> i2ctransfer -y 2 w2@0x0c 0x00 0x00\n>>>>>>>>>>\n>>>>>>>>>> And the transfer fails, while according to the driver that is a valid\n>>>>>>>>>> value. So maybe we are missing a regulator enable? Or its not a DW9714.\n>>>>>>>>>>\n>>>>>>>>>> Also \"i2cdetect -y -r 2\" does not see anything at address 0x0c (but some of\n>>>>>>>>>> these VCMs seem to be write only...) it does OTOH see an unknown device at\n>>>>>>>>>> address 0x21.\n>>>>>>>>> Well, when debugging the necessary TPS68470 settings I used a poor man's\n>>>>>>>>> i2ctransfer on Windows whilst the camera was running to read the values\n>>>>>>>>> that were set for both the PMIC and the camera sensor. Using the same\n>>>>>>>>> program I can connect to and read values from a device at 0x0c,\n>>>>>>> Just as further testing I dumped the contents of the device at 0x0c,\n>>>>>>> which comes back as\n>>>>>>>\n>>>>>>> f1 1 2 1 61 0 40 60\n>>>>>>>\n>>>>>>> Byte 0 is given in the driver you linked as the ID field and expected to\n>>>>>>> be f1. The driver controls focus by writing to the 3rd and 4th byte\n>>>>>>> (with the 4th being the LSB); the only value that seemed to fluctuate\n>>>>>>> when running windows and moving my hand in front of the sensor was byte\n>>>>>>> 4 and testing it out I wrote values into that byte and the focus\n>>>>>>> changes. So the device at 0x0c is definitely the vcm and it sure looks\n>>>>>>> like it's the DW9719\n>>>>>>>\n>>>>>>> The device at 0x21 is only available on Windows when the camera is\n>>>>>>> running, I thought it was quite likely that one of the \"spare\"\n>>>>>>> regulators from the TPS68470. One line is called VCM, and sure enough\n>>>>>>> it's enabled whilst the world-facing camera is running. I switched to\n>>>>>>> linux and started streaming the back camera, then enabled that voltage\n>>>>>>> regulator via i2ctransfer:\n>>>>>>>\n>>>>>>> sudo i2ctransfer 2 w2@0x4d 0x3c 0x6d\n>>>>>>>\n>>>>>>> sudo i2ctransfer 2 w2@0x4d 0x44 0x01\n>>>>>>>\n>>>>>>> And now i2cdetect shows the device at 0x0c on bus 2 - so we need more\n>>>>>>> jiggery pokey to map that VCM regulator to this new device (once we've\n>>>>>>> gotten it enumerated...) and the driver needs to have a tweak to call\n>>>>>>> regulator get and do a power on at some point.\n>>>>>> Awesome, great job on figuring this out!\n>>>>>>\n>>>>>> As you know I can spend $dayjob time on this, so I'll take on the job\n>>>>>> of creating the i2c-client and hooking up the regulator in some\n>>>>>> upstreamable manner.\n>>>>> Okedokey cool. I'd probably start at the cio2-bridge, if only because we\n>>>>> already have the adev there and the SSDB buffer loaded, so should be\n>>>>> easy enough to add an enum for the vcm_type and a call to\n>>>>> i2c_acpi_new_device()...bit of a weird place for that though I guess.\n>>>> Ah, I was actually thinking about doing this int he int3472 code for\n>>>> a number of reasons:\n>>>>\n>>>> 1. We already have the regulator_init_data there and we will need to\n>>>> expand it for this.\n>>>>\n>>>> 2. It is sorta the central place where we deal with all this glue-stuff\n>>> I'm not too sure about that. The INT3472 model the \"Intel camera PMIC\"\n>>> (I don't remember the exact wording, but that's more or less how the\n>>> device is described in Windows, and it matches the intent we see in the\n>>> DSDT).\n>> I agree that the INT3472 models the PMIC, or whatever discrete bits\n>> which offer similar functionality.\n>>\n>>> Given that we already have cio2-bridge, and that it hooks up the\n>>> sensor to the CIO2, it seems to me that it would be a better central\n>>> place.\n>> Ok, I was sorta expecting you to want to keep glue code like this\n>> out of drivers/media. But I guess that only applies to putting ACPI\n>> specific stuff in sensor drivers; and since the cio2-bridge code is\n>> already x86/ACPI specific you are fine with adding ACPI code there?\n>>\n>> I'm fine with putting the VCM i2c-client instantiation in the\n>> cio2-bridge code, that may also make it easier to tie the 2 together\n>> at the media-controller level.\n> \n> \n> Having looked at this yesterday evening I'm more and more convinced it's\n> necessary. I hacked it into the ov8865 driver in the interim (just by\n> calling i2c_acpi_new_device() in probe) and then worked on that dw9719\n> code you found [1] to turn it into an i2c driver (attached, though still\n> needs a bit of work), which will successfully bind to the i2c client\n> enumerated by that i2c_acpi_new_device() call. From there though it\n> needs a way for the v4l2 subdev to be matched to the sensor's subdev.\n> This can happen automatically by way of the lens-focus firmware property\n> against the sensor - we currently build those in the cio2-bridge, so\n> adding another software node for the VCM and creating a lens-focus\n> property for the sensor's software_node with a pointer to the VCM's node\n> seems like the best way to do that.\n\nSo besides prepping a v5 of my previous series, with update regulator\ninit-data for the VCM I've also been looking into this, attached are\nthe results.\n\nSome notes from initial testing:\n\n1. The driver you attached will only successful probe if I insmod\nit while streaming video from the sensor. So I think we need another\nregulator or the clk for just the VCM too, I will investigate this\nlater this week.\n\n2. I need some help with all the fwnode link stuff (I'm not very familiar\nwith this). There seems to be a chicken and egg problem here though,\nbecause the v4l2subdev for the VCM does not register because of async stuff\nand if we add it to the \"graph\" then my idea to enumerate the VCMs\nfrom the SSDB on the complete() callback won't work. But we can do this\non a per sensor basis instead from the cio2_notifier_bound() callback\ninstead I guess ?\n\nCan someone give me some hints how the fwnode link code should look/work\nand how I can get the async registering of the subdev for the VCM to\ncomplete ?\n\nRegards,\n\nHans\n\n\n\n\n> \n> \n> To throw a spanner in the works though; I noticed this delightful _CRS\n> for the OV9734 sensor of a  Surface Laptop 1 earlier:\n> \n> \n> Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n> {\n>     Name (SBUF, ResourceTemplate ()\n>     {\n>         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>     })\n>     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n> }\n\nHmm, we do have i2c_acpi_client_count(adev), so it is easy to use\nthat and just always use the last resource for the VCM. But that assumes\nthat is what is going on here and I have no idea.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 3A18ABDB1C\n\tfor ;\n\tMon, 1 Nov 2021 16:03:07 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8DE9A60159;\n\tMon, 1 Nov 2021 17:03:06 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [216.205.24.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 32D51600C3\n\tfor ;\n\tMon, 1 Nov 2021 17:03:05 +0100 (CET)","from mail-ed1-f70.google.com (mail-ed1-f70.google.com\n\t[209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-399-j5a-AX9TPs2Sx19wtbiyQg-1; Mon, 01 Nov 2021 12:03:01 -0400","by mail-ed1-f70.google.com with SMTP id\n\tz20-20020a05640240d400b003dce046ab51so15952485edb.14\n\tfor ;\n\tMon, 01 Nov 2021 09:03:01 -0700 (PDT)","from [10.40.1.223] ([81.30.35.201])\n\tby smtp.gmail.com with ESMTPSA id\n\tk23sm9096302edv.22.2021.11.01.09.02.58\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 01 Nov 2021 09:02:59 -0700 (PDT)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"dEueUF+a\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1635782583;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=poVw1vHntb/J3CeACZg8LDavFCWD1ev24FU+A8Hue4Y=;\n\tb=dEueUF+a9eGkThgLGlu3iVDauqBebr6mbP6NG4U9RunJ3vlDyZcD/uwmuEiiJzPAcseCWz\n\tHgKXLtpF7LYKyQKMYVFUFWkjODRoVpzGpc3a2s80WEW0kIsuChV/QqHqr31tgaobewYIB8\n\tz841V16Vdo8SIR2eVzATqY8Vhm5fsWc=","X-MC-Unique":"j5a-AX9TPs2Sx19wtbiyQg-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to;\n\tbh=gk5XNKCZbo3Tpz9vz86LjcecgJFzgf9KSoGYskL3Rr0=;\n\tb=0v/iiYZlvOJw71fKXNr/L0jP8h4TpoGMiwhm+KlqNEVQ2yOCh5TFBMBBDX2A4CnffV\n\tkIUFv8nfT0WkZfEF0DjIiMs7O5TVVkp4WTa91kASBAV4XaLTcDrQ8H66KQ9U/MIaQVNx\n\tQT7p/nNj3QIa6a1Zdqhl26jVN98wpVEanbZyCxB4ZSC5XffOQ2siEAHWvHi1Lpl0FpAc\n\t2VKbASRUwYWx+ykK9oy6OYZOTGXcv4uJm05j3sX+Y9ur3BQpsQ4IkOIULXjFYYZky81v\n\tGthz1MNo6cW8EjC7mc6FzpLVtwdRz5hhAYckfn2lu0EJAFj7/Z+AEtnNeYH0bHHfvInq\n\tPbbQ==","X-Gm-Message-State":"AOAM530x/zKhEZp52gKr7Qfck7ZR8rewQK3cXea48SQd2hEyB0P+cqFI\n\tNM0CJy4MKUkety08q8dvfp6/tNvnwr/+4gBR1MN3a2HzUTdx9ZGZRIc7SMbJotabRtobxf+q8h6\n\tsHb+KtDc6xWO4T84vyfZVGWIG+6rrgtnvYQ==","X-Received":["by 2002:a17:907:6d28:: with SMTP id\n\tsa40mr11219022ejc.201.1635782580333; \n\tMon, 01 Nov 2021 09:03:00 -0700 (PDT)","by 2002:a17:907:6d28:: with SMTP id\n\tsa40mr11218981ejc.201.1635782579960; \n\tMon, 01 Nov 2021 09:02:59 -0700 (PDT)"],"X-Google-Smtp-Source":"ABdhPJzW6YgrfXBy489RO00ij8GcnwkDlBZ8Lwu1PsoTR+B2WB3pyGxJyVVLD4kgaEhf9zwWSt2Z9g==","Message-ID":"<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","Date":"Mon, 1 Nov 2021 17:02:58 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>","From":"Hans de Goede ","In-Reply-To":"<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Type":"multipart/mixed;\n\tboundary=\"------------ydTyNLd1yw4W0z7J7a0zsqV0\"","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20648,"web_url":"https://patchwork.libcamera.org/comment/20648/","msgid":"","date":"2021-11-01T15:55:17","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Fri, Oct 29, 2021 at 12:50:31PM +0100, Daniel Scally wrote:\n> Hi all\n> \n> +CC linux-media and libcamera-devel, as it's probably a good time to\n> broaden this out. Also Andy because I'm hoping you can help :) The\n> background of the discussion is about how we identify and enumerate\n> (correctly, I.E. with a type matching the vcm driver's i2c_device_id,\n> and there are a few different vcm's in scope which seem encoded in the\n> SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3\n> centric ACPI tables. The I2C address for the device is just a second\n> I2cSerialBusV2 against the sensor's acpi device rather than a separate\n> one, which is no awkward. We also need to get firmware created for the\n> VCM such that the sensor will link to it via the lens-focus property.\n\n> On 28/10/2021 09:57, Hans de Goede wrote:\n\n...\n\n> To throw a spanner in the works though; I noticed this delightful _CRS\n> for the OV9734 sensor of a  Surface Laptop 1 earlier:\n> \n> Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n> {\n>     Name (SBUF, ResourceTemplate ()\n>     {\n>         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>             0x00, ResourceConsumer, , Exclusive,\n>             )\n>     })\n>     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n> }\n> \n> How do we know which one's the VCM when there's more than just two like\n> that? Andy: don't suppose you can shed any light there?\n\nSeems to me that the order is defined by address and if software engineers are\nnot (so) crazy, it shouldn't deviate from device to device.\n\nAt least this is stated in the internal documentation.\n\nThe order is\n\n1. Sensor (single addr)\n2. VCM (single addr)\n3. EEPROM (addr per page)\n\nInterestingly that your list have no VCM in the _CRS defined...\n\nNot sure how to distinguish that if it's not a typo and indeed the case.\nSounds like DMI quirk :-( again (something like 3-bit flag to define\nwhich devices are present in the _CRS taking into account the ordering\nrequirements).","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 5FBA4BF415\n\tfor ;\n\tMon, 1 Nov 2021 16:16:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 9F600600C3;\n\tMon, 1 Nov 2021 17:16:58 +0100 (CET)","from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 024ED600B2\n\tfor ;\n\tMon, 1 Nov 2021 16:56:25 +0100 (CET)","from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t01 Nov 2021 08:55:37 -0700","from smile.fi.intel.com ([10.237.72.184])\n\tby fmsmga002-auth.fm.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2021 08:55:35 -0700","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mhZeY-002iTw-2o; Mon, 01 Nov 2021 17:55:18 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10154\"; a=\"218232677\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"218232677\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"583024047\""],"Date":"Mon, 1 Nov 2021 17:55:17 +0200","From":"Andy Shevchenko ","To":"Daniel Scally ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","X-Mailman-Approved-At":"Mon, 01 Nov 2021 17:16:56 +0100","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20649,"web_url":"https://patchwork.libcamera.org/comment/20649/","msgid":"","date":"2021-11-01T15:59:44","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Mon, Nov 01, 2021 at 05:55:18PM +0200, Andy Shevchenko wrote:\n> On Fri, Oct 29, 2021 at 12:50:31PM +0100, Daniel Scally wrote:\n> > Hi all\n> > \n> > +CC linux-media and libcamera-devel, as it's probably a good time to\n> > broaden this out. Also Andy because I'm hoping you can help :) The\n> > background of the discussion is about how we identify and enumerate\n> > (correctly, I.E. with a type matching the vcm driver's i2c_device_id,\n> > and there are a few different vcm's in scope which seem encoded in the\n> > SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3\n> > centric ACPI tables. The I2C address for the device is just a second\n> > I2cSerialBusV2 against the sensor's acpi device rather than a separate\n> > one, which is no awkward. We also need to get firmware created for the\n> > VCM such that the sensor will link to it via the lens-focus property.\n> \n> > On 28/10/2021 09:57, Hans de Goede wrote:\n> \n> ...\n> \n> > To throw a spanner in the works though; I noticed this delightful _CRS\n> > for the OV9734 sensor of a  Surface Laptop 1 earlier:\n> > \n> > Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n> > {\n> >     Name (SBUF, ResourceTemplate ()\n> >     {\n> >         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >     })\n> >     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n> > }\n> > \n> > How do we know which one's the VCM when there's more than just two like\n> > that? Andy: don't suppose you can shed any light there?\n> \n> Seems to me that the order is defined by address and if software engineers are\n> not (so) crazy, it shouldn't deviate from device to device.\n> \n> At least this is stated in the internal documentation.\n> \n> The order is\n> \n> 1. Sensor (single addr)\n> 2. VCM (single addr)\n> 3. EEPROM (addr per page)\n> \n> Interestingly that your list have no VCM in the _CRS defined...\n> \n> Not sure how to distinguish that if it's not a typo and indeed the case.\n> Sounds like DMI quirk :-( again (something like 3-bit flag to define\n> which devices are present in the _CRS taking into account the ordering\n> requirements).\n\nHold on, there is a way out!\n\nSSDB has fields:\n\n\tu8 romtype;\n\tu8 vcmtype;\n\n0 means no device present.\n\nSo, seems documentation is consistent and no quirks are needed (until\nproven otherwise).","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 14CAFC324E\n\tfor ;\n\tMon, 1 Nov 2021 16:17:00 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id E154660159;\n\tMon, 1 Nov 2021 17:16:58 +0100 (CET)","from mga04.intel.com (mga04.intel.com [192.55.52.120])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 84019600C3\n\tfor ;\n\tMon, 1 Nov 2021 17:07:10 +0100 (CET)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t01 Nov 2021 09:00:03 -0700","from smile.fi.intel.com ([10.237.72.184])\n\tby orsmga004-auth.jf.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2021 09:00:01 -0700","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mhZiq-002iWc-MO; Mon, 01 Nov 2021 17:59:44 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10154\"; a=\"229771648\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"229771648\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"599071289\""],"Date":"Mon, 1 Nov 2021 17:59:44 +0200","From":"Andy Shevchenko ","To":"Daniel Scally ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","X-Mailman-Approved-At":"Mon, 01 Nov 2021 17:16:56 +0100","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20650,"web_url":"https://patchwork.libcamera.org/comment/20650/","msgid":"","date":"2021-11-01T19:51:48","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/1/21 20:18, Andy Shevchenko wrote:\n> On Mon, Nov 01, 2021 at 05:02:58PM +0100, Hans de Goede wrote:\n>> On 10/29/21 13:50, Daniel Scally wrote:\n> \n> ...\n> \n>>> To throw a spanner in the works though; I noticed this delightful _CRS\n>>> for the OV9734 sensor of a  Surface Laptop 1 earlier:\n>>>\n>>> Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n>>> {\n>>>     Name (SBUF, ResourceTemplate ()\n>>>     {\n>>>         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n>>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>>             0x00, ResourceConsumer, , Exclusive,\n>>>             )\n>>>         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n>>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>>             0x00, ResourceConsumer, , Exclusive,\n>>>             )\n>>>         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n>>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>>             0x00, ResourceConsumer, , Exclusive,\n>>>             )\n>>>         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n>>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>>             0x00, ResourceConsumer, , Exclusive,\n>>>             )\n>>>         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n>>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>>             0x00, ResourceConsumer, , Exclusive,\n>>>             )\n>>>     })\n>>>     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n>>> }\n>>\n>> Hmm, we do have i2c_acpi_client_count(adev), so it is easy to use\n>> that and just always use the last resource for the VCM. But that assumes\n>> that is what is going on here and I have no idea.\n> \n> You probably composed this message before reading my reply(ies).\n\nYes, sorry about that; and thank you for your answer the info\nyou provided is very helpful. If I understand things correctly\nwill can just always take the 2nd I2cSerialBusV2 resource entry\nfor the VCM since if there is a VCM that is where its\nI2cSerialBusV2 resource entry will be.\n\n> ...\n> \n>> Change the first parameter of i2c_acpi_new_device() from\n>> a struct device * to a struct acpi_device *.\n>>\n>> This is necessary because in some cases we may only have access\n>> to the fwnode / acpi_device and not to the matching physical-node\n>> struct device *.\n> \n> Can we rather create an fwnode based API and then\n> \n> static inline\n> struct i2c_client *i2c_acpi_new_device(struct device *dev, int index,\n> \t\t\t\t struct i2c_board_info *info)\n> \treturn i2c_acpi_new_device_by_fwnode(dev_fwnode(), index, info);\n> }\n> \n> ?\n\nYes that is a good idea, I'll switch to that in my local tree, so\nv1 (which I will post once I've something working) will have this.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9E895BF415\n\tfor ;\n\tMon, 1 Nov 2021 19:51:55 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id D9C9F600C3;\n\tMon, 1 Nov 2021 20:51:54 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id E61E1600B2\n\tfor ;\n\tMon, 1 Nov 2021 20:51:52 +0100 (CET)","from mail-ed1-f71.google.com (mail-ed1-f71.google.com\n\t[209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-15-8Bmd4Yu8O6qhqVm5Q1jekw-1; Mon, 01 Nov 2021 15:51:50 -0400","by mail-ed1-f71.google.com with SMTP id\n\tv9-20020a50d849000000b003dcb31eabaaso16664045edj.13\n\tfor ;\n\tMon, 01 Nov 2021 12:51:50 -0700 (PDT)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\tu16sm7331189ejy.16.2021.11.01.12.51.48\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 01 Nov 2021 12:51:48 -0700 (PDT)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"cjqT+LfX\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1635796311;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=XF+GUpk7TRN42x7Cxid2d7J7w5atfm+lJIY3Ab+K3mk=;\n\tb=cjqT+LfXfONB8Plkt6pBRThfonC4QsGA6sG+3iF0aiWFR6+cZVpl0kugcruFBvJZ4ZUlf7\n\tMD2lL6ga2vbkcMXpC83sfV7O9oWZMfz/uNUizfMROwrEc12WQqq3ZVFQKlCslLOKdTiTJy\n\teJhz3BzSn3Q4kB+6Oq1lnYjE5r1j/Pc=","X-MC-Unique":"8Bmd4Yu8O6qhqVm5Q1jekw-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=XF+GUpk7TRN42x7Cxid2d7J7w5atfm+lJIY3Ab+K3mk=;\n\tb=rFTD6+I4Of3UnA95dCcYXwuzps6SxL+5TIAR6fOMB1g4/38VvutN1/HZkMm+JTg3bt\n\tIPNx5B0HlheqhZIDcYCrQP/FP459lPwau5mF61Wkpd0HXwKT0gnneiLetw7cvaZ9RnEM\n\t+mTuIk785fjQ0eQ57KUa5MCmndFqxaVLgwfSo+5jldNVrloO0ylhKYU6/wbt9KL4ZHfg\n\tOY7ceQ3/hxnaFNPisPAtRuCCHD3G0mv3FBViZ6YE5uQ6lve3a+O8v9KvWGy+09Ps7dRf\n\tNJdamDJ+P0M5x49HKhKg1IeeZGYIGeMWP4D/+xXhT4Zt+Wx1R6pR37gnJ58Mc2aVKCz5\n\t99RA==","X-Gm-Message-State":"AOAM530DvxTkzQ3isSqQ+vxpZKgP521LLh3eDPtOwZSk+avCCz4rglzQ\n\tumJYgdI/ZEXR6xxoVAjKQpr2kkye3Z6MLI7ZrL/JmnrVkDSKqHhAUMuwwKZoLG1Ghml5e916cHY\n\t5kFOuV5KG5rWU4+ZmmZQjX67LCXMLyBQtRA==","X-Received":["by 2002:a05:6402:4308:: with SMTP id\n\tm8mr43423781edc.188.1635796309335; \n\tMon, 01 Nov 2021 12:51:49 -0700 (PDT)","by 2002:a05:6402:4308:: with SMTP id\n\tm8mr43423753edc.188.1635796309127; \n\tMon, 01 Nov 2021 12:51:49 -0700 (PDT)"],"X-Google-Smtp-Source":"ABdhPJxyg+hEtJbMt/kYfTRxWVaDdO8Dqp2X16CmbcMyDYc1ID5vn61YoKNXfEklwSYjJJ2umJXnDA==","Message-ID":"","Date":"Mon, 1 Nov 2021 20:51:48 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Andy Shevchenko ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t","From":"Hans de Goede ","In-Reply-To":"","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20651,"web_url":"https://patchwork.libcamera.org/comment/20651/","msgid":"","date":"2021-11-01T19:18:04","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Mon, Nov 01, 2021 at 05:02:58PM +0100, Hans de Goede wrote:\n> On 10/29/21 13:50, Daniel Scally wrote:\n\n...\n\n> > To throw a spanner in the works though; I noticed this delightful _CRS\n> > for the OV9734 sensor of a  Surface Laptop 1 earlier:\n> > \n> > Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n> > {\n> >     Name (SBUF, ResourceTemplate ()\n> >     {\n> >         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n> >             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n> >             0x00, ResourceConsumer, , Exclusive,\n> >             )\n> >     })\n> >     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n> > }\n> \n> Hmm, we do have i2c_acpi_client_count(adev), so it is easy to use\n> that and just always use the last resource for the VCM. But that assumes\n> that is what is going on here and I have no idea.\n\nYou probably composed this message before reading my reply(ies).\n\n...\n\n> Change the first parameter of i2c_acpi_new_device() from\n> a struct device * to a struct acpi_device *.\n> \n> This is necessary because in some cases we may only have access\n> to the fwnode / acpi_device and not to the matching physical-node\n> struct device *.\n\nCan we rather create an fwnode based API and then\n\nstatic inline\nstruct i2c_client *i2c_acpi_new_device(struct device *dev, int index,\n\t\t\t\t struct i2c_board_info *info)\n\treturn i2c_acpi_new_device_by_fwnode(dev_fwnode(), index, info);\n}\n\n?","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C7B17BDB1C\n\tfor ;\n\tMon, 1 Nov 2021 20:03:44 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 598E4600C3;\n\tMon, 1 Nov 2021 21:03:44 +0100 (CET)","from mga12.intel.com (mga12.intel.com [192.55.52.136])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 49B88600B2\n\tfor ;\n\tMon, 1 Nov 2021 21:03:42 +0100 (CET)","from orsmga006.jf.intel.com ([10.7.209.51])\n\tby fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t01 Nov 2021 12:18:22 -0700","from smile.fi.intel.com ([10.237.72.184])\n\tby orsmga006-auth.jf.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2021 12:18:21 -0700","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mhcom-002n1z-Gq; Mon, 01 Nov 2021 21:18:04 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10155\"; a=\"211152705\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"211152705\"","E=Sophos;i=\"5.87,200,1631602800\"; d=\"scan'208\";a=\"449069418\""],"Date":"Mon, 1 Nov 2021 21:18:04 +0200","From":"Andy Shevchenko ","To":"Hans de Goede ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20652,"web_url":"https://patchwork.libcamera.org/comment/20652/","msgid":"","date":"2021-11-01T23:26:23","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Andy\n\nOn 01/11/2021 15:55, Andy Shevchenko wrote:\n> On Fri, Oct 29, 2021 at 12:50:31PM +0100, Daniel Scally wrote:\n>> Hi all\n>>\n>> +CC linux-media and libcamera-devel, as it's probably a good time to\n>> broaden this out. Also Andy because I'm hoping you can help :) The\n>> background of the discussion is about how we identify and enumerate\n>> (correctly, I.E. with a type matching the vcm driver's i2c_device_id,\n>> and there are a few different vcm's in scope which seem encoded in the\n>> SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3\n>> centric ACPI tables. The I2C address for the device is just a second\n>> I2cSerialBusV2 against the sensor's acpi device rather than a separate\n>> one, which is no awkward. We also need to get firmware created for the\n>> VCM such that the sensor will link to it via the lens-focus property.\n>> On 28/10/2021 09:57, Hans de Goede wrote:\n> ...\n>\n>> To throw a spanner in the works though; I noticed this delightful _CRS\n>> for the OV9734 sensor of a  Surface Laptop 1 earlier:\n>>\n>> Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n>> {\n>>     Name (SBUF, ResourceTemplate ()\n>>     {\n>>         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>     })\n>>     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n>> }\n>>\n>> How do we know which one's the VCM when there's more than just two like\n>> that? Andy: don't suppose you can shed any light there?\n> Seems to me that the order is defined by address and if software engineers are\n> not (so) crazy, it shouldn't deviate from device to device.\n>\n> At least this is stated in the internal documentation.\n>\n> The order is\n>\n> 1. Sensor (single addr)\n> 2. VCM (single addr)\n> 3. EEPROM (addr per page)\n\n\nThank you! That's really helpful, much appreciated.\n\n> Interestingly that your list have no VCM in the _CRS defined...\n>\n> Not sure how to distinguish that if it's not a typo and indeed the case.\n> Sounds like DMI quirk :-( again (something like 3-bit flag to define\n> which devices are present in the _CRS taking into account the ordering\n> requirements).\n\n\nThere's a field in the SSDB buffer against the sensor's acpi device,\nwith values from 0-4. We found an enumeration online, so we think that\nthe VCM in the surface go is a DW9719.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 4D15CBF415\n\tfor ;\n\tMon, 1 Nov 2021 23:26:28 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 64FC560259;\n\tTue, 2 Nov 2021 00:26:27 +0100 (CET)","from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com\n\t[IPv6:2a00:1450:4864:20::32e])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7CCA4600BA\n\tfor ;\n\tTue, 2 Nov 2021 00:26:25 +0100 (CET)","by mail-wm1-x32e.google.com with SMTP id\n\tb2-20020a1c8002000000b0032fb900951eso410533wmd.4\n\tfor ;\n\tMon, 01 Nov 2021 16:26:25 -0700 (PDT)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\th18sm9527237wre.46.2021.11.01.16.26.24\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 01 Nov 2021 16:26:24 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"RsEm6xTV\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=9KdY1mjESmMvVAcwHVOwXELedlsfZ2Tt7d3SBA18Sdg=;\n\tb=RsEm6xTVEjJb1DNwrWD8gorUw40W+lq/aFI+NT2bBNJ6kzPx+3V6I5Ypvz17SOrOQC\n\t5x4ottMggFtOeqHdu0Oq5dwqRLUeh7G++Bu+Bgez7x9mqyf9Y1yTV43gxk8iBLbEbX16\n\txHNJNUKQgetlJtMHkCTrGnmNfh4oyqVeuqvmcUleJjpME7WB6Nbki3501EuDIj8wTpif\n\tOZstd+FmMRRY9CIaQKxslbUYFaYvPRAJ8fxf4bLcRpqgR/vL9c6jIOggAYLiV0z/1Zgq\n\tLFg6316dZe8WDg4FYV6MHTuoLlrFxnpNo75v7NzK5/81Y/ekFNqA/lHg0r+D6k6F/JAX\n\t3NDg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=9KdY1mjESmMvVAcwHVOwXELedlsfZ2Tt7d3SBA18Sdg=;\n\tb=fw7PawQGlGCJclyFuF7vTXefEpVTLww6a9cRRNCxhD/FRr7sSSx+cJEmqwQPRBndzj\n\tDZ/WZDN30yRhRCx5J0lzyTAkO/YcCsZrZwdoMbfOPVzbizJsbXMM4SZq9z83qtgR9Ti9\n\tQnWqz0S+8Oh1phzRW2/FVK+Z+vx/bMhEkFRNu8rhMqfH4HjJB0EcUtWTjDwTFFYRZPNV\n\tUXBOsw+g0jVmptYar1xnseAjcxQ2ufUWZHYwRq7jbl8ATY6Jsz2ZiFSEt74vxtZl4X+y\n\tle5Q+Xv7lzDq0OcyiE9jnZqvKAd8YSRnsxWxp1qAFwEnJkzGDp5AWQNCR9HWpLzJHbaw\n\tmk6Q==","X-Gm-Message-State":"AOAM533BM3bQLW/q0/g/vqODC8aJMAU1LyXqhFdFenx1BSUrWHopsRP0\n\tKLcJbEf/47IdNWrbPjOFqEPuIQ9OODg=","X-Google-Smtp-Source":"ABdhPJw1DmrYpGziuqTXCEs7+H/q+7NQvWxHBtKvoUIQxoxtfbD2tT4SaDYGQlBG0+gphF+Qwbdq9A==","X-Received":"by 2002:a05:600c:1d01:: with SMTP id\n\tl1mr2452308wms.44.1635809185089; \n\tMon, 01 Nov 2021 16:26:25 -0700 (PDT)","To":"Andy Shevchenko ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t","From":"Daniel Scally ","Message-ID":"","Date":"Mon, 1 Nov 2021 23:26:23 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20653,"web_url":"https://patchwork.libcamera.org/comment/20653/","msgid":"<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","date":"2021-11-01T23:43:10","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 01/11/2021 16:02, Hans de Goede wrote:\n>\n> On 10/29/21 13:50, Daniel Scally wrote:\n>> Hi all\n>>\n>>\n>> +CC linux-media and libcamera-devel, as it's probably a good time to\n>> broaden this out. Also Andy because I'm hoping you can help :) The\n>> background of the discussion is about how we identify and enumerate\n>> (correctly, I.E. with a type matching the vcm driver's i2c_device_id,\n>> and there are a few different vcm's in scope which seem encoded in the\n>> SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3\n>> centric ACPI tables. The I2C address for the device is just a second\n>> I2cSerialBusV2 against the sensor's acpi device rather than a separate\n>> one, which is no awkward. We also need to get firmware created for the\n>> VCM such that the sensor will link to it via the lens-focus property.\n>>\n>> On 28/10/2021 09:57, Hans de Goede wrote:\n>>> Hi,\n>>>\n>>> On 10/28/21 10:49, Laurent Pinchart wrote:\n>>>> Hi Hans,\n>>>>\n>>>> On Thu, Oct 28, 2021 at 09:51:08AM +0200, Hans de Goede wrote:\n>>>>> On 10/28/21 09:10, Daniel Scally wrote:\n>>>>>> On 27/10/2021 15:16, Hans de Goede wrote:\n>>>>>>> On 10/27/21 12:07, Daniel Scally wrote:\n>>>>>>>> On 26/10/2021 11:14, Hans de Goede wrote:\n>>>>>>>>>>> So yesterday I already sorta guessed it would be the DW9714 because of\n>>>>>>>>>>> the 0x0c address and I tried:\n>>>>>>>>>>>\n>>>>>>>>>>> i2ctransfer -y 2 w2@0x0c 0x00 0x00\n>>>>>>>>>>>\n>>>>>>>>>>> And the transfer fails, while according to the driver that is a valid\n>>>>>>>>>>> value. So maybe we are missing a regulator enable? Or its not a DW9714.\n>>>>>>>>>>>\n>>>>>>>>>>> Also \"i2cdetect -y -r 2\" does not see anything at address 0x0c (but some of\n>>>>>>>>>>> these VCMs seem to be write only...) it does OTOH see an unknown device at\n>>>>>>>>>>> address 0x21.\n>>>>>>>>>> Well, when debugging the necessary TPS68470 settings I used a poor man's\n>>>>>>>>>> i2ctransfer on Windows whilst the camera was running to read the values\n>>>>>>>>>> that were set for both the PMIC and the camera sensor. Using the same\n>>>>>>>>>> program I can connect to and read values from a device at 0x0c,\n>>>>>>>> Just as further testing I dumped the contents of the device at 0x0c,\n>>>>>>>> which comes back as\n>>>>>>>>\n>>>>>>>> f1 1 2 1 61 0 40 60\n>>>>>>>>\n>>>>>>>> Byte 0 is given in the driver you linked as the ID field and expected to\n>>>>>>>> be f1. The driver controls focus by writing to the 3rd and 4th byte\n>>>>>>>> (with the 4th being the LSB); the only value that seemed to fluctuate\n>>>>>>>> when running windows and moving my hand in front of the sensor was byte\n>>>>>>>> 4 and testing it out I wrote values into that byte and the focus\n>>>>>>>> changes. So the device at 0x0c is definitely the vcm and it sure looks\n>>>>>>>> like it's the DW9719\n>>>>>>>>\n>>>>>>>> The device at 0x21 is only available on Windows when the camera is\n>>>>>>>> running, I thought it was quite likely that one of the \"spare\"\n>>>>>>>> regulators from the TPS68470. One line is called VCM, and sure enough\n>>>>>>>> it's enabled whilst the world-facing camera is running. I switched to\n>>>>>>>> linux and started streaming the back camera, then enabled that voltage\n>>>>>>>> regulator via i2ctransfer:\n>>>>>>>>\n>>>>>>>> sudo i2ctransfer 2 w2@0x4d 0x3c 0x6d\n>>>>>>>>\n>>>>>>>> sudo i2ctransfer 2 w2@0x4d 0x44 0x01\n>>>>>>>>\n>>>>>>>> And now i2cdetect shows the device at 0x0c on bus 2 - so we need more\n>>>>>>>> jiggery pokey to map that VCM regulator to this new device (once we've\n>>>>>>>> gotten it enumerated...) and the driver needs to have a tweak to call\n>>>>>>>> regulator get and do a power on at some point.\n>>>>>>> Awesome, great job on figuring this out!\n>>>>>>>\n>>>>>>> As you know I can spend $dayjob time on this, so I'll take on the job\n>>>>>>> of creating the i2c-client and hooking up the regulator in some\n>>>>>>> upstreamable manner.\n>>>>>> Okedokey cool. I'd probably start at the cio2-bridge, if only because we\n>>>>>> already have the adev there and the SSDB buffer loaded, so should be\n>>>>>> easy enough to add an enum for the vcm_type and a call to\n>>>>>> i2c_acpi_new_device()...bit of a weird place for that though I guess.\n>>>>> Ah, I was actually thinking about doing this int he int3472 code for\n>>>>> a number of reasons:\n>>>>>\n>>>>> 1. We already have the regulator_init_data there and we will need to\n>>>>> expand it for this.\n>>>>>\n>>>>> 2. It is sorta the central place where we deal with all this glue-stuff\n>>>> I'm not too sure about that. The INT3472 model the \"Intel camera PMIC\"\n>>>> (I don't remember the exact wording, but that's more or less how the\n>>>> device is described in Windows, and it matches the intent we see in the\n>>>> DSDT).\n>>> I agree that the INT3472 models the PMIC, or whatever discrete bits\n>>> which offer similar functionality.\n>>>\n>>>> Given that we already have cio2-bridge, and that it hooks up the\n>>>> sensor to the CIO2, it seems to me that it would be a better central\n>>>> place.\n>>> Ok, I was sorta expecting you to want to keep glue code like this\n>>> out of drivers/media. But I guess that only applies to putting ACPI\n>>> specific stuff in sensor drivers; and since the cio2-bridge code is\n>>> already x86/ACPI specific you are fine with adding ACPI code there?\n>>>\n>>> I'm fine with putting the VCM i2c-client instantiation in the\n>>> cio2-bridge code, that may also make it easier to tie the 2 together\n>>> at the media-controller level.\n>>\n>> Having looked at this yesterday evening I'm more and more convinced it's\n>> necessary. I hacked it into the ov8865 driver in the interim (just by\n>> calling i2c_acpi_new_device() in probe) and then worked on that dw9719\n>> code you found [1] to turn it into an i2c driver (attached, though still\n>> needs a bit of work), which will successfully bind to the i2c client\n>> enumerated by that i2c_acpi_new_device() call. From there though it\n>> needs a way for the v4l2 subdev to be matched to the sensor's subdev.\n>> This can happen automatically by way of the lens-focus firmware property\n>> against the sensor - we currently build those in the cio2-bridge, so\n>> adding another software node for the VCM and creating a lens-focus\n>> property for the sensor's software_node with a pointer to the VCM's node\n>> seems like the best way to do that.\n> So besides prepping a v5 of my previous series, with update regulator\n> init-data for the VCM I've also been looking into this, attached are\n> the results.\n>\n> Some notes from initial testing:\n>\n> 1. The driver you attached will only successful probe if I insmod\n> it while streaming video from the sensor. So I think we need another\n> regulator or the clk for just the VCM too, I will investigate this\n> later this week.\n\nOh really, I'll test that too; thanks for the patches. There's a couple\nof tweaks to the driver anyway, so hopefully be able to get it ironed out.\n\n\nRegarding this comment on your 2nd patch:\n\n\nNote there seems to be a pre-existing problem where there is no teardown\nof the bridge?\n\n\nI forget the exact reasoning, but this was deliberately done when we\noriginally merged the bridge code. I'll see if I can dig out the old\ndiscussion where we decided to go that way, but my search-fu is failing\nme at the moment.\n\n> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n> with this). There seems to be a chicken and egg problem here though,\n> because the v4l2subdev for the VCM does not register because of async stuff\n> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n> from the SSDB on the complete() callback won't work. But we can do this\n> on a per sensor basis instead from the cio2_notifier_bound() callback\n> instead I guess ?\n\n\nI think on top of your work in the cio2-bridge for patch 3 you can do this:\n\n\n1. Create another software node against the cio2_sensor struct, with the\nname coming from the vcm_types array\n\n2. Assign that software node to board_info.swnode in\ncio2_bridge_instantiate_vcm_i2c_client()\n\n3. Add another entry to dev_properties for the sensor, that is named\n\"lens-focus\" and contains a reference to the software_node created in #2\njust like the references to the sensor/cio2 nodes.\n\n\nThis way when the sensor driver calls\nv4l2_async_register_subdev_sensor() it should create a notifier that\nlooks for that VCM client to bind. I think then rather than putting\nanything in the .bound() / .complete() callbacks, we should modify core\nto do _something_ when async matching some subdevs. The something would\ndepend on the kind of devices that match, for example with the sensor\ndriver and the ipu3-cio2 driver, there's an entity whos function is\nMEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\nMEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\nis going to result in media pad links being created. Similarly for our\nsensor that's a device with entity function MEDIA_ENT_F_LENS matching to\nMEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\neither an interface link or a new kind of link (maybe\n\"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\nthat they form a single logical unit, which we can then report to libcamera.\n\n\nHope that makes sense...\n\n>\n> Can someone give me some hints how the fwnode link code should look/work\n> and how I can get the async registering of the subdev for the VCM to\n> complete ?\n>\n> Regards,\n>\n> Hans\n>\n>\n>\n>\n>>\n>> To throw a spanner in the works though; I noticed this delightful _CRS\n>> for the OV9734 sensor of a  Surface Laptop 1 earlier:\n>>\n>>\n>> Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings\n>> {\n>>     Name (SBUF, ResourceTemplate ()\n>>     {\n>>         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,\n>>             AddressingMode7Bit, \"\\\\_SB.PCI0.I2C2\",\n>>             0x00, ResourceConsumer, , Exclusive,\n>>             )\n>>     })\n>>     Return (SBUF) /* \\_SB_.PCI0.I2C2.CAMF._CRS.SBUF */\n>> }\n> Hmm, we do have i2c_acpi_client_count(adev), so it is easy to use\n> that and just always use the last resource for the VCM. But that assumes\n> that is what is going on here and I have no idea.\n>\n> Regards,\n>\n> Hans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 1441DBDB1C\n\tfor ;\n\tMon, 1 Nov 2021 23:43:14 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 6A35260122;\n\tTue, 2 Nov 2021 00:43:13 +0100 (CET)","from mail-wr1-x435.google.com (mail-wr1-x435.google.com\n\t[IPv6:2a00:1450:4864:20::435])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 28209600BA\n\tfor ;\n\tTue, 2 Nov 2021 00:43:12 +0100 (CET)","by mail-wr1-x435.google.com with SMTP id r8so17708546wra.7\n\tfor ;\n\tMon, 01 Nov 2021 16:43:12 -0700 (PDT)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\tf81sm829236wmf.22.2021.11.01.16.43.11\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 01 Nov 2021 16:43:11 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"R646zbbY\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=O10au1hHtrja/v/8/NHPudJ8rIic3kJ6GfWorzqnpjk=;\n\tb=R646zbbYvj19igQMgHmsp7NRAQtL0hejvZlTL+aQDHUo6iRMCEw3WGpT0JIOXrKTAY\n\t+Z/1uMmX3WmTFjR59XaelBqO245U4lDY5Z3fPY1PHdgcoD7oqVi33iOgH6y2nFrh4y2G\n\tlJLLTPlT02hpXMk8JR2zSfzsuNCe5VxBWSIv0Cu3LwQsP11ofqd2AEVVYmu5kUv6xxrW\n\tErqAiqccZ0c3JLCnyX5kX7pjRXcQDwy8ofmTZTh7OJw4r/vHu+k/N6vHeqb+bNSvnHtY\n\t5jcWZyBqOSlmWwdGnTJr4exfv5SQfa+VE36Hfcdg98sy6reyrzvpQZ5gboacGsy2LW89\n\tMljw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=O10au1hHtrja/v/8/NHPudJ8rIic3kJ6GfWorzqnpjk=;\n\tb=HeINg53DRu6JhoWz8c5/RmZyDIqbD1a0DYCzwJ/AKxNcrAZUEkPz+oMJU0sOx1bxYa\n\ttJaMV8ygZUy1oRav5etJQTQuBuqaC3kqDEzIwPHE8g41lofpVj5EBrACDOwYZu5MhTcD\n\tjw2kN2FDn+bH4V12TYc8AoV1nmTMXzrC/MszzpbM+vdMgazsM6gRIBYoWp2Lx9cz3gWQ\n\tJM+KOOm/FqMT3QuYzMP7k2duTG1bR/u7hnTCrGX4YYtRaLYE7sp4nC4e2zYhztaJvMBs\n\t/FBQIxz+kYlxD7aBfgc7Jtt3njCmvTIQ4lMVVhhvLh3gaUBBBeCSnMii+4SYo0/0WnyG\n\twm4A==","X-Gm-Message-State":"AOAM533vIv6hugj6va6HTdXTz15GxlNRdRCrrWFpsf3rkxBIN95Yxg84\n\tseeI+k31IQje48zwr3bkjEA=","X-Google-Smtp-Source":"ABdhPJx9wkl7OBvHBc/vdAEs96gulfmYfMRZXeCgXT8aebi2GFupjXQPHet/mnfxJ/5IQ3PRG7Wj4Q==","X-Received":"by 2002:a05:6000:10cb:: with SMTP id\n\tb11mr30025628wrx.71.1635810191784; \n\tMon, 01 Nov 2021 16:43:11 -0700 (PDT)","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","From":"Daniel Scally ","Message-ID":"<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","Date":"Mon, 1 Nov 2021 23:43:10 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20678,"web_url":"https://patchwork.libcamera.org/comment/20678/","msgid":"<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","date":"2021-11-04T14:49:48","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi Daniel,\n\nOn 11/2/21 00:43, Daniel Scally wrote:\n> Hi Hans\n> \n> On 01/11/2021 16:02, Hans de Goede wrote:\n\n\n\n>>> Having looked at this yesterday evening I'm more and more convinced it's\n>>> necessary. I hacked it into the ov8865 driver in the interim (just by\n>>> calling i2c_acpi_new_device() in probe) and then worked on that dw9719\n>>> code you found [1] to turn it into an i2c driver (attached, though still\n>>> needs a bit of work), which will successfully bind to the i2c client\n>>> enumerated by that i2c_acpi_new_device() call. From there though it\n>>> needs a way for the v4l2 subdev to be matched to the sensor's subdev.\n>>> This can happen automatically by way of the lens-focus firmware property\n>>> against the sensor - we currently build those in the cio2-bridge, so\n>>> adding another software node for the VCM and creating a lens-focus\n>>> property for the sensor's software_node with a pointer to the VCM's node\n>>> seems like the best way to do that.\n>> So besides prepping a v5 of my previous series, with update regulator\n>> init-data for the VCM I've also been looking into this, attached are\n>> the results.\n>>\n>> Some notes from initial testing:\n>>\n>> 1. The driver you attached will only successful probe if I insmod\n>> it while streaming video from the sensor. So I think we need another\n>> regulator or the clk for just the VCM too, I will investigate this\n>> later this week.\n> \n> Oh really, I'll test that too; thanks for the patches. There's a couple\n> of tweaks to the driver anyway, so hopefully be able to get it ironed out.\n\nOk, I've figured this out now, with the attached patch (which also\nexplains what is going on) as well as an updated tps68470_board_data.c\nwith updated regulator_init_data for the VCM (also attached), the driver\ncan now successfully talk to the VCM in probe() while we are NOT\nstreaming from the ov8865.\n\nDaniel, please feel free to squash this into your original dw9719 patch.\n\n\n\n>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>> with this). There seems to be a chicken and egg problem here though,\n>> because the v4l2subdev for the VCM does not register because of async stuff\n>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>> from the SSDB on the complete() callback won't work. But we can do this\n>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>> instead I guess ?\n> \n> \n> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n> \n> \n> 1. Create another software node against the cio2_sensor struct, with the\n> name coming from the vcm_types array\n> \n> 2. Assign that software node to board_info.swnode in\n> cio2_bridge_instantiate_vcm_i2c_client()\n> \n> 3. Add another entry to dev_properties for the sensor, that is named\n> \"lens-focus\" and contains a reference to the software_node created in #2\n> just like the references to the sensor/cio2 nodes.\n> \n> \n> This way when the sensor driver calls\n> v4l2_async_register_subdev_sensor() it should create a notifier that\n> looks for that VCM client to bind. I think then rather than putting\n> anything in the .bound() / .complete() callbacks, we should modify core\n> to do _something_ when async matching some subdevs. The something would\n> depend on the kind of devices that match, for example with the sensor\n> driver and the ipu3-cio2 driver, there's an entity whos function is\n> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n> is going to result in media pad links being created. Similarly for our\n> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n> either an interface link or a new kind of link (maybe\n> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n> that they form a single logical unit, which we can then report to libcamera.\n> \n> \n> Hope that makes sense...\n\nMaybe? I have not looked into this closely yet. I'll continue working on\nthis coming Tuesday.\n\nIf you feel like tinkering I would not mind if you beat me to it this\nweekend :) OTOH please enjoy your weekend doing whatever, I can continue\nworking on this during office-hours next week.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C0222BF415\n\tfor ;\n\tThu, 4 Nov 2021 14:49:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0D15B60347;\n\tThu, 4 Nov 2021 15:49:59 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A6CC360128\n\tfor ;\n\tThu, 4 Nov 2021 15:49:56 +0100 (CET)","from mail-ed1-f70.google.com (mail-ed1-f70.google.com\n\t[209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-11-yUSRGas5MeakCn9xv5Jgzg-1; Thu, 04 Nov 2021 10:49:52 -0400","by mail-ed1-f70.google.com with SMTP id\n\tw13-20020a05640234cd00b003e2fde5ff8aso266659edc.14\n\tfor ;\n\tThu, 04 Nov 2021 07:49:51 -0700 (PDT)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\thq37sm2842678ejc.116.2021.11.04.07.49.48\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 04 Nov 2021 07:49:49 -0700 (PDT)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"A71Q61is\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636037395;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=65zK6w0BPrF+QyDBrN2N9qPj8Z3y06NtBrsfLkGtDUc=;\n\tb=A71Q61issBnXqK0rB5crLVk5eFmmymIecmpop9T2JUkt5ebNrl/MJJ8/ojNRJJC5HzMGAe\n\tzOE1I+sJHHvFv9PX50pUVUVjOGh0tH60xbI4yud8woD+qAPkl5DnBlGtUV5jdlX/D+JIo9\n\taCnbICVmkM6h+DnA1EmZF7XuoVrEyCU=","X-MC-Unique":"yUSRGas5MeakCn9xv5Jgzg-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to;\n\tbh=sMzFcxJrjcUujKTofhoOTmW7rHRL06aKGxPsyli09Ek=;\n\tb=b0FtAtfTwgs+0Uz9ZtV4t2a/haSmH/pjgGIixcyhsQVblmba0ZlMn6+sJqaqcDYqqq\n\t3hS4xpkqEqHNYyN7j1WclconqusiGqDOIKFSlTtup6MoAKCC5BED6pcOb6npqV8qvCzb\n\tlmw6bHn6eh7YxPG7Vz/VXysgrHk9dIJ0GKikc0Q2w7sJTtgxFwa1zR7ObK+rszcKi5mC\n\tpQtjWJQv2Sp5PDznbqwqpPQiFUi0Qv1uh8vHyDbNPzBTAH2u/inOO6HMG++9qEgrY47r\n\t3HB5RZEH2lQqg0d/iVvb7c7OIRNBbsB36iNqUCa+oYNGBfFanALETj5vS1UKgB5eboOC\n\tDIDw==","X-Gm-Message-State":"AOAM530d1sVUU7k2ZGfh8IBEgUsIgJGAIeMtLc2f1fqKH+3oRr0eTW0e\n\tlwwJmU5zK3RHHWKdqZTxzpKGE7si8EF386zZx7rliuroGEK0oGADqV1wc5MBzgeg5KG82cIB6a8\n\tcar/3fU6VtUO2zc51TbGZ3idn1Qgrcv4bhA==","X-Received":["by 2002:a17:906:1396:: with SMTP id\n\tf22mr21415340ejc.228.1636037390297; \n\tThu, 04 Nov 2021 07:49:50 -0700 (PDT)","by 2002:a17:906:1396:: with SMTP id\n\tf22mr21415289ejc.228.1636037389878; \n\tThu, 04 Nov 2021 07:49:49 -0700 (PDT)"],"X-Google-Smtp-Source":"ABdhPJxrze++uYnVXNFYNdRm+SM5pIVdiYy1NjRRTXim9lZvXiyvy6ut6cU5UGeOWIO+MFmKywNX5A==","Message-ID":"<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","Date":"Thu, 4 Nov 2021 15:49:48 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","From":"Hans de Goede ","In-Reply-To":"<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Type":"multipart/mixed;\n\tboundary=\"------------xU8cQ3voysiv0Z2zjroxEWAd\"","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20682,"web_url":"https://patchwork.libcamera.org/comment/20682/","msgid":"","date":"2021-11-04T18:14:19","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Thu, Nov 04, 2021 at 03:49:48PM +0100, Hans de Goede wrote:\n> On 11/2/21 00:43, Daniel Scally wrote:\n\n...\n\n> Ok, I've figured this out now, with the attached patch (which also\n> explains what is going on) as well as an updated tps68470_board_data.c\n> with updated regulator_init_data for the VCM (also attached), the driver\n> can now successfully talk to the VCM in probe() while we are NOT\n> streaming from the ov8865.\n\nThanks, Hans.\n\n...\n\n> const struct int3472_tps68470_board_data *int3472_tps68470_get_board_data(const char *dev_name)\n> {\n> \tconst struct int3472_tps68470_board_data *board_data;\n> \tconst struct dmi_system_id *match;\n> \n> \tmatch = dmi_first_match(int3472_tps68470_board_data_table);\n> \twhile (match) {\n> \t\tboard_data = match->driver_data;\n> \t\tif (strcmp(board_data->dev_name, dev_name) == 0)\n> \t\t\treturn board_data;\n\n> \t\tdmi_first_match(++match);\n\nNot sure I understood the purpose of the call.\n\n> \t}\n> \treturn NULL;\n> }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id CF037BDB1C\n\tfor ;\n\tThu, 4 Nov 2021 18:14:40 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 44A8E6034D;\n\tThu, 4 Nov 2021 19:14:40 +0100 (CET)","from mga18.intel.com (mga18.intel.com [134.134.136.126])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B713960128\n\tfor ;\n\tThu, 4 Nov 2021 19:14:38 +0100 (CET)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t04 Nov 2021 11:14:36 -0700","from smile.fi.intel.com ([10.237.72.184])\n\tby orsmga004-auth.jf.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2021 11:14:34 -0700","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mihFj-003aGa-G3; Thu, 04 Nov 2021 20:14:19 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10158\"; a=\"218667368\"","E=Sophos;i=\"5.87,209,1631602800\"; d=\"scan'208\";a=\"218667368\"","E=Sophos;i=\"5.87,209,1631602800\"; d=\"scan'208\";a=\"600363835\""],"Date":"Thu, 4 Nov 2021 20:14:19 +0200","From":"Andy Shevchenko ","To":"Hans de Goede ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20683,"web_url":"https://patchwork.libcamera.org/comment/20683/","msgid":"<8f2b784d-7b3f-cb66-7186-66454a221188@gmail.com>","date":"2021-11-04T23:20:15","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 04/11/2021 14:49, Hans de Goede wrote:\n> Hi Daniel,\n>\n> On 11/2/21 00:43, Daniel Scally wrote:\n>> Hi Hans\n>>\n>> On 01/11/2021 16:02, Hans de Goede wrote:\n> \n>\n>>>> Having looked at this yesterday evening I'm more and more convinced it's\n>>>> necessary. I hacked it into the ov8865 driver in the interim (just by\n>>>> calling i2c_acpi_new_device() in probe) and then worked on that dw9719\n>>>> code you found [1] to turn it into an i2c driver (attached, though still\n>>>> needs a bit of work), which will successfully bind to the i2c client\n>>>> enumerated by that i2c_acpi_new_device() call. From there though it\n>>>> needs a way for the v4l2 subdev to be matched to the sensor's subdev.\n>>>> This can happen automatically by way of the lens-focus firmware property\n>>>> against the sensor - we currently build those in the cio2-bridge, so\n>>>> adding another software node for the VCM and creating a lens-focus\n>>>> property for the sensor's software_node with a pointer to the VCM's node\n>>>> seems like the best way to do that.\n>>> So besides prepping a v5 of my previous series, with update regulator\n>>> init-data for the VCM I've also been looking into this, attached are\n>>> the results.\n>>>\n>>> Some notes from initial testing:\n>>>\n>>> 1. The driver you attached will only successful probe if I insmod\n>>> it while streaming video from the sensor. So I think we need another\n>>> regulator or the clk for just the VCM too, I will investigate this\n>>> later this week.\n>> Oh really, I'll test that too; thanks for the patches. There's a couple\n>> of tweaks to the driver anyway, so hopefully be able to get it ironed out.\n> Ok, I've figured this out now, with the attached patch (which also\n> explains what is going on) as well as an updated tps68470_board_data.c\n> with updated regulator_init_data for the VCM (also attached), the driver\n> can now successfully talk to the VCM in probe() while we are NOT\n> streaming from the ov8865.\n>\n> Daniel, please feel free to squash this into your original dw9719 patch.\n>\n\nNice thanks - I'll do that.\n\n>\n>>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>>> with this). There seems to be a chicken and egg problem here though,\n>>> because the v4l2subdev for the VCM does not register because of async stuff\n>>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>>> from the SSDB on the complete() callback won't work. But we can do this\n>>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>>> instead I guess ?\n>>\n>> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n>>\n>>\n>> 1. Create another software node against the cio2_sensor struct, with the\n>> name coming from the vcm_types array\n>>\n>> 2. Assign that software node to board_info.swnode in\n>> cio2_bridge_instantiate_vcm_i2c_client()\n>>\n>> 3. Add another entry to dev_properties for the sensor, that is named\n>> \"lens-focus\" and contains a reference to the software_node created in #2\n>> just like the references to the sensor/cio2 nodes.\n>>\n>>\n>> This way when the sensor driver calls\n>> v4l2_async_register_subdev_sensor() it should create a notifier that\n>> looks for that VCM client to bind. I think then rather than putting\n>> anything in the .bound() / .complete() callbacks, we should modify core\n>> to do _something_ when async matching some subdevs. The something would\n>> depend on the kind of devices that match, for example with the sensor\n>> driver and the ipu3-cio2 driver, there's an entity whos function is\n>> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n>> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n>> is going to result in media pad links being created. Similarly for our\n>> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n>> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n>> either an interface link or a new kind of link (maybe\n>> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n>> that they form a single logical unit, which we can then report to libcamera.\n>>\n>>\n>> Hope that makes sense...\n> Maybe? I have not looked into this closely yet. I'll continue working on\n> this coming Tuesday.\n>\n> If you feel like tinkering I would not mind if you beat me to it this\n> weekend :) OTOH please enjoy your weekend doing whatever, I can continue\n> working on this during office-hours next week.\n\n\nI'll probably have some time to look at it over the next few days; I'll\nlet you know how I get on.\n\n>\n> Regards,\n>\n> Hans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id BE7A7BDB1C\n\tfor ;\n\tThu, 4 Nov 2021 23:20:20 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C0A056034D;\n\tFri, 5 Nov 2021 00:20:19 +0100 (CET)","from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com\n\t[IPv6:2a00:1450:4864:20::42e])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C7C20600B5\n\tfor ;\n\tFri, 5 Nov 2021 00:20:17 +0100 (CET)","by mail-wr1-x42e.google.com with SMTP id b12so10994933wrh.4\n\tfor ;\n\tThu, 04 Nov 2021 16:20:17 -0700 (PDT)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\ty10sm8036538wrd.84.2021.11.04.16.20.16\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 04 Nov 2021 16:20:16 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"gRhwjpCH\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=XOQaUgD4zkMFxDHKIDUhxCamHk/vx1cLGyBMvSH2pYU=;\n\tb=gRhwjpCHOgTvlzzMhUHjcKsCF89AfHgGeA72bYqlWatM9QT4mjsbwtQ1Hphoxhj1/h\n\t0j4xUJkpZpJR2/icSOdAxJZZY67Daw8TNlXjvZzVLUeVmjlZ6UpX9jkToT5QLCh9PkaF\n\tsfsCbIeNhq4ph98cqs6iV5zPVC7SdXxDfBkLoA9gi3GxlTWEbS4hRDqdv543F343t3sh\n\tQEozAWWkG61e6g2btYeOKGqo9vk2+M8G+y5+7vVRvc3n0TvZyeUShevLUnaBQ++aXIqk\n\tigz8QzBjZLtrwn6O6SUD84vF1bdVKikw4UxgCRUffdKeAPOJ+c3EDdozINwTVXG0vV3U\n\tZPDw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=XOQaUgD4zkMFxDHKIDUhxCamHk/vx1cLGyBMvSH2pYU=;\n\tb=NIG3rms/7OJ7Fe85CEHg3tfTxsTieiNs/ZjfC8ONPIG3P6B7Ma86Q4jrkVAmTx7ME9\n\tV0yAmTctwqgE1W1x5uxl5xMxB2Ky1aPvWMVpatL16pBSw0WZzeY81/xN5vTq0mTFZlNb\n\tbfWANwu9rv2SzC6y9U5BWylO/Xn8ncupBeSGaWrvKlLpJVyZPg4T/okzXYBXOJZrzZOE\n\tDDk7bMYtd6GYxA9GJ7jodYAMo34ciWWJktXZ2746BCpRs5jXDFjaJKetQNE+rvohWFm4\n\thGMpeYb/tiEkCBRRYgdojFugfJDvgytmou8bBaBatj3RCS/kT8MfV+PwV8jcu/QAU1qX\n\tbSdg==","X-Gm-Message-State":"AOAM533mTt/M8k2BDnIdyzvstDbZJgwaqTnIXkYEtl2D+JiixX/sWNgO\n\tC0b3UWRtduA/aAx3ktxA1Rk=","X-Google-Smtp-Source":"ABdhPJxYjjk7ksNM6DZY0QBFw3XrRRXqQDI+uOs5vl/sOyRTzB9b6WFc7OTrb1J0Ji2QuljUwOf5cw==","X-Received":"by 2002:a05:6000:1010:: with SMTP id\n\ta16mr57017298wrx.155.1636068017335; \n\tThu, 04 Nov 2021 16:20:17 -0700 (PDT)","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","From":"Daniel Scally ","Message-ID":"<8f2b784d-7b3f-cb66-7186-66454a221188@gmail.com>","Date":"Thu, 4 Nov 2021 23:20:15 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20698,"web_url":"https://patchwork.libcamera.org/comment/20698/","msgid":"<3e2a32c3-1e42-a510-6010-6be07bdd101d@redhat.com>","date":"2021-11-06T14:12:07","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/4/21 19:14, Andy Shevchenko wrote:\n> On Thu, Nov 04, 2021 at 03:49:48PM +0100, Hans de Goede wrote:\n>> On 11/2/21 00:43, Daniel Scally wrote:\n> \n> ...\n> \n>> Ok, I've figured this out now, with the attached patch (which also\n>> explains what is going on) as well as an updated tps68470_board_data.c\n>> with updated regulator_init_data for the VCM (also attached), the driver\n>> can now successfully talk to the VCM in probe() while we are NOT\n>> streaming from the ov8865.\n> \n> Thanks, Hans.\n> \n> ...\n> \n>> const struct int3472_tps68470_board_data *int3472_tps68470_get_board_data(const char *dev_name)\n>> {\n>> \tconst struct int3472_tps68470_board_data *board_data;\n>> \tconst struct dmi_system_id *match;\n>>\n>> \tmatch = dmi_first_match(int3472_tps68470_board_data_table);\n>> \twhile (match) {\n>> \t\tboard_data = match->driver_data;\n>> \t\tif (strcmp(board_data->dev_name, dev_name) == 0)\n>> \t\t\treturn board_data;\n> \n>> \t\tdmi_first_match(++match);\n> \n> Not sure I understood the purpose of the call.\n\nYou are right , that should have a \"match = \" in front of it, but\nI actually like this form found else where better:\n\n for (match = dmi_first_match(int3472_tps68470_board_data_table);\n match;\n match = dmi_first_match(match + 1)) {\n\nThat IMHO makes the whole code a lot clearer, so I'll switch to that for\nthe next version, thank you for catching this.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9FEBABF415\n\tfor ;\n\tSat, 6 Nov 2021 14:12:15 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id CDFA16034F;\n\tSat, 6 Nov 2021 15:12:14 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [216.205.24.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 924126033A\n\tfor ;\n\tSat, 6 Nov 2021 15:12:12 +0100 (CET)","from mail-ed1-f71.google.com (mail-ed1-f71.google.com\n\t[209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-557-ptSZcO0xPRqakShXZyWxmA-1; Sat, 06 Nov 2021 10:12:09 -0400","by mail-ed1-f71.google.com with SMTP id\n\tq6-20020a056402518600b003e28d92bb85so11247456edd.7\n\tfor ;\n\tSat, 06 Nov 2021 07:12:09 -0700 (PDT)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\tsg17sm5793569ejc.72.2021.11.06.07.12.07\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tSat, 06 Nov 2021 07:12:07 -0700 (PDT)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"DSL/CjF1\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636207931;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=NvL28t+9mmNIhKid1W8YhAFvBVkKSYd5UykSql3UdJ8=;\n\tb=DSL/CjF1Mv6scTJaU+PJR0JTpOOL56zOjxyTtYSS1hoY5jGOD5J4j1jwHuYIzWUDmX1PeE\n\tlyAyyX0r6g+CkRRErnUfehrl5H5+ZvWN1lOKTiFpF4fkHFLKGR03w/+UJpMIUFkJ1P/TTC\n\tlnAb/EmAhrlNjoWb3o8CXeYPZNxQXLQ=","X-MC-Unique":"ptSZcO0xPRqakShXZyWxmA-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=NvL28t+9mmNIhKid1W8YhAFvBVkKSYd5UykSql3UdJ8=;\n\tb=FCJk2UYdbsXSCmkcyDnHLM/BFDUEhtJhb6Vnw6tCBfFfwtIB6ChKgDADQ+HCtVe9/C\n\tdFoXByPKSspecS8WSwPoq/GXSeSeBomcLd2OnHHsgbazoDi9Lqtp9eFuuWdN7WigPyaL\n\tIByrWWtYksNABOC5xm6NhLyYexeOb14yG1fZiJPms0dtlzY+BEIy7vzSUvUCGzncJnY7\n\t6yyLYUQHQ3xknQ8g7/01dI5MO1nKx7H3xvJyltj15f/PFPqMP4HM/7tM2vbkKO8jGJYd\n\tWqs4TdZx3s3EhKmc2ARJIrS4HXWq7dxZVBqphXFI/MG51lyF64ZKlkrP2V0B5oAKZ+Xm\n\toHHw==","X-Gm-Message-State":"AOAM531DBKRE8ZA680b3vdUNvyw+HXX2oqilcTQ+GFJvNT8YMiTom+iQ\n\tpIBHjAnNJtxScrl8ZIT5/ldWY83ZB2LpJme1dz982ydcy1f5qyNH5uCCxiFBFU+3twH/yZYj/ss\n\tBo81n79LvrmS4Dibcu2M1pnsd7iyZQVg+8A==","X-Received":["by 2002:a17:906:6b1a:: with SMTP id\n\tq26mr77714819ejr.185.1636207928625; \n\tSat, 06 Nov 2021 07:12:08 -0700 (PDT)","by 2002:a17:906:6b1a:: with SMTP id\n\tq26mr77714790ejr.185.1636207928410; \n\tSat, 06 Nov 2021 07:12:08 -0700 (PDT)"],"X-Google-Smtp-Source":"ABdhPJyZAKFHxsHAxT8AQIMcGt+HZHLg18xc7Trn1BTg6tRegrsxDmthab5sZ61MbsKL0W4N18i7JA==","Message-ID":"<3e2a32c3-1e42-a510-6010-6be07bdd101d@redhat.com>","Date":"Sat, 6 Nov 2021 15:12:07 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Andy Shevchenko ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>\n\t","From":"Hans de Goede ","In-Reply-To":"","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20703,"web_url":"https://patchwork.libcamera.org/comment/20703/","msgid":"","date":"2021-11-06T18:39:35","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":104,"url":"https://patchwork.libcamera.org/api/people/104/","name":"Andy Shevchenko","email":"andy.shevchenko@gmail.com"},"content":"On Sat, Nov 6, 2021 at 8:15 PM Hans de Goede wrote:\n> On 11/4/21 19:14, Andy Shevchenko wrote:\n> > On Thu, Nov 04, 2021 at 03:49:48PM +0100, Hans de Goede wrote:\n> >> On 11/2/21 00:43, Daniel Scally wrote:\n\n...\n\n> >> dmi_first_match(++match);\n> >\n> > Not sure I understood the purpose of the call.\n>\n> You are right , that should have a \"match = \" in front of it, but\n> I actually like this form found else where better:\n>\n> for (match = dmi_first_match(int3472_tps68470_board_data_table);\n> match;\n> match = dmi_first_match(match + 1)) {\n>\n> That IMHO makes the whole code a lot clearer, so I'll switch to that for\n> the next version, thank you for catching this.\n\nI'm very glad that you read my mind!\nI was too modest to express the same proposal as you do just above. Go for it!","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B5CADBDB1C\n\tfor ;\n\tSat, 6 Nov 2021 20:24:07 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id E80156034F;\n\tSat, 6 Nov 2021 21:24:06 +0100 (CET)","from mail-ed1-x534.google.com (mail-ed1-x534.google.com\n\t[IPv6:2a00:1450:4864:20::534])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 8B64C6033A\n\tfor ;\n\tSat, 6 Nov 2021 19:40:12 +0100 (CET)","by mail-ed1-x534.google.com with SMTP id c8so28300095ede.13\n\tfor ;\n\tSat, 06 Nov 2021 11:40:12 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"p85m9S6s\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=GCgFfhtXVgNBXIqk9OVgPMU35MsxnNsdqeQ1ofm4KxA=;\n\tb=p85m9S6syVRMMQKpEMM1fdRVA56p4I0t8SesjHA03nm0zg5vduW4wjynx6opFjvSx6\n\tF7feBjT0OySTWE+CD0SV2lVdKEHJW7VTA8Knjw2racFjHdlUuWyRv6zWzF6ddieZmEnj\n\tm3h8WXarvVJXU8E3/m+GAbRExXi5o/7/24HEDQCR3lWJ10IqY4LqyCX+0qwuMpL0ANia\n\tz6fS/98mg2itGsJrFq3kRgOMMBJUpJmnxS9gf9o722oY50Xw/e7azc0Vv44bwlqYu5DM\n\tlpLpqp/Q4Pbv16zOqeGX+RUxCaVeNLboOD6CiDlafB5pQpqg/jjghzgxisX7SXxie1S5\n\tps2w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=GCgFfhtXVgNBXIqk9OVgPMU35MsxnNsdqeQ1ofm4KxA=;\n\tb=pBytiNsqvgwA/mp0mTy0V29YPKVmcloUyUhmkr8904R7IPWDVlgjvdZK5E1CAB6Mg/\n\thOsAprOg5Hru0/hXiyLLS8Dl8cdnzsPq+rUQjcexd97MwPuXmqEvXiiINI4Mm12G/K/t\n\tk74hM+jVoglR9VFaVSiauuoXB/YRR7bHTWQy38g5aTmX93jTENzCWJOXx4I90+gLyFxP\n\tGfODAu6Oe5gy6uZDA9D44c+WhFvpn4BymuIa1gCQlRtekKYsiy1o+v9105olUISbt1Gc\n\t6IpB0zWynIIAmoxaLy0vdhnifC6WYPIHetCM1eFQS1+a4KJYV10hROPnSk8OLYpEVMSb\n\t8i6A==","X-Gm-Message-State":"AOAM531SuJgP36whfFsQiEB/zP001cTfOaaZlE4BfJe8diqhoQ0qryvY\n\tpwXcKOG48XdHSt24XWt1k06KKTrR4QXCLsBxIrw=","X-Google-Smtp-Source":"ABdhPJyz9ZsK8Ob0unh5UnIOQUNIWw8aDVCiszEeghIVcz0xzmkFKsU9SgX5VNeQ8NjGlN65ShGhRISxa1KUi4g22VA=","X-Received":"by 2002:a17:906:6a0a:: with SMTP id\n\tqw10mr56737971ejc.141.1636224012026; \n\tSat, 06 Nov 2021 11:40:12 -0700 (PDT)","MIME-Version":"1.0","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t<8d0470d3-7356-b476-6807-5c8606ee3545@redhat.com>\n\t\n\t<3e2a32c3-1e42-a510-6010-6be07bdd101d@redhat.com>","In-Reply-To":"<3e2a32c3-1e42-a510-6010-6be07bdd101d@redhat.com>","From":"Andy Shevchenko ","Date":"Sat, 6 Nov 2021 20:39:35 +0200","Message-ID":"","To":"Hans de Goede ","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailman-Approved-At":"Sat, 06 Nov 2021 21:24:06 +0100","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20708,"web_url":"https://patchwork.libcamera.org/comment/20708/","msgid":"","date":"2021-11-08T13:12:38","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/2/21 00:43, Daniel Scally wrote:\n> Hi Hans\n\n\n \n\n>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>> with this). There seems to be a chicken and egg problem here though,\n>> because the v4l2subdev for the VCM does not register because of async stuff\n>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>> from the SSDB on the complete() callback won't work. But we can do this\n>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>> instead I guess ?\n> \n> \n> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n> \n> \n> 1. Create another software node against the cio2_sensor struct, with the\n> name coming from the vcm_types array\n> \n> 2. Assign that software node to board_info.swnode in\n> cio2_bridge_instantiate_vcm_i2c_client()\n> \n> 3. Add another entry to dev_properties for the sensor, that is named\n> \"lens-focus\" and contains a reference to the software_node created in #2\n> just like the references to the sensor/cio2 nodes.\n> \n> \n> This way when the sensor driver calls\n> v4l2_async_register_subdev_sensor() it should create a notifier that\n> looks for that VCM client to bind. I think then rather than putting\n> anything in the .bound() / .complete() callbacks, we should modify core\n> to do _something_ when async matching some subdevs. The something would\n> depend on the kind of devices that match, for example with the sensor\n> driver and the ipu3-cio2 driver, there's an entity whos function is\n> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n> is going to result in media pad links being created. Similarly for our\n> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n> either an interface link or a new kind of link (maybe\n> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n> that they form a single logical unit, which we can then report to libcamera.\n> \n> \n> Hope that makes sense...\n\nOk, so I gave this a try, see the attached patches, but the v4l2-subdev for\nthe VCM still does not show up.\n\nI think that instead I need to build a full link between the sensor\nand the VCM similar to the cio2 <-> sensor link. Both ends of that link\nhave:\n\n\n|\n--","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id D9252BDB1C\n\tfor ;\n\tMon, 8 Nov 2021 13:12:48 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0469760361;\n\tMon, 8 Nov 2021 14:12:48 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2B5FE6032C\n\tfor ;\n\tMon, 8 Nov 2021 14:12:44 +0100 (CET)","from mail-ed1-f72.google.com (mail-ed1-f72.google.com\n\t[209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-48-y9Cr6pLRN9SlkaPqD1tP8A-1; Mon, 08 Nov 2021 08:12:40 -0500","by mail-ed1-f72.google.com with SMTP id\n\tr25-20020a05640216d900b003dca3501ab4so14772985edx.15\n\tfor ;\n\tMon, 08 Nov 2021 05:12:40 -0800 (PST)","from [10.40.1.223] ([81.30.35.201])\n\tby smtp.gmail.com with ESMTPSA id\n\tv10sm9050966edt.24.2021.11.08.05.12.38\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 08 Nov 2021 05:12:38 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"cPhBPVHw\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636377163;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=UY1DJbbNBauBjggHXwQBhosyOCGnR6fpTu5PO8To/6Y=;\n\tb=cPhBPVHwSl17CxB8+eNqqew6WLVNlmClaSgCNWvKu9wFE/S3WxzPCfiFE/2OCwASY3gdKv\n\t7f9LnlQl/nkrwzWyMe6YMBQ/4gMyaTLSDR349/PAZR+oH+i2z1Mycdvn1SgEq3//cvseGJ\n\tqFBtRLqBDW8IwxtYQq0aLBXfDSyNNwI=","X-MC-Unique":"y9Cr6pLRN9SlkaPqD1tP8A-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to;\n\tbh=AsMipTb2q4FT03KK4sOQ/YJsTgCE1td2q0U9s0bzR3A=;\n\tb=hNPoK8mQiAF6EEWbgDmiYCqOQnxjBvLvVTbK+Ub63RKRUq/69emQ08pGcOt3rz6laH\n\tWWJ9rgrI/36ZlfQLiM18Q2r6NGmzxk731C+g0ylol9kIj4fUAZlyqWQp4+YH2Be1AuJ1\n\tMOWmFOq/0GE+z8r5tyOswoTTdsL6gDB931twpPp3zzEpBZC+64SZZ4aZ3CS9yPLWMeV9\n\t4Rndx+Qv/VrU48SiKFIhTrGxVfFDWubkueGgTqJVcUx4H25phVJyKd8IZXIGoWB2Kt5l\n\tbkfskIxOfeJYUWZDNmB7MAIxGy8cAN4kAEq3K/syiDm1P2IRsKvRLJwWrwRTVCzSpsRO\n\tRT4g==","X-Gm-Message-State":"AOAM53346LbLRiws+cvyH36N9ZOY8TXrqq7lRljYqQ9jxMGLEyfB7cVu\n\txE/Mo4VoJ+1Z2Rp/vtIzU9QzcBNdAJrpjNXmyxzcCjuL7aOLoosNNdGbRuiOsX0R1RfsSNDYoCY\n\tsVxdtnvz5L3EqlUnPFaRD6W1FIiqj3eos3g==","X-Received":["by 2002:a05:6402:2743:: with SMTP id\n\tz3mr70385397edd.167.1636377159369; \n\tMon, 08 Nov 2021 05:12:39 -0800 (PST)","by 2002:a05:6402:2743:: with SMTP id\n\tz3mr70385375edd.167.1636377159145; \n\tMon, 08 Nov 2021 05:12:39 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJytltS5qXFcV3dqHRvl1JznuRPIwywzMDzzrm30bZuaXWK55nM8wrVcSQrg1Tv0fzMYBv93cg==","Message-ID":"","Date":"Mon, 8 Nov 2021 14:12:38 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","From":"Hans de Goede ","In-Reply-To":"<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Type":"multipart/mixed;\n\tboundary=\"------------kmD534ZgNF5k6uA0cryDJGeT\"","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20715,"web_url":"https://patchwork.libcamera.org/comment/20715/","msgid":"","date":"2021-11-08T14:12:57","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Mon, Nov 08, 2021 at 02:12:38PM +0100, Hans de Goede wrote:\n> On 11/2/21 00:43, Daniel Scally wrote:\n\n> Does this sound reasonable / like I'm heading in the right direction?\n\nIt is up to you folks, since I have no time to participate in this with\na full dive right now. Below just some comments on the patches in case\nthey will go.\n\n...\n\n> -\tstruct acpi_device *adev = ACPI_COMPANION(dev);\n> +\tstruct acpi_device *adev = to_acpi_device_node(fwnode);\n> \tstruct i2c_acpi_lookup lookup;\n> \tstruct i2c_adapter *adapter;\n> \tLIST_HEAD(resource_list);\n> \tint ret;\n\nMake sense to move assignment here.\n\n\tadev = to_acpi_device_node(fwnode);\n\n> +\tif (!adev)\n> +\t\treturn ERR_PTR(-ENODEV);\n\n...\n\n> +static inline struct i2c_client *i2c_acpi_new_device(struct device *dev,\n> +\t\t\t\t\t\t int index,\n> +\t\t\t\t\t\t struct i2c_board_info *info)\n> +{\n> +\treturn i2c_acpi_new_device_by_fwnode(dev->fwnode, index, info);\n\ndev_fwnode(dev)\n\n> +}\n\n...\n\n> +int cio2_bridge_sensors_are_ready(void)\n> +{\n> +\tstruct acpi_device *adev;\n\n> +\tbool ready = true;\n\nRedundant. See below.\n\n> +\tunsigned int i;\n> +\n> +\tfor (i = 0; i < ARRAY_SIZE(cio2_supported_sensors); i++) {\n> +\t\tconst struct cio2_sensor_config *cfg =\n> +\t\t\t&cio2_supported_sensors[i];\n> +\n> +\t\tfor_each_acpi_dev_match(adev, cfg->hid, NULL, -1) {\n> +\t\t\tif (!adev->status.enabled)\n> +\t\t\t\tcontinue;\n\n> +\t\t\tif (!acpi_dev_ready_for_enumeration(adev))\n> +\t\t\t\tready = false;\n\nYou may put the adev here and return false.\n\n> +\t\t}\n> +\t}\n\n> +\treturn ready;\n\nSo return true.\n\n> +}\n\n...\n\n> +\tif (sensor->ssdb.vcmtype)\n> +\t\tnodes[SWNODE_VCM] = NODE_VCM(\n> +\t\t\t\t\tcio2_vcm_types[sensor->ssdb.vcmtype - 1]);\n\nWouldn't be better\n\n\t\tnodes[SWNODE_VCM] =\n\t\t\tNODE_VCM(cio2_vcm_types[sensor->ssdb.vcmtype - 1]);\n\n?\n\n...\n\n> +\tsensor->vcm_i2c_client = i2c_acpi_new_device_by_fwnode(\n> +\t\t\t\t\tacpi_fwnode_handle(sensor->adev),\n> +\t\t\t\t\t1, &board_info);\n\nDitto.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id F001EBDB1C\n\tfor ;\n\tMon, 8 Nov 2021 14:13:45 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4F4F26035D;\n\tMon, 8 Nov 2021 15:13:45 +0100 (CET)","from mga17.intel.com (mga17.intel.com [192.55.52.151])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 011EF6032C\n\tfor ;\n\tMon, 8 Nov 2021 15:13:38 +0100 (CET)","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t08 Nov 2021 06:13:12 -0800","from smile.fi.intel.com ([10.237.72.184])\n\tby orsmga003-auth.jf.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2021 06:13:10 -0800","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mk5OL-004iec-GD; Mon, 08 Nov 2021 16:12:57 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10161\"; a=\"212963761\"","E=Sophos;i=\"5.87,218,1631602800\"; d=\"scan'208\";a=\"212963761\"","E=Sophos;i=\"5.87,218,1631602800\"; d=\"scan'208\";a=\"451535644\""],"Date":"Mon, 8 Nov 2021 16:12:57 +0200","From":"Andy Shevchenko ","To":"Hans de Goede ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20738,"web_url":"https://patchwork.libcamera.org/comment/20738/","msgid":"","date":"2021-11-09T00:43:10","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 08/11/2021 13:12, Hans de Goede wrote:\n> Hi,\n>\n> On 11/2/21 00:43, Daniel Scally wrote:\n>> Hi Hans\n> \n> \n>\n>>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>>> with this). There seems to be a chicken and egg problem here though,\n>>> because the v4l2subdev for the VCM does not register because of async stuff\n>>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>>> from the SSDB on the complete() callback won't work. But we can do this\n>>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>>> instead I guess ?\n>>\n>> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n>>\n>>\n>> 1. Create another software node against the cio2_sensor struct, with the\n>> name coming from the vcm_types array\n>>\n>> 2. Assign that software node to board_info.swnode in\n>> cio2_bridge_instantiate_vcm_i2c_client()\n>>\n>> 3. Add another entry to dev_properties for the sensor, that is named\n>> \"lens-focus\" and contains a reference to the software_node created in #2\n>> just like the references to the sensor/cio2 nodes.\n>>\n>>\n>> This way when the sensor driver calls\n>> v4l2_async_register_subdev_sensor() it should create a notifier that\n>> looks for that VCM client to bind. I think then rather than putting\n>> anything in the .bound() / .complete() callbacks, we should modify core\n>> to do _something_ when async matching some subdevs. The something would\n>> depend on the kind of devices that match, for example with the sensor\n>> driver and the ipu3-cio2 driver, there's an entity whos function is\n>> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n>> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n>> is going to result in media pad links being created. Similarly for our\n>> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n>> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n>> either an interface link or a new kind of link (maybe\n>> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n>> that they form a single logical unit, which we can then report to libcamera.\n>>\n>>\n>> Hope that makes sense...\n> Ok, so I gave this a try, see the attached patches, but the v4l2-subdev for\n> the VCM still does not show up.\n\n\nThis is exactly where I got to over the weekend too\n\n> I think that instead I need to build a full link between the sensor\n> and the VCM similar to the cio2 <-> sensor link. Both ends of that link\n> have:\n>\n> \n> |\n> -- | sensor side and the link nr on the cio2 side\n> |\n> --\n> And then the 2 endpoints contain a swref property pointing to the\n> other endpoint swnode.\n>\n> I think we need a similar setup adding a swnode child named\n> (SWNODE_GRAPH_PORT_NAME_FMT, 1), to the nodes[SWNODE_SENSOR_HID] node.\n>\n> Note 1, since 0 is the \"port\" to the cio2, this new port child then\n> gets an endpoint \"0\" child itself, likewise we add a \"port 0\" child\n> to the vcm swnode, with a \"endpoint 0\" child below that and then have\n> the 2 endpoints contain swref properties pointing to each other.\n>\n> I think that this will properly make the VCm part of the graph and\n> will make its v4l2-subdev get instantiated when the graph is\n> complete. Before I spend a bunch of time on implementing this,\n> let me ask this:\n>\n> Does this sound reasonable / like I'm heading in the right direction?\nI don't think that we need to add the software nodes as\nports/endpoints...as far as I can tell it ought to work like this:\n\n\n1. The sensor calls v4l2_async_register_subdev_sensor() which...\n\n    a) creates a notifier\n\n    b) looks for reference properties of the device's fwnode called\n\"lens-focus\" and calls v4l2_async_notifier_add_fwnode_subdev() against\nthe reference, which tells the notifier it's connected to this other\nfwnode and to expect it to bind.\n\n2. When new subdevs are registered they get tested for a match against\nthe notifier registered in 1a that matches to their fwnode using\nmatch_fwnode() [1]. This should work, on the grounds that we registered\nthe device using the board_info.swnode and registered a lens-focus\nproperty that points to that software_node\n\n3. When a match is found, the notifier's .bound() function is called.\nWhen all the asds that the notifier expects are bound the notifier's\n.complete() callback is called.\n\n\nThat's not working correctly for me at the moment, but I think this is a\nsurmountable problem rather than the wrong approach, so I'm just working\nthrough the differences to try and get the matching working.\n\n\nFor the devnodes, the ipu3-cio2 driver itself creates the devnodes for\nthe subdevices that bind to it (like the sensor) as part of its\n.complete() callback [2] by calling v4l2_device_register_subdev_nodes(),\nas far as I can tell there's nothing in v4l2 core that handles that\nautomatically so I think that that lack is what's preventing the\ndevnodes from showing up. I think we should tackle the problem of the\nmissing devnodes by mimicking the effects of that function somewhere\nwithin core, probably v4l2_async_match_notify() (which calls the\nnotifier's .bound() callback). I think the creation of the links to\nexpose to userspace that this is a logical unit should probably happen\nin the same place, using the entity.function field of the subdev and the\nasd to decide exactly what kind of link to create.\n\n\n[1]\nhttps://elixir.bootlin.com/linux/latest/source/drivers/media/v4l2-core/v4l2-async.c#L69\n\n[2]\nhttps://elixir.bootlin.com/linux/latest/source/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c#L1449\n\n>\n> Regards,\n>\n> Hans\n>\n>\n>\n> p.s.\n>\n> I have found a new solution for the probe-ordering problem which\n> is patch 2 of the attached patches, I personally I'm happy with\n> this solution. I hope you like it too.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B8405BDB1C\n\tfor ;\n\tTue, 9 Nov 2021 00:43:14 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 07B436034A;\n\tTue, 9 Nov 2021 01:43:14 +0100 (CET)","from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com\n\t[IPv6:2a00:1450:4864:20::32b])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id DC11460121\n\tfor ;\n\tTue, 9 Nov 2021 01:43:11 +0100 (CET)","by mail-wm1-x32b.google.com with SMTP id 71so14406698wma.4\n\tfor ;\n\tMon, 08 Nov 2021 16:43:11 -0800 (PST)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\to1sm18562223wru.91.2021.11.08.16.43.10\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 08 Nov 2021 16:43:11 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"bEPhcld/\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=oGjp5b4ngUffl2yK6piZs/YOocjtH4nFxXbL9t6FXbY=;\n\tb=bEPhcld/t8F5IP60hlDo7ioOSRzmp0UeovpIevJ3exH17uZia47Za4lhFif1+IT16P\n\tiuqOC2agQtX3j+HBMOwigLjr8Wbx5a08oYNQeqWmKmeDE065cTeZvW2F8bb0bZeo40jP\n\t2rv/wCmdHbAkcvnMzZe0qgVYcS82981SJzV6HhqHV/bBGyJd3H1ueaJQKebEJ0MT6I7f\n\tIm9slbdTazfUXJUpk9tEUDvaT8CZFrzkCDhsjXwUW7DTcf7F+oXAUp0Mzf6nGxzQ0G6T\n\tPEuerVtXZ0uQKXU7PHtc1XWIbmDwpZongnBEN88SOmpgbC6Y9tIaREX40u2z8gJVciIZ\n\ts1NA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=oGjp5b4ngUffl2yK6piZs/YOocjtH4nFxXbL9t6FXbY=;\n\tb=U9re3wJxvVWZz977wqK9IQPOu2TM/p5Q9DU43ZS5yW7ojIsSK6h2e0tbfj63zZZ+8t\n\t7/pJmlno2BXu/vcz9ixvcd20gupQIUH2AZpSjvx32Wc043+SDja9kgsUHT2rKPN+22r0\n\tcc5Sr9+9YB/u7kIaJxb16P91cLE4z5madT9Tubxa/59tiW+H3lx0iShmkBzXmLi+schq\n\t7IxIrJ/kr0siMgRprqJCNgFebufMDfvNGJbH1sTna6Sv7r5Cbuf0tezshmxzeM7Tf7D9\n\t1zjRYbN3edhd+5gBeHK5ehFP5Oq2SIAoODyeHRU+JoWtRF8PPbg4fPlxTSjYxvsrPXBA\n\t1Qgg==","X-Gm-Message-State":"AOAM530im30qeeH97ZZoOrhwW4kIHFInEYWSWqFtZlf4YcKUDvJiaN9n\n\t1fbs0rxrrUsiG4qsww+wPd0=","X-Google-Smtp-Source":"ABdhPJyzR8qXwOwt1M5n9Gm6tsOLF23PEVo2HUSouP+gxsPCg1MdePlp2EjHiPXuOxj4/izN8wIsvw==","X-Received":"by 2002:a1c:1f06:: with SMTP id f6mr2542069wmf.55.1636418591486; \n\tMon, 08 Nov 2021 16:43:11 -0800 (PST)","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t","From":"Daniel Scally ","Message-ID":"","Date":"Tue, 9 Nov 2021 00:43:10 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20750,"web_url":"https://patchwork.libcamera.org/comment/20750/","msgid":"","date":"2021-11-09T12:09:23","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 09/11/2021 00:43, Daniel Scally wrote:\n> Hi Hans\n>\n> On 08/11/2021 13:12, Hans de Goede wrote:\n>> Hi,\n>>\n>> On 11/2/21 00:43, Daniel Scally wrote:\n>>> Hi Hans\n>> \n>> \n>>\n>>>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>>>> with this). There seems to be a chicken and egg problem here though,\n>>>> because the v4l2subdev for the VCM does not register because of async stuff\n>>>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>>>> from the SSDB on the complete() callback won't work. But we can do this\n>>>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>>>> instead I guess ?\n>>> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n>>>\n>>>\n>>> 1. Create another software node against the cio2_sensor struct, with the\n>>> name coming from the vcm_types array\n>>>\n>>> 2. Assign that software node to board_info.swnode in\n>>> cio2_bridge_instantiate_vcm_i2c_client()\n>>>\n>>> 3. Add another entry to dev_properties for the sensor, that is named\n>>> \"lens-focus\" and contains a reference to the software_node created in #2\n>>> just like the references to the sensor/cio2 nodes.\n>>>\n>>>\n>>> This way when the sensor driver calls\n>>> v4l2_async_register_subdev_sensor() it should create a notifier that\n>>> looks for that VCM client to bind. I think then rather than putting\n>>> anything in the .bound() / .complete() callbacks, we should modify core\n>>> to do _something_ when async matching some subdevs. The something would\n>>> depend on the kind of devices that match, for example with the sensor\n>>> driver and the ipu3-cio2 driver, there's an entity whos function is\n>>> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n>>> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n>>> is going to result in media pad links being created. Similarly for our\n>>> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n>>> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n>>> either an interface link or a new kind of link (maybe\n>>> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n>>> that they form a single logical unit, which we can then report to libcamera.\n>>>\n>>>\n>>> Hope that makes sense...\n>> Ok, so I gave this a try, see the attached patches, but the v4l2-subdev for\n>> the VCM still does not show up.\n>\n> This is exactly where I got to over the weekend too\n>\n>> I think that instead I need to build a full link between the sensor\n>> and the VCM similar to the cio2 <-> sensor link. Both ends of that link\n>> have:\n>>\n>> \n>> |\n>> --> | sensor side and the link nr on the cio2 side\n>> |\n>> -->\n>> And then the 2 endpoints contain a swref property pointing to the\n>> other endpoint swnode.\n>>\n>> I think we need a similar setup adding a swnode child named\n>> (SWNODE_GRAPH_PORT_NAME_FMT, 1), to the nodes[SWNODE_SENSOR_HID] node.\n>>\n>> Note 1, since 0 is the \"port\" to the cio2, this new port child then\n>> gets an endpoint \"0\" child itself, likewise we add a \"port 0\" child\n>> to the vcm swnode, with a \"endpoint 0\" child below that and then have\n>> the 2 endpoints contain swref properties pointing to each other.\n>>\n>> I think that this will properly make the VCm part of the graph and\n>> will make its v4l2-subdev get instantiated when the graph is\n>> complete. Before I spend a bunch of time on implementing this,\n>> let me ask this:\n>>\n>> Does this sound reasonable / like I'm heading in the right direction?\n> I don't think that we need to add the software nodes as\n> ports/endpoints...as far as I can tell it ought to work like this:\n>\n>\n> 1. The sensor calls v4l2_async_register_subdev_sensor() which...\n>\n>     a) creates a notifier\n>\n>     b) looks for reference properties of the device's fwnode called\n> \"lens-focus\" and calls v4l2_async_notifier_add_fwnode_subdev() against\n> the reference, which tells the notifier it's connected to this other\n> fwnode and to expect it to bind.\n>\n> 2. When new subdevs are registered they get tested for a match against\n> the notifier registered in 1a that matches to their fwnode using\n> match_fwnode() [1]. This should work, on the grounds that we registered\n> the device using the board_info.swnode and registered a lens-focus\n> property that points to that software_node\n>\n> 3. When a match is found, the notifier's .bound() function is called.\n> When all the asds that the notifier expects are bound the notifier's\n> .complete() callback is called.\n>\n>\n> That's not working correctly for me at the moment, but I think this is a\n> surmountable problem rather than the wrong approach, so I'm just working\n> through the differences to try and get the matching working.\n\n\nOK, I eventually got this working - the dw9719 registers as\n/dev/v4l-subdev7 for me now ... long story short is the attached patch\nwas needed to make the references work, as the internals of v4l2 aren't\nchecking for fwnode->secondary. Prior to your latest series as well, an\nadditional problem was that once the VCMs fwnode was linked to the\nsensor's the .complete() callback for ipu3-cio2 would never call\n(because it needs ALL the devices for the linked fwnodes to be bound to\ndo that)...which meant the VCMs never got instantiated, because that was\nwhere that function was called. With your new set separating those\nprocesses it works well, so yes I like that new approach very much :D\n\n\nIn the end we don't have to add a call creating the subdev's - it turns\nout that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\nthe nodes for the vcm when .complete() is called for that driver. I\nstill think we should add a bit creating the link to expose to userspace\nin match_notify() though.\n\n\nTrying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n-L fails with an IOCTL error, so I have some remedial work on the driver\nwhich I'll do tonight; I'd expect to be able to control focus with\nv4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n\n>\n>\n> For the devnodes, the ipu3-cio2 driver itself creates the devnodes for\n> the subdevices that bind to it (like the sensor) as part of its\n> .complete() callback [2] by calling v4l2_device_register_subdev_nodes(),\n> as far as I can tell there's nothing in v4l2 core that handles that\n> automatically so I think that that lack is what's preventing the\n> devnodes from showing up. I think we should tackle the problem of the\n> missing devnodes by mimicking the effects of that function somewhere\n> within core, probably v4l2_async_match_notify() (which calls the\n> notifier's .bound() callback). I think the creation of the links to\n> expose to userspace that this is a logical unit should probably happen\n> in the same place, using the entity.function field of the subdev and the\n> asd to decide exactly what kind of link to create.\n>\n>\n> [1]\n> https://elixir.bootlin.com/linux/latest/source/drivers/media/v4l2-core/v4l2-async.c#L69\n>\n> [2]\n> https://elixir.bootlin.com/linux/latest/source/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c#L1449\n>\n>> Regards,\n>>\n>> Hans\n>>\n>>\n>>\n>> p.s.\n>>\n>> I have found a new solution for the probe-ordering problem which\n>> is patch 2 of the attached patches, I personally I'm happy with\n>> this solution. I hope you like it too.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9EF47BF415\n\tfor ;\n\tTue, 9 Nov 2021 12:09:26 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4F73B6034E;\n\tTue, 9 Nov 2021 13:09:26 +0100 (CET)","from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com\n\t[IPv6:2a00:1450:4864:20::42b])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 7A6EA600BF\n\tfor ;\n\tTue, 9 Nov 2021 13:09:25 +0100 (CET)","by mail-wr1-x42b.google.com with SMTP id d3so32564563wrh.8\n\tfor ;\n\tTue, 09 Nov 2021 04:09:25 -0800 (PST)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\tp12sm23586548wrr.10.2021.11.09.04.09.24\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tTue, 09 Nov 2021 04:09:24 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"jsNvb8EW\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:from:to:cc:references:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language;\n\tbh=qI2NcGAePU0B0rW4aThWEvdBvfzm1F9Y1ZUvzLzW3vo=;\n\tb=jsNvb8EWBFERmUlleteMCicR9fEnSJb6xOohRH7AJgCNUeNsniy/2FrkRHsfGs3PXP\n\tljIy0xPtrEWNVOQx/EgGew/a/4zPre1FZsMxehQA7LClMBGJNby2h2BxGo2LJXJXFcm6\n\tKaOOjvY5D/8E6Fd1FqTDvwQhE317jb6Dqf+sIUACeh6uvoyYoSW05MVeRnYFlOgrPyEf\n\tRudZPPCFtUzbwANGbQkVWiFfA4wp1J/7ePyQZSrC8Ja/6PM4G4eHqiwmAWI3fU8LAgQJ\n\tZJ0eyrJS0AKMn8ATSw7onxVd+jTd/GlNeFoQMZD2ZqwgLV41H/AmsrQNGQ4TUH8OF3o8\n\tihjg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:from:to:cc:references:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language;\n\tbh=qI2NcGAePU0B0rW4aThWEvdBvfzm1F9Y1ZUvzLzW3vo=;\n\tb=Zv3hZ/FchDH2LRXnrERwzJNI7jbgOYibESmM6khioMd2Q/M793jgJNaCXwqCuZXvEN\n\tXF37vDHtBBeMi9i0Xt8Fg6AGSL9Kpap5xosa7Is6my8t9QlOiAY92KbUVt2Kp8KokGpq\n\t161YAuJwG9Bs/0sC4WvELC17Ar5/OVKrES9nCnMTJtdoCQsT3VhHWE2LfCkfp94xccSY\n\tTwcsFHf7Y636T75ZMl6jOkUxghyxeUKZqkSDDbZpvGOV8a+fj0gDciiTI42UIjhEM2ae\n\tRQY2RQq8gq2EWbozgFZjmkqoES8OqZGvTfBwxTs8ZLzYrz684f3A6fdMkA+ZcHXhdok2\n\tyLxQ==","X-Gm-Message-State":"AOAM532BEZ8Pd8ltPKxO6etX374RO2e0J5xYIGWLCwbnpzwL6urXL4y3\n\tnULA2RlaVrIzci3wcUIDutU=","X-Google-Smtp-Source":"ABdhPJxYqbTtsnVMHGXZbMgsCMBh1UUKtFPriRY4BlsipYhOyrH2HRS+Qmvk1UxwaznTcbG1gLkcsA==","X-Received":"by 2002:adf:df0c:: with SMTP id\n\ty12mr9119139wrl.168.1636459765176; \n\tTue, 09 Nov 2021 04:09:25 -0800 (PST)","From":"Daniel Scally ","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t","Message-ID":"","Date":"Tue, 9 Nov 2021 12:09:23 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"multipart/mixed;\n\tboundary=\"------------FE25CACB98F1C2A5B8B0BD71\"","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20760,"web_url":"https://patchwork.libcamera.org/comment/20760/","msgid":"","date":"2021-11-09T16:02:20","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/9/21 13:09, Daniel Scally wrote:\n> Hi Hans\n> \n> On 09/11/2021 00:43, Daniel Scally wrote:\n>> Hi Hans\n>>\n>> On 08/11/2021 13:12, Hans de Goede wrote:\n>>> Hi,\n>>>\n>>> On 11/2/21 00:43, Daniel Scally wrote:\n>>>> Hi Hans\n>>> \n>>> \n>>>\n>>>>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>>>>> with this). There seems to be a chicken and egg problem here though,\n>>>>> because the v4l2subdev for the VCM does not register because of async stuff\n>>>>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>>>>> from the SSDB on the complete() callback won't work. But we can do this\n>>>>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>>>>> instead I guess ?\n>>>> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n>>>>\n>>>>\n>>>> 1. Create another software node against the cio2_sensor struct, with the\n>>>> name coming from the vcm_types array\n>>>>\n>>>> 2. Assign that software node to board_info.swnode in\n>>>> cio2_bridge_instantiate_vcm_i2c_client()\n>>>>\n>>>> 3. Add another entry to dev_properties for the sensor, that is named\n>>>> \"lens-focus\" and contains a reference to the software_node created in #2\n>>>> just like the references to the sensor/cio2 nodes.\n>>>>\n>>>>\n>>>> This way when the sensor driver calls\n>>>> v4l2_async_register_subdev_sensor() it should create a notifier that\n>>>> looks for that VCM client to bind. I think then rather than putting\n>>>> anything in the .bound() / .complete() callbacks, we should modify core\n>>>> to do _something_ when async matching some subdevs. The something would\n>>>> depend on the kind of devices that match, for example with the sensor\n>>>> driver and the ipu3-cio2 driver, there's an entity whos function is\n>>>> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n>>>> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n>>>> is going to result in media pad links being created. Similarly for our\n>>>> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n>>>> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n>>>> either an interface link or a new kind of link (maybe\n>>>> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n>>>> that they form a single logical unit, which we can then report to libcamera.\n>>>>\n>>>>\n>>>> Hope that makes sense...\n>>> Ok, so I gave this a try, see the attached patches, but the v4l2-subdev for\n>>> the VCM still does not show up.\n>>\n>> This is exactly where I got to over the weekend too\n>>\n>>> I think that instead I need to build a full link between the sensor\n>>> and the VCM similar to the cio2 <-> sensor link. Both ends of that link\n>>> have:\n>>>\n>>> \n>>> |\n>>> -->> | sensor side and the link nr on the cio2 side\n>>> |\n>>> -->>\n>>> And then the 2 endpoints contain a swref property pointing to the\n>>> other endpoint swnode.\n>>>\n>>> I think we need a similar setup adding a swnode child named\n>>> (SWNODE_GRAPH_PORT_NAME_FMT, 1), to the nodes[SWNODE_SENSOR_HID] node.\n>>>\n>>> Note 1, since 0 is the \"port\" to the cio2, this new port child then\n>>> gets an endpoint \"0\" child itself, likewise we add a \"port 0\" child\n>>> to the vcm swnode, with a \"endpoint 0\" child below that and then have\n>>> the 2 endpoints contain swref properties pointing to each other.\n>>>\n>>> I think that this will properly make the VCm part of the graph and\n>>> will make its v4l2-subdev get instantiated when the graph is\n>>> complete. Before I spend a bunch of time on implementing this,\n>>> let me ask this:\n>>>\n>>> Does this sound reasonable / like I'm heading in the right direction?\n>> I don't think that we need to add the software nodes as\n>> ports/endpoints...as far as I can tell it ought to work like this:\n>>\n>>\n>> 1. The sensor calls v4l2_async_register_subdev_sensor() which...\n>>\n>>     a) creates a notifier\n>>\n>>     b) looks for reference properties of the device's fwnode called\n>> \"lens-focus\" and calls v4l2_async_notifier_add_fwnode_subdev() against\n>> the reference, which tells the notifier it's connected to this other\n>> fwnode and to expect it to bind.\n>>\n>> 2. When new subdevs are registered they get tested for a match against\n>> the notifier registered in 1a that matches to their fwnode using\n>> match_fwnode() [1]. This should work, on the grounds that we registered\n>> the device using the board_info.swnode and registered a lens-focus\n>> property that points to that software_node\n>>\n>> 3. When a match is found, the notifier's .bound() function is called.\n>> When all the asds that the notifier expects are bound the notifier's\n>> .complete() callback is called.\n>>\n>>\n>> That's not working correctly for me at the moment, but I think this is a\n>> surmountable problem rather than the wrong approach, so I'm just working\n>> through the differences to try and get the matching working.\n> \n> \n> OK, I eventually got this working - the dw9719 registers as\n> /dev/v4l-subdev7 for me now ... long story short is the attached patch\n> was needed to make the references work, as the internals of v4l2 aren't\n> checking for fwnode->secondary. Prior to your latest series as well, an\n> additional problem was that once the VCMs fwnode was linked to the\n> sensor's the .complete() callback for ipu3-cio2 would never call\n> (because it needs ALL the devices for the linked fwnodes to be bound to\n> do that)...which meant the VCMs never got instantiated, because that was\n> where that function was called. With your new set separating those\n> processes it works well, so yes I like that new approach very much :D\n> \n> \n> In the end we don't have to add a call creating the subdev's - it turns\n> out that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\n> the nodes for the vcm when .complete() is called for that driver. I\n> still think we should add a bit creating the link to expose to userspace\n> in match_notify() though.\n> \n> \n> Trying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n> -L fails with an IOCTL error, so I have some remedial work on the driver\n> which I'll do tonight; I'd expect to be able to control focus with\n> v4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n\nThat is great, thank you so much. I wanted to look into this myself\ntoday but I got distracted by other stuff.\n\nMainly getting Windows to work (including cameras) after a fresh\nWindows install on A Dell Latitude 7285 which I just got as a second\ndevice to test IPU3 stuff on :)\n\nTalking about this Dell Latitude 7285, I haven't had a chance to\nlook into this at all. But chances are I will need to do some\nI2C-register dumps under Windows, last time you mentioned you\nhad some small tool for this ? It is ok if it is a bit hackish,\nit will still be very useful to have :) And I believe I will\nalso need to override the DSDT under Windows for this, right?\nI should be able to cope with that too.\n\nRegards,\n\nHans\n\n> \n>>\n>>\n>> For the devnodes, the ipu3-cio2 driver itself creates the devnodes for\n>> the subdevices that bind to it (like the sensor) as part of its\n>> .complete() callback [2] by calling v4l2_device_register_subdev_nodes(),\n>> as far as I can tell there's nothing in v4l2 core that handles that\n>> automatically so I think that that lack is what's preventing the\n>> devnodes from showing up. I think we should tackle the problem of the\n>> missing devnodes by mimicking the effects of that function somewhere\n>> within core, probably v4l2_async_match_notify() (which calls the\n>> notifier's .bound() callback). I think the creation of the links to\n>> expose to userspace that this is a logical unit should probably happen\n>> in the same place, using the entity.function field of the subdev and the\n>> asd to decide exactly what kind of link to create.\n>>\n>>\n>> [1]\n>> https://elixir.bootlin.com/linux/latest/source/drivers/media/v4l2-core/v4l2-async.c#L69\n>>\n>> [2]\n>> https://elixir.bootlin.com/linux/latest/source/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c#L1449\n>>\n>>> Regards,\n>>>\n>>> Hans\n>>>\n>>>\n>>>\n>>> p.s.\n>>>\n>>> I have found a new solution for the probe-ordering problem which\n>>> is patch 2 of the attached patches, I personally I'm happy with\n>>> this solution. I hope you like it too.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 7EA03BF415\n\tfor ;\n\tTue, 9 Nov 2021 16:02:39 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8B0D06035D;\n\tTue, 9 Nov 2021 17:02:38 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 8982A600BF\n\tfor ;\n\tTue, 9 Nov 2021 17:02:36 +0100 (CET)","from mail-ed1-f70.google.com (mail-ed1-f70.google.com\n\t[209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-37-bGCHA_MoNyC91G5VtoaZnQ-1; Tue, 09 Nov 2021 11:02:23 -0500","by mail-ed1-f70.google.com with SMTP id\n\tw26-20020a056402071a00b003e28a389d04so18305937edx.4\n\tfor ;\n\tTue, 09 Nov 2021 08:02:23 -0800 (PST)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\tj12sm7935771edr.67.2021.11.09.08.02.21\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tTue, 09 Nov 2021 08:02:21 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"K1g6ylXC\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636473755;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=QeqhO8LdgIwx7XbjD5FvYnW4mubWV0mM0TFuqZnc/DA=;\n\tb=K1g6ylXCPfC5L/p+Xj0lCOc+QepN0P1WOMeJYiuiOquQfRAupfgjqnzvkRHwSnTHcoNvrW\n\tG3s7a9g8fQwPkEQaq7W3DaYtGYRHLC1h5IOu04GM5sHOgzLN9fvgzeM1Sr40b9MZTA5sYZ\n\tvd1d2AK7fndx8803mklsWmAJ3t5B6IM=","X-MC-Unique":"bGCHA_MoNyC91G5VtoaZnQ-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=QeqhO8LdgIwx7XbjD5FvYnW4mubWV0mM0TFuqZnc/DA=;\n\tb=gOu8QQEhJaW+q2di8PGGsT1L43xj6Qm2QtG8LcQAjxPTd9MJdH01FyJ4uc399sX560\n\tkGDMY6h/+zuKD8BUrNDAsSP6h5p/dP3anEeTuCtOKHWz79ibBKKHmQG/dHkjHF1wP7/M\n\t0E5LF9llpUTcNfroSxGig4TDTAaFqxCE8X4W1HHClasriHaPpsMfqRfdWCH2b9a90JXw\n\tNKycRjtJ4vFc1TZtdaXrbLeHNra1pl0MyCaD2WuiUOO07OOyqMTz9qpVcPuoXMjlesfj\n\tdAvArUg1isfPy1W8DmvYv+oX5a6VAWBXQhkhJSHPXENK+wCPDjdN7x6qcOtO2B8aKTwA\n\t2g6A==","X-Gm-Message-State":"AOAM5312sUB5tVQRnDvnz38TI9rwKr0hU3g/L4k7/TT112xL5+/CNhc+\n\t4iuKUQ87YCArlBLYtQdr3cIEJWuvWu1oHhhAcm4pqZQE0N6JtWnmMo+kjDe0+Q/l74g7j8jr172\n\tC4C0tSRtyRB5+bsLVIbYpx8e/7swt+LDXnw==","X-Received":["by 2002:a05:6402:40ce:: with SMTP id\n\tz14mr11579020edb.294.1636473742233; \n\tTue, 09 Nov 2021 08:02:22 -0800 (PST)","by 2002:a05:6402:40ce:: with SMTP id\n\tz14mr11578950edb.294.1636473741794; \n\tTue, 09 Nov 2021 08:02:21 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJzVRpywvrSngrG7kUBo7sP/71HjmFnhRIAM+b7cH42+c+jO8Y7rsw5KyqGMQU4dJNH3RCpNQg==","Message-ID":"","Date":"Tue, 9 Nov 2021 17:02:20 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t","From":"Hans de Goede ","In-Reply-To":"","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20764,"web_url":"https://patchwork.libcamera.org/comment/20764/","msgid":"<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","date":"2021-11-09T16:35:57","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 09/11/2021 16:02, Hans de Goede wrote:\n> Hi,\n>\n> On 11/9/21 13:09, Daniel Scally wrote:\n>> Hi Hans\n>>\n>> On 09/11/2021 00:43, Daniel Scally wrote:\n>>> Hi Hans\n>>>\n>>> On 08/11/2021 13:12, Hans de Goede wrote:\n>>>> Hi,\n>>>>\n>>>> On 11/2/21 00:43, Daniel Scally wrote:\n>>>>> Hi Hans\n>>>> \n>>>> \n>>>>\n>>>>>> 2. I need some help with all the fwnode link stuff (I'm not very familiar\n>>>>>> with this). There seems to be a chicken and egg problem here though,\n>>>>>> because the v4l2subdev for the VCM does not register because of async stuff\n>>>>>> and if we add it to the \"graph\" then my idea to enumerate the VCMs\n>>>>>> from the SSDB on the complete() callback won't work. But we can do this\n>>>>>> on a per sensor basis instead from the cio2_notifier_bound() callback\n>>>>>> instead I guess ?\n>>>>> I think on top of your work in the cio2-bridge for patch 3 you can do this:\n>>>>>\n>>>>>\n>>>>> 1. Create another software node against the cio2_sensor struct, with the\n>>>>> name coming from the vcm_types array\n>>>>>\n>>>>> 2. Assign that software node to board_info.swnode in\n>>>>> cio2_bridge_instantiate_vcm_i2c_client()\n>>>>>\n>>>>> 3. Add another entry to dev_properties for the sensor, that is named\n>>>>> \"lens-focus\" and contains a reference to the software_node created in #2\n>>>>> just like the references to the sensor/cio2 nodes.\n>>>>>\n>>>>>\n>>>>> This way when the sensor driver calls\n>>>>> v4l2_async_register_subdev_sensor() it should create a notifier that\n>>>>> looks for that VCM client to bind. I think then rather than putting\n>>>>> anything in the .bound() / .complete() callbacks, we should modify core\n>>>>> to do _something_ when async matching some subdevs. The something would\n>>>>> depend on the kind of devices that match, for example with the sensor\n>>>>> driver and the ipu3-cio2 driver, there's an entity whos function is\n>>>>> MEDIA_ENT_F_VID_IF_BRIDGE matching to an entity whos function is\n>>>>> MEDIA_ENT_F_CAM_SENSOR, and it seems to me that every scenario like that\n>>>>> is going to result in media pad links being created. Similarly for our\n>>>>> sensor that's a device with entity function MEDIA_ENT_F_LENS matching to\n>>>>> MEDIA_ENT_F_CAM_SENSOR, and I think that in those cases we can create\n>>>>> either an interface link or a new kind of link (maybe\n>>>>> \"MEDIA_LNK_FL_ANCILLARY_LINK\" or something...) between the two to show\n>>>>> that they form a single logical unit, which we can then report to libcamera.\n>>>>>\n>>>>>\n>>>>> Hope that makes sense...\n>>>> Ok, so I gave this a try, see the attached patches, but the v4l2-subdev for\n>>>> the VCM still does not show up.\n>>> This is exactly where I got to over the weekend too\n>>>\n>>>> I think that instead I need to build a full link between the sensor\n>>>> and the VCM similar to the cio2 <-> sensor link. Both ends of that link\n>>>> have:\n>>>>\n>>>> \n>>>> |\n>>>> -->>> | sensor side and the link nr on the cio2 side\n>>>> |\n>>>> -->>>\n>>>> And then the 2 endpoints contain a swref property pointing to the\n>>>> other endpoint swnode.\n>>>>\n>>>> I think we need a similar setup adding a swnode child named\n>>>> (SWNODE_GRAPH_PORT_NAME_FMT, 1), to the nodes[SWNODE_SENSOR_HID] node.\n>>>>\n>>>> Note 1, since 0 is the \"port\" to the cio2, this new port child then\n>>>> gets an endpoint \"0\" child itself, likewise we add a \"port 0\" child\n>>>> to the vcm swnode, with a \"endpoint 0\" child below that and then have\n>>>> the 2 endpoints contain swref properties pointing to each other.\n>>>>\n>>>> I think that this will properly make the VCm part of the graph and\n>>>> will make its v4l2-subdev get instantiated when the graph is\n>>>> complete. Before I spend a bunch of time on implementing this,\n>>>> let me ask this:\n>>>>\n>>>> Does this sound reasonable / like I'm heading in the right direction?\n>>> I don't think that we need to add the software nodes as\n>>> ports/endpoints...as far as I can tell it ought to work like this:\n>>>\n>>>\n>>> 1. The sensor calls v4l2_async_register_subdev_sensor() which...\n>>>\n>>>     a) creates a notifier\n>>>\n>>>     b) looks for reference properties of the device's fwnode called\n>>> \"lens-focus\" and calls v4l2_async_notifier_add_fwnode_subdev() against\n>>> the reference, which tells the notifier it's connected to this other\n>>> fwnode and to expect it to bind.\n>>>\n>>> 2. When new subdevs are registered they get tested for a match against\n>>> the notifier registered in 1a that matches to their fwnode using\n>>> match_fwnode() [1]. This should work, on the grounds that we registered\n>>> the device using the board_info.swnode and registered a lens-focus\n>>> property that points to that software_node\n>>>\n>>> 3. When a match is found, the notifier's .bound() function is called.\n>>> When all the asds that the notifier expects are bound the notifier's\n>>> .complete() callback is called.\n>>>\n>>>\n>>> That's not working correctly for me at the moment, but I think this is a\n>>> surmountable problem rather than the wrong approach, so I'm just working\n>>> through the differences to try and get the matching working.\n>>\n>> OK, I eventually got this working - the dw9719 registers as\n>> /dev/v4l-subdev7 for me now ... long story short is the attached patch\n>> was needed to make the references work, as the internals of v4l2 aren't\n>> checking for fwnode->secondary. Prior to your latest series as well, an\n>> additional problem was that once the VCMs fwnode was linked to the\n>> sensor's the .complete() callback for ipu3-cio2 would never call\n>> (because it needs ALL the devices for the linked fwnodes to be bound to\n>> do that)...which meant the VCMs never got instantiated, because that was\n>> where that function was called. With your new set separating those\n>> processes it works well, so yes I like that new approach very much :D\n>>\n>>\n>> In the end we don't have to add a call creating the subdev's - it turns\n>> out that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\n>> the nodes for the vcm when .complete() is called for that driver. I\n>> still think we should add a bit creating the link to expose to userspace\n>> in match_notify() though.\n>>\n>>\n>> Trying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n>> -L fails with an IOCTL error, so I have some remedial work on the driver\n>> which I'll do tonight; I'd expect to be able to control focus with\n>> v4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n> That is great, thank you so much. I wanted to look into this myself\n> today but I got distracted by other stuff.\n\n\nNo problem; I'll link you the patches for the updated versions of\neverything once I've sorted the IOCTL error tonight.\n\n> Mainly getting Windows to work (including cameras) after a fresh\n> Windows install on A Dell Latitude 7285 which I just got as a secondFwiw I gave up \n> device to test IPU3 stuff on :)\n>\n> Talking about this Dell Latitude 7285, I haven't had a chance to\n> look into this at all. But chances are I will need to do some\n> I2C-register dumps under Windows, last time you mentioned you\n> had some small tool for this ? It is ok if it is a bit hackish,\n> it will still be very useful to have :) And I believe I will\n> also need to override the DSDT under Windows for this, right?\n> I should be able to cope with that too.\n\n\nSo the tool I was using was the I2cTestTool [1], which requires you to\nfirst hack the DSDT to enable usermode access [2]. You need the\nMicrosoft ASL compiler [3] to insert the new DSDT, but fwiw I gave up\ntrying to use their tool to actually compile the table and just did it\nrunning Ubuntu with iasl, then saved the file onto the Go2's SD card and\nloaded it using asl.exe in Windows...the MS tool just wouldn't compile\nfor whatever reason.\n\n\nAll that said; you don't actually need to do this for the Latitude 7285\n- on the Github thread a chap with that device found the schematics and\nposted them [4], so we should already have the information we need to\npopulate the board data for that one. The sensor drivers need some work\nthough - the ov9734 I have a series somewhere that I think should work\nbut haven't ever tested, the ov8858 I don't think anyone's looked at yet.\n\n\n[1]\nhttps://github.com/microsoft/Windows-iotcore-samples/tree/develop/BusTools/I2cTestTool\n\n[2]\nhttps://docs.microsoft.com/en-us/windows/uwp/devices-sensors/enable-usermode-access\n\n[3]\nhttps://docs.microsoft.com/en-gb/windows-hardware/drivers/bringup/microsoft-asl-compiler\n\n[4]\nhttps://github.com/linux-surface/linux-surface/issues/91#issuecomment-829641311\n\n>\n> Regards,\n>\n> Hans\n>\n>>>\n>>> For the devnodes, the ipu3-cio2 driver itself creates the devnodes for\n>>> the subdevices that bind to it (like the sensor) as part of its\n>>> .complete() callback [2] by calling v4l2_device_register_subdev_nodes(),\n>>> as far as I can tell there's nothing in v4l2 core that handles that\n>>> automatically so I think that that lack is what's preventing the\n>>> devnodes from showing up. I think we should tackle the problem of the\n>>> missing devnodes by mimicking the effects of that function somewhere\n>>> within core, probably v4l2_async_match_notify() (which calls the\n>>> notifier's .bound() callback). I think the creation of the links to\n>>> expose to userspace that this is a logical unit should probably happen\n>>> in the same place, using the entity.function field of the subdev and the\n>>> asd to decide exactly what kind of link to create.\n>>>\n>>>\n>>> [1]\n>>> https://elixir.bootlin.com/linux/latest/source/drivers/media/v4l2-core/v4l2-async.c#L69\n>>>\n>>> [2]\n>>> https://elixir.bootlin.com/linux/latest/source/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c#L1449\n>>>\n>>>> Regards,\n>>>>\n>>>> Hans\n>>>>\n>>>>\n>>>>\n>>>> p.s.\n>>>>\n>>>> I have found a new solution for the probe-ordering problem which\n>>>> is patch 2 of the attached patches, I personally I'm happy with\n>>>> this solution. I hope you like it too.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id EA515BDB1C\n\tfor ;\n\tTue, 9 Nov 2021 16:36:01 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 979626034E;\n\tTue, 9 Nov 2021 17:36:01 +0100 (CET)","from mail-wr1-x435.google.com (mail-wr1-x435.google.com\n\t[IPv6:2a00:1450:4864:20::435])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 64AB1600BF\n\tfor ;\n\tTue, 9 Nov 2021 17:36:00 +0100 (CET)","by mail-wr1-x435.google.com with SMTP id n29so22311482wra.11\n\tfor ;\n\tTue, 09 Nov 2021 08:36:00 -0800 (PST)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\tc15sm19960503wrs.19.2021.11.09.08.35.57\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tTue, 09 Nov 2021 08:35:58 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"eigByJhJ\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=9eIj1bbtg5HOMIrS+ELWUQu2fqK0JhvhSVburvo43vk=;\n\tb=eigByJhJE5x1DzSJ0tYxWsIlcYTV6BV0XobkwTzxcCSBUtIHt43ZyqGCwX+MHFQkTD\n\tMPTJ6qy6aNwGytQLR54QK4DiDdMXxDQpkLkVwCOn+m7qJ5dNl0DoBIizewhmBAe7HbyJ\n\tr5HLy4yMhWuiZvDXb08NOxWESQxJnzupU3Wi6uVdL4snKI89DKC8MLa0Hyy/JXwebeP5\n\ty0yk3CKVjs2Yi++M6eV9VOpb9is7d8TmnqrF1jt8SiijU6x47vOJfUUnKHLPFSSSC5sI\n\tBbK62b7u11Mxz4XrUlK2+uMTT/a4mCvzluAXZAPSjdJKrVHzHUvnFXj3qgz4uOnzWke+\n\t1XwQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=9eIj1bbtg5HOMIrS+ELWUQu2fqK0JhvhSVburvo43vk=;\n\tb=XgBwFheSm1GihIJQ17gNKrCufe2/QhJ7ndHRRjBeCA4gMJ3YMpGgdGQDS/ZGqxo3fq\n\to0D90BCXpIFt95Vu9ioRflSdKORg8vgeKLyydRXPerhpu+5Q/wrSUDwTSKdyI1w6MHoY\n\t281YN5ydB6Kwy4vJ0PeQXZ3ia7OnOfzgKB49sKyoJEZSk5oiOV0wXlPcuMe8DhdNelhW\n\taXNBCLcLONPkJQ1SXbsH5P6V7Xv8fQlw0WMVt6VUhsdAQJLes2URZK94fEZ0/W0A3gPp\n\t7Za3R5SYAiV5B/U1sEv14/zUaCouT78la1Es1TC3K1Muj16A+BBizCzKv4jWFPfv881B\n\tbUgA==","X-Gm-Message-State":"AOAM5327rcTprfu4ddWGBbOeduY83d7QZJoUgnVsUvaUvLAsakDAQEEv\n\tbZaeF5wtETcduUl7LeZrEzxTPoFrTvM=","X-Google-Smtp-Source":"ABdhPJxEvnVy6eMvKW32RB5SBp4FqKwoi/sFpf88FuRe4RsqzpcGiBn5gSytYFiTzeJZSr/mDfjQww==","X-Received":"by 2002:adf:fdc3:: with SMTP id\n\ti3mr10833289wrs.200.1636475759955; \n\tTue, 09 Nov 2021 08:35:59 -0800 (PST)","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t","From":"Daniel Scally ","Message-ID":"<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","Date":"Tue, 9 Nov 2021 16:35:57 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20776,"web_url":"https://patchwork.libcamera.org/comment/20776/","msgid":"<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","date":"2021-11-10T00:01:19","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hi Hans\n\nOn 09/11/2021 16:35, Daniel Scally wrote:\n>>>> That's not working correctly for me at the moment, but I think this is a\n>>>> surmountable problem rather than the wrong approach, so I'm just working\n>>>> through the differences to try and get the matching working.\n>>> OK, I eventually got this working - the dw9719 registers as\n>>> /dev/v4l-subdev7 for me now ... long story short is the attached patch\n>>> was needed to make the references work, as the internals of v4l2 aren't\n>>> checking for fwnode->secondary. Prior to your latest series as well, an\n>>> additional problem was that once the VCMs fwnode was linked to the\n>>> sensor's the .complete() callback for ipu3-cio2 would never call\n>>> (because it needs ALL the devices for the linked fwnodes to be bound to\n>>> do that)...which meant the VCMs never got instantiated, because that was\n>>> where that function was called. With your new set separating those\n>>> processes it works well, so yes I like that new approach very much :D\n>>>\n>>>\n>>> In the end we don't have to add a call creating the subdev's - it turns\n>>> out that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\n>>> the nodes for the vcm when .complete() is called for that driver. I\n>>> still think we should add a bit creating the link to expose to userspace\n>>> in match_notify() though.\n>>>\n>>>\n>>> Trying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n>>> -L fails with an IOCTL error, so I have some remedial work on the driver\n>>> which I'll do tonight; I'd expect to be able to control focus with\n>>> v4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n>> That is great, thank you so much. I wanted to look into this myself\n>> today but I got distracted by other stuff.\n>\n> No problem; I'll link you the patches for the updated versions of\n> everything once I've sorted the IOCTL error tonight.\n\n\nOK, this is running now. With the attached patches on top of your v5\nseries and the 4-patch series from earlier today, the dw9719 registers\nas a v4l2 subdev and I can control it with v4l2-ctl -d /dev/v4l-subdev7\n-c focus_absolute=1200 (or whatever value). One problem I'm experiencing\nis that the focus position I set isn't maintained; it holds for a couple\nof seconds and then resets to the \"normal\" focus...this happens when the\n.close() callback for the driver is called, which happens right after\nthe control value is applied. All the other VCM drivers in the kernel\npower down on .close() so I did the same, but the behaviour is not\nparticularly useful - since removing the power seems to reset it, it\nneeds to be on whilst the linked sensor is streaming I suppose. Given\nthat ascertaining the state of the sensor probably will require some\nlink established between them anyway I guess I will look at that next,\nunless you'd rather do it?","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 8FD22BDB1C\n\tfor ;\n\tWed, 10 Nov 2021 00:01:24 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4A6CF6034E;\n\tWed, 10 Nov 2021 01:01:23 +0100 (CET)","from mail-wm1-x330.google.com (mail-wm1-x330.google.com\n\t[IPv6:2a00:1450:4864:20::330])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id BC25560234\n\tfor ;\n\tWed, 10 Nov 2021 01:01:21 +0100 (CET)","by mail-wm1-x330.google.com with SMTP id y196so602615wmc.3\n\tfor ;\n\tTue, 09 Nov 2021 16:01:21 -0800 (PST)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\to25sm4004261wms.17.2021.11.09.16.01.20\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tTue, 09 Nov 2021 16:01:20 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Vy1+fn6m\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:from:to:cc:references:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language;\n\tbh=75ySCRDyvjzi8ujH1E+qJNgup4xQ25gICqNWYdHvk/s=;\n\tb=Vy1+fn6mE2j0ZsY3psFTEE9jiwq4CnyiyYGbffH9vKb5X4KtEv5xz8fOWbW+BYKR/1\n\thGbUJ8Z1k0rjlXnWUbuflqhDFHe8891mDETZviI4n1Ui2ub7jO11xaXhSyXTGl+11Xut\n\t6f0rnGcuGyzJW4l57WFkr5LaE873mQFUzbU2nYSbUwDCpUhsYkAY6Vz6wrnDK+hCL9aE\n\tPQU0fiycxtexD9sUE5HhrqDRxOBG6Lcy4RqaqC4KO9caPU1Kj2ipiWV1u6DzU/Gc7cM+\n\tdt88EKYOyP0Q1cSsU8DhaIf0Sfy74Gw2+Y+Fl6LA+w4699/p8VjOymB3BKz7yT/caWuu\n\t9DGw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:from:to:cc:references:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language;\n\tbh=75ySCRDyvjzi8ujH1E+qJNgup4xQ25gICqNWYdHvk/s=;\n\tb=kYJ4pwYv7XFO+u9bBwbVY8v6QJDdyRSA5SwXE40pAUSBui+RpMlm9yFAUHjBSzsQWr\n\tdI5+c9T6RzJ6ykrba3uRalCfRnaO8RV5zhjyTv15g3biiDZExRTT0OD/Nfef6zZBWpoh\n\tTjZJscSeoPjjY3SY1a4hlkCOOgzqAShxpad/HcvUpND59FiXz3Jid0TFehM068NTOlIa\n\tpLwdKBWLgLuoeePZJ1Wub1P3xtRdRRAAwZCmcIE8xH/SDZxgvonb//h6y2H8d1K4DneO\n\tk7/UG+67MQyZr9ISPOaOn9sO/obxIT2+9/693DDfjosbKwxugJa3RaGNxvGC+ZECduK0\n\ttTig==","X-Gm-Message-State":"AOAM5328/xs2kb05GU8AOgiBdnOHYS/BQTptC2jOzqlgaWBznJ6h6kBu\n\tbVsA0Dm3Mrnt73kzgNj32QY=","X-Google-Smtp-Source":"ABdhPJy5D63IiwoDRki1MBWJ/T486XvwFzFwkDseiPn75fq6uEB0Q/fEAKsU3/juf+ZW8B3VfP6soA==","X-Received":"by 2002:a05:600c:2107:: with SMTP id\n\tu7mr11848642wml.82.1636502481303; \n\tTue, 09 Nov 2021 16:01:21 -0800 (PST)","From":"Daniel Scally ","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","Message-ID":"<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","Date":"Wed, 10 Nov 2021 00:01:19 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","Content-Type":"multipart/mixed;\n\tboundary=\"------------B01EC9D8B71A46848004E290\"","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20779,"web_url":"https://patchwork.libcamera.org/comment/20779/","msgid":"","date":"2021-11-10T08:15:07","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":103,"url":"https://patchwork.libcamera.org/api/people/103/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Wed, Nov 10, 2021 at 12:01:19AM +0000, Daniel Scally wrote:\n> On 09/11/2021 16:35, Daniel Scally wrote:\n\nSome comments to the code below.\n\n...\n\n> +static int dw9719_i2c_rd8(struct i2c_client *client, u8 reg, u8 *val)\n> +{\n> +\tstruct i2c_msg msg[2];\n\n> +\tu8 buf[2] = { reg };\n\nSee below.\n\n> +\tint ret;\n> +\n> +\tmsg[0].addr = client->addr;\n> +\tmsg[0].flags = 0;\n> +\tmsg[0].len = 1;\n> +\tmsg[0].buf = buf;\n> +\n> +\tmsg[1].addr = client->addr;\n> +\tmsg[1].flags = I2C_M_RD;\n> +\tmsg[1].len = 1;\n> +\tmsg[1].buf = &buf[1];\n> +\t*val = 0;\n> +\n> +\tret = i2c_transfer(client->adapter, msg, 2);\n> +\tif (ret < 0)\n> +\t\tgoto err;\n> +\n> +\t*val = buf[1];\n> +\n> +\treturn 0;\n\n> +err:\n> +\treturn ret;\n\nUseless. Return in-place.\n\n> +}\n\n...\n\n> +\tu8 buf[3] = { reg, (u8)(val >> 8), (u8)(val & 0xff)};\n\nThis, and similar cases, has endianess issue.\n\nYou are supposed to have __be16 or __le16 buffer with respect to the hardware.\nAnother way (since I looked at the other places) is to use put_unligned_*().\n\nAs per above this requires put_unaligned_be16().\n\n...\n\n> +\tpm_runtime_set_autosuspend_delay(&client->dev, 1000);\n\nWhy this can't be set by user space?\n\n...\n\n> Subject: [PATCH 2/3] device property: Check fwnode->secondary when finding\n> properties\n> \n> fwnode_property_get_reference_args() searches for named properties\n> against a fwnode_handle, but these could instead be against the fwnode's\n> secondary. If the property isn't found against the primary, check the\n> secondary to see if it's there instead.\n\nReviewed-by: Andy Shevchenko \n\n> Signed-off-by: Daniel Scally \n> ---\n> drivers/base/property.c | 12 ++++++++++--\n> 1 file changed, 10 insertions(+), 2 deletions(-)\n> \n> diff --git a/drivers/base/property.c b/drivers/base/property.c\n> index 453918eb7390..054e62a4e710 100644\n> --- a/drivers/base/property.c\n> +++ b/drivers/base/property.c\n> @@ -479,8 +479,16 @@ int fwnode_property_get_reference_args(const struct fwnode_handle *fwnode,\n> \t\t\t\t unsigned int nargs, unsigned int index,\n> \t\t\t\t struct fwnode_reference_args *args)\n> {\n> -\treturn fwnode_call_int_op(fwnode, get_reference_args, prop, nargs_prop,\n> -\t\t\t\t nargs, index, args);\n> +\tint ret;\n> +\n> +\tret = fwnode_call_int_op(fwnode, get_reference_args, prop, nargs_prop,\n> +\t\t\t\t nargs, index, args);\n> +\n> +\tif (ret < 0 && !IS_ERR_OR_NULL(fwnode->secondary))\n> +\t\tret = fwnode_call_int_op(fwnode->secondary, get_reference_args,\n> +\t\t\t\t\t prop, nargs_prop, nargs, index, args);\n> +\n> +\treturn ret;\n> }\n> EXPORT_SYMBOL_GPL(fwnode_property_get_reference_args);\n> \n> -- \n> 2.25.1\n> \n\n> From dd7532ddea71482502394b6b36c9fd3e5f2a0a37 Mon Sep 17 00:00:00 2001\n> From: Daniel Scally \n> Date: Tue, 9 Nov 2021 23:12:06 +0000\n> Subject: [PATCH 1/3] platform/x86: int3472: Add vsio regulator supply to board\n> file\n> \n> The Surface Go2 board file needs to additionally specify a supply name\n> mapping the VSIO regulator to the world facing camera's VCM device, as\n> it can sit behind an I2C daisy chain which requires this regulator be\n> enabled to function.\n\nReviewed-by: Andy Shevchenko \n\n> Signed-off-by: Daniel Scally \n> ---\n> drivers/platform/x86/intel/int3472/tps68470_board_data.c | 1 +\n> 1 file changed, 1 insertion(+)\n> \n> diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c\n> index 20615c342875..556a615afaa9 100644\n> --- a/drivers/platform/x86/intel/int3472/tps68470_board_data.c\n> +++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c\n> @@ -29,6 +29,7 @@ static struct regulator_consumer_supply int347a_vcm_consumer_supplies[] = {\n> \n> static struct regulator_consumer_supply int347a_vsio_consumer_supplies[] = {\n> \tREGULATOR_SUPPLY(\"dovdd\", \"i2c-INT347A:00\"),\n> +\tREGULATOR_SUPPLY(\"vsio\", \"i2c-INT347A:00-VCM\"),\n> };\n> \n> static const struct regulator_init_data surface_go_tps68470_core_reg_init_data = {\n> -- \n> 2.25.1\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B3DBCBDB1C\n\tfor ;\n\tWed, 10 Nov 2021 08:15:26 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 12CA46035A;\n\tWed, 10 Nov 2021 09:15:26 +0100 (CET)","from mga04.intel.com (mga04.intel.com [192.55.52.120])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C08D960128\n\tfor ;\n\tWed, 10 Nov 2021 09:15:23 +0100 (CET)","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; \n\t10 Nov 2021 00:15:21 -0800","from smile.fi.intel.com ([10.237.72.184])\n\tby orsmga003-auth.jf.intel.com with\n\tESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2021 00:15:19 -0800","from andy by smile.fi.intel.com with local (Exim 4.95)\n\t(envelope-from )\n\tid 1mkil9-005Le4-Um; Wed, 10 Nov 2021 10:15:07 +0200"],"X-IronPort-AV":["E=McAfee;i=\"6200,9189,10163\"; a=\"231347228\"","E=Sophos;i=\"5.87,223,1631602800\"; d=\"scan'208\";a=\"231347228\"","E=Sophos;i=\"5.87,223,1631602800\"; d=\"scan'208\";a=\"452216705\""],"Date":"Wed, 10 Nov 2021 10:15:07 +0200","From":"Andy Shevchenko ","To":"Daniel Scally ","Message-ID":"","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20852,"web_url":"https://patchwork.libcamera.org/comment/20852/","msgid":"<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>","date":"2021-11-11T10:35:02","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/10/21 01:01, Daniel Scally wrote:\n> Hi Hans\n> \n> On 09/11/2021 16:35, Daniel Scally wrote:\n>>>>> That's not working correctly for me at the moment, but I think this is a\n>>>>> surmountable problem rather than the wrong approach, so I'm just working\n>>>>> through the differences to try and get the matching working.\n>>>> OK, I eventually got this working - the dw9719 registers as\n>>>> /dev/v4l-subdev7 for me now ... long story short is the attached patch\n>>>> was needed to make the references work, as the internals of v4l2 aren't\n>>>> checking for fwnode->secondary. Prior to your latest series as well, an\n>>>> additional problem was that once the VCMs fwnode was linked to the\n>>>> sensor's the .complete() callback for ipu3-cio2 would never call\n>>>> (because it needs ALL the devices for the linked fwnodes to be bound to\n>>>> do that)...which meant the VCMs never got instantiated, because that was\n>>>> where that function was called. With your new set separating those\n>>>> processes it works well, so yes I like that new approach very much :D\n>>>>\n>>>>\n>>>> In the end we don't have to add a call creating the subdev's - it turns\n>>>> out that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\n>>>> the nodes for the vcm when .complete() is called for that driver. I\n>>>> still think we should add a bit creating the link to expose to userspace\n>>>> in match_notify() though.\n>>>>\n>>>>\n>>>> Trying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n>>>> -L fails with an IOCTL error, so I have some remedial work on the driver\n>>>> which I'll do tonight; I'd expect to be able to control focus with\n>>>> v4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n>>> That is great, thank you so much. I wanted to look into this myself\n>>> today but I got distracted by other stuff.\n>>\n>> No problem; I'll link you the patches for the updated versions of\n>> everything once I've sorted the IOCTL error tonight.\n> \n> \n> OK, this is running now. With the attached patches on top of your v5\n> series and the 4-patch series from earlier today, the dw9719 registers\n> as a v4l2 subdev and I can control it with v4l2-ctl -d /dev/v4l-subdev7\n> -c focus_absolute=1200 (or whatever value).\n\nGreat, thank you! I've given this a quick test and indeed everything\nworks :)\n\nI did notice a typo in a comment in the dw9719.c file which I added\nmyself, can you squash in this fix pleas? :\n\ndiff --git a/drivers/media/i2c/dw9719.c b/drivers/media/i2c/dw9719.c\nindex 047f7636efde..c647b50c2ebf 100644\n--- a/drivers/media/i2c/dw9719.c\n+++ b/drivers/media/i2c/dw9719.c\n@@ -283,7 +283,7 @@ static int dw9719_probe(struct i2c_client *client)\n \t * the TPS68470 PMIC have I2C passthrough capability, to disconnect the\n \t * sensor's I2C pins from the I2C bus when the sensors VSIO (Sensor-IO)\n \t * is off, because some sensors then short these pins to ground;\n-\t * and the DW9719 might sit behind this passthrough, this it needs to\n+\t * and the DW9719 might sit behind this passthrough, thus it needs to\n \t * enable VSIO as that will also enable the I2C passthrough.\n \t */\n \tdw9719->regulators[1].supply = \"vsio\";\n\nAlso I think that the \n\n\"device property: Check fwnode->secondary when finding properties\"\n\nThat patch looks good to me, so please add my:\n\nReviewed-by: Hans de Goede \n\nCan you submit this upstream please?\n\nI will prepare a new version of my:\n\n\"[PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data\"\n\nseries, addressing the few remaining comments and adding the regulator\ndata + instantiating support for the VCM.\n\n> One problem I'm experiencing\n> is that the focus position I set isn't maintained; it holds for a couple\n> of seconds and then resets to the \"normal\" focus...this happens when the\n> .close() callback for the driver is called, which happens right after\n> the control value is applied. All the other VCM drivers in the kernel\n> power down on .close() so I did the same>\n\nRight, I believe that this is fine though, we expect people to use\nlibcamera with this and once libcamera gets autofocus support, then\nI would expect libcamera to keep the fd open the entire time while\nstreaming.\n\n>, but the behaviour is not\n> particularly useful - since removing the power seems to reset it, it\n> needs to be on whilst the linked sensor is streaming I suppose. Given\n> that ascertaining the state of the sensor probably will require some\n> link established between them anyway I guess I will look at that next,\n> unless you'd rather do it?\n\nI don't think this is necessary, see above.\n\nWhat is necessary is some way for libcamera to:\n\n1. See if there is a VCM which belongs to the sensor; and\n2. If there is a VCM figure out which v4l2-subdev it is.\n\nAlso see this email thread, where Hans Verkuil came to the\nconclusion that this info is currently missing from the MC\nrepresentation (link is to the conclusion):\n\nhttps://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 7DFC1BF415\n\tfor ;\n\tThu, 11 Nov 2021 10:35:25 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 97BDD6035A;\n\tThu, 11 Nov 2021 11:35:24 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id CCCB76032C\n\tfor ;\n\tThu, 11 Nov 2021 11:35:21 +0100 (CET)","from mail-ed1-f72.google.com (mail-ed1-f72.google.com\n\t[209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-444-hlrAnT1ANnGRigzuEIwS5A-1; Thu, 11 Nov 2021 05:35:04 -0500","by mail-ed1-f72.google.com with SMTP id\n\tx13-20020a05640226cd00b003e2bf805a02so5000146edd.23\n\tfor ;\n\tThu, 11 Nov 2021 02:35:04 -0800 (PST)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\tb11sm1330099ede.52.2021.11.11.02.35.02\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 11 Nov 2021 02:35:02 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"CB1ivuik\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636626920;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=3947w7BVsfyQCi9nBoH4pX/BueOPaJwJbIbUK885wUg=;\n\tb=CB1ivuikHB+YYfFMfUfes4VOeD9J2xmUoUjTS5GARqGR8qYir57WIp+efOO54YuT0efFiT\n\tsO87SUvn8p9J2iX683VK2BoEJw+0EElTVzWCUDjD8Fmehw2otBEHF7KPrOYqU1gNTFMaOI\n\t/gWfvFqycl7B/54tXnGEAsMsYz2mrHQ=","X-MC-Unique":"hlrAnT1ANnGRigzuEIwS5A-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=3947w7BVsfyQCi9nBoH4pX/BueOPaJwJbIbUK885wUg=;\n\tb=t8aFnzNqreQbNv9mIXcnowdibxJ5n3teLeiPX2eQbPwK5ZPolqMYC+tg7CzLE04gSN\n\twAheEis8tpROqbZx7kWrap5CeWVilJGitANkA/AgtK76vTnAMkGq6yhd1cOwN3jDkGJa\n\tkPG8AAv34sNRWn0366FHT6Ek2qrkXod8AHMG7w0Qoe9XQUrX8Tlhv/LnIjnv+EdZj5ET\n\tbdvqRnnpA9w/WgDf9/nUUXWSWqj4Aws9vdWtNxc5Ravuh5lPpdl+gD3N2I//8+xIge1m\n\tKm4Dfdnc728/1LyZQX6vZnGe9MYR8kCUTQWOuiqguVD1P99WcWU/GYBvDWx8VArvMSZy\n\tDbOw==","X-Gm-Message-State":"AOAM533G1sepyEySbtKnvzJ3BBTeRwMHay+FtBfFKJNhn3lF178zHiz6\n\tyHI6o7UxY1xIKSD0+OuKpXHThAGCsf+Zp/zACY/yGn2N133ojX4Pi1H6fDuCPBAA+ZdH5PpE+pm\n\tUALd8I91F++xzMYhZsyJ7lXdEWCHGG3tn7Q==","X-Received":["by 2002:a17:907:1b25:: with SMTP id\n\tmp37mr8090464ejc.140.1636626903386; \n\tThu, 11 Nov 2021 02:35:03 -0800 (PST)","by 2002:a17:907:1b25:: with SMTP id\n\tmp37mr8090425ejc.140.1636626903129; \n\tThu, 11 Nov 2021 02:35:03 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJw+zADBiwPobb8o5J25sZYGnLeKDoNyRmkPBQk5oAjs+3ad9bjuC0LvB+KRRfBFTk0RRZEEOA==","Message-ID":"<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>","Date":"Thu, 11 Nov 2021 11:35:02 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","From":"Hans de Goede ","In-Reply-To":"<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20853,"web_url":"https://patchwork.libcamera.org/comment/20853/","msgid":"","date":"2021-11-11T11:18:29","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":90,"url":"https://patchwork.libcamera.org/api/people/90/","name":"Daniel Scally","email":"djrscally@gmail.com"},"content":"Hello\n\nOn 11/11/2021 10:35, Hans de Goede wrote:\n> Hi,\n>\n> On 11/10/21 01:01, Daniel Scally wrote:\n>> Hi Hans\n>>\n>> On 09/11/2021 16:35, Daniel Scally wrote:\n>>>>>> That's not working correctly for me at the moment, but I think this is a\n>>>>>> surmountable problem rather than the wrong approach, so I'm just working\n>>>>>> through the differences to try and get the matching working.\n>>>>> OK, I eventually got this working - the dw9719 registers as\n>>>>> /dev/v4l-subdev7 for me now ... long story short is the attached patch\n>>>>> was needed to make the references work, as the internals of v4l2 aren't\n>>>>> checking for fwnode->secondary. Prior to your latest series as well, an\n>>>>> additional problem was that once the VCMs fwnode was linked to the\n>>>>> sensor's the .complete() callback for ipu3-cio2 would never call\n>>>>> (because it needs ALL the devices for the linked fwnodes to be bound to\n>>>>> do that)...which meant the VCMs never got instantiated, because that was\n>>>>> where that function was called. With your new set separating those\n>>>>> processes it works well, so yes I like that new approach very much :D\n>>>>>\n>>>>>\n>>>>> In the end we don't have to add a call creating the subdev's - it turns\n>>>>> out that v4l2 knows it's part of ipu3-cio2's v4l2-device so it registers\n>>>>> the nodes for the vcm when .complete() is called for that driver. I\n>>>>> still think we should add a bit creating the link to expose to userspace\n>>>>> in match_notify() though.\n>>>>>\n>>>>>\n>>>>> Trying to list controls for the dw9719 with v4l2-ctl -d /dev/v4l-subdev7\n>>>>> -L fails with an IOCTL error, so I have some remedial work on the driver\n>>>>> which I'll do tonight; I'd expect to be able to control focus with\n>>>>> v4l2-ctl -d /dev/v4l-subdev7 -c absolute_focus=n once this is sorted.\n>>>> That is great, thank you so much. I wanted to look into this myself\n>>>> today but I got distracted by other stuff.\n>>> No problem; I'll link you the patches for the updated versions of\n>>> everything once I've sorted the IOCTL error tonight.\n>>\n>> OK, this is running now. With the attached patches on top of your v5\n>> series and the 4-patch series from earlier today, the dw9719 registers\n>> as a v4l2 subdev and I can control it with v4l2-ctl -d /dev/v4l-subdev7\n>> -c focus_absolute=1200 (or whatever value).\n> Great, thank you! I've given this a quick test and indeed everything\n> works :)\n>\n> I did notice a typo in a comment in the dw9719.c file which I added\n> myself, can you squash in this fix pleas? :\n\n\nNo problem, will do\n\n> Also I think that the \n>\n> \"device property: Check fwnode->secondary when finding properties\"\n>\n> That patch looks good to me, so please add my:\n>\n> Reviewed-by: Hans de Goede \n>\n> Can you submit this upstream please?\n\n\nThanks; I'll post it later yes (and thanks for your R-b too Andy)\n\n> I will prepare a new version of my:\n>\n> \"[PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data\"\n>\n> series, addressing the few remaining comments and adding the regulator\n> data + instantiating support for the VCM.\n>\n>> One problem I'm experiencing\n>> is that the focus position I set isn't maintained; it holds for a couple\n>> of seconds and then resets to the \"normal\" focus...this happens when the\n>> .close() callback for the driver is called, which happens right after\n>> the control value is applied. All the other VCM drivers in the kernel\n>> power down on .close() so I did the same>\n> Right, I believe that this is fine though, we expect people to use\n> libcamera with this and once libcamera gets autofocus support, then\n> I would expect libcamera to keep the fd open the entire time while\n> streaming.\n\n\nOK - as long as that's how it works then I agree that this is fine as is\nyes.\n\n\n> What is necessary is some way for libcamera to:\n>\n> 1. See if there is a VCM which belongs to the sensor; and\n> 2. If there is a VCM figure out which v4l2-subdev it is.\n>\n> Also see this email thread, where Hans Verkuil came to the\n> conclusion that this info is currently missing from the MC\n> representation (link is to the conclusion):\n>\n> https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html\n\n\nYeah I read through that thread too, and had a brief chat with Laurent\nabout it. My plan was to add a new type of link called an \"ancillary\nlink\" between two entities, and automatically create those in\nmatch_notify() based on the function field of the matching entities, and\nexpose them as part of the media graph. I've started working on that but\nnot progressed far enough to share anything. Libcamera would need\nupdating with support for that too though.\n\n>\n> Regards,\n>\n> Hans\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 98848BDB1C\n\tfor ;\n\tThu, 11 Nov 2021 11:18:33 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id D9F8760362;\n\tThu, 11 Nov 2021 12:18:32 +0100 (CET)","from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com\n\t[IPv6:2a00:1450:4864:20::42b])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 9AF7B60345\n\tfor ;\n\tThu, 11 Nov 2021 12:18:31 +0100 (CET)","by mail-wr1-x42b.google.com with SMTP id r8so9155344wra.7\n\tfor ;\n\tThu, 11 Nov 2021 03:18:31 -0800 (PST)","from [192.168.0.14]\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net. [86.13.91.161])\n\tby smtp.gmail.com with ESMTPSA id\n\tx8sm2588240wrw.6.2021.11.11.03.18.30\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 11 Nov 2021 03:18:30 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"MpgvikC7\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding:content-language; \n\tbh=FCBgmSdMWITgJW2L8m1gtyu9V1eNdyphN4ypTf5HJH4=;\n\tb=MpgvikC7h0+FEukajCIYIXo+KJQ4tdrl5fE0GxLSoxhgGMEO/G4oqVzhfWioygKx1j\n\tdOI9o0E/NRy9SUOH69v8lsmIqfvF1os2SjBC2DlUrkdsieRmSyUBM+IZ5xV9vAxdXqer\n\tKyQ2Mh8UCTF6fMc6n4UsZiihHE+SRSw6QZ05AOJBWTTbsXxqKk046uVTZDaddjLxEDfS\n\tX0kSNVXBvVu7PMwHaVCWpBYLPoevPdwf1rhMKQGJiCHEHTzqPvWau83HIYByaMA8n5+m\n\tp5rXipdi97YP6d8fzgCVWaLZ4Jqp0Ze/SoprH+m28oCWJ9bHQq6wbqyAQJmNIfQMZFrF\n\tauiA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=FCBgmSdMWITgJW2L8m1gtyu9V1eNdyphN4ypTf5HJH4=;\n\tb=KVn1S+GumtWU0l350g6Qd8pV+U6deaqsiFMYtqnxim9DXVdnhnZ09k3P7CZeQ3uAoC\n\tCkDpRCuLAjng8M1Y46IkvpueKghBX6PbCXLtaX5dQcPkLQSeCcrgeDDHCQ+QbS9W49CP\n\tAp+1dz2mfAompyp4m+VGiWsL1QrpYJ2OANowYLblTJqjGeXng0vwayUS0EUOVQVWaqz0\n\tcX98ZLvbNQiMiOiStW3VL5/xnuk1Dp1Kjbs3q4lJF2kX9aGE2s7S5CTDY+q6ZiQ6A4Du\n\tn2YyTCjwz9Dw15kYyFO5rACx/xV/Djg9wBNvrNz/EvxrqG0hSAAF02WQNLndJ7cPOkeQ\n\tKeoA==","X-Gm-Message-State":"AOAM532igicHzcD9eg656UypDKHA1SYKj3VdqDDhgk8KwR+kfrPkKYpx\n\t4EFmw9AuF5UyF5q4dMEHr8E=","X-Google-Smtp-Source":"ABdhPJzTZELvAH1wqyeQyoHfwpDWhKLUE8yGAmSM0K2uJpOC8aQNpr0z1A2oTvyYRFTGbCc/L6wGIQ==","X-Received":"by 2002:a5d:5651:: with SMTP id\n\tj17mr7914892wrw.166.1636629511211; \n\tThu, 11 Nov 2021 03:18:31 -0800 (PST)","To":"Hans de Goede ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>","From":"Daniel Scally ","Message-ID":"","Date":"Thu, 11 Nov 2021 11:18:29 +0000","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101\n\tThunderbird/78.13.0","MIME-Version":"1.0","In-Reply-To":"<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit","Content-Language":"en-US","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20866,"web_url":"https://patchwork.libcamera.org/comment/20866/","msgid":"<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","date":"2021-11-11T15:23:38","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/11/21 12:18, Daniel Scally wrote:\n\n\n\n>>> One problem I'm experiencing\n>>> is that the focus position I set isn't maintained; it holds for a couple\n>>> of seconds and then resets to the \"normal\" focus...this happens when the\n>>> .close() callback for the driver is called, which happens right after\n>>> the control value is applied. All the other VCM drivers in the kernel\n>>> power down on .close() so I did the same>\n>> Right, I believe that this is fine though, we expect people to use\n>> libcamera with this and once libcamera gets autofocus support, then\n>> I would expect libcamera to keep the fd open the entire time while\n>> streaming.\n> \n> \n> OK - as long as that's how it works then I agree that this is fine as is\n> yes.\n\nSo I've just picked up an old project of mine, called gtk-v4l which\nis a nice simply v4l2 controls applet and patches it up to also\nwork on v4l-subdevs:\n\nhttps://github.com/jwrdegoede/gtk-v4l/\n\nSo now you can run:\n\nsudo gtk-v4l -d /dev/v4l-subdev8\n\nAnd it will give you a slider to control the focus; and as\na bonus it keeps the v4l-subdev open, so no more runtime-pm\nissue :)\n\n>> What is necessary is some way for libcamera to:\n>>\n>> 1. See if there is a VCM which belongs to the sensor; and\n>> 2. If there is a VCM figure out which v4l2-subdev it is.\n>>\n>> Also see this email thread, where Hans Verkuil came to the\n>> conclusion that this info is currently missing from the MC\n>> representation (link is to the conclusion):\n>>\n>> https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html\n> \n> \n> Yeah I read through that thread too, and had a brief chat with Laurent\n> about it. My plan was to add a new type of link called an \"ancillary\n> link\" between two entities, and automatically create those in\n> match_notify() based on the function field of the matching entities, and\n> expose them as part of the media graph. I've started working on that but\n> not progressed far enough to share anything.\n\nSounds good.\n\n> Libcamera would need\n> updating with support for that too though.\n\nRight I think libcamera will need updating no matter what, first we\nneed to comeup with a userspace API for this.\n\nAlthough I guess it would be good to also write libcamera patches\nonce the kernel patches are ready, but not yet merged, to make\nsure the API is usable without problems by libcamera.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 0C37CBF415\n\tfor ;\n\tThu, 11 Nov 2021 15:23:49 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0A6CD6035A;\n\tThu, 11 Nov 2021 16:23:48 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AFF26600B5\n\tfor ;\n\tThu, 11 Nov 2021 16:23:45 +0100 (CET)","from mail-ed1-f71.google.com (mail-ed1-f71.google.com\n\t[209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-508-csnzssk3PKu3nGyRZQFDpg-1; Thu, 11 Nov 2021 10:23:41 -0500","by mail-ed1-f71.google.com with SMTP id\n\tv9-20020a50d849000000b003dcb31eabaaso5704527edj.13\n\tfor ;\n\tThu, 11 Nov 2021 07:23:40 -0800 (PST)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\to5sm1930478edc.25.2021.11.11.07.23.39\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 11 Nov 2021 07:23:39 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"TyxmyAAg\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636644224;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=96KHuS7Sase+wnAJHqC9Sz589beINyZY9/+jfe26UQ4=;\n\tb=TyxmyAAgMxsRaO86IdrG4kBXA+S6I+Jycs6LaVBbhUCjGqRRw37fUjUhrezy1CtDwHeQfb\n\ta4QW2Y9/UUlvRqYf1trwVPgbRdFU2TlOdhhGVzTl42GrFskQO1a+4KkIN/ZEUS3hYQghuQ\n\tNpvDVg85wdk6bhl4CLDkjl8q039ea4g=","X-MC-Unique":"csnzssk3PKu3nGyRZQFDpg-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=96KHuS7Sase+wnAJHqC9Sz589beINyZY9/+jfe26UQ4=;\n\tb=7DZQ0fLXKdKfqw6bn+bSyyBLE+K3YczJGUoZuQu6OYJqvLwNCEAd2ATbzo3/Qp764f\n\tNDT5rdlGhvXgptJLX0nprEYIivGgrL8cOzrM3pVjmbMS0AldV/a/V4SLIjuNktUJo7rX\n\tsIGjMJtSWPI/r6qve/6S84RROPfE/52+iR3H+N74h5M/2BhyJ2pe4CmDt8GjIM2tfac5\n\tldIsiB+0krZwnNt9aLMZUC9lZN8wDWi90UlNnYnHNIAn6eBwPwo3R3tCLin2ZSOICbXc\n\trL0w2enpSI8hO6kv4tBzGZSXSvM221FCV+BwmAakVAMyG/8uGiqVqT7tK4tZ+7Usq1B3\n\tROVg==","X-Gm-Message-State":"AOAM530Mv9pLrQs1PpwDYUH9jQE0LnA9xdtHFUs85X0UxhFqsRx6EFeX\n\t9b+oBy4egn3TURtXqvqkNXBs+5DjRhLwAWhCUbF9ByHhzYNG6e+sQ6G9AYFD9sRhilfB7kSKNyD\n\tP6xls7KUCoLGO6sQnmmEb1oKvmiA8pxT5wg==","X-Received":["by 2002:a17:907:72d4:: with SMTP id\n\tdu20mr10540750ejc.419.1636644219944; \n\tThu, 11 Nov 2021 07:23:39 -0800 (PST)","by 2002:a17:907:72d4:: with SMTP id\n\tdu20mr10540720ejc.419.1636644219694; \n\tThu, 11 Nov 2021 07:23:39 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJyPGM7oH1p/+UOJ7OQp3Yfr6EFk/h+fjhTea7RA3yZZWNXTbgrUSLimGiKS2AhMAc2AkYUhQw==","Message-ID":"<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","Date":"Thu, 11 Nov 2021 16:23:38 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t","From":"Hans de Goede ","In-Reply-To":"","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20868,"web_url":"https://patchwork.libcamera.org/comment/20868/","msgid":"","date":"2021-11-11T15:51:11","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":27,"url":"https://patchwork.libcamera.org/api/people/27/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.com"},"content":"Hi Hans\n\nOn Thu, 11 Nov 2021 at 15:23, Hans de Goede wrote:\n>\n> Hi,\n>\n> On 11/11/21 12:18, Daniel Scally wrote:\n>\n> \n>\n> >>> One problem I'm experiencing\n> >>> is that the focus position I set isn't maintained; it holds for a couple\n> >>> of seconds and then resets to the \"normal\" focus...this happens when the\n> >>> .close() callback for the driver is called, which happens right after\n> >>> the control value is applied. All the other VCM drivers in the kernel\n> >>> power down on .close() so I did the same>\n> >> Right, I believe that this is fine though, we expect people to use\n> >> libcamera with this and once libcamera gets autofocus support, then\n> >> I would expect libcamera to keep the fd open the entire time while\n> >> streaming.\n> >\n> >\n> > OK - as long as that's how it works then I agree that this is fine as is\n> > yes.\n>\n> So I've just picked up an old project of mine, called gtk-v4l which\n> is a nice simply v4l2 controls applet and patches it up to also\n> work on v4l-subdevs:\n>\n> https://github.com/jwrdegoede/gtk-v4l/\n>\n> So now you can run:\n>\n> sudo gtk-v4l -d /dev/v4l-subdev8\n>\n> And it will give you a slider to control the focus; and as\n> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n> issue :)\n\nDo the lens and sensor share a regulator / enable GPIO?\n\nI was looking at the same issue for a Sony IMX135 module with AD5398\nVCM driver [1].\nIn my case they do share an enable GPIO, so using regulator-gpio we\ncan register via regulator_register_notifier for information on when\nthe regulator is powered up. It can then also reset to the last\nposition should the sensor subdev enable the regulator without the\nlens driver being opened at all.\n\nI don't know if that helps in your case.\n\n Dave\n\n[1] https://github.com/6by9/linux/commit/e15e712e8c17afe03f121540178371ce2a8a7922\non branch https://github.com/6by9/linux/commits/rpi-5.10.y-imx135\n\n> >> What is necessary is some way for libcamera to:\n> >>\n> >> 1. See if there is a VCM which belongs to the sensor; and\n> >> 2. If there is a VCM figure out which v4l2-subdev it is.\n> >>\n> >> Also see this email thread, where Hans Verkuil came to the\n> >> conclusion that this info is currently missing from the MC\n> >> representation (link is to the conclusion):\n> >>\n> >> https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html\n> >\n> >\n> > Yeah I read through that thread too, and had a brief chat with Laurent\n> > about it. My plan was to add a new type of link called an \"ancillary\n> > link\" between two entities, and automatically create those in\n> > match_notify() based on the function field of the matching entities, and\n> > expose them as part of the media graph. I've started working on that but\n> > not progressed far enough to share anything.\n>\n> Sounds good.\n>\n> > Libcamera would need\n> > updating with support for that too though.\n>\n> Right I think libcamera will need updating no matter what, first we\n> need to comeup with a userspace API for this.\n>\n> Although I guess it would be good to also write libcamera patches\n> once the kernel patches are ready, but not yet merged, to make\n> sure the API is usable without problems by libcamera.\n>\n> Regards,\n>\n> Hans\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B5079BF415\n\tfor ;\n\tThu, 11 Nov 2021 15:51:30 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id A85896035A;\n\tThu, 11 Nov 2021 16:51:29 +0100 (CET)","from mail-wm1-x334.google.com (mail-wm1-x334.google.com\n\t[IPv6:2a00:1450:4864:20::334])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2C916600B5\n\tfor ;\n\tThu, 11 Nov 2021 16:51:28 +0100 (CET)","by mail-wm1-x334.google.com with SMTP id\n\tn33-20020a05600c502100b0032fb900951eso2335129wmr.4\n\tfor ;\n\tThu, 11 Nov 2021 07:51:28 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"a+GjUURE\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=Q9fpzcjJOliiClFHyEfNex98ZSc6ufkk4IN4tLlM1To=;\n\tb=a+GjUURELtjY4tL3TIcfPO9KmfzySKBnpwL2jSFEhieFlp2ULJkAY9dOg+PFE1gWs9\n\t8+EhbGFkmQLZyu/lOb6n01pi9w5izrrDuLch0Bstlw+DN9wBEK/jlKsClpsZWH/CqMKs\n\t3EzQx5gAeAIjHpK4KVwO/erfFz6GSNjjk/pOzc2dPLnNbmWvQyquj6LlO/iIN5jlEhJ2\n\tYM/lwFvcmttifwOWXq4eKgmLgBkwxTAfW4ugDVZIgzYte4jgydgTDDUqF6cpa3VpXECm\n\tSjujRrSWL2V3tDGR/qZofpQXpwSeiLP+a0c76NeDDUlBIyb3934Yz55wtrB7Il6zKTBR\n\tUJRA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=Q9fpzcjJOliiClFHyEfNex98ZSc6ufkk4IN4tLlM1To=;\n\tb=WkNxVtFgIopnjbMZ36snsKdltl1IJZV5XW1HFghLteIybd9asNA4/2Qzb2cby8ZZQu\n\tZ+HLzZHxw9GvB8cd3NwGV3ZdDjyhJXKs3a25j8cNXgNZFpTGen91DVwbHoUa6P4OY8HG\n\tL3SS5P8Nd37cQXpmsiFbGAhW9rBZl1qbJ+my5yHXufcBaC7gi6T7rDAqxPEjHgTwp8Cn\n\tHvqDmFcIWj+lcg1piKmrJJQ0l06ieUru5SDPs5HHPMAb1xvL8Ly2B9SzTtVJEQmfZ5Xf\n\tk8M9hhP7Eef8Vhd8RQGGrG4SwKNJSVesyf8i1bvMyR+pPrriXquszP2H8RnuAF8cERr1\n\tcRfw==","X-Gm-Message-State":"AOAM532gfYVYl7jHoh3faazT48ByHOUNUju2cqcwJY7T0vtjDXWBQaSu\n\twOxB+ls2fuVnZgh0zlj6RIDcb7GZ07fBf1Awln4QoA==","X-Google-Smtp-Source":"ABdhPJyzthmxzmtXBc09CEqbgaJtIYxWX3pGcb2I0MHuxnkg0O8lIMzFUZ6eHk8B0OKkwGCxw0tGGlIEAjLqKT7B+T4=","X-Received":"by 2002:a7b:cc07:: with SMTP id\n\tf7mr26732161wmh.106.1636645887851; \n\tThu, 11 Nov 2021 07:51:27 -0800 (PST)","MIME-Version":"1.0","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","In-Reply-To":"<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","From":"Dave Stevenson ","Date":"Thu, 11 Nov 2021 15:51:11 +0000","Message-ID":"","To":"Hans de Goede ","Content-Type":"text/plain; charset=\"UTF-8\"","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20869,"web_url":"https://patchwork.libcamera.org/comment/20869/","msgid":"","date":"2021-11-11T15:51:22","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Thu, Nov 11, 2021 at 04:23:38PM +0100, Hans de Goede wrote:\n> On 11/11/21 12:18, Daniel Scally wrote:\n> \n> \n> \n> >>> One problem I'm experiencing\n> >>> is that the focus position I set isn't maintained; it holds for a couple\n> >>> of seconds and then resets to the \"normal\" focus...this happens when the\n> >>> .close() callback for the driver is called, which happens right after\n> >>> the control value is applied. All the other VCM drivers in the kernel\n> >>> power down on .close() so I did the same>\n> >> Right, I believe that this is fine though, we expect people to use\n> >> libcamera with this and once libcamera gets autofocus support, then\n> >> I would expect libcamera to keep the fd open the entire time while\n> >> streaming.\n> > \n> > \n> > OK - as long as that's how it works then I agree that this is fine as is\n> > yes.\n> \n> So I've just picked up an old project of mine, called gtk-v4l which\n> is a nice simply v4l2 controls applet and patches it up to also\n> work on v4l-subdevs:\n> \n> https://github.com/jwrdegoede/gtk-v4l/\n> \n> So now you can run:\n> \n> sudo gtk-v4l -d /dev/v4l-subdev8\n> \n> And it will give you a slider to control the focus; and as\n> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n> issue :)\n> \n> >> What is necessary is some way for libcamera to:\n> >>\n> >> 1. See if there is a VCM which belongs to the sensor; and\n> >> 2. If there is a VCM figure out which v4l2-subdev it is.\n> >>\n> >> Also see this email thread, where Hans Verkuil came to the\n> >> conclusion that this info is currently missing from the MC\n> >> representation (link is to the conclusion):\n> >>\n> >> https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/026144.html\n> > \n> > \n> > Yeah I read through that thread too, and had a brief chat with Laurent\n> > about it. My plan was to add a new type of link called an \"ancillary\n> > link\" between two entities, and automatically create those in\n> > match_notify() based on the function field of the matching entities, and\n> > expose them as part of the media graph. I've started working on that but\n> > not progressed far enough to share anything.\n> \n> Sounds good.\n> \n> > Libcamera would need\n> > updating with support for that too though.\n> \n> Right I think libcamera will need updating no matter what, first we\n> need to comeup with a userspace API for this.\n> \n> Although I guess it would be good to also write libcamera patches\n> once the kernel patches are ready, but not yet merged, to make\n> sure the API is usable without problems by libcamera.\n\nI strongly agree with this. We're moving towards mandating a libcamera\nimplementation to get new APIs merged in the kernel.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C2733BF415\n\tfor ;\n\tThu, 11 Nov 2021 15:51:46 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 7C1F660362;\n\tThu, 11 Nov 2021 16:51:46 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D752F600B5\n\tfor ;\n\tThu, 11 Nov 2021 16:51:44 +0100 (CET)","from pendragon.ideasonboard.com\n\t(117.145-247-81.adsl-dyn.isp.belgacom.be [81.247.145.117])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 791A3292;\n\tThu, 11 Nov 2021 16:51:44 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"gOxznymt\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1636645904;\n\tbh=OIk80XiSaJVgOHOEauFOo+DEOId50i2wp9aGo078ITg=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=gOxznymt2jI9wmoegDQKhiIruCxU4ksagBhN6UwH24zOi/yBvnzKdSGAn1HBEwwSE\n\trMHxTVaGskal6Cf/WfLsG5SdCsNkqjhA8t12y5vPbt5T0OfRYJ7MChMjLzuPdph/WS\n\tDqJleIoarpxq468h9NkA1jImYLO9NXlDpkHkBql8=","Date":"Thu, 11 Nov 2021 17:51:22 +0200","From":"Laurent Pinchart ","To":"Hans de Goede ","Message-ID":"","References":"<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20870,"web_url":"https://patchwork.libcamera.org/comment/20870/","msgid":"<90a31605-49c9-9e4b-765f-c8f8773b3ba0@redhat.com>","date":"2021-11-11T15:59:58","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/9/21 17:35, Daniel Scally wrote:\n\n\n\n>> Talking about this Dell Latitude 7285, I haven't had a chance to\n>> look into this at all. But chances are I will need to do some\n>> I2C-register dumps under Windows, last time you mentioned you\n>> had some small tool for this ? It is ok if it is a bit hackish,\n>> it will still be very useful to have :) And I believe I will\n>> also need to override the DSDT under Windows for this, right?\n>> I should be able to cope with that too.\n> \n> \n> So the tool I was using was the I2cTestTool [1], which requires you to\n> first hack the DSDT to enable usermode access [2]. You need the\n> Microsoft ASL compiler [3] to insert the new DSDT, but fwiw I gave up\n> trying to use their tool to actually compile the table and just did it\n> running Ubuntu with iasl, then saved the file onto the Go2's SD card and\n> loaded it using asl.exe in Windows...the MS tool just wouldn't compile\n> for whatever reason.\n> \n> \n> All that said; you don't actually need to do this for the Latitude 7285\n> - on the Github thread a chap with that device found the schematics and\n> posted them [4], so we should already have the information we need to\n> populate the board data for that one. The sensor drivers need some work\n> though - the ov9734 I have a series somewhere that I think should work\n> but haven't ever tested, the ov8858 I don't think anyone's looked at yet.\n\nAwesome, thank you very much for these links.\n\nIf you can dig up the ov9734 patch series you have and email me a copy (1),\nthat would be great, then I can start looking into getting things to work\non the Latitude 7285.\n\nRegards,\n\nHans\n\n\n1) No need to make it compile with the latest, I can take care of that\njust email me what you have :)","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 83277BDB1C\n\tfor ;\n\tThu, 11 Nov 2021 16:00:06 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C3EA56035D;\n\tThu, 11 Nov 2021 17:00:05 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A57EA600B5\n\tfor ;\n\tThu, 11 Nov 2021 17:00:02 +0100 (CET)","from mail-ed1-f70.google.com (mail-ed1-f70.google.com\n\t[209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-562-IwwLUi-oPYmxh-aadx3jYQ-1; Thu, 11 Nov 2021 11:00:00 -0500","by mail-ed1-f70.google.com with SMTP id\n\ti9-20020a508709000000b003dd4b55a3caso5774102edb.19\n\tfor ;\n\tThu, 11 Nov 2021 08:00:00 -0800 (PST)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\td4sm1776727edk.78.2021.11.11.07.59.58\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 11 Nov 2021 07:59:58 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"MqTo/yVU\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636646401;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=bAbPESGtFo3yvuzwtwquN7c9hFMdNyDm/P5bKVw3nw4=;\n\tb=MqTo/yVU/3V+Z49X9+45V1ZwilrweqdUd+3D2YvPJZJEZKIBF48hcmxJJB/S98p6hAsGV7\n\th6EKSU/0GL1HYSbcpVcicdjiLYDhC5zWZGjWpKYR7rXoleIzr5tf999WLE+Op/i7f648ds\n\tfNH9kj7MYkjalHjDT+zLRbaMMSwNnHg=","X-MC-Unique":"IwwLUi-oPYmxh-aadx3jYQ-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=bAbPESGtFo3yvuzwtwquN7c9hFMdNyDm/P5bKVw3nw4=;\n\tb=A6hWgrFQqug/s+8lfxPNIe9SRrxv6J0sgw9zHNyEv17BwnZ6WasbEcLvD4u8wi7RKY\n\tcxiWqaK91MhtBabSygVe8DrPMebSyxXQPM7AHWhWTwOtyLxB24fs54VsCwsZS8N7BM3Y\n\thhQ3QkqzOR7tGaJz3wF5MljF7fIVYTN74oussEBoiHNjNRhbBan1wdnkVQWZdWHnw89Z\n\tn3gO+8RCnGxHSOBhIPh/jLx9s+ZRgTvy8croilKmrMNsWMtzsTlGH5U1yHLvURMg9Lu4\n\tUDxvtJSr/esQbS1CryReGb8E8cp8aIqEfq7n9S8OXbIHXgvHiKGbOJWaf4UFNEphlwDY\n\tbJrw==","X-Gm-Message-State":"AOAM531jRfNOcW9SYhNeuu22VFTApPRckn7Rxznmk2vQ6gn/SiIdbKxJ\n\tulG14Fg1b8AG1dDOnXVQTmGwna/ZxjSXuhRg0r+Mmqw/1YGvcCGovInTFZU4ESH/yCozZTkk31B\n\tN8IefHXIlM45i+WVJFaEZPHVtHJeqKhiKsA==","X-Received":["by 2002:a17:906:9402:: with SMTP id\n\tq2mr10740554ejx.106.1636646399204; \n\tThu, 11 Nov 2021 07:59:59 -0800 (PST)","by 2002:a17:906:9402:: with SMTP id\n\tq2mr10740524ejx.106.1636646399027; \n\tThu, 11 Nov 2021 07:59:59 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJzeQshSvv0KICKi1+QRdOT9qMooUYa+pWhea4ph2MXN+K6lf7Fdi5FPc6WJY6aNS3HvCZ9CRQ==","Message-ID":"<90a31605-49c9-9e4b-765f-c8f8773b3ba0@redhat.com>","Date":"Thu, 11 Nov 2021 16:59:58 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Daniel Scally ,\n\tLaurent Pinchart ,\n\tKate Hsuan ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","From":"Hans de Goede ","In-Reply-To":"<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20875,"web_url":"https://patchwork.libcamera.org/comment/20875/","msgid":"<6e832988-4810-fe59-7357-886b286697a0@redhat.com>","date":"2021-11-11T16:50:28","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":102,"url":"https://patchwork.libcamera.org/api/people/102/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 11/11/21 16:51, Dave Stevenson wrote:\n> Hi Hans\n> \n> On Thu, 11 Nov 2021 at 15:23, Hans de Goede wrote:\n>>\n>> Hi,\n>>\n>> On 11/11/21 12:18, Daniel Scally wrote:\n>>\n>> \n>>\n>>>>> One problem I'm experiencing\n>>>>> is that the focus position I set isn't maintained; it holds for a couple\n>>>>> of seconds and then resets to the \"normal\" focus...this happens when the\n>>>>> .close() callback for the driver is called, which happens right after\n>>>>> the control value is applied. All the other VCM drivers in the kernel\n>>>>> power down on .close() so I did the same>\n>>>> Right, I believe that this is fine though, we expect people to use\n>>>> libcamera with this and once libcamera gets autofocus support, then\n>>>> I would expect libcamera to keep the fd open the entire time while\n>>>> streaming.\n>>>\n>>>\n>>> OK - as long as that's how it works then I agree that this is fine as is\n>>> yes.\n>>\n>> So I've just picked up an old project of mine, called gtk-v4l which\n>> is a nice simply v4l2 controls applet and patches it up to also\n>> work on v4l-subdevs:\n>>\n>> https://github.com/jwrdegoede/gtk-v4l/\n>>\n>> So now you can run:\n>>\n>> sudo gtk-v4l -d /dev/v4l-subdev8\n>>\n>> And it will give you a slider to control the focus; and as\n>> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n>> issue :)\n> \n> Do the lens and sensor share a regulator / enable GPIO?\n\nNo, if they did then there would be no runtime-pm issue,\nbecause then the VCM would not get turned off after\na v4l2-set command (for a quick test) since then the\nstreaming from the sensor would keep the sensor and\nthus the regulator on.\n\n> I was looking at the same issue for a Sony IMX135 module with AD5398\n> VCM driver [1].\n> In my case they do share an enable GPIO, so using regulator-gpio we\n> can register via regulator_register_notifier for information on when\n> the regulator is powered up. It can then also reset to the last\n> position should the sensor subdev enable the regulator without the\n> lens driver being opened at all.\n\nThat sounds like it is relying on board-depedent behavior\n(the enable GPIO and/or regulator being shared) which we don't\nwant in the VCM drivers as those are supposed to be board\nagnostic.\n\nThis really is something which should be fixed in userspace\nwhere the userspace consumer of the sensor should also always\nopen the vcm v4l-subdev.\n\nRegards,\n\nHans","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 1FF52BDB1C\n\tfor ;\n\tThu, 11 Nov 2021 16:50:37 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 53BF56035A;\n\tThu, 11 Nov 2021 17:50:36 +0100 (CET)","from us-smtp-delivery-124.mimecast.com\n\t(us-smtp-delivery-124.mimecast.com [170.10.129.124])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 23C05600B5\n\tfor ;\n\tThu, 11 Nov 2021 17:50:34 +0100 (CET)","from mail-ed1-f72.google.com (mail-ed1-f72.google.com\n\t[209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id\n\tus-mta-237-OctMjCVBP16ghTp4PKQUtw-1; Thu, 11 Nov 2021 11:50:30 -0500","by mail-ed1-f72.google.com with SMTP id\n\tw13-20020a05640234cd00b003e2fde5ff8aso5873008edc.14\n\tfor ;\n\tThu, 11 Nov 2021 08:50:30 -0800 (PST)","from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214?\n\t(2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl.\n\t[2001:1c00:c1e:bf00:1054:9d19:e0f0:8214])\n\tby smtp.gmail.com with ESMTPSA id\n\tgs17sm1640687ejc.28.2021.11.11.08.50.28\n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 11 Nov 2021 08:50:28 -0800 (PST)"],"Authentication-Results":["lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=redhat.com header.i=@redhat.com\n\theader.b=\"GSM6IySl\"; dkim-atps=neutral","relay.mimecast.com;\n\tauth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hdegoede@redhat.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1636649432;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\tto:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\tcontent-transfer-encoding:content-transfer-encoding:\n\tin-reply-to:in-reply-to:references:references;\n\tbh=xoB+BlNHwsAzfxp8VbiEpqj9sxlWz3w+P0LTUa9Ql/8=;\n\tb=GSM6IySlWVuEHfjOy0kfZfrxd7lvsHwRHSNz5psv86AYyr8jI3TRBNRlJPEVyw9NIKivef\n\tdfdn5oSLSL3o5Cd6muGS37DBTCbqlHh8UBttzSgC8gm4lyHctVfOHCNyd+hRR4tTPHDR5m\n\tmr1/9QvbNPfxfSZjZkUP2lMKyWSbr8g=","X-MC-Unique":"OctMjCVBP16ghTp4PKQUtw-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:message-id:date:mime-version:user-agent:subject\n\t:content-language:to:cc:references:from:in-reply-to\n\t:content-transfer-encoding;\n\tbh=xoB+BlNHwsAzfxp8VbiEpqj9sxlWz3w+P0LTUa9Ql/8=;\n\tb=k4AMsEHOExK5yhx8x/nT3G2oyrlDofZwU7P6Y0aaBDzNiCOGKSrWoBYCq685LCo/Ay\n\tNtxKRLBw+b1UXpFoGR3PyZ+40IiHmu+6SQv6zgKgtV/7ukzw8iPWTPzCR7+/P+5kbiFy\n\tZiXz1eml1c0WaZf1riJVcYFslt+F/NWWbDvJgA8x7DUQ/MSH4UIwKlgqdoxs7YYvQMCH\n\tN4XuH+2WUqNMzofsW/j8Jl6DEbc9Rl7H7yf0XUh7eLDYtMr/o3X0z4Gbvm0WHaBJXE/A\n\th3pqd/oEv3ZH4Ka+8pMIiVxupUsR1hLCu15a32ZVNBnWd8SbX3aBj21EDQbdjMsWuVdZ\n\tCYZA==","X-Gm-Message-State":"AOAM533NXuoW3m3ULDzyXWhjnzyvADEll5wmq1jFQXvjgNXwAbqh6zyh\n\tgX400mYK47uoh8bpIMGv9iOkcc32cRtN4gozUKmzpC1DbdiU3mySwIS6CgIFQe2EKl5BLjPw3zv\n\tzWIs7nRRWOEn550hTwd9qK09Ku6VPyZWrFw==","X-Received":["by 2002:a05:6402:2930:: with SMTP id\n\tee48mr3301633edb.295.1636649429577; \n\tThu, 11 Nov 2021 08:50:29 -0800 (PST)","by 2002:a05:6402:2930:: with SMTP id\n\tee48mr3301610edb.295.1636649429416; \n\tThu, 11 Nov 2021 08:50:29 -0800 (PST)"],"X-Google-Smtp-Source":"ABdhPJyMtCZXTlVM9QtoETgLw5i8JksfxcdPFHfhAM8GFHocDQWNxIv2rGTCNDLDk35V2b7QCuzIZA==","Message-ID":"<6e832988-4810-fe59-7357-886b286697a0@redhat.com>","Date":"Thu, 11 Nov 2021 17:50:28 +0100","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101\n\tThunderbird/91.2.0","To":"Dave Stevenson ","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>\n\t","From":"Hans de Goede ","In-Reply-To":"","X-Mimecast-Spam-Score":"0","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20880,"web_url":"https://patchwork.libcamera.org/comment/20880/","msgid":"","date":"2021-11-11T19:30:39","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":27,"url":"https://patchwork.libcamera.org/api/people/27/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.com"},"content":"On Thu, 11 Nov 2021 at 16:50, Hans de Goede wrote:\n>\n> Hi,\n>\n> On 11/11/21 16:51, Dave Stevenson wrote:\n> > Hi Hans\n> >\n> > On Thu, 11 Nov 2021 at 15:23, Hans de Goede wrote:\n> >>\n> >> Hi,\n> >>\n> >> On 11/11/21 12:18, Daniel Scally wrote:\n> >>\n> >> \n> >>\n> >>>>> One problem I'm experiencing\n> >>>>> is that the focus position I set isn't maintained; it holds for a couple\n> >>>>> of seconds and then resets to the \"normal\" focus...this happens when the\n> >>>>> .close() callback for the driver is called, which happens right after\n> >>>>> the control value is applied. All the other VCM drivers in the kernel\n> >>>>> power down on .close() so I did the same>\n> >>>> Right, I believe that this is fine though, we expect people to use\n> >>>> libcamera with this and once libcamera gets autofocus support, then\n> >>>> I would expect libcamera to keep the fd open the entire time while\n> >>>> streaming.\n> >>>\n> >>>\n> >>> OK - as long as that's how it works then I agree that this is fine as is\n> >>> yes.\n> >>\n> >> So I've just picked up an old project of mine, called gtk-v4l which\n> >> is a nice simply v4l2 controls applet and patches it up to also\n> >> work on v4l-subdevs:\n> >>\n> >> https://github.com/jwrdegoede/gtk-v4l/\n> >>\n> >> So now you can run:\n> >>\n> >> sudo gtk-v4l -d /dev/v4l-subdev8\n> >>\n> >> And it will give you a slider to control the focus; and as\n> >> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n> >> issue :)\n> >\n> > Do the lens and sensor share a regulator / enable GPIO?\n>\n> No, if they did then there would be no runtime-pm issue,\n> because then the VCM would not get turned off after\n> a v4l2-set command (for a quick test) since then the\n> streaming from the sensor would keep the sensor and\n> thus the regulator on.\n\nRegistering with the regulator was more so that it restored the\nposition on sensor power up, independent of whether the lens driver\nwas opened or not.\n\n> > I was looking at the same issue for a Sony IMX135 module with AD5398\n> > VCM driver [1].\n> > In my case they do share an enable GPIO, so using regulator-gpio we\n> > can register via regulator_register_notifier for information on when\n> > the regulator is powered up. It can then also reset to the last\n> > position should the sensor subdev enable the regulator without the\n> > lens driver being opened at all.\n>\n> That sounds like it is relying on board-depedent behavior\n> (the enable GPIO and/or regulator being shared) which we don't\n> want in the VCM drivers as those are supposed to be board\n> agnostic.\n\nAll platforms I've encountered so far have used the same GPIO to\ncontrol both VCM and sensor, hence why I asked. The number of use\ncases where you want one without the other is incredibly low, and\nhardware guys generally don't like wasting GPIOs or having to route\nthem around the PCB. It's interesting that your platform has separated\nthem.\n\n> This really is something which should be fixed in userspace\n> where the userspace consumer of the sensor should also always\n> open the vcm v4l-subdev.\n\nNot all use cases involve libcamera, and what you're proposing is\nmaking life very difficult for the simple use cases.\nThere may be GStreamer folk on board with libcamera, but I've heard no\nnoises from FFmpeg about libcamera support. V4L2 is still the default\nAPI that users generally care about. Particularly with mono sensors\nthe output is often directly usable without worrying about the\ncomplexities of ISPs, but you're effectively saying \"jump through lots\nof hoops or you can't use a VCM with these sensors\".\n\nIf userspace has called VIDIOC_STREAMON doesn't that mean they want\nthe whole entity (as configured) to be powered on and start streaming?\nAre you saying that the lens isn't part of that entity? In which case\nwhy does Media Controller include it (and eventually link it to the\nsensor) in the media entity?\n\nWould you advocate making backlight control in DRM a function that\nuserspace is responsible for independently of the panel pipeline?\nThere are significant similarities to this situation as the panel\nisn't usable without the backlight being powered, same as the sensor\nisn't usable without the VCM being powered.\n\nSorry, but I just see isolating power control for the VCM from the\nsensor in this way to be a very odd design decision. It'd be\ninteresting to hear other views.\n\n Dave","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 48F34BDB1C\n\tfor ;\n\tThu, 11 Nov 2021 19:30:59 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4780D6035A;\n\tThu, 11 Nov 2021 20:30:58 +0100 (CET)","from mail-wr1-x429.google.com (mail-wr1-x429.google.com\n\t[IPv6:2a00:1450:4864:20::429])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id F0E6F600B5\n\tfor ;\n\tThu, 11 Nov 2021 20:30:55 +0100 (CET)","by mail-wr1-x429.google.com with SMTP id b12so11590469wrh.4\n\tfor ;\n\tThu, 11 Nov 2021 11:30:55 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"ZlXI/Xv9\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=Rm56SCqAXb5uOyc72Bo1A0nWO7aIt/JfY9K6Wibt22A=;\n\tb=ZlXI/Xv9cUajKr1koyCV4xSbtY1lZSzj04i/YurC3WfSFy45QvgkbQ7B18cBYElM1/\n\t24buOHhukeMGmHIkbIG8KUzYMsItbq/YAIy76qE2EVIu+a+tCQiQiDRG6/MLm76y1RP6\n\tN1PU6Af9JDtSTdcy8KL0FwM0RLeJRjXYPwNc7Q3O4wz7ox6u4wb3YLbOo6KAq4XTg3TP\n\tME+C0EtfhnF/5Cffef5LafaXqmLeRk2xcLsRCiYx37xiyaxS7VYg5jxg0zoDRAdR/6pu\n\tpkPtHbeUTWNGlZjgFOJUEAcEuPAivAL77g7SXUNUKv3i5jEWEsZTH8QkJ6zaw5QfjoC8\n\tVXDg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=Rm56SCqAXb5uOyc72Bo1A0nWO7aIt/JfY9K6Wibt22A=;\n\tb=YCezYIzpRdeLT3zOK75Y8HT3C2yN29RG34Fe2Xvv9FuZPIJ1oRtS8m078C5IoOzUPs\n\tTmCDHmpeQM8rWUUBqxFZwFgO4QLcCYdj8aGeXL7d2aXd9X0lTVZszK68MPuTnCejj2bG\n\t4nvV1Reasb9SQlnHsU+SLOFv8iYgSxgVDEcjEKX8W+kyO35ZxgcQkpe9h7XUbL7mb0vr\n\t9zi0B6uTWAQih0tFEFqjv6oF08BrTCU99YPZkzx84piZAeGF2ueQeSAYjGUIwKzcUHUv\n\tsrnxyAzqCjATGzZdigBLGYhuB3EU2lMfBNjUnHxUWu6ePIrQgFnR9l762PEC9tY1oTnj\n\t0qQQ==","X-Gm-Message-State":"AOAM531iEZiXS5+bYBptOibbbwnKvQTLQiXg+7I6rAfhoaFLkeD3VsF9\n\tIU9HWMj35l9N9vWRs+W3kM3HvkbGVxbayDF2n45lZg==","X-Google-Smtp-Source":"ABdhPJwP/zQ8Io2BSfNk/+Y5OzMOn0xtaXTvpjgHoIv3PpmeghMiZcO3Z5QNAZnKtEl44NoLscCANB719IKlfZpVWDI=","X-Received":"by 2002:a5d:5850:: with SMTP id\n\ti16mr11432881wrf.197.1636659055425; \n\tThu, 11 Nov 2021 11:30:55 -0800 (PST)","MIME-Version":"1.0","References":"\n\t<3b61bb2d-1136-cf35-ba7a-724da9642855@gmail.com>\n\t<418dc16a-2a03-7604-a8e2-31c5ddfcf436@redhat.com>\n\t<58dabc46-211c-844d-3ed3-fd2411936d6d@gmail.com>\n\t\n\t\n\t\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>\n\t\n\t<6e832988-4810-fe59-7357-886b286697a0@redhat.com>","In-Reply-To":"<6e832988-4810-fe59-7357-886b286697a0@redhat.com>","From":"Dave Stevenson ","Date":"Thu, 11 Nov 2021 19:30:39 +0000","Message-ID":"","To":"Hans de Goede ","Content-Type":"text/plain; charset=\"UTF-8\"","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20881,"web_url":"https://patchwork.libcamera.org/comment/20881/","msgid":"","date":"2021-11-11T22:04:27","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hello,\n\nOn Thu, Nov 11, 2021 at 07:30:39PM +0000, Dave Stevenson wrote:\n> On Thu, 11 Nov 2021 at 16:50, Hans de Goede wrote:\n> > On 11/11/21 16:51, Dave Stevenson wrote:\n> > > On Thu, 11 Nov 2021 at 15:23, Hans de Goede wrote:\n> > >> On 11/11/21 12:18, Daniel Scally wrote:\n> > >>\n> > >> \n> > >>\n> > >>>>> One problem I'm experiencing\n> > >>>>> is that the focus position I set isn't maintained; it holds for a couple\n> > >>>>> of seconds and then resets to the \"normal\" focus...this happens when the\n> > >>>>> .close() callback for the driver is called, which happens right after\n> > >>>>> the control value is applied. All the other VCM drivers in the kernel\n> > >>>>> power down on .close() so I did the same>\n> > >>>> Right, I believe that this is fine though, we expect people to use\n> > >>>> libcamera with this and once libcamera gets autofocus support, then\n> > >>>> I would expect libcamera to keep the fd open the entire time while\n> > >>>> streaming.\n> > >>>\n> > >>>\n> > >>> OK - as long as that's how it works then I agree that this is fine as is\n> > >>> yes.\n> > >>\n> > >> So I've just picked up an old project of mine, called gtk-v4l which\n> > >> is a nice simply v4l2 controls applet and patches it up to also\n> > >> work on v4l-subdevs:\n> > >>\n> > >> https://github.com/jwrdegoede/gtk-v4l/\n> > >>\n> > >> So now you can run:\n> > >>\n> > >> sudo gtk-v4l -d /dev/v4l-subdev8\n> > >>\n> > >> And it will give you a slider to control the focus; and as\n> > >> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n> > >> issue :)\n> > >\n> > > Do the lens and sensor share a regulator / enable GPIO?\n> >\n> > No, if they did then there would be no runtime-pm issue,\n> > because then the VCM would not get turned off after\n> > a v4l2-set command (for a quick test) since then the\n> > streaming from the sensor would keep the sensor and\n> > thus the regulator on.\n> \n> Registering with the regulator was more so that it restored the\n> position on sensor power up, independent of whether the lens driver\n> was opened or not.\n> \n> > > I was looking at the same issue for a Sony IMX135 module with AD5398\n> > > VCM driver [1].\n> > > In my case they do share an enable GPIO, so using regulator-gpio we\n> > > can register via regulator_register_notifier for information on when\n> > > the regulator is powered up. It can then also reset to the last\n> > > position should the sensor subdev enable the regulator without the\n> > > lens driver being opened at all.\n> >\n> > That sounds like it is relying on board-depedent behavior\n> > (the enable GPIO and/or regulator being shared) which we don't\n> > want in the VCM drivers as those are supposed to be board\n> > agnostic.\n> \n> All platforms I've encountered so far have used the same GPIO to\n> control both VCM and sensor, hence why I asked. The number of use\n> cases where you want one without the other is incredibly low, and\n> hardware guys generally don't like wasting GPIOs or having to route\n> them around the PCB. It's interesting that your platform has separated\n> them.\n> \n> > This really is something which should be fixed in userspace\n> > where the userspace consumer of the sensor should also always\n> > open the vcm v4l-subdev.\n> \n> Not all use cases involve libcamera, and what you're proposing is\n> making life very difficult for the simple use cases.\n> There may be GStreamer folk on board with libcamera, but I've heard no\n> noises from FFmpeg about libcamera support. V4L2 is still the default\n> API that users generally care about. Particularly with mono sensors\n> the output is often directly usable without worrying about the\n> complexities of ISPs, but you're effectively saying \"jump through lots\n> of hoops or you can't use a VCM with these sensors\".\n\nUsage of libcamera is certainly not mandatory, but let's not forget that\nwe're dealing with complex devices. In most cases applications will want\nauto-focus, which will require a userspace camera stack. Even when using\nmanual focus, apart from moving the lens to the infinity position, there\nisn't much that an application could do without some sort of calibration\ndata. Having to keep the VCM subdev open is the easy part. As long as\nthis is documented properly in the V4L2 API, I don't think it's a big\nissue.\n\n> If userspace has called VIDIOC_STREAMON doesn't that mean they want\n> the whole entity (as configured) to be powered on and start streaming?\n> Are you saying that the lens isn't part of that entity? In which case\n> why does Media Controller include it (and eventually link it to the\n> sensor) in the media entity?\n> \n> Would you advocate making backlight control in DRM a function that\n> userspace is responsible for independently of the panel pipeline?\n> There are significant similarities to this situation as the panel\n> isn't usable without the backlight being powered, same as the sensor\n> isn't usable without the VCM being powered.\n\nIsn't the backlight actually controlled through sysfs separately from\nthe display pipeline ?\n\n> Sorry, but I just see isolating power control for the VCM from the\n> sensor in this way to be a very odd design decision. It'd be\n> interesting to hear other views.\n\nDespite the above, I wouldn't oppose powering the VCM automatically when\nthe sensor is streaming, but I'm concerned about corner cases. For\ninstance, one may want to keep the VCM powered when toggling streaming\noff and then back on. I wouldn't be surprised if there were other need\nto have control of VCM power from userspace. I haven't studied the\nquestion in details though.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 390ACBF415\n\tfor ;\n\tThu, 11 Nov 2021 22:04:53 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 543A56035A;\n\tThu, 11 Nov 2021 23:04:52 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 1A439600B5\n\tfor ;\n\tThu, 11 Nov 2021 23:04:50 +0100 (CET)","from pendragon.ideasonboard.com\n\t(117.145-247-81.adsl-dyn.isp.belgacom.be [81.247.145.117])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 9A012556;\n\tThu, 11 Nov 2021 23:04:49 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"Jc6Xfs53\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1636668289;\n\tbh=JaXSSl6CfURdaRkByhsdCbwOkUqMFeBkAxaV0dyaN0g=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Jc6Xfs532Wpf9FlPGhGh1ceCQQHpJykOH/PTaw8FfIkjtxuiVaivc7lWP9RkbcqSR\n\tVNXPkHk9oR/MdVimMs6rXlTz7rgW7CPfYj/HZFgI9tL0Jdtu1CO1ALjpon68HY/JVK\n\tMQPy+dY+4PsV+zKIRPHADzlJvYMxscWv+9Cky5nU=","Date":"Fri, 12 Nov 2021 00:04:27 +0200","From":"Laurent Pinchart ","To":"Dave Stevenson ","Message-ID":"","References":"\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>\n\t\n\t<6e832988-4810-fe59-7357-886b286697a0@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":20905,"web_url":"https://patchwork.libcamera.org/comment/20905/","msgid":"","date":"2021-11-12T10:32:31","subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","submitter":{"id":27,"url":"https://patchwork.libcamera.org/api/people/27/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.com"},"content":"Hi Laurent\n\nOn Thu, 11 Nov 2021 at 22:04, Laurent Pinchart\n wrote:\n>\n> Hello,\n>\n> On Thu, Nov 11, 2021 at 07:30:39PM +0000, Dave Stevenson wrote:\n> > On Thu, 11 Nov 2021 at 16:50, Hans de Goede wrote:\n> > > On 11/11/21 16:51, Dave Stevenson wrote:\n> > > > On Thu, 11 Nov 2021 at 15:23, Hans de Goede wrote:\n> > > >> On 11/11/21 12:18, Daniel Scally wrote:\n> > > >>\n> > > >> \n> > > >>\n> > > >>>>> One problem I'm experiencing\n> > > >>>>> is that the focus position I set isn't maintained; it holds for a couple\n> > > >>>>> of seconds and then resets to the \"normal\" focus...this happens when the\n> > > >>>>> .close() callback for the driver is called, which happens right after\n> > > >>>>> the control value is applied. All the other VCM drivers in the kernel\n> > > >>>>> power down on .close() so I did the same>\n> > > >>>> Right, I believe that this is fine though, we expect people to use\n> > > >>>> libcamera with this and once libcamera gets autofocus support, then\n> > > >>>> I would expect libcamera to keep the fd open the entire time while\n> > > >>>> streaming.\n> > > >>>\n> > > >>>\n> > > >>> OK - as long as that's how it works then I agree that this is fine as is\n> > > >>> yes.\n> > > >>\n> > > >> So I've just picked up an old project of mine, called gtk-v4l which\n> > > >> is a nice simply v4l2 controls applet and patches it up to also\n> > > >> work on v4l-subdevs:\n> > > >>\n> > > >> https://github.com/jwrdegoede/gtk-v4l/\n> > > >>\n> > > >> So now you can run:\n> > > >>\n> > > >> sudo gtk-v4l -d /dev/v4l-subdev8\n> > > >>\n> > > >> And it will give you a slider to control the focus; and as\n> > > >> a bonus it keeps the v4l-subdev open, so no more runtime-pm\n> > > >> issue :)\n> > > >\n> > > > Do the lens and sensor share a regulator / enable GPIO?\n> > >\n> > > No, if they did then there would be no runtime-pm issue,\n> > > because then the VCM would not get turned off after\n> > > a v4l2-set command (for a quick test) since then the\n> > > streaming from the sensor would keep the sensor and\n> > > thus the regulator on.\n> >\n> > Registering with the regulator was more so that it restored the\n> > position on sensor power up, independent of whether the lens driver\n> > was opened or not.\n> >\n> > > > I was looking at the same issue for a Sony IMX135 module with AD5398\n> > > > VCM driver [1].\n> > > > In my case they do share an enable GPIO, so using regulator-gpio we\n> > > > can register via regulator_register_notifier for information on when\n> > > > the regulator is powered up. It can then also reset to the last\n> > > > position should the sensor subdev enable the regulator without the\n> > > > lens driver being opened at all.\n> > >\n> > > That sounds like it is relying on board-depedent behavior\n> > > (the enable GPIO and/or regulator being shared) which we don't\n> > > want in the VCM drivers as those are supposed to be board\n> > > agnostic.\n> >\n> > All platforms I've encountered so far have used the same GPIO to\n> > control both VCM and sensor, hence why I asked. The number of use\n> > cases where you want one without the other is incredibly low, and\n> > hardware guys generally don't like wasting GPIOs or having to route\n> > them around the PCB. It's interesting that your platform has separated\n> > them.\n> >\n> > > This really is something which should be fixed in userspace\n> > > where the userspace consumer of the sensor should also always\n> > > open the vcm v4l-subdev.\n> >\n> > Not all use cases involve libcamera, and what you're proposing is\n> > making life very difficult for the simple use cases.\n> > There may be GStreamer folk on board with libcamera, but I've heard no\n> > noises from FFmpeg about libcamera support. V4L2 is still the default\n> > API that users generally care about. Particularly with mono sensors\n> > the output is often directly usable without worrying about the\n> > complexities of ISPs, but you're effectively saying \"jump through lots\n> > of hoops or you can't use a VCM with these sensors\".\n>\n> Usage of libcamera is certainly not mandatory, but let's not forget that\n> we're dealing with complex devices. In most cases applications will want\n> auto-focus, which will require a userspace camera stack. Even when using\n> manual focus, apart from moving the lens to the infinity position, there\n> isn't much that an application could do without some sort of calibration\n> data. Having to keep the VCM subdev open is the easy part. As long as\n> this is documented properly in the V4L2 API, I don't think it's a big\n> issue.\n\nYou know I've never been a huge fan of Media Controller, but at least\nthere you can preconfigure your pipeline via media-ctl and then stream\nwith v4l2-ctl. If the VCM isn't powered, then v4l2-ctl becomes largely\nuseless as a test tool without now having a second program to hold the\nsubdev open (as Hans has found out). The same goes for anything else\nthat streams a pre-configured pipeline (eg GStreamer v4l2src or FFmpeg\nv4l2 plugin).\n\nPreconfigure your lens position via \"v4l2-ctl\n--set-ctrl=focus_absolute=X\", or have a sensible default in the VCM\ndriver config (it describes the hardware, so it could be in DT), have\nthe pipeline handle power, and you still have a usable capture device\nthrough just V4L2. Otherwise you're saying that the powered down\nposition of the VCM (wherever that might be) is the best you get.\n\n> > If userspace has called VIDIOC_STREAMON doesn't that mean they want\n> > the whole entity (as configured) to be powered on and start streaming?\n> > Are you saying that the lens isn't part of that entity? In which case\n> > why does Media Controller include it (and eventually link it to the\n> > sensor) in the media entity?\n> >\n> > Would you advocate making backlight control in DRM a function that\n> > userspace is responsible for independently of the panel pipeline?\n> > There are significant similarities to this situation as the panel\n> > isn't usable without the backlight being powered, same as the sensor\n> > isn't usable without the VCM being powered.\n>\n> Isn't the backlight actually controlled through sysfs separately from\n> the display pipeline ?\n\nBrightness is controlled via sysfs, same as lens position is set via\nthe VCM subdev.\nIt allows for an override of the state via sysfs, same as you can have\nuserspace open the VCM subdev.\nHowever drm_panel_enable [1] calls backlight_enable, and\ndrm_panel_disable [2] calls backlight_disable for automatic control by\nthe framework.\n\n[1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_panel.c#L151\n[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_panel.c#L183\n\n> > Sorry, but I just see isolating power control for the VCM from the\n> > sensor in this way to be a very odd design decision. It'd be\n> > interesting to hear other views.\n>\n> Despite the above, I wouldn't oppose powering the VCM automatically when\n> the sensor is streaming, but I'm concerned about corner cases. For\n> instance, one may want to keep the VCM powered when toggling streaming\n> off and then back on. I wouldn't be surprised if there were other need\n> to have control of VCM power from userspace. I haven't studied the\n> question in details though.\n\nRefcount the users. Opening the subdev counts as one, and streaming\ncounts as one. You can now hold the power on if you wish to do so.\n\nIt's the \"let userspace worry about it\" that worries me. The same\napproach was taken with MC, and it was a pain in the neck for users\nuntil libcamera comes along a decade later.\nIMHO V4L2 as an API should be fit for purpose and usable with or\nwithout libcamera.\nTelling users that they need to go and read the EDID for their display\nthemselves and configure the mode would be viewed as daft, but the I2C\nchannel to a display is largely as independent of the display pipeline\nas the VCM is to the video pipeline. Perhaps display pipelines aren't\ncomplex enough?\n\nSorry, just my two-penneth as someone who has to support general\nusers, rather than just develop platforms or address specific use\ncases.\n\n Dave","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C7B70BF415\n\tfor ;\n\tFri, 12 Nov 2021 10:32:51 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id B3E826034D;\n\tFri, 12 Nov 2021 11:32:50 +0100 (CET)","from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com\n\t[IPv6:2a00:1450:4864:20::32b])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A140860234\n\tfor ;\n\tFri, 12 Nov 2021 11:32:48 +0100 (CET)","by mail-wm1-x32b.google.com with SMTP id z200so7314926wmc.1\n\tfor ;\n\tFri, 12 Nov 2021 02:32:48 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"b7I6dsuM\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=lEgRWZPJOnuaXyVqSLHqW3ZI0kRkx6uv+t5iGzsqTSQ=;\n\tb=b7I6dsuMphrrez1452Etqw93omgStljnKAbBEOtMb0GC+Ovdr5Kqqy+lGfhfsaIFTR\n\t8tEcA2Z5lukrTFWoTi39+kS9qsMEcJiv8iIVVcKvehsGQztk1ERCGK3qcbq9HQWRG8kR\n\tyl+SL6GEa2urMvovOHd4CZC0ZqnqYdgh8qwxbrK3DnYgdTOTJgTcAfJ23RRIXmvqwzWP\n\tVRmU/Jg5aFxEKkjjWI//IpZlW4593R9xyVlirYy/2zAq3+QY+/yEMpeL1vgVCoEzf7Ii\n\tLq2MRpwN5Akj//6Bq+1sqiZzMmH3LgSYSxj0J629Q3Zs5vT08Bmyx1AucekD1beGjbdt\n\tacmg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=lEgRWZPJOnuaXyVqSLHqW3ZI0kRkx6uv+t5iGzsqTSQ=;\n\tb=evoCM/98FuBfxFMwHYS16FhWvJzKx/Wd5dVQvC9sCMV+1Iaw8tyMvZKGlIaJHUgx/A\n\tDNWSN77tr4RcviMgZ+HP1Ll+h0u4yLIE1uhxU5UuujPkDoyVfmNZM2Szn7W3BaDUM+tY\n\tRwTM8aLg3CLlrzPNwtHHjlXVruY+o2ZRvFJ04vP8mINTFLQbkYIsLxLwzoLUk33kvP28\n\tYKcqjg/BhtMyWGxZB1KRlUQRoSsc3MLKsx/hMPgKTm+3+XVLrhyqWyS8Rm/LoS4CYqUB\n\tQYsz5LxQsP/wNB4/KpkDCgzvVVQDejSmbMSJp9sEVErd0CAE3V+A6hpq8o3T2TmFKwke\n\t5Zpw==","X-Gm-Message-State":"AOAM532UiNjv8zpsutwecvjFE1W7QQhaEm2meSxK9VslnuXJbbPZIN/t\n\tz/zRulHUA9io34y9caMDO8eK5nEhFqDweuJ2MHHtqQ==","X-Google-Smtp-Source":"ABdhPJwXYjwXRutw8o9DY1Qex+uF2PYT5LR3N+WCFgoTOTNC06Xc/jtSC1DsVygCbsW49/96CmIn3pbi/sKjq6Sh0yo=","X-Received":"by 2002:a05:600c:358a:: with SMTP id\n\tp10mr15622734wmq.180.1636713168180; \n\tFri, 12 Nov 2021 02:32:48 -0800 (PST)","MIME-Version":"1.0","References":"\n\t\n\t<29bf3454-2f82-7791-2aa2-c5e1cb5610a5@gmail.com>\n\t<6ee7c491-4636-8819-c954-dfc6abcfd1a5@gmail.com>\n\t<495cbb6b-656d-6c3b-669a-f4b588e970cc@redhat.com>\n\t\n\t<4c7b9d72-4634-ea1d-5fff-bf17c3834b72@redhat.com>\n\t\n\t<6e832988-4810-fe59-7357-886b286697a0@redhat.com>\n\t\n\t","In-Reply-To":"","From":"Dave Stevenson ","Date":"Fri, 12 Nov 2021 10:32:31 +0000","Message-ID":"","To":"Laurent Pinchart ","Content-Type":"text/plain; charset=\"UTF-8\"","Subject":"Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass\n\tacpi_enforce_resources=lax on the Surface Go (version1))","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ,\n\tAndy Shevchenko ,\n\tLinux Media Mailing List ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]