lkml.org 
[lkml]   [2018]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v16 0/9] LPC: legacy ISA I/O support
From
Date
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

Anyway, let's wait for any more input.

Much appreciated,
John

>


\
 
 \ /
  Last update: 2018-03-06 12:37    [W:1.816 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site