files to vendor-provided ones. It should make easier to adopt platform
code to new revisions of hardware and to use DTS overlays for various
Beaglebone extensions (shields/capes).
Original dts filenames were not changed, they're now wrappers over dts
files provided by TI. So make sure you update .dtb files on your
devices as part of kernel update
GPIO addressing was changed: instead of one global /dev/gpioc0 there
are per-bank instances of /dev/gpiocX. Each bank has 32 pins so for
instance pin 121 on /dev/gpioc0 in old addressing scheme is now pin 25
on /dev/gpioc3
On Pandaboard serial console devices was changed from /dev/ttyu0 to
/dev/ttyu2 so you'll have to update /etc/ttys to get login prompt
on serial port in multiuser mode. Single user mode serial console
should work as-is
Differential Revision: https://reviews.freebsd.org/D2146
Reviewed by: rpaulo, ian, Michal Meloun, Svatopluk Kraus
1 second is not enugh for TDA19988 HDMI framer (e.g. on Beaglebone Black)
- Add per-device i2c_timout sysctl (dev.iichb.X.i2c_timeout) to control
I2C bus timeout manually
- Pass softc instead of device_t to all sysctl handlers
For OMAP4, the old values for 1MHz gave a bus frequency of about 890KHz.
The new numbers hit 1MHz exactly.
For AM335x the prescaler values are adjusted to give a 24MHz clock for
all 3 standard speeds, as the manual recommends (as near as we can tell,
there are errors and typos apparent in the document). Also, 1MHz speed
is added, and has been tested successfully on a BeagleboneWhite board.
PR: 195009
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
few changes to drivers, no kernel config was added. As the SoCs are quite
old and the code is unmaintained start the process of removing support by
deleting the header file and code that depends on it along with the macro
SOC_OMAP3. Other Ti SoCs shouldn't be affected, other than for us to have
less code to maintain.
Differential Revision: https://reviews.freebsd.org/D936
Reviewed by: rpaulo, loos
. interrupt storm detected on "intr70:"; throttling interrupt source;
. Added access serialization on iicbus_transfer(), previously there was
no such protection and a new transfer could easily confuse the
controller;
. Add error checkings (i.e. stop the transfer when a error is detected
and do _not_ overwrite the previous error);
. On command done interrupt do not assume that the transfer was finished
sucessfully as we will receive the command done interrupt even after
errors;
. Simplify the FIFO handling;
. Reset the FIFO between the transfers as the FIFO may contain data from
the last (failed) transfer;
. Fix the iicbus speed for AM335x, which in turn will make better use of
the I2C noise filter (set to one internal clock cycle);
. Move the read and write handler to ithread instead of notifying the
requesting thread with wakeup(9);
. Fix the comments based on OMAP4 TRM.
The above changes allows me to read the EDID from my HDMI monitor on BBB
with gonzo's patches to support TDA19988 (which does 128 bytes reads) and
repeatedly scan the iicbus (with a modified i2c(8)) without lock up the bus.
Phabric: D465
(7-bit device address << 1), always leaving the room for the read/write bit.
This commit convert ti_i2c and revert r259127 on bcm2835_bsc to make them
compatible with 8-bit addresses. Previous to this commit an i2c device
would have different addresses depending on the controller it was attached
to (by example, when compared to any iicbb(4) based i2c controller), which
was a pretty annoying behavior.
Also, update the PMIC i2c address on beaglebone* DTS files to match the new
address scheme.
Now the userland utilities need to do the correct slave address shifting
(but it is going to work with any i2c controller on the system).
Discussed with: ian
MFC after: 2 weeks
The ti_i2c controller only works in the master mode and the i2c address
passed on iicbus_reset() is used to set the controller slave address when
operating as an i2c slave (which isn't currently supported).
When talking to a slave, the slave address is correctly provided to
ti_i2c_tranfer().
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
this change we may end up with a panic (Fatal kernel mode data abort:
'External Non-Linefetch Abort (S)') as described in
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/276862.aspx.
It is now possible to bring up I2C1 and I2C2 on BBB.
Approved by: adrian (mentor)
