[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2551b3f1-0dc0-aaf1-680c-9634d2a6b65d@linux.intel.com>
Date: Wed, 9 Feb 2022 17:11:24 +0200
From: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To: Jan Dabros <jsd@...ihalf.com>, linux-kernel@...r.kernel.org,
linux-i2c@...r.kernel.org, andriy.shevchenko@...ux.intel.com
Cc: mika.westerberg@...ux.intel.com, hdegoede@...hat.com,
wsa@...nel.org, rrangel@...omium.org, mw@...ihalf.com,
jaz@...ihalf.com, upstream@...ihalf.com, thomas.lendacky@....com,
alexander.deucher@....com, Nimesh.Easow@....com,
mario.limonciello@....com, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v4 0/2] i2c-designware: Add support for AMD PSP semaphore
On 2/8/22 16:12, Jan Dabros wrote:
> This patchset comprises support for new i2c-designware controller setup on some
> AMD Cezanne SoCs, where x86 is sharing i2c bus with PSP. PSP uses the same
> controller and acts as an i2c arbitrator there (x86 is leasing bus from it).
>
> First commit aims to improve generic i2c-designware code by adding extra locking
> on probe() and disable() paths. I would like to ask someone with access to
> boards which use Intel BayTrail(CONFIG_I2C_DESIGNWARE_BAYTRAIL) to verify
> behavior of my changes on such setup.
>
I'm going to run overnight with both patches a test case that used to
cause some activity on a shared I2C bus on Baytrail based MRD 7 tablet.
Test below used to trigger system hang after a few hours - days before
some PUNIT - graphics related issue was fixed a few years ago:
#!/bin/sh
X &
export DISPLAY=:0
sleep 2
xclock -update 30 -digital -geometry 500x50+1+1027 &
xload -update 60 -bg black -hl red -fg green -geometry 1916x250+1+774 &
sleep 1
xsetroot -solid red
xset s noblank s off -dpms
glxgears >/dev/null &
while :; do acpi -b; sleep 1.2; done
Powered by blists - more mailing lists