From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D2B6183CD6 for ; Sat, 28 Sep 2024 10:46:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727520404; cv=none; b=jOgXpw/DUN56SNUap+pC0UPCEnxbx2LE0yfzuOWVSsoRal/zwcSXev8LRPn3ZDOJtHaI2hYZaVN6U7soh+bH1xr5nRTIUMrXiXz/tg+cQOCXa2bdX3RpLkOnFXPRARkzin1IbNuy3u5PNBQB1mJgPRXQamZmqWIZajdZFtQ8hNU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727520404; c=relaxed/simple; bh=Ei6/ccAdpO9+K8ToXprbjnDvfcVFhhzoN0+sWM3un3o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LCAMELJZXQpCaHIT3zkjWFq+4sETFi9hcAez3D9kOfJlTSwbGOimhPoQmbx7NMuZqvFlySvsPv9EkAok1dfSVZ3Q+onNlO+xohX5a+CqrL02cgkZHaLtMb1mOJM9qBHRJmatccD1nInMtrSqs96a8GP+48dQEGFVfkFMBLgMv5U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=Q2i/naNj; arc=none smtp.client-ip=209.85.167.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Q2i/naNj" Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5398aeceb51so137443e87.0 for ; Sat, 28 Sep 2024 03:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1727520400; x=1728125200; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=TXl4k8mZsxgHoI3VWw6PVnVAQPFUA35ZT1bf6htZGpw=; b=Q2i/naNjF5E89/ugKAV7A5ioLVfKbTsnt/K6+sbBksI6Kcp/4uFm3a4Mrxy0vR2UGO FCNexXdm1RCaPY2NZ0Sd0UlOGi6Br4xTKcq+45Om36KAJ8VHCox/HNPCt0zdL4x+N7hl 4j41uORW0UzfYY6CJH+QOM4zmiVPDLJIZiiBnl8/7xQSogv9qdanValGxq1TJtqzzED+ w4ROtf8l60IYA58P/22jU3DBkiSztZB0X0VWjnTEhY77NFX97aiy+OLpgEziehrEwZvP 8kccJFFqU2MbdgpX4FrD9D090Gx8ogL3aqh07PvTVCPdVsxma55oDjx7Ewp2N6HZtFTD RZMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727520400; x=1728125200; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TXl4k8mZsxgHoI3VWw6PVnVAQPFUA35ZT1bf6htZGpw=; b=Zd83Lk+9j+WJDmMve5CYaxC7XG72brbuK8xJPSVhk/nTrZnoVMdlqL+xI0L7LvV2Bw JsbLGCx9sMZKSuPaxIc8CaomWGeseYj7ymH1IImj11gVu9VWO/4kwPgzu1nu+cUC5Ptj PlAMVRxgABMFzsULRHmyEbPLbq5kKI8zi8HjNNFARcFlN6djwwll40PinwfGhRz+fTqa s506alicrAwLLvWPfyImk5UwUIVzvaTdIf5EBzss/7RAOm4EfgcHC5xNKc5lk+sKY8J0 Lf2rBWc85I600m2TPOEAdf7f8b79zJb6sCUJDxZJk4CmfKLC9NEajssuWWtDmBBTFwxF qRtg== X-Forwarded-Encrypted: i=1; AJvYcCV3qGq3qbufx7EOnl8ys84caFdxbR6v/+7ooyHN32cdsHYSkQqJLXZ3ywCBCKYcCp8+kF3CaNPQN4C3@vger.kernel.org X-Gm-Message-State: AOJu0YyGwXugiNCjEH77MsH7a5qjAUAj1P4q3aLVWeu/CG/79SE1C3oA ed2Fj1r2DNYYZCajvqtAzrr+PchRAda7J9GdquMSm9DBnhZJiW6JceXwkqqX4b0= X-Google-Smtp-Source: AGHT+IGsmYsnTJi0UA9gkkFBqJigGWkiZumRwMsuVRnPqYW+9Inz7cEUrpbiw3sVbiDeWsbzm89sxQ== X-Received: by 2002:a05:6512:1396:b0:52c:def2:d8af with SMTP id 2adb3069b0e04-5389fc430a0mr1143476e87.4.1727520400331; Sat, 28 Sep 2024 03:46:40 -0700 (PDT) Received: from [192.168.1.4] (88-112-131-206.elisa-laajakaista.fi. [88.112.131.206]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-538a0458ffesm610795e87.300.2024.09.28.03.46.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Sep 2024 03:46:38 -0700 (PDT) Message-ID: Date: Sat, 28 Sep 2024 13:46:37 +0300 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/7] Add SDM670 camera subsystem Content-Language: en-US To: Richard Acayan Cc: Bryan O'Donoghue , Andi Shyti , Bjorn Andersson , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Loic Poulain , Robert Foss , Todor Tomov , Mauro Carvalho Chehab , Konrad Dybcio , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-i2c@vger.kernel.org, linux-media@vger.kernel.org References: <20240904020448.52035-9-mailingradian@gmail.com> <5c58b41a-7fc7-456d-979c-edb8dbe4305d@linaro.org> From: Vladimir Zapolskiy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Richard. On 9/28/24 01:23, Richard Acayan wrote: > On Fri, Sep 06, 2024 at 04:00:32PM +0300, Vladimir Zapolskiy wrote: >> Hi Bryan, Richard, >> >> On 9/6/24 15:19, Bryan O'Donoghue wrote: >>> On 06/09/2024 03:36, Richard Acayan wrote: >>>> On Thu, Sep 05, 2024 at 10:09:34PM +0200, Andi Shyti wrote: >>>>> Hi Richard, >>>>> >>>>> On Tue, Sep 03, 2024 at 10:04:49PM GMT, Richard Acayan wrote: >>>>>> This adds support for the camera subsystem on the Snapdragon 670. >>>>>> >>>>>> As of next-20240902, camss seems to be a bit broken, but the same series >>>>>> works on stable (although it is much less reliable now that the CCI clock >>>>>> frequency is not being assigned). >>>>> >>>>> I am not understanding this bit: is this series making it better >>>>> or not? Can you please clarify what is broken, what is less >>>>> reliable and what works? >>>> >>>> When applying this camss series and some camera sensor patches on >>>> linux-next, the Pixel 3a seems to hang when camera capture starts. >>>> >>>> When applying the same patches on stable, the camera does not cause the >>>> Pixel 3a to hang. >>> >>> Right so -next isn't stable that's not exactly a revelation. >>> >>> >>>> When these device tree properties from the previous series were removed: >>>> >>>> assigned-clocks = <&camcc CAM_CC_CCI_CLK>; >>>> assigned-clock-rates = <37500000>; >>>> >>>> the CCI would sometimes fail to probe with the error: >>> >>> Right, we don't have clk_set_rate in the cci driver. >>> >>> Maybe just leave the assigned clock for this submission and we can do a >>> sweep of fixes to CCI at a later stage including setting the clock >>> instead of having it be assigned. >> >> first of all it would be nice to confirm that the setting of a particular >> clock frequency is actually needed. >> >> Fortunately it's pretty trivial to check it in runtime with a temporary >> modification in the board dts file, namely disable CAMSS in board dts file, >> but keep CCI enabled, then simply scan the bus with a regular "i2cdetect" >> tool in runtime. >> >> If i2cdetect on the CCI bus works only for 37.5MHz clock frequency, then it >> is needed, otherwise (and this is my expectation) it is not needed neither >> in the dtsi files nor in the driver. >> >>>> >>>> [ 51.572732] i2c-qcom-cci ac4a000.cci: deferred probe timeout, ignoring dependency >>>> [ 51.572769] i2c-qcom-cci ac4a000.cci: probe with driver i2c-qcom-cci failed with error -110 >>>> >>>> On further testing, the rate can be set to 19.2 MHz, and there would be >>>> no failure (or rather, it wouldn't happen often enough for me to witness >>>> it). >>> >>> That's expected 19.2 and 37.5 MHz are supported by CAMCC for your part. >>> >> >> I read it as the setting of 37.5MHz clock frequency is not needed, please >> correct me. > > It is not. My test setup just needs specific EPROBE_DEFER behaviour > (my setup being postmarketOS with a full-disk encryption password prompt > and camcc-sdm845 loaded after mounting the root filesystem). Good, let the assigned clock frequency be dropped from the dtsi file then. > In drivers/base/platform.c, the platform_probe() function calls > of_clk_set_defaults() then dev_pm_domain_attach() prior to probing the > driver: > > static int platform_probe(struct device *_dev) > { > ... > ret = of_clk_set_defaults(_dev->of_node, false); > if (ret < 0) > return ret; > > ret = dev_pm_domain_attach(_dev, true); > if (ret) > goto out; > > if (drv->probe) { > ret = drv->probe(dev); > if (ret) > dev_pm_domain_detach(_dev, true); > } > ... > } > > When handling the assigned-clock-rates property, > of_clk_get_hw_from_clkspec() eventually returns ERR_PTR(-EPROBE_DEFER), > being propagated all the way. > > When handling the power-domains property (if not avoided by deferring > with the assigned clock), __genpd_dev_pm_attach() returns a value > returned by driver_deferred_probe_check_state(), which is immediately > -ETIMEDOUT. I grasp it from the problem description, thank you for the explanation. For sake of simplicity please make camcc-sdm845 as a built-in driver while testing, it will allow to progress with the platform CAMSS support. The issue with the observed ETIMEDOUT is generic and it's kind of unrelated to the CCI/CAMSS support on SDM670. -- Best wishes, Vladimir