From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR Date: Fri, 29 Apr 2016 17:56:14 -0700 Message-ID: References: <1461839010-110231-1-git-send-email-mika.westerberg@linux.intel.com> <20160429090351.GS12528@pali> <201604292300.23616@pali> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Andy Lutomirski , Mika Westerberg , Jean Delvare , Wolfram Sang , Jarkko Nikula , "Rafael J. Wysocki" , "linux-i2c@vger.kernel.org" , Linux ACPI , Mario Limonciello List-Id: linux-i2c@vger.kernel.org On Fri, Apr 29, 2016 at 2:42 PM, Andy Lutomirski = wrote: > On Fri, Apr 29, 2016 at 2:00 PM, Pali Roh=C3=A1r wrote: >> On Friday 29 April 2016 20:10:23 Andy Lutomirski wrote: >>> On Fri, Apr 29, 2016 at 2:03 AM, Pali Roh=C3=A1r >>> wrote: >>> > On Thursday 28 April 2016 11:34:38 Andy Lutomirski wrote: >>> >> On 04/28/2016 03:23 AM, Mika Westerberg wrote: >>> >> >Many Intel systems the BIOS declares a SystemIO OpRegion below >>> >> >the SMBus >>> >> > >>> >> >PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 9= 00: >>> >> > Device (SBUS) >>> >> > { >>> >> > >>> >> > OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10) >>> >> > Field (SMBI, ByteAcc, NoLock, Preserve) >>> >> > { >>> >> > >>> >> > HSTS, 8, >>> >> > Offset (0x02), >>> >> > HCON, 8, >>> >> > HCOM, 8, >>> >> > TXSA, 8, >>> >> > DAT0, 8, >>> >> > DAT1, 8, >>> >> > HBDR, 8, >>> >> > PECR, 8, >>> >> > RXSA, 8, >>> >> > SDAT, 16 >>> >> > >>> >> > } >>> >> > >>> >> >There are also bunch of ASL methods that that the BIOS can use = to >>> >> >access these fields. Most of the systems in question ASL method= s >>> >> >accessing the SMBI OpRegion are never used. >>> >> > >>> >> >Now, because of this SMBI OpRegion many systems fail to load th= e >>> >> >SMBus >>> >> > >>> >> >driver with an error looking like one below: >>> >> > ACPI Warning: SystemIO range >>> >> > 0x0000000000003040-0x000000000000305F >>> >> > >>> >> > conflicts with OpRegion >>> >> > 0x0000000000003040-0x000000000000304F >>> >> > (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255) >>> >> > >>> >> > ACPI: If an ACPI driver is available for this device, you >>> >> > should use >>> >> > >>> >> > it instead of the native driver >>> >> > >>> >> >The reason is that this SMBI OpRegion conflicts with the PCI BA= R >>> >> >used by the SMBus driver. >>> >> > >>> >> >It turns out that we can install a custom SystemIO address spac= e >>> >> >handler for the SMBus device to intercept all accesses through >>> >> >that OpRegion. This allows us to share the PCI BAR with the ASL >>> >> >code if it for some reason is using it. We do not expect that >>> >> >this OpRegion handler will ever be called but if it is we print >>> >> >a warning and execute the read/write operation under a lock >>> >> >which prevents ASL and OS from messing each other. >>> >> >>> >> Tested-by: Andy Lutomirski # Dell XPS 13 9350 >>> >> >>> >> This successfully works around: >>> >> >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=3D110041 >>> >> >>> >> but the BIOS people should still fix their ASL. Sigh. >>> >> >>> >> On the Dell laptop, the observable effect is that the driver loa= ds >>> >> and finds the iTCO thing. >>> >> >>> >> Pali, this may be considerably more useful on your laptop. >>> > >>> > Andy, I am right that I will be able to load i2c-i801.ko driver >>> > without acpi_enforce_resources=3Dlax parameter? >>> >>> Yes, and it works on my laptop. >> >> Looks like it is working also on my laptop. >> >>> > If yes, then it sounds good! Finally I would be able to bind >>> > lis3lv02d_i2c.ko driver for accelerometer which is on my E6440 >>> > machine. >>> > >>> > Andy, is there any way to tell i2c-i801.ko driver that on i2c bus >>> > (which that driver exports) is present some i2c device? Months ag= o >>> > I got list of Latitude machines on which i2c address is that >>> > accelerometer present. >>> > >>> > It is possible to hardcode that mapping (DMI name of laptop --> i= 2c >>> > address) into dell-laptop driver, so i2c-i801.ko and >>> > lis3lv02d_i2c.ko will be automatically loaded and lis3l binded >>> > correctly to i801 i2c address? >>> >>> I don't know how this part works, but I doubt that doing it in >>> dell-laptop will be convenient. After all, dell-laptop can load >>> before i2c-i801. >>> >>> Jean and Wolfram: is there a quirk mechanism to add i2c devices tha= t >>> aren't directly enumerable but are known to exist due to DMI? >> >> Maybe something like i2c_register_board_info()? > > Maybe. i think that wants to be called before the adapter shows up, = though. i2c_probe_optional_slaves may be a more appropriate place to put this. Also, is there any indication in your DSDT that this thing exists? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html