Probe failures on mt8183-kukui-jacuzzi-juniper-sku16

[Chen-Yu Tsai]

On Wed, Jun 5, 2024 at 8:33 PM Nícolas F. R. A. Prado
<nfraprado at collabora.com> wrote:
>
> On Wed, Jun 05, 2024 at 04:01:06PM +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Tue, Jun 4, 2024 at 11:52 PM Nícolas F. R. A. Prado
> > <nfraprado at collabora.com> wrote:
> > >
> > > Hi,
> > >
> > > We're monitoring the status of device probe on the
> > > mt8183-kukui-jacuzzi-juniper-sku16 platform in KernelCI, and I thought it'd be
> > > helpful to share the results.
> > >
> > > These are the current failures:
> > >
> > > * /soc/i2c at 11009000/trackpad at 15
> > > * /soc/svs at 1100bc00
> > > * /thermal-sensor1
> > > * /thermal-sensor2
> > >
> > > In more details:
> > >
> > > * /soc/i2c at 11009000/trackpad at 15: I believe this is a second source trackpad and
> > >   is thus waiting for the "platform/chrome: Introduce DT hardware prober" series
> > >   [1] to be merged before it can be handled. Although looks like there haven't
> > >   been updates to the series in a while.
> >
> > I've been working on other stuff and haven't had time to respin this series.
>
> No worries, but it's good to know that that's the latest status and I didn't
> miss something.
>
> >
> > Just to confirm, is the failure due to pinctrl conflicts when the trackpad
> > variants probe asynchronously?
>
> Yes:
>
> [    2.185408] input: hid-over-i2c 06CB:CDB5 Mouse as /devices/platform/soc/11009000.i2c/i2c-2/2-002c/0018:06CB:CDB5.0001/input/input2
> [    2.845044] mt8183-pinctrl 10005000.pinctrl: pin GPIO7 already requested by 2-002c; cannot claim for 2-0015
> [    2.854700] mt8183-pinctrl 10005000.pinctrl: error -EINVAL: pin-7 (2-0015)
> [    2.869503] mt8183-pinctrl 10005000.pinctrl: error -EINVAL: could not request pin 7 (GPIO7) from group GPIO7  on device pinctrl_paris
> [    2.894885] elan_i2c 2-0015: Error applying setting, reverse things back

Yup. That's the issue. We work around it either with staggered driver probe
(built-in vs module) or move the pinctrl up to the i2c bus node.

> >
> [..]
> > > * /thermal-sensor1, /thermal-sensor2: The following is reported:
> > >
> > >     [    2.813605] thermal_sys: Failed to find 'trips' node
> > >     [    2.813611] thermal_sys: Failed to find trip points for thermal-sensor1 id=0
> > >     [    2.813619] generic-adc-thermal thermal-sensor1: Thermal zone sensor register failed: -22
> > >     [    2.813624] generic-adc-thermal thermal-sensor1: probe with driver generic-adc-thermal failed with error -22
> > >
> > >   And the same for thermal-sensor2. So both are missing the required 'trips'
> > >   subnode.
> >
> > IIRC either the driver or the DT had comments saying "these zones don't
> > need trip points". In that case maybe the driver should use
> > thermal_tripless_zone_device_register() for them?
>
> I believe you're thinking of the SoC thermal zones, which had trips added (and
> the comment removed) in commit 978979409209 ("arm64: dts: mediatek: mt8183:
> Refactor thermal zones"). But these are the kukui board thermal zones.

I see. I dug through the schematics we have, and they all seem to say that
the first NTC is for the SoC. The use for the second one seems to depend
on the project, with some saying close to the LCM (display?) or LTE PA,
and on the Jacuzzi family it's for ambient temp.

Regarding trip points, for the NTC close to the SoC, I guess we could copy
the SoC thermal trip points and reduce the values by some amount, 20
degrees maybe? For the other one we could probably make the critical
trip point some value that feels hot to the touch?

ChenYu

> The thermal-zones dt-binding does describe the 'trips' node as required, so I
> think the only option in this case is to add trips to them, or remove the
> thermal zones altogether. I'm guessing the
> thermal_tripless_zone_device_register() helper is meant for other thermal zones
> that aren't described in the DT.
>
> Thanks,
> Nícolas