openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/drivers/fsi/Kconfig

79 lines
2.4 KiB
Plaintext
Raw Normal View History

drivers/fsi: Add empty fsi bus definitions This change adds the initial (empty) fsi bus definition, and introduces drivers/fsi/. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Chris Bostic <cbostic@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-02 00:53:41 +08:00
#
# FSI subsystem
#
fsi: Make FSI a menuconfig to ease disabling it all No need to get into the submenu to disable all FSI-related config entries Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com> Acked-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-03 19:09:26 +08:00
menuconfig FSI
drivers/fsi: Add empty fsi bus definitions This change adds the initial (empty) fsi bus definition, and introduces drivers/fsi/. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Chris Bostic <cbostic@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-02 00:53:41 +08:00
tristate "FSI support"
fsi: Match fsi slaves and engines to available dt nodes This change populates device tree nodes for scanned FSI slaves and engines. If the master populates ->of_node of the FSI master device, we'll look for matching slaves, and under those slaves we'll look for matching engines. This means that FSI drivers will have their ->of_node pointer populated if there's a corresponding DT node, which they can use for further device discover. Presence of device tree nodes is optional, and only required for fsi device drivers that need extra properties, or subordinate devices, to be enumerated. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-12 13:15:45 +08:00
depends on OF
drivers/fsi: Implement slave initialisation Implement fsi_slave_init: if we can read a chip ID, create fsi_slave devices and register with the driver core. Includes changes from Christopher Bostic <cbostic@linux.vnet.ibm.com>. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:42 +08:00
select CRC4
drivers/fsi: Add empty fsi bus definitions This change adds the initial (empty) fsi bus definition, and introduces drivers/fsi/. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Chris Bostic <cbostic@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-02 00:53:41 +08:00
---help---
FSI - the FRU Support Interface - is a simple bus for low-level
access to POWER-based hardware.
drivers/fsi: Add GPIO based FSI master Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response. Includes changes from Edward A. James <eajames@us.ibm.com> and Jeremy Kerr <jk@ozlabs.org>. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:54 +08:00
if FSI
fsi: Add new central chardev support The various FSI devices (sbefifo, occ, scom, more to come) currently use misc devices. This is problematic as the minor device space for misc is limited and there can be a lot of them. Also it limits our ability to move them to a dedicated /dev/fsi directory or to be smart about device naming and numbering. It also means we have IDAs on every single of these drivers This creates a common fsi "device_type" for the optional /dev/fsi grouping and a dev_t allocator for all FSI devices. "Legacy" devices get to use a backward compatible numbering scheme (as long as chip id <16 and there's only one copy of a given unit type per chip). A single major number and a single IDA are shared for all FSI devices. This doesn't convert the FSI device drivers to use the new scheme yet, they will be converted individually. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2018-06-20 13:22:52 +08:00
config FSI_NEW_DEV_NODE
bool "Create '/dev/fsi' directory for char devices"
default n
---help---
This option causes char devices created for FSI devices to be
located under a common /dev/fsi/ directory. Set to N unless your
userspace has been updated to handle the new location.
Additionally, it also causes the char device names to be offset
by one so that chip 0 will have /dev/scom1 and chip1 /dev/scom2
to match old userspace expectations.
New userspace will use udev rules to generate predictable access
symlinks in /dev/fsi/by-path when this option is enabled.
drivers/fsi: Add GPIO based FSI master Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response. Includes changes from Edward A. James <eajames@us.ibm.com> and Jeremy Kerr <jk@ozlabs.org>. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:54 +08:00
config FSI_MASTER_GPIO
tristate "GPIO-based FSI master"
depends on GPIOLIB
select CRC4
---help---
This option enables a FSI master driver using GPIO lines.
drivers/fsi: Add hub master support Add an engine driver to expose a "hub" FSI master - which has a set of control registers in the engine address space, and uses a chunk of the slave address space for actual FSI communication. Additional changes from Jeremy Kerr <jk@ozlabs.org>. Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:57 +08:00
config FSI_MASTER_HUB
tristate "FSI hub master"
---help---
This option enables a FSI hub master driver. Hub is a type of FSI
master that is connected to the upstream master via a slave. Hubs
allow chaining of FSI links to an arbitrary depth. This allows for
a high target device fanout.
fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which is currently unused on OpenPower systems. This adds an alternative to the fsi-master-gpio driver that uses that coprocessor instead of bit banging from the ARM core itself. The end result is about 4 times faster. The firmware for the coprocessor and its source code can be found at https://github.com/ozbenh/cf-fsi and is system specific. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2018-06-12 07:55:04 +08:00
config FSI_MASTER_AST_CF
tristate "FSI master based on Aspeed ColdFire coprocessor"
depends on GPIOLIB
depends on GPIO_ASPEED
fsi: master-ast-cf: select GENERIC_ALLOCATOR In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver fails to link: ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined! ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined! ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined! ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined! Select the dependency as all other users do. Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2018-08-14 06:37:18 +08:00
select GENERIC_ALLOCATOR
fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which is currently unused on OpenPower systems. This adds an alternative to the fsi-master-gpio driver that uses that coprocessor instead of bit banging from the ARM core itself. The end result is about 4 times faster. The firmware for the coprocessor and its source code can be found at https://github.com/ozbenh/cf-fsi and is system specific. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2018-06-12 07:55:04 +08:00
---help---
This option enables a FSI master using the AST2400 and AST2500 GPIO
lines driven by the internal ColdFire coprocessor. This requires
the corresponding machine specific ColdFire firmware to be available.
drivers/fsi: Add SCOM FSI client device driver Create a simple SCOM engine device driver that reads and writes its control registers via an FSI bus. Includes changes from Edward A. James <eajames@us.ibm.com>. Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:56 +08:00
config FSI_SCOM
tristate "SCOM FSI client device driver"
---help---
This option enables an FSI based SCOM device driver.
fsi/sbefifo: Add driver for the SBE FIFO This driver provides an in-kernel and a user API for accessing the command FIFO of the SBE (Self Boot Engine) of the POWER9 processor, via the FSI bus. It provides an in-kernel interface to submit command and receive responses, along with a helper to locate and analyse the response status block. It's a simple synchronous submit() type API. The user interface uses the write/read interface that an earlier version of this driver already provided, however it has some specific limitations in order to keep the driver simple and avoid using up a lot of kernel memory: - The user should perform a single write() with the command and a single read() to get the response (with a buffer big enough to hold the entire response). - On a write() the command is simply "stored" into a kernel buffer, it is submitted as one operation on the subsequent read(). This allows to have the code write directly from the FIFO into the user buffer and avoid hogging the SBE between the write() and read() syscall as it's critical that the SBE be freed asap to respond to the host. An extra write() will simply replace the previously written command. - A write of a single 4 bytes containing the value 0x52534554 in big endian will trigger a reset request. No read is necessary, the write() call will return when the reset has been acknowledged or times out. - The command is limited to 4K bytes. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Joel Stanley <joel@jms.id.au> ---
2018-05-17 13:58:00 +08:00
config FSI_SBEFIFO
tristate "SBEFIFO FSI client device driver"
fsi/sbefifo: Add dependency on OF_ADDRESS The driver calls of_platform_device_create() which is only available if OF_ADDRESS is enabled. When building sparc64 images, this results in ERROR: "of_platform_device_create" [drivers/fsi/fsi-sbefifo.ko] undefined! Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO") Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2018-07-03 21:43:49 +08:00
depends on OF_ADDRESS
fsi/sbefifo: Add driver for the SBE FIFO This driver provides an in-kernel and a user API for accessing the command FIFO of the SBE (Self Boot Engine) of the POWER9 processor, via the FSI bus. It provides an in-kernel interface to submit command and receive responses, along with a helper to locate and analyse the response status block. It's a simple synchronous submit() type API. The user interface uses the write/read interface that an earlier version of this driver already provided, however it has some specific limitations in order to keep the driver simple and avoid using up a lot of kernel memory: - The user should perform a single write() with the command and a single read() to get the response (with a buffer big enough to hold the entire response). - On a write() the command is simply "stored" into a kernel buffer, it is submitted as one operation on the subsequent read(). This allows to have the code write directly from the FIFO into the user buffer and avoid hogging the SBE between the write() and read() syscall as it's critical that the SBE be freed asap to respond to the host. An extra write() will simply replace the previously written command. - A write of a single 4 bytes containing the value 0x52534554 in big endian will trigger a reset request. No read is necessary, the write() call will return when the reset has been acknowledged or times out. - The command is limited to 4K bytes. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Joel Stanley <joel@jms.id.au> ---
2018-05-17 13:58:00 +08:00
---help---
This option enables an FSI based SBEFIFO device driver. The SBEFIFO is
a pipe-like FSI device for communicating with the self boot engine
(SBE) on POWER processors.
fsi: Add On-Chip Controller (OCC) driver The OCC is a device embedded on a POWER processor that collects and aggregates sensor data from the processor and system. The OCC can provide the raw sensor data as well as perform thermal and power management on the system. This driver provides an atomic communications channel between a service processor (e.g. a BMC) and the OCC. The driver is dependent on the FSI SBEFIFO driver to get hardware access through the SBE to the OCC SRAM. Commands are issued to the SBE to send or fetch data to the SRAM. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-11-09 05:05:21 +08:00
config FSI_OCC
tristate "OCC SBEFIFO client device driver"
depends on FSI_SBEFIFO
---help---
This option enables an SBEFIFO based On-Chip Controller (OCC) device
driver. The OCC is a device embedded on a POWER processor that collects
and aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.
drivers/fsi: Add GPIO based FSI master Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response. Includes changes from Edward A. James <eajames@us.ibm.com> and Jeremy Kerr <jk@ozlabs.org>. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-07 05:08:54 +08:00
endif