All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced
Date: Wed, 07 Sep 2016 17:06:04 +0200	[thread overview]
Message-ID: <3419224.SdRtVQMJCi@wuerfel> (raw)
In-Reply-To: <1473255233-154297-2-git-send-email-yuanzhichang@hisilicon.com>

On Wednesday, September 7, 2016 9:33:50 PM CEST Zhichang Yuan wrote:
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +
> +typedef u64 (*inhook)(void *devobj, unsigned long ptaddr, void *inbuf,
> +                               size_t dlen, unsigned int count);
> +typedef void (*outhook)(void *devobj, unsigned long ptaddr,
> +                               const void *outbuf, size_t dlen,
> +                               unsigned int count);
> +
> +struct extio_ops {
> +       inhook  pfin;
> +       outhook pfout;
> +       void *devpara;
> +};
> +
> +extern struct extio_ops *arm64_simops __refdata;
> +
> +/*Up to now, only applied to Hip06 LPC. Define as static here.*/
> +static inline void arm64_set_simops(struct extio_ops *ops)
> +{
> +       if (ops)
> +               WRITE_ONCE(arm64_simops, ops);
> +}
> +
> +
> +#define BUILDIO(bw, type)                                              \
> +static inline type in##bw(unsigned long addr)                          \
> +{                                                                      \
> +       if (addr >= PCIBIOS_MIN_IO)                                     \
> +               return read##bw(PCI_IOBASE + addr);                     \
> +       return (arm64_simops && arm64_simops->pfin) ?                   \
> +               arm64_simops->pfin(arm64_simops->devpara, addr, NULL,   \
> +                                       sizeof(type), 1) : -1;          \
> +}                                                      \
> 

Hmm, the way this is done, enabling CONFIG_ARM64_INDIRECT_PIO at
compile time means that only the dynamically registered PIO support
is possible for I/O port ranges 0-0xfff.

I think the runtime check should better test if simops was defined
first and fall back to normal PIO otherwise, in order to allow
LPC implementations on a PCI-LPC bridge.

How about allowing an I/O port range to be defined along with
the operations and check against that?

u8 intb(unsigned long port)
{
	if (arm64_simops &&
	    (port >= arm64_simops->min) && 
	    (port <= arm64_simops->max))
		return arm64_simops->pfin(arm64_simops, port, 1);
	else
		return readb(PCI_IOBASE + addr);
}

The other advantage of that is that you can dynamically register
a translation for the LPC port range into the Linux I/O port range
like PCI hosts do.

We may also want to move the inb/outb definitions into a .c file
as they are getting rather big.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Zhichang Yuan <yuanzhichang@hisilicon.com>,
	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,
	zhichang.yuan02@gmail.com, zourongrong@gmail.com
Subject: Re: [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced
Date: Wed, 07 Sep 2016 17:06:04 +0200	[thread overview]
Message-ID: <3419224.SdRtVQMJCi@wuerfel> (raw)
In-Reply-To: <1473255233-154297-2-git-send-email-yuanzhichang@hisilicon.com>

On Wednesday, September 7, 2016 9:33:50 PM CEST Zhichang Yuan wrote:
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +
> +typedef u64 (*inhook)(void *devobj, unsigned long ptaddr, void *inbuf,
> +                               size_t dlen, unsigned int count);
> +typedef void (*outhook)(void *devobj, unsigned long ptaddr,
> +                               const void *outbuf, size_t dlen,
> +                               unsigned int count);
> +
> +struct extio_ops {
> +       inhook  pfin;
> +       outhook pfout;
> +       void *devpara;
> +};
> +
> +extern struct extio_ops *arm64_simops __refdata;
> +
> +/*Up to now, only applied to Hip06 LPC. Define as static here.*/
> +static inline void arm64_set_simops(struct extio_ops *ops)
> +{
> +       if (ops)
> +               WRITE_ONCE(arm64_simops, ops);
> +}
> +
> +
> +#define BUILDIO(bw, type)                                              \
> +static inline type in##bw(unsigned long addr)                          \
> +{                                                                      \
> +       if (addr >= PCIBIOS_MIN_IO)                                     \
> +               return read##bw(PCI_IOBASE + addr);                     \
> +       return (arm64_simops && arm64_simops->pfin) ?                   \
> +               arm64_simops->pfin(arm64_simops->devpara, addr, NULL,   \
> +                                       sizeof(type), 1) : -1;          \
> +}                                                      \
> 

Hmm, the way this is done, enabling CONFIG_ARM64_INDIRECT_PIO at
compile time means that only the dynamically registered PIO support
is possible for I/O port ranges 0-0xfff.

I think the runtime check should better test if simops was defined
first and fall back to normal PIO otherwise, in order to allow
LPC implementations on a PCI-LPC bridge.

How about allowing an I/O port range to be defined along with
the operations and check against that?

u8 intb(unsigned long port)
{
	if (arm64_simops &&
	    (port >= arm64_simops->min) && 
	    (port <= arm64_simops->max))
		return arm64_simops->pfin(arm64_simops, port, 1);
	else
		return readb(PCI_IOBASE + addr);
}

The other advantage of that is that you can dynamically register
a translation for the LPC port range into the Linux I/O port range
like PCI hosts do.

We may also want to move the inb/outb definitions into a .c file
as they are getting rather big.

	Arnd

  reply	other threads:[~2016-09-07 15:06 UTC|newest]

Thread overview: 55+ 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 ` Zhichang Yuan
2016-09-07 13:33 ` [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced Zhichang Yuan
2016-09-07 13:33   ` Zhichang Yuan
2016-09-07 15:06   ` Arnd Bergmann [this message]
2016-09-07 15:06     ` Arnd Bergmann
2016-09-08  7:45     ` zhichang.yuan
2016-09-08  7:45       ` zhichang.yuan
2016-09-08  7:45       ` zhichang.yuan
2016-09-08 13:23       ` Arnd Bergmann
2016-09-08 13:23         ` Arnd Bergmann
2016-09-13  6:08         ` zhichang
2016-09-13  6:08           ` zhichang
2016-09-07 15:21   ` kbuild test robot
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 13:33   ` Zhichang Yuan
2016-09-07 15:27   ` Arnd Bergmann
2016-09-07 15:27     ` Arnd Bergmann
2016-09-08  8:06     ` zhichang.yuan
2016-09-08  8:06       ` zhichang.yuan
2016-09-08 10:00       ` Arnd Bergmann
2016-09-08 10:00         ` Arnd Bergmann
2016-09-13  6:31         ` zhichang
2016-09-13  6:31           ` zhichang
2016-09-14 12:34           ` Arnd Bergmann
2016-09-14 12:34             ` Arnd Bergmann
2016-09-07 17:51   ` kbuild test robot
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 13:33   ` Zhichang Yuan
2016-09-07 14:50   ` Arnd Bergmann
2016-09-07 14:50     ` Arnd Bergmann
2016-09-08  9:51     ` zhichang
2016-09-08  9:51       ` zhichang
2016-09-08  9:58       ` Arnd Bergmann
2016-09-08  9:58         ` Arnd Bergmann
2016-09-14 11:48         ` zhichang.yuan
2016-09-14 11:48           ` zhichang.yuan
2016-09-14 12:07           ` Arnd Bergmann
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 13:33   ` Zhichang Yuan
2016-09-07 14:52   ` Arnd Bergmann
2016-09-07 14:52     ` Arnd Bergmann
2016-09-08 10:04     ` zhichang
2016-09-08 10:04       ` zhichang
2016-09-08 11:04       ` Arnd Bergmann
2016-09-08 11:04         ` Arnd Bergmann
2016-09-14 11:26         ` zhichang
2016-09-14 11:26           ` zhichang
2016-09-14 12:36           ` Arnd Bergmann
2016-09-14 12:36             ` Arnd Bergmann
2016-09-08  9:26   ` kbuild test robot
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=3419224.SdRtVQMJCi@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.