2015-05-30 12:17:18 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2014 The DragonFly Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* This code is derived from software contributed to The DragonFly Project
|
|
|
|
* by Matthew Dillon <dillon@backplane.com> and was subsequently ported
|
|
|
|
* to FreeBSD by Michael Gmelin <freebsd@grem.de>
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
* 3. Neither the name of The DragonFly Project nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
* from this software without specific, prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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
|
|
|
|
* COPYRIGHT HOLDERS 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.
|
|
|
|
*
|
|
|
|
* $FreeBSD$
|
|
|
|
*/
|
|
|
|
|
2016-11-02 17:04:00 +00:00
|
|
|
#ifndef _ICHIIC_IG4_VAR_H_
|
|
|
|
#define _ICHIIC_IG4_VAR_H_
|
2015-05-30 12:17:18 +00:00
|
|
|
|
|
|
|
#include "bus_if.h"
|
|
|
|
#include "device_if.h"
|
|
|
|
#include "pci_if.h"
|
add iic interface to ig4 driver, move isl and cyapa to iicbus
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
|
|
|
#include "iicbus_if.h"
|
2015-05-30 12:17:18 +00:00
|
|
|
|
|
|
|
#define IG4_RBUFSIZE 128
|
|
|
|
#define IG4_RBUFMASK (IG4_RBUFSIZE - 1)
|
|
|
|
|
|
|
|
enum ig4_op { IG4_IDLE, IG4_READ, IG4_WRITE };
|
|
|
|
|
|
|
|
struct ig4iic_softc {
|
|
|
|
device_t dev;
|
|
|
|
struct intr_config_hook enum_hook;
|
add iic interface to ig4 driver, move isl and cyapa to iicbus
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
|
|
|
device_t iicbus;
|
2015-05-30 12:17:18 +00:00
|
|
|
struct resource *regs_res;
|
|
|
|
int regs_rid;
|
|
|
|
struct resource *intr_res;
|
|
|
|
int intr_rid;
|
|
|
|
void *intr_handle;
|
|
|
|
int intr_type;
|
|
|
|
enum ig4_op op;
|
|
|
|
int cmd;
|
|
|
|
int rnext;
|
|
|
|
int rpos;
|
|
|
|
char rbuf[IG4_RBUFSIZE];
|
|
|
|
int error;
|
|
|
|
uint8_t last_slave;
|
2016-12-26 22:13:43 +00:00
|
|
|
int platform_attached : 1;
|
2015-05-30 12:17:18 +00:00
|
|
|
int use_10bit : 1;
|
|
|
|
int slave_valid : 1;
|
|
|
|
int read_started : 1;
|
|
|
|
int write_started : 1;
|
2015-06-25 07:52:51 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Locking semantics:
|
|
|
|
*
|
2016-11-02 17:04:00 +00:00
|
|
|
* Functions implementing the icbus interface that interact
|
2015-06-25 07:52:51 +00:00
|
|
|
* with the controller acquire an exclusive lock on call_lock
|
|
|
|
* to prevent interleaving of calls to the interface and a lock on
|
|
|
|
* io_lock right afterwards, to synchronize controller I/O activity.
|
2016-11-02 17:04:00 +00:00
|
|
|
*
|
|
|
|
* The interrupt handler can only read data while no iicbus call
|
2015-06-25 07:52:51 +00:00
|
|
|
* is in progress or while io_lock is dropped during mtx_sleep in
|
|
|
|
* wait_status and set_controller. It is safe to drop io_lock in those
|
|
|
|
* places, because the interrupt handler only accesses those registers:
|
|
|
|
*
|
|
|
|
* - IG4_REG_I2C_STA (I2C Status)
|
|
|
|
* - IG4_REG_DATA_CMD (Data Buffer and Command)
|
|
|
|
* - IG4_REG_CLR_INTR (Clear Interrupt)
|
|
|
|
*
|
|
|
|
* Locking outside of those places is required to make the content
|
|
|
|
* of rpos/rnext predictable (e.g. whenever data_read is called and in
|
2016-11-02 17:04:00 +00:00
|
|
|
* ig4iic_transfer).
|
2015-06-25 07:52:51 +00:00
|
|
|
*/
|
|
|
|
struct sx call_lock;
|
|
|
|
struct mtx io_lock;
|
2015-05-30 12:17:18 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct ig4iic_softc ig4iic_softc_t;
|
|
|
|
|
|
|
|
/* Attach/Detach called from ig4iic_pci_*() */
|
|
|
|
int ig4iic_attach(ig4iic_softc_t *sc);
|
|
|
|
int ig4iic_detach(ig4iic_softc_t *sc);
|
|
|
|
|
2016-11-02 17:04:00 +00:00
|
|
|
/* iicbus methods */
|
add iic interface to ig4 driver, move isl and cyapa to iicbus
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
|
|
|
extern iicbus_transfer_t ig4iic_transfer;
|
|
|
|
extern iicbus_reset_t ig4iic_reset;
|
2015-05-30 12:17:18 +00:00
|
|
|
|
2016-11-02 17:04:00 +00:00
|
|
|
#endif /* _ICHIIC_IG4_VAR_H_ */
|