Hi,
Presently working on Tegra K1, to understand about CL DVFS.
I am searching for the code , who is reading ,interpreting and writing/informing CL DVFS to PMIC [AMS]. Please let me know if any one has come across the same point.
I have found some of the information & but not full in detail ,
Here is the file : arch/arm/mach-tegra/tegra_cl_dvfs.c
It has mapped the DVFS address:
root@tegra-ubuntu:/home/ubuntu# cat /proc/iomem
70110000-701103ff : tegra_cl_dvfs
Note This address is allocated for DVFS as per TRM:
DVFS 7011:0000 7011:03ff
Printing the content of the cl dvfs registers
cat /sys/kernel/debug/clock/dfll_cpu/cl_dvfs/registers
CONTROL REGISTERS:
[0x00] = 0x00000002
[0x04] = 0x00000080
[0x08] = 0x004a0002
[0x0c] = 0x005040ff
[0x10] = 0x00000060
[0x14] = 0x1500ffdb
[0x18] = 0x00000000
[0x1c] = 0x00000f00
[0x20] = 0x4a200a00
[0x24] = 0x00000000
[0x28] = 0x00000006
[0x2c] = 0x000100b6
I2C and INTR REGISTERS:
[0x40] = 0x00107080
[0x44] = 0x00000000
[0x48] = 0x00000034
[0x5c] = 0x00000003
[0x60] = 0x00000000
LUT:
[0x200] = 0x00000020
[0x204] = 0x00000022
[0x208] = 0x00000024
[0x20c] = 0x00000026
[0x210] = 0x00000028
[0x214] = 0x0000002a
[0x218] = 0x0000002b
[0x21c] = 0x0000002d
[0x220] = 0x0000002f
[0x224] = 0x00000030
[0x228] = 0x00000032
[0x22c] = 0x00000033
[0x230] = 0x00000035
[0x234] = 0x00000036
[0x238] = 0x00000038
[0x23c] = 0x00000039
[0x240] = 0x0000003a
[0x244] = 0x0000003c
[0x248] = 0x0000003d
[0x24c] = 0x0000003f
[0x250] = 0x00000040
[0x254] = 0x00000041
[0x258] = 0x00000043
[0x25c] = 0x00000044
[0x260] = 0x00000046
[0x264] = 0x00000048
[0x268] = 0x0000004a
[0x26c] = 0x0000004b
[0x270] = 0x0000004d
[0x274] = 0x0000004e
[0x278] = 0x00000050
[0x27c] = 0x00000052
[0x280] = 0x00000053
Please let me know, what is the interpretation of LUT Table. To which registers of PMIC will be written?
I’m not sure if this is what you’re asking, but “DVFS 7011:0000” is a base physical address for the DVFS controller as a whole (the TRM uses physical addresses rather than virtual for TRM table 1, section 2.1). The other values on the left side of the LUT look to be offsets, e.g., “[0x00]” has data 32-bits (4-bytes) wide starting at 0x70110000. The TRM for DVFS is describing bits within byte offsets rather than purely byte offsets, but the two can be converted (for example, LUT 0x00 would apply to the first 32 bits).
A typical operation if this 4-byte alignment is imposed through the /sys interface would be to read the whole value, save this whole value, flip the bit or bits of interest, and then write the modified 4 bytes back with all bits other than the flipped bits being constant.
Hi,
The following information is valid & true “DVFS 7011:0000” is a base physical address for the DVFS controller as a whole (the TRM uses physical addresses rather than virtual for TRM table 1, section 2.1). The other values on the left side of the LUT look to be offsets, e.g., “[0x00]” has data 32-bits (4-bytes) wide starting at 0x70110000."
Can you provide more data on the TRM 6.0 CL-DVFS, 6.1.19 CL_DVFS_OUTPUT_LUT_0
This lookup table (LUT) contains voltage LUT values stored in a 33-deep by 8 bit wide RAM. To program the LUT, simply sequentially address the RAM, using the base offset address of 0x20 (10’b10xxxxxxxx). Addresses are DWORD aligned, not BYTE aligned. PMIC values must be programmed to span the entire desired operating range, and be monotonically increasing. The logic assumes that the middle entry (16th) corresponds to the ‘safe’ initial voltage, as specified in the DFLL_OUTPUT_CONFIG.SAFE field. DFLL_OUTPUT_CONFIG_SAFE is initialized by default to 0x10, which corresponds to the middle of the LUT. However, the safe value can point to any LUT entry.
Someone else will need to verify this, but I believe the meaning is that even though addresses are listed for individual bits or bytes in 8-bit wide RAM that the programming of these values requires DWORD (32-bit) register assignments for each modification to the memory. E.G., you would have to prepare all 32-bits for their assignment prior to putting data to the memory address. Second, “monotonic” looks like you must start at the lowest address register value first for data writes, and walk upwards in memory address writing each 4-byte word in order without skipping any range in between.
Perhaps a better question would be to know what you want to accomplish? I suspect that incorrect settings of some of these registers could cause permanent hardware failure. The context of the question would be important for anyone giving a specific answer.
The base value of out_map->reg_value filled in LUT table( LUT base value) is 0x1e ( or 0xa , it is based on PMIC veriosn) . The value is from e1733_fill_reg_map() . The expected voltage range is 1.3v - 0.7v = 500 mV .
LUT table is used to convert DFLL voltage requests into I2C commands for the PMIC and there are 33 steps [LUT table] to tune this voltage based on CL-DVFS logic signal.
If you would like to know how to translate the value to PMIC voltage , you have to check PMIC (AS3722) datasheet.
About CL_DVFS_OUTPUT_LUT_0 in TRM ,
LUT values stored in a 33-deep by 8 bit wide RAM : LUT table include 33 elements with 8bit-length to tune this voltage
The entire desired operating range should be 1.3v~0.7v ( 33 steps to adjust)
The default value of the middle entry (16th) [0x23c] is 0x10 , but it would be overwrite by cl-dvfs driver (e1733_cpu_vdd_map)