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

79 lines
2.6 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
/*-
* 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 */
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;
Add a method to iicbus to request IIC_M_NOSTOP behaviour for multibyte transfers to be default. It simplifies porting code which assumes such settings. Discussed with: avg, llos, nwhitehorn Sponsored by: The FreeBSD Foundation MFC after: 1 week
2014-10-27 07:51:26 +00:00
bool nostop;
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 {
Add a method to iicbus to request IIC_M_NOSTOP behaviour for multibyte transfers to be default. It simplifies porting code which assumes such settings. Discussed with: avg, llos, nwhitehorn Sponsored by: The FreeBSD Foundation MFC after: 1 week
2014-10-27 07:51:26 +00:00
IICBUS_IVAR_ADDR, /* Address or base address */
IICBUS_IVAR_NOSTOP, /* nostop defaults */
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 a method to iicbus to request IIC_M_NOSTOP behaviour for multibyte transfers to be default. It simplifies porting code which assumes such settings. Discussed with: avg, llos, nwhitehorn Sponsored by: The FreeBSD Foundation MFC after: 1 week
2014-10-27 07:51:26 +00:00
IICBUS_ACCESSOR(nostop, NOSTOP, bool)
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
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)
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;
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