Thanks Bjorn.
On 11/19/2024 8:29 PM, Bjorn Andersson wrote:
On Tue, Nov 19, 2024 at 8:29 AM Mukesh Kumar Savaliya
<quic_msavaliy@xxxxxxxxxxx> wrote:
On 10/11/2024 11:28 PM, Bjorn Andersson wrote:
On Fri, Oct 11, 2024 at 05:47:57PM +0530, Mukesh Kumar Savaliya wrote:
[..]
pm_runtime_get_sync() function fails during PM early resume and returning
-EACCES because runtime PM for the device is disabled at the early stage
causing i2c transfer to fail. Make changes to serve transfer with forced
resume.
Few i2c clients like PCI OR touch may request i2c transfers during early
resume stage. In order to serve transfer request do :
This problem description is too generic. I am not aware of any use case
upstream where PCI or touch might need to perform i2c transfers during
early resume; your commit message should educate me.
yes, it's generic as of now since we have an internal usecase with PCI
is yet to be enabled in upstream. Not tied up with any usecase in
upstream, i just heard recently.
Provided the scenario is generic and possible by any client, can this
code change be reviewed or shall be kept on halt till PCI usecase gets
enabled ?
If this is a valid scenario in the upstream kernel, yes. If it solves
a problem only manifesting itself based on a downstream design then
you need to exactly describe that scenario so that reviewers can
decide if this is a problem with the upstream kernel or your
downstream design.
The exact scenario from PCIe switch is as below. Hope it describes the
usecase at high level to understand PCIe client -> PCIe Driver -> I2C
driver.
PCIe switch needs certain configurations through i2c after powering on
the switch, as part of suspend we are using suspend_noirq() to turn off
the switch because some PCIe clients do some transfers till
suspend_noirq() phase. And as part of resume_noirq(), we will enable the
power to the switch and configures the switch again through i2c.
Regards,
Bjonr
