a10_timer is currently use in UP allwinner SoC (A10 and A13).
Those don't have the generic arm timer.
The arm generic timecounter is broken in the A64 SoC, some attempts have
been made to fix the glitch but users still reported some minor ones.
Since the A64 (and all Allwinner SoC) still have this timer controller, rework
the driver so we can use it in any SoC.
Since it doesn't have the 64 bits counter on all SoC, use one of the
generic 32 bits counter as the timecounter source.
PR: 229644
Without this the mmc stack sometimes think that we are in in a retune
operation and some command like switch the bus width to 4 bits failed.
We now switch correctly to 4 bits mode for sd card.
Reported by: jmg, others in pine64 irc channel
Recent DTS use the syscon for the emac controller.
We support this but since U-Boot is still using old DTS it was never
needed for us to add this support, but this is a problem when using upstream
recent DTS and will be when U-Boot will catch up.
While here add a new compatible to the aw_syscon driver as Linux changed it ...
Now that aw_sid expose nvmem interface, use that to read the calibration
data.
Add support for H5 SoC.
Fix the bindings, we used to have non-upstreamed bindings. Switch to the
one that have been sent upstream. They are not stable yet, so we switch
from custom, wrong, bindings to correct, proposed bindings
Rework aw_sid so it can work with the nvmem interface.
Each SoC expose a set of fuses (for now rootkey/boardid and, if available,
the thermal calibration data). A fuse can be private or public, reading private
fuse needs to be done via some registers instead of reading directly.
Each fuse is exposed as a sysctl.
For now leave the possibility for a driver to read any fuse without using
the nvmem interface as the awg and emac driver use this to generate a mac
address.
It doesn't work since 2 years when we stopped patching DTS.
The DTS now have the correct bindings but they are a lot different
from our hacked ones we used to have (and more representative of the
reality).
Remove the old clocks for allwinner as now all the SoCs have been converted
to clkng.
The only old clock now is the gmac clock which still lives under the /clocks
dts node.
The test for checking if the clock have a mux was inverted and the mask
to calculate the parent index was wrong was wrong too.
It means that upon creation the incorrect parent was resolved as the current
one and upon reparent the switch was never made.
Pointy hat (lots of them): manu
Using MMCCAM on AllWinner boards is now possible, reaching highest
possible data transfer speed.
For now, MMCCAM doesn't scan cards on boot. This means that scanning
has to be done manually and that it's not possible to mount root FS
from MMC/SD card since there is no block device at the boot time.
For manually scanning the cards, run:
# camcontrol rescan X:0:0
Where X is the bus number (look at camcontrol devlist to determine
bus number assigned to the MMC controller).
Reviewed by: manu
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15891
Each clock drivers if now fully subclassed, this have the advantage that
we can control the probe order.
Some clocks can have parents from other drivers, for example clocks in the
sun8i_r driver uses clocks from the main clock driver.
This worked before because the sun8i_r node is after the main ccu node in the
dtb and driver are probed in DTB order. This cannot work with the Display
Engine clocks as it is the first node in the DTB.
Tested on: A83T, H5 A64
Tested on: A20 (kevans)
r329104 imported 4.15 DTS which brought CCU to a10/a20. In the process, they
swapped the ordering of 'clocks' for allwinner,sun4i-a10-ahci on both
sun4i-a10 and sun7i-a20 from PLL, Gate to Gate, PLL.
Swap it in the driver.
Note: At this time, this has only been tested on a single board from one of
the supported SoCs. This is enough to boot the board from MMC and have
functional USB- which is still an improvement over where we were at just
before with no functional clocks.
Differential Revision: https://reviews.freebsd.org/D15810
This happens in two cases for a20 clocks:
pll_core for 'n' factor:
factor=0, val=1
factor=n, val=n
ahb divisor:
factor=0,val=/2
factor=n,val=/2^n
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D15806
- Calculate the number of segments based on the page size
- Add some comments on dma function so it's easier to read
- Only enable interrupts on the last dma segment
- If the segments size is the max transfer size, use the special size 0
for the controller.
- The max_data ivars is in block so calculate it properly.
Always disable FIFO access as we don't use it.
Rename some register bits so they are in sync with the register name.
While here add my copyright as I've probably wrote 70% of the code here.
The module uses the mod clock and not the ahb one.
We need to set the mod clock to twice the speed requested as the smallest
divider in the controller is 2.
The clock test function weren't calculating the register value best on the
best div but on the max one.
The cdr2 test function was using the cdr1 formula.
Pointy Hat: manu
Don't enable regulator on attach but dealt with them on power_up/power_off
Only set the voltage for the signaling regulator since I don't have boards
that can change the supply voltage.
Enable 1.8v signaling voltage.
Only do a reset of the controller at attach and init it at power_up.
We use to enable some interrupts in reset, only enable the interrupts
we are interested in when doing a request.
While here remove the regulators handling in power_on as it is very wrong
and will be dealt with in another commit.
Tested on: A31, A64
Move the allwinner early printf support to the snps driver as it
should work with all implementation.
While here add instruction for enabling it on 64bits SoCs.
Name each ehci driver uniquely.
This remove the warning printed at each arm boot :
module_register: cannot register simplebus/ehci from kernel; already loaded from kernel
Name each ahci driver uniquely.
This remove the warning printed at each arm boot :
module_register: cannot register simplebus/ahci from kernel; already loaded from kernel
WHile gate_shift was present in the NM_CLK macro it wasn't set into the
clock definition structure resulting in NM clocks not being correctly
gated when they should.
If the module wasn't enabled by the bootloader it will have stayed ungated.
Switch test between zero based factor and power of two one.
This resulted in a miscalculation of the factor if it was a power
of two one.
Some clocks frequencies were not calculated correctly because of that.
Split out delay parsing into a separate function; we'll support both
{tx,rx}-delay as well as the new versions.
While here, validate that they're within the expected range and fail to
attach if they are not. Assuming that we can clamp the delay is a bad idea
that might result in a non-working awg anyways, so we'll fail early to make
it easier to catch.
This version also unsets the tx and rx delay registers unconditionally and
then sets them if we read a non-zero delay. These delay properties should
default to 0 if not specified, as declared in the binding documentation.
Presumably the delays will be set via hardware configuration if they're not
explicitly set in FDT.
OF_getprop_alloc takes element size argument and returns number of
elements in the property. There are valid use cases for such behavior
but mostly API consumers pass 1 as element size to get string
properties. What API users would expect from OF_getprop_alloc is to be
a combination of malloc + OF_getprop with the same semantic of return
value. This patch modifies API signature to match these expectations.
For the valid use cases with element size != 1 and to reduce
modification scope new OF_getprop_alloc_multi function has been
introduced that behaves the same way OF_getprop_alloc behaved prior to
this patch.
Reviewed by: ian, manu
Differential Revision: https://reviews.freebsd.org/D14850
If a regulator is missing a mandatory property (like 'regulator-name'), do
not fail, regulator_parse_ofw_stdparam is returning a non-zero value so just
skip this regulator.
Also if any regulator fails to attach continue with the rest of the regulators
instead of returning ENXIO in axp8xx_attach
Tested On: BananaPi M3
It was later found that some operation on the OrangePi one will cause
direct accesses to the eeprom to return wrong data again, so reading it all
once via prctl at attach time is no longer sufficient.
vbus-supply properties may be specified for each PHY. These properties
reference a regulator that we must turn on/off as we turn the PHY on/off.
However, if the usbphy comes up before the regulator in question (as is the
case with GPIO-controlled regulators), then we will fail to grab a handle to
the regulator and control it as the PHY power state changes.
Fix it by just attaching the usbphy driver later. We don't really need it at
RESOURCE, we just need it to be before DEFAULT when ehci/ohci attach. In
particular, this fixes the USB NIC on a board that we don't yet supported-
without this, it will not power on and if_ure cannot attach.
Tested on: various boards [manu]
Tested on: OrangePi R1 [Rap2 (irc)]
Reported by: Rap2 (irc, "Cannot find USB NIC")
It would have been on an actual named pass before, but none were really
appropriate in name. Move it to the recently created SUPPORTDEV pass, which
perfectly describes it and keeps it in the right order.
Getting regulator is good, enabling them is better.
When the mmc stack decide to change the voltage for IO, don't
change the main vcc of the sd/mmc, only the io vcc.
AXP803 and AXP813/818 are very similar, only two regulators differs.
AXP803 is the companion chip for A64/R18
AXP813 is the companion chip for A83T
AXP818 is the companion chip for H8 (~A83T)
Add support for all regulators found in both of them.
