* LPC Bus Driver @ 2020-03-02 22:44 Luis Tanica 2020-03-03 10:13 ` John Garry 0 siblings, 1 reply; 6+ messages in thread From: Luis Tanica @ 2020-03-02 22:44 UTC (permalink / raw) To: john.garry; +Cc: linux-kernel Hi John, 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. But then I saw the logic_pio stuff as well and now I'm not sure what the best approach would be anymore Would kindly ask for some advice here. Kind regards, Luis Tanica ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LPC Bus Driver 2020-03-02 22:44 LPC Bus Driver Luis Tanica @ 2020-03-03 10:13 ` John Garry 2020-03-03 15:45 ` Xu Yilun 0 siblings, 1 reply; 6+ messages in thread From: John Garry @ 2020-03-03 10:13 UTC (permalink / raw) To: Luis Tanica; +Cc: linux-kernel, linux-fpga, Greg Kroah-Hartman, Arnd Bergmann + add fpga list and Greg+Arnd for misc drivers Hi Luis, > > 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. 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? > But then I saw the logic_pio stuff as well and now I'm not sure what the best approach would be anymore Logic PIO is for IO Port accesses. It could serve your purpose, but you would need to use IO port accesses for your slave driver, like inb and outb. 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. All the best, john ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LPC Bus Driver 2020-03-03 10:13 ` John Garry @ 2020-03-03 15:45 ` Xu Yilun 2020-03-03 16:24 ` Arnd Bergmann 0 siblings, 1 reply; 6+ messages in thread From: Xu Yilun @ 2020-03-03 15:45 UTC (permalink / raw) To: John Garry, luis.f.tanica; +Cc: linux-kernel, linux-fpga, gregkh, arnd On Tue, Mar 03, 2020 at 10:13:36AM +0000, John Garry wrote: > + add fpga list and Greg+Arnd for misc drivers > > Hi Luis, > > > > >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. > > 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? > > > But then I saw the logic_pio stuff as well and now I'm not sure what the > best approach would be anymore > > Logic PIO is for IO Port accesses. It could serve your purpose, but you > would need to use IO port accesses for your slave driver, like inb and outb. I quickly checked the logic PIO. When you implemented logic_pio for your lpc and CPLD, you create an map from IO port addr to CPLD register addr. You need to use inb/outb to access CPLD register (with some uncertain IO addrs?) I'm not sure why it is needed to access non-pio devices using PIO, it may be of some special purpose? Regmap may be a general choise. > > 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? Thanks, Yilun > > All the best, > john ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LPC Bus Driver 2020-03-03 15:45 ` Xu Yilun @ 2020-03-03 16:24 ` Arnd Bergmann 2020-03-03 18:07 ` Luis Tanica 0 siblings, 1 reply; 6+ messages in thread From: Arnd Bergmann @ 2020-03-03 16:24 UTC (permalink / raw) To: Xu Yilun; +Cc: John Garry, luis.f.tanica, linux-kernel, linux-fpga, gregkh 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LPC Bus Driver 2020-03-03 16:24 ` Arnd Bergmann @ 2020-03-03 18:07 ` Luis Tanica 2020-03-04 9:51 ` John Garry 0 siblings, 1 reply; 6+ messages in thread From: Luis Tanica @ 2020-03-03 18:07 UTC (permalink / raw) To: Arnd Bergmann, Xu Yilun; +Cc: John Garry, linux-kernel, linux-fpga, gregkh Thank you all for the help. This is the gist of what I got from your responses. - if CPLD is the only thing on LPC bus, consider creating a single driver for it - if not, then creating the LPC bus layer would be ideal - could also consider I2C framework and treat it like an I2C device I believe for us we'll only ever have that one CPLD on the LPC bus, so a single driver could be a good idea. The only reason I like regmap though, is that I could define a regmap bus that would implement all the LPC read/write operations (by implementing the .reg_read and .reg_write for regmap_bus) and then I could use those registers as I pleased from different places. For instance, we could have a CPLD driver that exposes all the registers/fields via sysfs but then I could also have an arm-reset driver that only maps the register it needs for the arm reset. I actually started implementing the LPC bus, and then having 2 devices (reset and cpld) implemented as LPC devices. Even though it seems a bit more logical overall, it's a lot of overhead for what I need. I would like to take a look at the I2C option, since that's the only idea here I haven't explored. If you could point me in the right direction on how to do it (or some examples in the kernel) I'd appreciate. I should be able to make a decision after that, but I'm tempted to create a single driver and keep it simple for now. P.S.: This is my first time using the mailing list and I'm guessing Outlook is not the best client to use. Any tips on that end? Luis From: Arnd Bergmann <arnd@arndb.de> Sent: Tuesday, March 3, 2020 09:24 To: Xu Yilun <yilun.xu@intel.com> Cc: John Garry <john.garry@huawei.com>; Luis Tanica <luis.f.tanica@seagate.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-fpga@vger.kernel.org <linux-fpga@vger.kernel.org>; gregkh <gregkh@linuxfoundation.org> Subject: Re: LPC Bus Driver 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LPC Bus Driver 2020-03-03 18:07 ` Luis Tanica @ 2020-03-04 9:51 ` John Garry 0 siblings, 0 replies; 6+ messages in thread From: John Garry @ 2020-03-04 9:51 UTC (permalink / raw) To: Luis Tanica, Arnd Bergmann, Xu Yilun; +Cc: linux-kernel, linux-fpga, gregkh On 03/03/2020 18:07, Luis Tanica wrote: > Thank you all for the help. This is the gist of what I got from your responses. > > - if CPLD is the only thing on LPC bus, consider creating a single driver for it > - if not, then creating the LPC bus layer would be ideal > - could also consider I2C framework and treat it like an I2C device > > I believe for us we'll only ever have that one CPLD on the LPC bus, so a single driver could be a good idea. > The only reason I like regmap though, is that I could define a regmap bus that would implement all the LPC read/write operations (by implementing the .reg_read and .reg_write for regmap_bus) nd then I could use those registers as I pleased from different places. > For instance, we could have a CPLD driver that exposes all the registers/fields via sysfs but then I could also have an arm-reset driver that only maps the register it needs for the arm reset. > > I actually started implementing the LPC bus, and then having 2 devices (reset and cpld) implemented as LPC devices. > Even though it seems a bit more logical overall, it's a lot of overhead for what I need. > > I would like to take a look at the I2C option, since that's the only idea here I haven't explored. If you could point me in the right direction on how to do it (or some examples in the kernel) I'd appreciate. Arnd originally gave me this idea for modelling the HiSilicon LPC driver as an I2C host, so he may know. From checking drivers/i2c/busses/Kconfig, maybe I2C_CROS_EC_TUNNEL could support LPC. > I should be able to make a decision after that, but I'm tempted to create a single driver and keep it simple for now. > > P.S.: This is my first time using the mailing list and I'm guessing Outlook is not the best client to use. Any tips on that end? Maybe this will help: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/email-clients.rst I use firefox in windows, since outlook cannot be configured for kernel posting style, AFAIK. > > Luis > > > > > From: Arnd Bergmann <arnd@arndb.de> > > Sent: Tuesday, March 3, 2020 09:24 > > To: Xu Yilun <yilun.xu@intel.com> > > Cc: John Garry <john.garry@huawei.com>; Luis Tanica <luis.f.tanica@seagate.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-fpga@vger.kernel.org <linux-fpga@vger.kernel.org>; gregkh <gregkh@linuxfoundation.org> > > Subject: Re: LPC Bus Driver > > > > > 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 > > . > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-04 9:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-02 22:44 LPC Bus Driver Luis Tanica 2020-03-03 10:13 ` John Garry 2020-03-03 15:45 ` Xu Yilun 2020-03-03 16:24 ` Arnd Bergmann 2020-03-03 18:07 ` Luis Tanica 2020-03-04 9:51 ` John Garry
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®