Minimum LCDC is 2 so clock freq shouild be 2*max_pixel_clock. Maximum pixel
clock for HDMI is 148500 (1920x1080). But AM335x can not run in this mode
due to bandwidth and clock limitations
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
While in theory this should have been a transparent change (and was for all
other drivers), cpsw(4) never used the proper accessor macros in a few
places but spelt the indirect m_hdr.mh_* out itself. Convert those to
use m_len and m_data and unbreak the driver build.
To cut off the power we need to start the shutdown sequence by writing
the OFF bit on PMIC.
Once the PMIC is programmed the SoC needs to toggle the PMIC_PWR_ENABLE
pin when it is ready for the PMIC to cut off the power. This is done by
triggering the ALARM2 interrupt on SoC RTC.
The RTC driver only works in power management mode which means it won't
provide any kind of time keeping functionality. It only implements a way
to trigger the ALARM2 interrupt when requested.
Differential Revision: https://reviews.freebsd.org/D1489
Reviewed by: rpaulo
MFC after: 2 weeks
According to http://e2e.ti.com/support/arm/sitara_arm/f/791/t/210729 the
USB reset pulse has an undocumented duration of 200ns and during this
period the module must not be acessed.
We wait for 100us to take into account for some imprecision of the early
DELAY() loop.
This fixes the eventual 'External Non-Linefetch Abort (S)' that happens at
boot while resetting the musb subsystem.
While here, enable the USB subsystem clock before the first access.
Discussed with: ian, adrian
MFC after: 2 weeks
This enables the use of GPIO pins as interrupt sources for kernel devices
directly attached to gpiobus (userland notification will be added soon).
The use of gpio interrupts for other kernel devices will be possible when
intrng is complete.
All GPIO pins can be set to trigger on:
- active-low;
- active-high;
- rising edge;
- falling edge.
Tested on: Beaglebone-black
Fix the following issues:
- Removed revision from device softc, it isn't used anywhere else out of
device attach routine;
- Move the duplicated code for verification of valid banks (and pins) to
a single function;
- Use some macros to simplify the handling of some constants;
- Update some stale comments.
TI OMAP controllers which will return the reset-in-progress bit as zero if
you read the status register too fast after setting the reset bit.
The zero is apparently from a stale snapshot of the internal state presented
in the interface register, and leads to a false indication that the reset
is complete when it either hasn't started yet or is in-progress. The
workaround is to first loop until the bit is seen as asserted, then do the
normal loop waiting to see it de-asserted.
Submitted by: Michal Meloun <meloun@miracle.cz>
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
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
For an unkown reason (at moment), sometimes if_cpsw cannot read from PHY
and fails to attach calling cpsw_detach() which end up in a panic.
Fix it by doing the proper check before detach the miibus and also fix the
leak of few variables.
And to actually make it work, ether_ifattach() has to be moved to the end
of cpsw_attach() to avoid a race where calling ether_ifdetach() before
domain_init() (which will only run later on) would make it crash at
INP_INFO_RLOCK() on in_pcbpurgeif0().
Tested on: BBB (am335x)
MFC after: 1 week
to be present. Thsi creates a new per-SoC driver that handles probe and
setting/getting the gpio flags.
Differential Revision: https://reviews.freebsd.org/D943
Reviewed by: loos, rpaulo
MFC after: 1 week
The TI watchdog timer is present on BeagleBone's. Since 2014, U-Boot
has been booting the BeagleBone with the watchdog enabled. We need to
disable it on boot to avoid a spurious reset.
The timer isn't exactly precise, but it will do as a watchdog. This
is also a reflection of the watchdog(9) API.
In the future, we could handle interrupts, but the watchdog(9) API
needs to be a bit smarter before that can happen.
Differential Revision: https://reviews.freebsd.org/D965
Reviewed by: andrew
MFC after: 1 week
Relnotes: yes
