d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
18ec4e956a
freebsd-skq/sys/dev/iicbus/iicbus.h

88 lines
2.9 KiB
C
Raw Normal View History

Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
* Copyright (c) 1998 Nicolas Souchu
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
$Id$ -> $FreeBSD$
1999-08-28 01:08:13 +00:00
* $FreeBSD$
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
*
*/
#ifndef __IICBUS_H
#define __IICBUS_H
Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked.
2008-08-04 21:03:06 +00:00
#include <sys/_lock.h>
#include <sys/_mutex.h>
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
#define IICBUS_IVAR(d) (struct iicbus_ivar *) device_get_ivars(d)
#define IICBUS_SOFTC(d) (struct iicbus_softc *) device_get_softc(d)
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
struct iicbus_softc
{
device_t dev; /* Myself */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
device_t owner; /* iicbus owner device structure */
Restore the ability for i2c slave devices to do IO from their probe method. r348164 added code to iicbus_request_bus/iicbus_release_bus to automatically call device_busy()/device_unbusy() as part of aquiring exclusive use of the bus (so modules can't be unloaded while the bus is exclusively owned and/or IO is in progress). That broke the ability to do i2c IO from a slave device probe method, because the slave isn't attached yet, so calling device_busy() triggers a sanity-check panic for trying to busy a non-attached device. Now we check whether the device status is < DS_ATTACHING, and if so we busy the iicbus rather than the slave device. I think this leaves a small window where a module could be unloaded while probing is in progress. But I think that's true of all devices, and probably should be fixed by introducing a DS_PROBING state for devices, and handling that at various points in the newbus code.
2019-07-08 20:26:56 +00:00
device_t busydev; /* iicbus_release_bus calls unbusy on this */
Add support for tracking nested calls to iicbus_request/release_bus(). Usually it is sufficient to use iicbus_transfer_excl(), or one of the higher-level convenience functions that use it, to reserve the bus for the duration of each register access. Occasionally it is important that a series of accesses or read-modify-write operations must be done without any other intervening access to the device, to prevent corrupting state. Without support for nested request/release, slave device drivers would have to stop using high-level convenience functions and resort to working with arrays of iic_msg structs just for a few operations (often involving one-time device setup or infrequent configuration changes). The changes here appear large from a glance at the diff, but in fact they're nearly trivial, and the large diff is because of changes in indentation and the re-wrapping of comments caused by that. One notable change is that iicbus_release_bus() now ignores the IICBUS_CALLBACK(IIC_RELEASE_BUS) return value. The old error handling left the bus in a kind of limbo state where it was still owned at the iicbus layer, but drivers rarely check the return of the release call, and it's unclear what they would do to recover from an error return anyway. No existing low-level drivers return any kind of error from IIC_RELEASE_BUS except one EINVAL for "you don't own the bus", to which the right response is probably to carry on with the process of releasing the reference to the bus anyway.
2017-07-26 21:06:26 +00:00
u_int owncount; /* iicbus ownership nesting count */
Change /dev/smb and /dev/iic interface to allow user programs to interact with devices dynamically. That means, + only one /dev/iic or /dev/smb device for each smb/iic bus to access + I2C/SMB device address must be given to any ioctl + new devices may be plugged and accessed after boot, which was impossible previously (device addresses were hardcoded into the kernel)
1999-01-09 18:08:24 +00:00
u_char started; /* address of the 'started' slave
* 0 if no start condition succeeded */
Allow the i2c node requirements to be slightly relaxed. These realtek switch PHYs speak a variant of i2c with some slightly modified handling. From the submitter, slightly modified now that some further digging has been done: The I2C framework makes a assumption that the read/not-write bit of the first byte (the address) indicates whether reads or writes are to follow. The RTL8366 family uses the bus: after sending the address+read/not-write byte, two register address bytes are sent, then the 16-bit register value is sent or received. While the register write access can be performed as a 4-byte write, the read access requires the read bit to be set, but the first two bytes for the register address then need to be transmitted. This patch maintains the i2c protocol behaviour but allows it to be relaxed (for these kinds of switch PHYs, and whatever else Realtek may do with this almost-but-not-quite i2c bus) - by setting the "strict" hint to 0. The "strict" hint defaults to 1. Submitted by: Stefan Bethke <stb@lassitu.de>
2011-12-04 11:55:33 +00:00
u_char strict; /* deny operations that violate the
* I2C protocol */
Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked.
2008-08-04 21:03:06 +00:00
struct mtx lock;
Allow i2c bus speed to be configured via hints, FDT data, and sysctl. The current support for controlling i2c bus speed is an inconsistant mess. There are 4 symbolic speed values defined, UNKNOWN, SLOW, FAST, FASTEST. It seems to be universally assumed that SLOW means the standard 100KHz rate from the original spec. Nothing ever calls iicbus_reset() with a speed of FAST, although some drivers would treat it as the 400KHz standard speed. Mostly iicbus_reset() is called with the speed set to UNKNOWN or FASTEST, and there's really no telling what any individual driver will do with those. The speed of an i2c bus is limited by the speed of the slowest device on the bus. This means that generally the bus speed needs to be configured based on the board/system and the components within it. Historically for i2c we've configured with device hints. Newer systems use FDT data and it documents a clock-frequency property for i2c busses. Hobbyists and developers are likely to want on the fly changes. These changes provide all 3 methods, but do not require any existing drivers to change to use the new facilities. This adds an iicbus method, iicbus_get_frequency(dev, speed) that gets the frequency for the requested symbolic speed. If the symbolic speed is SLOW or if there is no speed configured for the bus, the returned value is 100KHz, always. Otherwise, if bus speed is configured by hints, fdt, tunable, or sysctl, that speed is returned. It also adds a helper function, iicbus_init_frequency() that any bus driver subclassed from iicbus can initialize the frequency from some other source of info. Initial driver implementations are provided for Freescale and TI. Differential Revision: https://reviews.freebsd.org/D1174 PR: 195009
2014-11-18 01:54:31 +00:00
u_int bus_freq; /* Configured bus Hz. */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
};
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
struct iicbus_ivar
{
uint32_t addr;
Handle IRQ resources on iicbus and ofw_iicbus. Based on a patch submitted by Michal Meloun <meloun@miracle.cz>.
2015-05-09 03:05:44 +00:00
struct resource_list rl;
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
};
enum {
revert r273728 and parts of r306589, iicbus no-stop by default feature Since drm2 removal, there has not been any consumer of the feature in the tree. I am also unaware of any out-of-tree consumer. More importantly, the feature has been broken from the very start, both before and after r306589, because the ivar was set on a device that does not support it and it was read from another device that also does not support it. A bus-wide no-stop flag cannot be implemented as an ivar as iicbus attaches as a child of various drivers. Implementing the ivar in each and every I2C driver is just impractical. If we ever want to implement this feature properly, then probably the easiest way to do it would be via a flag in the softc of iicbus. In fact, we might have to do that in the stable branches if we want to fix the code for them. Reported by: ian (long time ago) MFC after: 1 month (maybe) X-MFC-note: cannot just merge the change, must keep drm2 happy
2019-05-29 09:08:20 +00:00
IICBUS_IVAR_ADDR /* Address or base address */
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
};
#define IICBUS_ACCESSOR(A, B, T) \
Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked.
2008-08-04 21:03:06 +00:00
__BUS_ACCESSOR(iicbus, A, IICBUS, B, T)
MFp4: Create an ivar for each iic device on the iicbus. This ivar holds the device's address.
2007-03-23 23:02:33 +00:00
IICBUS_ACCESSOR(addr, ADDR, uint32_t)
Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked.
2008-08-04 21:03:06 +00:00
#define IICBUS_LOCK(sc) mtx_lock(&(sc)->lock)
#define IICBUS_UNLOCK(sc) mtx_unlock(&(sc)->lock)
#define IICBUS_ASSERT_LOCKED(sc) mtx_assert(&(sc)->lock, MA_OWNED)
Define macros making it easier to define bus-specific pnpinfo for FDT systems. Pnpinfo is bus-specific and requires the bus name. The FDTCOMPAT_PNP_INFO() macro makes it easier to define new FDT-based pnpinfo for busses other than simplebus. Differential Revision: https://reviews.freebsd.org/D20382
2019-05-23 15:47:30 +00:00
#ifdef FDT
Rename IICBUS_FDT_PNPINFO -> IICBUS_FDT_PNP_INFO because all the other existing pnpinfo-related macros right now use PNP_INFO, not PNPINFO.
2019-05-23 16:03:30 +00:00
#define IICBUS_FDT_PNP_INFO(t) FDTCOMPAT_PNP_INFO(t, iicbus)
Define macros making it easier to define bus-specific pnpinfo for FDT systems. Pnpinfo is bus-specific and requires the bus name. The FDTCOMPAT_PNP_INFO() macro makes it easier to define new FDT-based pnpinfo for busses other than simplebus. Differential Revision: https://reviews.freebsd.org/D20382
2019-05-23 15:47:30 +00:00
#else
Rename IICBUS_FDT_PNPINFO -> IICBUS_FDT_PNP_INFO because all the other existing pnpinfo-related macros right now use PNP_INFO, not PNPINFO.
2019-05-23 16:03:30 +00:00
#define IICBUS_FDT_PNP_INFO(t)
Define macros making it easier to define bus-specific pnpinfo for FDT systems. Pnpinfo is bus-specific and requires the bus name. The FDTCOMPAT_PNP_INFO() macro makes it easier to define new FDT-based pnpinfo for busses other than simplebus. Differential Revision: https://reviews.freebsd.org/D20382
2019-05-23 15:47:30 +00:00
#endif
Allow i2c bus speed to be configured via hints, FDT data, and sysctl. The current support for controlling i2c bus speed is an inconsistant mess. There are 4 symbolic speed values defined, UNKNOWN, SLOW, FAST, FASTEST. It seems to be universally assumed that SLOW means the standard 100KHz rate from the original spec. Nothing ever calls iicbus_reset() with a speed of FAST, although some drivers would treat it as the 400KHz standard speed. Mostly iicbus_reset() is called with the speed set to UNKNOWN or FASTEST, and there's really no telling what any individual driver will do with those. The speed of an i2c bus is limited by the speed of the slowest device on the bus. This means that generally the bus speed needs to be configured based on the board/system and the components within it. Historically for i2c we've configured with device hints. Newer systems use FDT data and it documents a clock-frequency property for i2c busses. Hobbyists and developers are likely to want on the fly changes. These changes provide all 3 methods, but do not require any existing drivers to change to use the new facilities. This adds an iicbus method, iicbus_get_frequency(dev, speed) that gets the frequency for the requested symbolic speed. If the symbolic speed is SLOW or if there is no speed configured for the bus, the returned value is 100KHz, always. Otherwise, if bus speed is configured by hints, fdt, tunable, or sysctl, that speed is returned. It also adds a helper function, iicbus_init_frequency() that any bus driver subclassed from iicbus can initialize the frequency from some other source of info. Initial driver implementations are provided for Freescale and TI. Differential Revision: https://reviews.freebsd.org/D1174 PR: 195009
2014-11-18 01:54:31 +00:00
int iicbus_generic_intr(device_t dev, int event, char *buf);
void iicbus_init_frequency(device_t dev, u_int bus_freq);
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
Allow iic bridges to support a generalized transfer, rather than forcing all transfers to do the start read/write stop by hand. Some smart bridges prefer this sort of operation, and this allows us to support their features more easily. When bridges don't support it, we fall back to using the old-style opertaions. Expand the ioctl interface to expose this function. Unlike the old-style interface, this interface is thread safe, even on old bridges.
2006-07-14 23:15:06 +00:00
extern driver_t iicbus_driver;
extern devclass_t iicbus_devclass;
Allow i2c hardware drivers to declare their own relationships to ofw_iicbus rather than relying on a set of canned EARLY_DRIVER_MODULE() statements in the ofw_iicbus source. This means hw drivers will no longer be required to use one of a few predefined driver names. They will also now be able to decide themselves if they want to use DRIVER_MODULE or EARLY_DRIVER_MODULE and to set which pass to attach on for early modules. Mainly, this adds extern declarations for the driver and devclass variables. It also renames ofwiicbus_devclass to ofw_iicbus_devclass to be consistant with the way we use ofw_ prefixes on this stuff.
2018-02-18 19:33:28 +00:00
extern driver_t ofw_iicbus_driver;
extern devclass_t ofw_iicbus_devclass;
Allow iic bridges to support a generalized transfer, rather than forcing all transfers to do the start read/write stop by hand. Some smart bridges prefer this sort of operation, and this allows us to support their features more easily. When bridges don't support it, we fall back to using the old-style opertaions. Expand the ioctl interface to expose this function. Unlike the old-style interface, this interface is thread safe, even on old bridges.
2006-07-14 23:15:06 +00:00
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
#endif
Reference in New Issue Copy Permalink