All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Xu Yilun <yilun.xu@intel.com>
Cc: John Garry <john.garry@huawei.com>,
	luis.f.tanica@seagate.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-fpga@vger.kernel.org, gregkh <gregkh@linuxfoundation.org>
Subject: Re: LPC Bus Driver
Date: Tue, 3 Mar 2020 17:24:46 +0100	[thread overview]
Message-ID: <CAK8P3a01vYfqvj4eRQQsqC9FrUTr=q6ZRF-EuYV0iGC7AV7UBQ@mail.gmail.com> (raw)
In-Reply-To: <20200303154522.GA24568@yilunxu-OptiPlex-7050>

On Tue, Mar 3, 2020 at 4:47 PM Xu Yilun <yilun.xu@intel.com> wrote:
> On Tue, Mar 03, 2020 at 10:13:36AM +0000, John Garry wrote:
> > + add fpga list and Greg+Arnd for misc drivers
> > >We have this board with our own SoC, which is connected to an external CPLD (FPGA) via LPC (low pin count) bus.
> > >I've been doing some research to see what the best way of designing the drivers for it would be, and came across the Hisilicon LPC driver stuff (which I believe you're the maintainer for).
> > >
> > >Just a little background. Let's say our host (ARM) has a custom LPC controller. The LPC controller let's us perform reads/writes of CPLD registers via LPC bus. This CPLD is the only slave device attached to that bus and we only use it for reading/writing certain
> > >  registers (e.g., we use it to access some system information and for resetting the ARM during reboot).
> > >
> > >I was looking at the regmap framework and that seemed a good way to go.
> >
> > I thought that regmap only allows mapping in MMIO regions for multiplexing
> > access from multiple drivers or accessing registers outside the device HW
> > registers, but you seem to need to manually generate the LPC bus accesses to
> > access registers on the slave device.
>
> I'm not familar with LPC controller, but seems it could not perform
> read/write by one memory access or io access instruction
>
> I didn't find an existing bus_type for LPC bus, so I think regmap is a
> good way. When you have implemented the regmap for LPC bus, you need to
> access the CPLD registers by regmap_read/write, and just pass CPLD local
> register addr as parameter.

LPC uses the same software abstraction as the old ISA bus, providing
port (inb/outb) and mmio (readl/writel) style register access as well as
interrupts and a crude form of DMA access.

Whether regmap or something else works depends on which of these
communication options the CPLD uses.

> > If this FPGA is the only device which will ever be on this LPC bus, then
> > could you encode the LPC accesses directly in the FPGA driver?

I think this is the most important question. If the same SoC is used
in systems that connect something else on the same LPC bus, then
making it look like a normal ISA/LPC bus to Linux is probably best,
but if the CPLD and SoC are only ever used in this one combination,
there is nothing wrong with pretending that the LPC MMIO interface
on this chip part of the driver for the CPLD.

> > As another alternative, it might be worth considering writing an I2C
> > controller driver for your LPC host, i.e. model as an I2C bus, and have an
> > I2C client driver for the LPC slave (FPGA). I think that there are examples
> > of this in the kernel.
>
> How the host cpu is connected to LPC host?
> Why an I2C controller driver for LPC host? The LPC bus is compatible to i2c bus?

i2c is a simple bus that allows multiple devices to share a bus
and perform read/write operations on numbered registers. If the device
attached to the LPC bus fits into that, it might be even easier than
regmap.

       Arnd

  reply	other threads:[~2020-03-03 16:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 22:44 LPC Bus Driver Luis Tanica
2020-03-03 10:13 ` John Garry
2020-03-03 10:13   ` John Garry
2020-03-03 15:45   ` Xu Yilun
2020-03-03 16:24     ` Arnd Bergmann [this message]
2020-03-03 18:07       ` Luis Tanica
2020-03-04  9:51         ` John Garry

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='CAK8P3a01vYfqvj4eRQQsqC9FrUTr=q6ZRF-EuYV0iGC7AV7UBQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.garry@huawei.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luis.f.tanica@seagate.com \
    --cc=yilun.xu@intel.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 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.