First, SCL low timeout is set to 25 milliseconds by default as opposed
to 1 millisecond before. The new value is based on the SMBus
specification. The timeout can be changed on a per bus basis using
dev.iicbb.N.scl_low_timeout sysctl.
The driver uses DELAY to wait for high SCL up to 1 millisecond, then it
switches to pause_sbt(SBT_1MS) for the rest of the timeout.
While here I made a number of other changes. 'udelay' that's used for
timing clock and data signals is now calculated based on the requested
bus frequency (dev.iicbus.N.frequency) instead of being hardcoded to 10
microseconds. The calculations are done in such a fashion that the
default bus frequency of 100000 is converted to udelay of 10 us. This
is for backward compatibility. The actual frequency will be less than a
quarter (I think) of the requested frequency.
Also, I added detection of stuck low SCL in a few places. Previously,
the code would just carry on after the SCL low timeout and that might
potentially lead to misinterpreted bits.
Finally, I fixed several style issues near the code that I changed.
Many more are still remaining.
Tested by accessing HTU21 temperature and humidity sensor in this setup:
superio0: <Nuvoton NCT5104D/NCT6102D/NCT6106D (rev. B+)> at port 0x2e-0x2f on isa0
gpio1: <Nuvoton GPIO controller> at GPIO ldn 0x07 on superio0
pcib0: allocated type 4 (0x220-0x226) for rid 0 of gpio1
gpiobus1: <GPIO bus> on gpio1
gpioiic0: <GPIO I2C bit-banging driver> at pins 14-15 on gpiobus1
gpioiic0: SCL pin: 14, SDA pin: 15
iicbb0: <I2C bit-banging driver> on gpioiic0
iicbus0: <Philips I2C bus> on iicbb0 master-only
iic0: <I2C generic I/O> on iicbus0
Discussed with: ian, imp
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D22109
I limited potentially infinite timings by 960 us based on a footnote on
page 38 of Maxim Integrated Application Note 937, Book of iButton
Standards: "In order not to mask interrupt signalling by other devices
on the 1–Wire bus, tRSTL + tR should always be less than 960 us."
MFC after: 3 weeks
Previously we used the minimal value of 1 us and it was really tight.
Application Note 3829 has a table describing recommended t_rec values
for various bus voltages, temperature conditions and numbers of slave
devices. The new value decreases the maximum possible data rate from
16.3 Kbit/s to 13.3 Kbit/s, but it allows for up to four slaves on a
3.3V bus (under room temperature).
References:
- Maxim Integrated Application Note 3829
Determining the Recovery Time for Multiple-Slave 1-Wire(R) Networks
- Maxim Integrated Application Note 937
Book of iButton Standards
Discussed with: imp (D22108)
MFC after: 3 weeks
After r353292, netmap generic adapter on if_vlan interfaces panics on
asserting the NET_EPOCH. In more detail, this happens when
nm_os_generic_xmit_frame() is called, that is in the generic txsync
routine.
Fix the issue by entering the NET_EPOCH during the generic txsync.
We amortize the cost of entering/exiting over a whole batch of
transmissions.
PR: 241489
Reported by: Aleksandr Fedorov <aleksandr.fedorov@itglobal.com>
Previously the code used sbttous() before microseconds comparison in one
place, sbttons() and nanoseconds in another, division by SBT_1US and
microseconds in yet another.
Now the code consistently uses multiplication by SBT_1US to convert
microseconds to sbintime_t before comparing them with periods between
calls to sbinuptime(). This is fast, this is precise enough (below
0.03%) and the periods defined by the protocol cannot overflow.
Reviewed by: imp (D22108)
MFC after: 2 weeks
The lock is used only for start / stop signaling.
It is used only for 'flags' field and the related condition variable.
This change is a follow-up to r354067, it was suggested by Warner in
D22107.
Suggested by: imp
MFC after: 1 week
This is similar to what is done around other calls that lead to
own_command_wait() that can sleep.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22107
Some controllers cannot preset future output value while the pin is in
input mode. This adds a fallback for those controllers. The new code
assumes that a controller reports an error in that case.
For example, all hardware supported by nctgpio behaves in that way.
This is a temporary measure. In the future we will use
GPIO_PIN_PRESET_LOW / GPIO_PIN_PRESET_HIGH to preset the output either
in hardware, if supported, or in software (e.g., in
gpiobus_pin_setflags).
While here, I extracted common functionality of gpioiic_set{sda,scl} and
gpioiic_get{sda,scl} to gpioiic_setpin and gpioiic_getpin respectively.
MFC after: 2 weeks
The object does not provide anonymous memory.
Reported by: kib
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D22123
This method check that boot_on or always_on is set to 1 and if it
is it will try to enable the regulator.
The binding docs aren't clear on what to do but Linux enable the regulator
if any of those properties is set so we want to do the same.
The function first check the status to see if the regulator is
already enabled it then get the voltage to check if it is in a acceptable
range and then enables it.
This will be either called from the regnode_init method (if it's needed by the platform)
or by a SYSINIT at SI_SUB_LAST
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22106
NIC KTLS will add a new TLS send tag type in cxgbe(4) that is a
distinct tag from a ratelimit tag. To support this, refactor
cxgbe_snd_tag to be a simple send tag with a type and convert the
existing ratelimit tag to a new cxgbe_rate_tag structure.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D22072
Previously the table was allocated on first use by TOE and the
ratelimit code. The forthcoming NIC KTLS code also uses this table.
Allocate it unconditionally during attach to simplify consumers.
Reviewed by: np
Differential Revision: https://reviews.freebsd.org/D22028
This change consists of two parts.
First, nctgpio now supports hardware access via an I/O port window if
it's configured by firmware. For instance, PC Engines firmware
v4.10.0.2 does that. This is faster than going through the Super I/O
configuration registers.
Second, nctgpio now caches values of bits that it controls. For
example, the driver does not need to access the hardware to determine if
a pin is an output or an input, or a state of an output. Also, the
driver makes use of the fact that the hardware preserves an output state
of a pin accross a switch to the input mode and back.
With this change I am able to use the 1-Wire bus over nctgpio whereas
previously the driver introduced too much latency to be compliant with
the relatively strict protocol timings.
superio0: <Nuvoton NCT5104D/NCT6102D/NCT6106D (rev. B+)> at port 0x2e-0x2f on isa0
gpio1: <Nuvoton GPIO controller> at GPIO ldn 0x07 on superio0
pcib0: allocated type 4 (0x220-0x226) for rid 0 of gpio1
gpiobus1: <GPIO bus> on gpio1
owc0: <GPIO attached one-wire bus> at pin 4 on gpiobus1
ow0: <1 Wire Bus> on owc0
ow0: romid 28:b2:9e:45:92:10:02:34: no driver
ow_temp0: <Advanced One Wire Temperature> romid 28:b2:9e:45:92:10:02:34 on ow0
MFC after: 4 weeks
