From: zhichang <zhichang.yuan02@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
"zhichang.yuan" <yuanzhichang@hisilicon.com>
Cc: linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com,
linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com,
minyard@acm.org, benh@kernel.crashing.org,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
liviu.dudau@arm.com, zourongrong@gmail.com
Subject: Re: [PATCH V2 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Tue, 13 Sep 2016 14:31:13 +0800 [thread overview]
Message-ID: <57D79D31.8090607@gmail.com> (raw)
In-Reply-To: <74367472.RYBpLsaIy1@wuerfel>
On 2016年09月08日 18:00, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 4:06:01 PM CEST zhichang.yuan wrote:
>>>
>>>> +struct lpc_io_ops {
>>>> + unsigned int periosz;
>>>> + int (*lpc_iord)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>>>> + unsigned long ptaddr, unsigned char *buf,
>>>> + unsigned long dlen);
>>>> + int (*lpc_iowr)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>>>> + unsigned long ptaddr,
>>>> + const unsigned char *buf,
>>>> + unsigned long dlen);
>>>> +};
>>>
>>> The operations are not needed unless we also put the earlycon support
>>> in, so maybe leave them out from the first patch and only add them
>>> later (or drop the earlycon support if possible).
>>
>> Do you want to remove the struct lpc_io_ops member from struct hisilpc_dev??
>> I think we can not do that.
>>
>> These two functions are essential rd/wr operation for Hip06 LPC. They will be fallen into
>> when the upper layer drivers call their own IO in/out functions, such as serial_in/serial_out
>> for 8250 serial.
>>
>> I can define lpc_iord/lpc_iowr directly in struct hisilpc_dev and cancel the definition of
>> struct lpc_io_ops. In my original idea, several LPC cycle types will be supported. Each cycle
>> type has its specific ops. Now, only one cycle type is needed, the struct lpc_io_ops is not
>> meaningful.
>
> My point was that the indirect function calls are not needed at
> until patch four, so you can call the functions directly here,
> and make the logic for indirect function calls part of that
> later patch.
O. I think I got your meaning now.
In patch V2, the lpc_io_ops is not needed even if earlycon is supported. The early_in/early_out operation is
defined in hisi_lpc.c too, we can directly call the hisilpc_target_in/hisilpc_target_out to finish the LPC IO
operations.
At this moment, all the IO functions specific to the child devices of hip06 LPC have their own indirect call
method. This lpc_io_ops will be removed in V3.
>
> What are the other LPC cycle types that could be supported?
O. memory and firmware operations are supported too. But at this moment, we only use IO cycle.
Best,
Zhichang
>
> Arnd
>
next prev parent reply other threads:[~2016-09-13 6:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 13:33 [PATCH V2 0/4] ARM64 LPC: legacy ISA I/O support Zhichang Yuan
2016-09-07 13:33 ` [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced Zhichang Yuan
2016-09-07 15:06 ` Arnd Bergmann
2016-09-08 7:45 ` zhichang.yuan
2016-09-08 13:23 ` Arnd Bergmann
2016-09-13 6:08 ` zhichang
2016-09-07 15:21 ` kbuild test robot
2016-09-07 13:33 ` [PATCH V2 2/4] ARM64 LPC: LPC driver implementation on Hip06 Zhichang Yuan
2016-09-07 15:27 ` Arnd Bergmann
2016-09-08 8:06 ` zhichang.yuan
2016-09-08 10:00 ` Arnd Bergmann
2016-09-13 6:31 ` zhichang [this message]
2016-09-14 12:34 ` Arnd Bergmann
2016-09-07 17:51 ` kbuild test robot
2016-09-07 13:33 ` [PATCH V2 3/4] ARM64 LPC: support serial based on low-pin-count Zhichang Yuan
2016-09-07 14:50 ` Arnd Bergmann
2016-09-08 9:51 ` zhichang
2016-09-08 9:58 ` Arnd Bergmann
2016-09-14 11:48 ` zhichang.yuan
2016-09-14 12:07 ` Arnd Bergmann
2016-09-07 13:33 ` [PATCH V2 4/4] ARM64 LPC: support earlycon for UART connected to LPC Zhichang Yuan
2016-09-07 14:52 ` Arnd Bergmann
2016-09-08 10:04 ` zhichang
2016-09-08 11:04 ` Arnd Bergmann
2016-09-14 11:26 ` zhichang
2016-09-14 12:36 ` Arnd Bergmann
2016-09-08 9:26 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57D79D31.8090607@gmail.com \
--to=zhichang.yuan02@gmail.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=gabriele.paoloni@huawei.com \
--cc=john.garry@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=minyard@acm.org \
--cc=yuanzhichang@hisilicon.com \
--cc=zourongrong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).