f85fd4c909
NOTE: nothing is known to be fixed by this change, but it does enforce some delays that are documented to be necessary. Possibly this could fix some corner cases. The function tcphy_dp_aux_calibration(), like most of the functions in the type C PHY, is mostly undocumented and filled with mysterious, hardcoded numbers. Let's attempt to try to document some of these numbers and clean the function up a little bit. Here's the actual cleanup that happened here: 1. All magic numbers were replaced with bit definitions. 2. For registers that we modify multiple times I now keep track of the value of the register rather than randomly doing a read/modify/write or just hardcoding a new number based on knowing what the old number was. 3. Delay 10 ms (vs 1 ms) after writing the calibration code. No idea if this is important but it matches the example in the docs. 4. Whenever setting a "delayed" version of a signal always put an explicit delay in the code. No known problems were seen without this delay but it seems wise to have it. Whenever a delay of "at least 100 ns" was specified I used a delay of 1 us. 5. Added comments to some of the bits of code. 6. Removed duplicate setting of TX_ANA_CTRL_REG_5 (to 0) 7. Moved setting of TX_ANA_CTRL_REG_3 to the same place it was in the sample code. Note that TX_ANA_CTRL_REG_3 ought to be initted to 0 (and elsewhere we assume that we just got a reset), but it seems fine to be explicit. 8. Treats the calibration code as a 7-bit two's complement number. This isn't strictly required, but seems slightly cleaner. The docs say "treat this as a two's complement number, but it should never be negative". If we ever read the "adjustment" codes as documented then perhaps the two's complement bit will matter more. There are still a few weird / mysterious things around aux init and this doesn't attempt to fix all of them. Mostly it's aimed at doing changes that should be _very_ safe and add a lot of clarity. Things specifically not done: A) Resolve the fact that some registers are read/modify/write and others are explicitly initted to a value. We always call tcphy_dp_aux_calibration() right after resetting the PHY so it's probably not critical, but it's a little weird that the code is inconsistent. B) Fully resolve the documented init sequence with the current one. We still have a few mystery steps and we also leave out turning on TXDA_DRV_LDO_BG_FB_EN and TXDA_DRV_LDO_BG_REF_EN, which is in the sample code. C) Clean things up to read all the bits of the calibration code. This will hopefully come in a followup change. This also doesn't attempt to document any of the other parts of the PHY--just the aux init which is all I got docs for. Reviewed-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> |
||
|---|---|---|
| Documentation | ||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| drivers | ||
| firmware | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
README
Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.