public inbox for linux-arm-kernel@lists.infradead.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

  reply	other threads:[~2016-09-07 15:06 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 [this message]
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
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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox