Message ID | 1520333268-82754-1-git-send-email-john.garry@huawei.com |
---|---|
Headers | show |
Series | LPC: legacy ISA I/O support | expand |
On Tue, 2018-03-06 at 18:47 +0800, John Garry wrote: > This patchset supports the IPMI-bt device attached to the Low-Pin- > Count > interface implemented on Hisilicon Hip06/Hip07 SoC. > ----------- > | LPC host| > | | > ----------- > | > _____________V_______________LPC > | | > V V > ------------ > | BT(ipmi)| > ------------ > > When master accesses those peripherals beneath the Hip06/Hip07 LPC, a > specific > LPC driver is needed to make LPC host generate the standard LPC I/O > cycles with > the target peripherals'I/O port addresses. But on curent arm64 world, > there is > no real I/O accesses. All the I/O operations through in/out accessors > are based > on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed > through driver > specific accessors rather than MMIO. > To solve this issue and keep the relevant existing peripherals' > drivers untouched, > this patchset: > - introduces a generic I/O space management framework, logical PIO, > to support > I/O operations on host controllers operating either on MMIO > buses or on buses > requiring specific driver I/O accessors; > - redefines the in/out accessors to provide a unified interface for > both MMIO > and driver specific I/O operations. Using logical PIO, th call of > in/out() from > the host children drivers, such as ipmi-si, will be redirected to > the > corresponding device-specific I/O hooks to perform the I/O > accesses. > > Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC > peripherals can > be supported without any changes on the existing ipmi-si driver. > > The whole patchset has been tested on Hip07 D05 board both using DTB > and ACPI. > > V15 thread here: https://lkml.org/lkml/2018/2/26/584 Thanks for an update. Though I answered to previous thread. Summary: I'm fine with the series as long as maintainers are fine (Rafael et al.). On personal side I think that the handler approach is better. Details are in v15 thread. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy
On Tue, Mar 6, 2018 at 12:36 PM, John Garry <john.garry@huawei.com> wrote: > On 06/03/2018 11:21, Andy Shevchenko wrote: >> >> On Tue, 2018-03-06 at 18:47 +0800, John Garry wrote: >>> >>> This patchset supports the IPMI-bt device attached to the Low-Pin- >>> Count >>> interface implemented on Hisilicon Hip06/Hip07 SoC. >>> ----------- >>> | LPC host| >>> | | >>> ----------- >>> | >>> _____________V_______________LPC >>> | | >>> V V >>> ------------ >>> | BT(ipmi)| >>> ------------ >>> >>> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a >>> specific >>> LPC driver is needed to make LPC host generate the standard LPC I/O >>> cycles with >>> the target peripherals'I/O port addresses. But on curent arm64 world, >>> there is >>> no real I/O accesses. All the I/O operations through in/out accessors >>> are based >>> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed >>> through driver >>> specific accessors rather than MMIO. >>> To solve this issue and keep the relevant existing peripherals' >>> drivers untouched, >>> this patchset: >>> - introduces a generic I/O space management framework, logical PIO, >>> to support >>> I/O operations on host controllers operating either on MMIO >>> buses or on buses >>> requiring specific driver I/O accessors; >>> - redefines the in/out accessors to provide a unified interface for >>> both MMIO >>> and driver specific I/O operations. Using logical PIO, th call of >>> in/out() from >>> the host children drivers, such as ipmi-si, will be redirected to >>> the >>> corresponding device-specific I/O hooks to perform the I/O >>> accesses. >>> >>> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC >>> peripherals can >>> be supported without any changes on the existing ipmi-si driver. >>> >>> The whole patchset has been tested on Hip07 D05 board both using DTB >>> and ACPI. >>> >> >>> V15 thread here: https://lkml.org/lkml/2018/2/26/584 >> >> >> Thanks for an update. >> Though I answered to previous thread. >> >> Summary: I'm fine with the series as long as maintainers are fine >> (Rafael et al.). On personal side I think that the handler approach is >> better. Details are in v15 thread. > > > Hi Andy, > > Thanks for your input and continued support. As I mentioned in reply in v15, > the handler support would (or has) faced issues. And Rafael seems fine with > deferring the probe to the LLDD in Patch #7/9 Well, the only sort-of concern is that these devices may not be "serial bus slaves" in general, so the naming is slightly confusing. But overall this approach and the one based on a scan handler both boil down to checking a (list of) device ID(s) and doing something special in case of a match.
>>>> >>>> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC >>>> peripherals can >>>> be supported without any changes on the existing ipmi-si driver. >>>> >>>> The whole patchset has been tested on Hip07 D05 board both using DTB >>>> and ACPI. >>>> >>> >>>> V15 thread here: https://lkml.org/lkml/2018/2/26/584 >>> >>> >>> Thanks for an update. >>> Though I answered to previous thread. >>> >>> Summary: I'm fine with the series as long as maintainers are fine >>> (Rafael et al.). On personal side I think that the handler approach is >>> better. Details are in v15 thread. >> >> >> Hi Andy, >> >> Thanks for your input and continued support. As I mentioned in reply in v15, >> the handler support would (or has) faced issues. And Rafael seems fine with >> deferring the probe to the LLDD in Patch #7/9 > Hi Rafael, > Well, the only sort-of concern is that these devices may not be > "serial bus slaves" in general, so the naming is slightly confusing. > Right, the name. The key point is that we model the bus the same as other serial buses like I2C or SPI, so require the same treatment from the ACPI scan. Would you prefer acpi_is_serial_bus_slave() and acpi_device_flags.serial_bus_slave symbols be modified also? > But overall this approach and the one based on a scan handler both > boil down to checking a (list of) device ID(s) and doing something > special in case of a match. > > . > Thanks, John