Hi,
我m an Embedded Systems Engineer developing BSP for one of my company self-designed board where we use a Dialog DA9063-3FHK1 PMIC.
While implementing Linux support for PMIC regulators monitoring, I found out that different versions
of the DA9063 PMIC exist. They don't have the same register map.
As I can't figure out what register map my PMIC version belongs to, I'm posting here in order to know
如何查找在DA9063-3FHK1版本中实现的确切寄存器映射。
此致，
PinkPR
Device:
Hello
The best way to check the register values is to use the DA9063 GUI, this will allow you to check each register and its function. The -3FHK1 code describes the package, the 3F is the Variant number (OTP) and the HK1 is the physical package details.
The 3F Variant is in the process of being replaced by the 82 Variant, this Variant however is still going through the process of being released. I would recommend using the 82 variant in the future.
Kind Regards,
Elliott Dexter
Clickherefor the Link to the DA9063 GUI.
Hi Elliott, thanks for answering.
From what I understand, the DA9063 GUI is made to be used with the DA9063 Eval board.
I don't have this eval board, plus I can't find the DA9063 GUI on the internet.
我m actually not trying to find what's inside the OTP, but I'd just like to check if the register addresses on my PMIC version are compliant with what's written in the Linux source files.
我d especially like to check for the ADC part. There is no ADC feature implementated for DA9063 in the Linux Kernel, and that's what I'm working on.
PinkPR
Hello PinkPR,
DA9063 GUI
The GUI itself can be used without a Performance or Eval board, this will allow a user to check and edit OTP register settings but will not allow the user to check the OTP with the PMIC.
Clickherefor the DA9063 Support Page. The GUI is called PowerCommander
Chip ID and Variant
There are two register maps in the DA9063 driver. The AD tables and the BB tables, the BB tables are used for the DA9063 driver.
芯片ID和变体寄存器值用于检测芯片类型。这些寄存器是：
#define da9063_reg_chip_id 0x181
#define DA9063_REG_CHIP_VARIANT 0x182
ADC Mapping
Under
https://support.dialog-semiconductor.com/pmic-audio/device/da9063?qt-pmic_device=1#qt-pmic_device
Documents > Freescale BSP >
There are DA9063 Android integrations. These contain examples for the HWMON driver for the DA9063 as integrated into the Freescale/NXP Android releases.
The latest release,DA9063 i.MX 6 Lollipop Android L5.1.1 2.1.0 BSPhas a ZIP file, which is theDA9063 I.MX 6 LOLLIPOP ANDROID L5.1.1 2.1.0 BSP.ZIP, this contains a hwmon example for DA9063.
Kind Regards,
Elliott Dexter
Hi Elliott,
Do you know why internal regulators monitoring is not implemented in the hwmon driver ? That's precisely the feature I'm looking for.
我ll try to add this feature on top of the base driver you provided.
PinkPR
Hi Pierre-Olivier,
在过去,下/电压中断处理程序were too specific to be included in the general Linux driver and the kernel maintainers would not support their addition. The example in the Android implementation shows how the Android version needs to implemented for monitoring on the Dialog PEBIX reference platform, but it is believed any implementation will contain platform specific components.
Kind Regards,
Elliott Dexter
Hi Elliott,
Thanks for your answer. I still can't find how to perform ADC manual conversions on internal regulators.
I literally followed the"Monitoring Output Voltages --> Manual Measurement of Regulator Output Voltages"part (part 6.4, page 13) of theAN-PM-024 DA9063 Voltage Monitoringdocument, and it doesn't seem to work at all.
Plus I noticed some differences between this document content and the Datasheet content.
For example, the document tells to set
mon_a8_idx = 0.to select BUCKCORE1 monitoring. But according to the datasheet, you should setmon_a8_idx = 1.那是真的，什么是不是？
PinkPR
顺便问一下，3F和82版本之间的差异是什么？
Hi Pierre-Olivier,
Datasheet and Application note:
The DA9063 datasheet states a register value of 1 for BUCKCORE 1 and AN-PM-024 mostly states a register value of 1 for BUCKCORE1. However there is a typo in one of the tables in AN-PM-024, table 12, it states 0h, and this should also be a 1 to be correct and consistent with the other table. Thank you for pointing this out, we will update the document.
Variant 3F and 82:
Variant 3F and Variant 82 are very similar; there are a few minor changes to certain regulators voltages, current limits and start-up slots. There are also a few changes to minor registers but nothing that significantly changes its operation or purpose. The changes were recommended by customers and customer requirements.
ADC
When you said that you followed the document and it didn’t work at all, what did you mean?
Kind Regards,
Elliott Dexter
我实际上试图得到一个ADC-measured voltage value for each of the regulators.
1. I reset the ADC by writing in the ADC_MAN register the value ADC_MUX (8, 9, or 10 according to what group the measured regulator belongs to).
2. I write the index related to the regulator in MON_REG_5 or MON_REG_6.
3. I write the ADC_MAN bit (1 << 4) in the ADC_MAN register.
4. I wait for the value to be ready by waiting for the E_ADC_RDY bit (1 << 3) to be set in the EVENT_A register.
5. I get ADC_RES_H and ADC_RES_L and merge them in order to rebuild the conversion result.
The problem is, for every regulator that belongs to group A8 or A10, that I get a ADC_RES_H and ADC_RES_L full of high bits (OxFF).
In the case of A9, I get different values depending on the regulator, but they aren't logical at all.
For example, I have (in reality) LDO1 voltage > LDO2 voltage. But my ADC conversion tells the contrary.
Those illogical behaviors make me think that's there is a BIG problem in my algorithm, and it could come from bad infos from Datasheets / Application notes I have.
That's why I'm coming to you and ask for help :-)
PinkPR
Hi Pierre-Olivier,
我按照应用程序注意的说明，并没有任何问题。雷竞技安卓下载从Variant 3F开始，我将列出我的步骤;我将使用LD05设置为2.8 V作为示例：
Register Breakdown:
I used the GUI with a standard I2C interface for read and write commands, I did not use any of its other functions or alter any other register value. I also tested all three ADC channels with different regulators and didnt have any issues.
Kind Regards,
Elliott Dexter
Hello Pierre-Olivier,
A potential reason why you might be getting ADC_RES_H and ADC_RES_L registers full of high bits (OxFF), is that the regulator you are trying to measure is not enabled. I re-tried the manual measurements with the regulator dis-enabled and got the same result as you, but when I enabled the regulator, the ADC measured the correct output voltage of the regulator.
Kind Regards,
Elliott Dexter
Hi Elliott
我终于发现了什么问题。
我用示波器探测了I2C行，发现我们在mon_reg_5和mon_reg_6上完成了我们完成的写操作。
I was actually using the
regmap_writefunction of the Linux Kernel. This function verifies that the register you try to write in actually exists.I don't know why, butthe DA9063 Linux Driver register ranges was NOT including MON_REG_5 and MON_REG_6.
I just extended the register range to MON_REG_6 and everything worked.
我ll maybe submit a patch to the Linux Driver once everything will be clean.
Thank you very much for the time you allocated to help me :-)
PinkPR
Hello Pierre-Olivier,
No problem, happy to help..
Kind Regards,
Elliott Dexter
嗨皮埃尔奥利弗，
I have spoken with the Driver applications team about your last question, response below:
"Since Linux mainline v3.16-rc1 the DA9063 Linux device driver has used the standard Linux regmap framework to access the PMIC’s registers.
Regmap is a common approach for register I/O and is typically used by device drivers within the Linux kernel to perform these standard access operations. However, regmap is different compared to other operating system I/O methods. Part of the differences is due to the use of register access permission tables which regmap uses to create a chip model.
DA9063设备驱动程序定义寄存器访问权限，以基于设备驱动程序内置的预定义表格列出所有可能的I2C访问DA9063 PMIC寄存器的访问权限。这些表格持有register -> {readable, writable, volatile}映射和静态定义的文件drivers/mfd/da9063-i2c.c. The Linux kernel regmap core I/O functions can therefore restrict any PMIC register accesses according to the permissions coded into these tables.
应注意。When adding new functionality in Linux device drivers which will use the Linux core regmap functions to access registers: the relevant regmap access tables should be updated accordingly. If adding a new component to an existing regmap enabled device driver, each bit in every new register to be accessed should be carefully considered when formulating the register's access permission entry. The reasons for using regmap are not just to enforce register access restrictions; performance improvements, default values and simplifications to suspend and resume operations are also part of the regmap design."
Kind regards,
Elliott Dexter