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.shevche...@linux.intel.com>
Intel Finland Oy

Reply via email to