[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E40AAF0BF@FRAEML521-MBX.china.huawei.com>
Date: Tue, 13 Jun 2017 19:01:38 +0000
From: Gabriele Paoloni <gabriele.paoloni@...wei.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
"rafael@...nel.org" <rafael@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"will.deacon@....com" <will.deacon@....com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"frowand.list@...il.com" <frowand.list@...il.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"brian.starkey@....com" <brian.starkey@....com>,
"olof@...om.net" <olof@...om.net>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Linuxarm <linuxarm@...wei.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"minyard@....org" <minyard@....org>,
John Garry <john.garry@...wei.com>,
"xuwei (O)" <xuwei5@...ilicon.com>
Subject: RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
devices before scanning
Hi Mika
> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@...ux.intel.com]
> Sent: 13 June 2017 16:10
> To: Gabriele Paoloni
> Cc: Lorenzo Pieralisi; rafael@...nel.org; Rafael J. Wysocki;
> catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> frowand.list@...il.com; bhelgaas@...gle.com; arnd@...db.de; linux-arm-
> kernel@...ts.infradead.org; mark.rutland@....com;
> brian.starkey@....com; olof@...om.net; benh@...nel.crashing.org; linux-
> kernel@...r.kernel.org; linux-acpi@...r.kernel.org; Linuxarm; linux-
> pci@...r.kernel.org; minyard@....org; John Garry; xuwei (O)
> Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
> devices before scanning
>
> On Tue, Jun 13, 2017 at 02:38:26PM +0000, Gabriele Paoloni wrote:
> > > Is there an example ASL showing how these LPC devices are
> > > currently presented in ACPI?
> >
> > Please find below the asl sketch for our LPC and IPMI
> >
> > //
> > // LPC
> > //
> >
> > Scope(_SB) {
> > Device (LPC0) {
> > Name (_HID, "HISI0191") // HiSi LPC
> > Name (_CRS, ResourceTemplate () {
> > Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000)
> > })
> > }
> >
> > Device (LPC0.IPMI) {
> > Name (_HID, "IPI0001")
> > Method (_IFT) {
> > Return (0x03)
> > }
> > Name (LORS, ResourceTemplate() {
> > QWordIO (
> > ResourceConsumer,
> > MinNotFixed, // _MIF
> > MaxNotFixed, // _MAF
> > PosDecode,
> > EntireRange,
> > 0x0, // _GRA
> > 0xe4, // _MIN
> > 0x3fff, // _MAX
> > 0x0, // _TRA
> > 0x04, // _LEN
> > , ,
> > BTIO
> > )
> > })
> > CreateQWordField (LORS, BTIO._MIN, CMIN)
> > CreateQWordField (LORS, BTIO._MAX, CMAX)
> > CreateQWordField (LORS, BTIO._LEN, CLEN)
> >
> > Method (_PRS, 0) {
> > Return (LORS)
> > }
> >
> > Method (_CRS, 0) {
> > Return (LORS)
> > }
> > Method (_SRS, 1) {
> > CreateQWordField (Arg0, \_SB.LPC0.IPMI.BTIO._MIN, IMIN)
> > Store (IMIN, CMIN)
> > CreateQWordField (Arg0, \_SB.LPC0.IPMI.BTIO._MAX, IMAX)
> > Store (IMAX, CMAX)
> > }
> > }
> > [...]
> > }
>
> Thanks. So this looks pretty much like normal Linux MFD device which we
> already have support for adding ACPI bindings to child devices. It
> should also support splitting resources to child devices IIRC.
I am not very familiar with Linux MFD however the main issue here is that
1) for IPMI we want to re-use the standard IPMI driver without touching it:
see
static const struct acpi_device_id acpi_ipmi_match[] = {
{ "IPI0001", 0 },
{ },
};
in "drivers/char/ipmi/ipmi_si_intf.c" (and in general any standard driver
of an LPC child)
2) We need a way to guarantee that all LPC children are not enumerated
by acpi_default_enumeration() (so for example if an ipmi node is an LPC#
child it should not be enumerated, otherwise it should be)
Currently acpi_default_enumeration() skips spi/i2c slaves by checking:
1) if the acpi resource type is a serial bus
2) if the type of serial bus descriptor is I2C or SPI
For LPC we cannot leverage on any ACPI property to "recognize" that our
devices are LPC children; hence before I proposed for acpi_default_enumeration()
to skip devices that have already been enumerated (by calling
acpi_device_enumerated() ).
So in the current scenario, how do you think that MFD can help?
Do you see any possible solution?
Many thanks
Gab
Powered by blists - more mailing lists