 Okay. I think I'll get started. It's two minutes past 11.30. So, hi. I'm Kirti Jagdish. I work for Texas Instruments and that's my introduction. So, today I'm going to talk about PMIC, the first one to turn on and the last one to turn off. So, before I get started with my presentation, let me give you a brief agenda of today's presentation. I'll be talking about introduction to PMIC and then why do we need PMIC, main components of PMIC and then I'll give a brief overview about the Linux regulator framework, like how do we register that driver to the Linux regulator framework, then followed with the types of regulators. And I'll also subsequently speak about other components of PMIC, like the GPO driver, RTC driver, and then I'll get on to the I2C debugging on Uboot, followed by I2C debugging on Kernel, and then some hardware specific debug. So, that's the brief agenda that I plan to present today. Okay. So, let me get started. So, introduction to PMIC. So, what is PMIC or say PMIC? It's a power management integrated circuit. So, the most basic responsibility of the PMIC is to provide voltage sources to the SOC or the system on chip. So, it's a separate IC, sits outside the SOC, generally, and it talks to the actual SOC using I2C or SPI protocol. PMIC is most commonly used in a space crunch places like mobile devices, portable players, these days even automotive and industrial systems. So, the primary responsibility being implementing the power off and power on sequences and actually providing the voltage sources. So, there are multiple types of power supplies or the regulators, LDOs, SMPS, and DC-DC converters. So, most PMICs generally contain more than just the regulators. They even contain IDCs, GPIOs, some RTC, watchdog, even thermal support. So, some of the more complex PMICs even provide battery charging support. So, that's a quick introduction about PMIC. So, why do we need PMIC? It's basically a one stop solution where it contains multiple regulators, all the granular power supplies that are needed to actually boot up an SOC. So, even when there are multiple regulators, there is a granular control that one can actually turn on a particular regulator and the other regulators can be switched off and multiple regulators can be at multiple voltages. It even enables a very deep power management as in we can actually gate few regulators and have some of them on. And even on top of regulators, the PMIC even has ADCs, GPIOs and RTCs. ADC can be used to keep track of the vital power supplies and the current temperatures and current amperes. The thermal sensor can be used to monitor the device temperature and the RTC helps to keep track of the real-time clock. In case the SOC needs to be turned on and if the PMIC has the coin cell battery which is battery powered, the real-time clock can keep running and we have the same time after reboots. So, there's a quick example of a simple PMIC to start off with. It's TPS65218. It's a TI part, TI PMIC. We are using it to power up our AM437X family of SOCs. So, we can see that there are quite a bunch of DC-DC converters. There are about four DC-DC converters feeding to core MPU and analog domains and there is one LDO which feeds to some analog part and there are about other things like battery, backup battery stuff and some GPIOs. So, it's a pretty simple PMIC that powers up a single core processor. So, let us move on to a more complicated PMIC. So, this is TPS659039. It's the TI Palmas PMIC family. So, we can see that there are a bunch of LDOs and there are a bunch of SMPS on the right side and there are a bunch of LDOs on the left side. Just note down the current values here. All the LDOs are of the order of milliampere and the SMPS are mostly around ampere range in the 6 amp, 3 amp range and also see that there are some multi-phase regulators. So, these are there for a specific purpose basically. If the component needs, if are really like very power hungry and it needs a higher power, say the MPU which are like dual core or quad core processor, we generally power it up using the SMPS and if the component are like not so power hungry, something like MMC controller, they get powered up using LDOs. That's like the quick example of who needs what and yeah, there are there's a 12-bit GPADC with 12-bit GPADC with multiple channels on it. One can actually measure the critical voltage rails, runtime and even the current of that. There's RTC and there are multiple GPIOs and watchdog and whatnot. So, PMIC is the one which is actually powering up the system on chip or the actual host processor. So, who powers up the PMIC? Is it directly coming out from the DC voltage source? Actually, not. So, if you see this DRS7 is a dual core processor from TI itself, powered up by the TPS6 59039 family of PMICs. So, the input to the PMIC does not really come from the direct 12-volt input supply. It goes through one more layer of converters, the stepped-down converters. So, all it really depends is what is the input supply input voltage that is needed by the SMPS and the regulators. So, there is a 3.3 step-down converter and the 5-volt step-down converter. So, many of these SMPS are getting fed by the 3.3 volts supply and most of the other LDOs which need higher voltage are being fed by 5 volts. And we see that most of the SMPS are feeding into the power-hungry domains like the MPU domain, the DESP, the GPU domain. Since the SMPS are known to give out more amperes, they are chosen to provide the power-hungry domains. And the LDOs are really powering up some low power analog components and MMC and some low power peripherals. So, this is the quick overview of a power tree wherein how the voltage, input voltage from DC supply gets translated to the actual processor using it. So, now I have already explained about why different types of regulators are. So, LDO and SMPS are real basic two types wherein we use. LDO is a low dropout linear regulator. They are very simple and they are easy to regulate and they create very little noise. And it requires really no capacitor or an inductor that really stores no charge. So, it is kind of more suited for low power. As we saw, it generates about a few hundreds of milliamps. So, one problem with LDOs is that it creates excessive heat and it leads to reliability issue. The biggest advantage is that it gives out a very, very, very accurate output voltage. On the other hand, SMPSs are very popular these days because they are known for their high throughput and they store charge in either through capacitor or an inductor and repetitively they switch off and on that transistor. So, it is low heat levels and SMPSs are typically very high efficiency out of the order of 80%. So, it's sort of high cost and complex design. So, we need to have a tradeoff wherein what how many SMPSs was as how many LDOs we choose in a PMIC. So, and the disadvantage over LDO is that SMPSs can create high levels of noise and decrease the accuracy of output voltage, though it's not really like that bad accuracy. And SMPSs are generally used for high power applications like how we saw here in this powdery. Okay, now let's get on to the actual Linux modeling. So, since PMIC has so many components like regulators, RTC and what not. The most natural choice is multifunction device. So, we modulate using a multifunction driver. It's multifunction driven as it creates multiple things. So, most certainly they have regulators. So, we need regulator drivers and some of them talk to the SOC, the host SOC through some GPO signal. So, they do have a GPO driver and some of them host RTC. So, we have RTC driver. So, there are multiple other drivers. So, for today's segment I've covered about these three, four drivers. So, MFD is the top level driver which kind of initializes the entire PMIC. So, starting off with the reg map. So, if the PMIC is talking to the host SOC using a I2C protocol, so we have a DevM reg map in it for I2C for the entire PMIC reg map to do basic I2C read and write. It registers the top level interrupt handler which actually interrupts the host processor. There can be multiple sources from the PMIC which interrupts the host processor. It can be a thermal event or a voltage or protection sort of event or a GPODC event or an RTC event. So, the MFD driver registers a top level interrupt handler. It enables probing of the child devices using MFD add devices. And it performs any PMIC specific pad settings and any variant specific support. So, if you look at the device tree modeling, TIV associates most likely communicate with the host processor using the I2C protocol under an I2C bus. So, I2C is the parent of the MFD device, MFD divestree node. So, you can see that I've just copied the upstream divestree file. So, TPI 6528 is the PMIC that we are talking about. So, the reg is the slave ID of the PMIC where it sits on the I2C bus. So, 24 is the reg ID, the compatible and the top level interrupt that actually hits the SOC. And yeah, just a regulator node. Let's quickly move on to the regulated driver nuances. So, every regulator gets registered to the Linux framework with the DevM regulator register. There are obviously the non-DevM. The preferred one is the DevM regulator register because it takes care of the cleanup as well. So, most regulator drivers populate the enable, disable hooks to disable or to turn on or turn off the regulators. Then they populate get set voltage to basically program the voltage to which you want the regulator to give the desired output voltage. One can also get the current limit hooks. And so, we make use of regulator linear ranges. This is the most commonly used practice wherein we define the range of voltage levels. So, PMIC need not be like the, there will be multiple ranges wherein the PMIC, the voltage regulator can actually generate the voltages for. So, we use regulator linear ranges for that. And one more interesting ops is set RAM delay. This is to take care of the slew rate because the hardware essentially cannot really jump up or jump down the voltage within no time. So, it takes about an hour or a few microseconds to get the actual desired output. So, this set RAM delay is very important to give up some time to give some delay before we actually assume that the output voltage is at the desired level. So, there are multiple types of regulators that are modeled in Linux. The most simplest of them being fixed regulators wherein it continuously gives out a fixed voltage and the only thing that we can do is probably turn it on and turn it off. And coming on, the more complex variety is the variable DC-DC regulators, SMPS and LDO regulators wherein the variable regulators cater to a wide range of voltages and they have fixed number of steps to reach from one voltage to another voltage. So, variable voltage is desired when we want something like DVFS that is the dynamic voltage frequency scaling. That's a power management feature wherein we, based on the demand, we kind of operate the device at a particular voltage frequency combination. And it also enables us to attain low power modes. So, variable regulators are also used as cooling agents in thermal framework. And coming on, okay, there's one more category wherein the GPOs also can be modeled as regulators. Some of them have the ability to give out voltage. So, GPO regulators are generally two phase wherein the high level and low level map to different values of voltages. So, I've given some of the device tree nodes wherein the DC-DC is the variable supply. So, we can see that the minimum microvolts and maximum microvolts are populated and the regulator framework takes care of actually giving or setting the voltage under this range. And there are some multiple device tree properties that tell the actual property of, that describe the actual regulator. Buton means that regulator was already on, even before Linux came up. Regulator always on means that this regulator needs to be always on till the SOC is powered up. So, here is an example of sort of fixed regulator wherein minimum and maximum are the same. So, basically it's a one voltage value and either it gets turned on or turned off. But since it is marked as regulator always on, it's not always on regulator. Here's a quick example of GPO regulator node. Basically, there's a different min and max values. These are the values that it maps to when the GPO, say GPO is held in low state, it gives out 1.8 volts and when it's in the high state it goes about 3.3 volts. So, along with regulators, we even support GPO drivers, some of them have GPO. So, we use DevM GPO chip add data to configure it with, registered with the GPO framework. So, basic GPO functionalities are all the same. So, it gets direction to either configure it as input or output. GPO set get values to get the GPO level. And we can also originally have GPO request and free to do optional chip specific activation and deactivation, such as enabling or disabling the power and clock. And set multiple assigned multiple values for multiple signals at the same time. So, this is a quick GPO device tree node. Again, I've used the Palmas GPO node that is the TPS659038 node. So, since it gives out multiple GPOs, it acts as a GPO controller and gives out two GPO cells for the consumer. So, the consumer being GPO fan has models. The GPO parent has the Palmas GPO with the second GPO initialized at active high. And this actually is a cooling device that is mapping the high level to zero cooling and so the low level to the zero cooling and the high level to the 13,000 RPM GPO fan. I'll also talk about RTC driver. Basically, it's a real-time clock used to continuously monitor time. So, we register with the RTC framework with the Linux framework using DevM RTC device register, populates the basic read time, get time, set time ops. And even the RTC can even generate real-time alarms. So, we have the read alarm, set alarm and alarm IRQ enable ops. Yeah, that's pretty much. And it of course registered the RTC interrupts using a DevM requested IRQ. Yeah, this is one of the I2C again under Palmas node, which tells, which is actually having the TPS 61038 RTC. Again, that can generate some alarm events, so interrupt has been registered here. Okay, so let's quickly move on to Deepak. Now that we are done with a couple of bunch of drivers in PMIC. So, UBoot and Kernel prints to start off to debug any of the PMIC issue. At least more than 50% of them you could actually start off debugging, start off adding some prints to the UBoot and Kernel and you will be done with it. On top of that, we even have CISFS hooks in the kernel. One can use CIS class regulators for the regulators, CIS class, GPIO for GPIO, CIS class RTC for RTC. So, I'm talking more about regulators today. So, CIS class regulators will have entries for microvolts, which gives out the actual output voltage that a regulator is giving out and state tells whether the regulator is either on or off, microamps gives out the current that is being drawn. There are multiple other CISFS nodes, one can go and actually explore CIS class regulators' star. And in UBoot, if you have to talk about UBoot infrastructure, once you get to the UBoot prompt, if you have enabled config CMD regulator in UBoot, you can actually get the details like how we get in kernel similar to that using GPIO regulator commands. Okay. So, this is about the basic debugging infrastructure with kernel CISFS and prints. Moving on to more involved I2C debug tools. In UBoot, we have the I2C debugging using some command I2C, one should enable CMD I2C. So, one should first assign the I2C device that on which the, this is on which the PMIC sets. So, this is basically the bus number of the I2C bus number on which the PMIC sets on. So, we assign that using I2C dev zero command, say, if the PMIC is sitting on the I2C bus zero. One can dump the I2C registers of a particular slave ID using I2C MD with the slave ID, say, 0x558.24, whatever is the slave ID of the PMIC, one can actually dump all the registers. And one can modify the registers using I2C MW or basically memory write or memory modify, MD is for memory dump. So, yeah, this is one quick example wherein I assign the I2C device to zero and then I dump out the registers starting from 20. So, there are about 16 registers that I've dumped. And then I want to change the 23rd register and I want to set it to 3B instead of 3A. And that's how I use I2C MW to do that. And I can use I2C MD to actually verify that indeed happened. So, this is where that's actually reflected. And one can actually use I2C speed to check the I2C bus speed in UBoot. Moving on to kernel I2C debug tools. We have I2C dump, I2C get a bunch of I2C tools, which we can use on top of the other tools. So, we can actually directly read the I2C registers of the PMIC. So, I2C dump minus F stands for forced because we are actually forcing from the user space to read out or to write out the I2C registers even though kernel driver is actually owning it. So, minus F stands for forced and minus Y is non-interactive wherein you actually go and set it without even the kernel actually asking you to whether it should be setting or not. So, one should use it with utmost care because you can actually write to some regulator output value which is far more than what is expected and you can burn out the thing. So, one has to use this carefully. So, I2C dump gives out the entire register layout for that particular slave ID. Zero is the bus, the I2C bus number and the I0X58 is the slave ID. That's the format. I2C dump minus F minus Y with the I2C bus number and the I2C slave ID. Output is something like this. It actually dumps out the whole register layout of that particular slave ID and then we have I2C get to get the particular registers or register value. I2C set can be used to, you know, write it. It's similar to the UBoot memory modify memory write wherein we can actually specify which address and what needs to be written and we can write to that particular address of that I2C. So, I2C dump we can actually see that it's reflected with the right value, what we were intending to write. But again, I'll say one should use this with utmost care because this is real-time regulators or some things which can get messed up if you use directly with this. So, these are all the tools which help you when the system is alive and the Linux is up and UBoot is up. And so, before I actually, so once we have the system, we can use this but say if there is a random crash or a random hang, we really need to get into hardware. So, before we get into that, so I give a, I just give a brief I2C protocol fundamentals. So, there are basically two lines. One is the clock line and the other one is data line. So, SDA is the synchronous data line and SLA synchronous clock. So, I2C protocol is pretty simple. So, the start is when the master pulls out the SDA low line with a low with SEL at high. So, basically clock is high and the data line is pulled out. This marks the start of a I2C transaction. And there are about, I'm using a simple seven-bit addressing. So, there are seven address bits, A6 to A0, which is basically the slave ID, most likely. And the, there's a read-write bit. So, the bit 8 stands for read-write bit. If it is a read, then it's high. And if it is right, then it's a low. Followed by a ACNAC. So, basically, the receiving device pulls the data line low. In the ninth, if the receiving data pull, receiving device pulls the data line low. In the ninth bit, it means that the device has actually act. Otherwise, it's an ACNAC. And followed with it is multiple data frames. So, the data frames can be generated by either the slave or the master, depending on whether it's a read or write operation. And then we have the final stop, which says, okay, the transaction is now finished. So, stop condition is basically zero one of the data line followed by a zero one, following a zero one. Basically, the clock line transitions from high to low to high. And after that, the data line does that same thing. So, that's the stop bit. So, I hope I'm clear about the I2C protocol fundamentals. So, I explained this as a precursor to one of the hardware debug that I did. So, here is a quick capture of... So, the green line represents the data. And the yellow line is the clock line. It's not really good resolution, but yeah, I can still interpret this thing. So, this is... I'm showing a quick example of I2C write, a sequence followed by ACNAC. So, you can see that the start bit is here, where in the data line is pulled low when the clock is high, followed by the slave ID, which is basically the address bits, seven-bit addressing. So, 58 till here. And then since it's a write operation, the data line is held low. And then we have an ACC, where in the data line is pulled low. And then followed by some write data, basically 23, and then we have a stop bit. So, why am I showing this? This is a proper write transaction. But let us go to the buggy transaction for I2C. So, we see here that the start went through well, and then there's a slave ID, and that is basically 58x. So, 101 followed by 1,000. And then it was held high, so basically it was a read transaction. As soon as the read bit is done, the ninth clock never went low for data line, which means there was a knack. So, this is where the hardware is probably faulty for any multiple reason. Most likely, if the I2C clock is really high, and if the slave device is not able to cope up, we generally tend to reduce the I2C clock frequency, that most of the time solves the problems. And this is a typical debug wherein we probe out the clock and data lines. Yeah. So, there's another good tool to use. It's called AdWag I2C protocol analyzer. Basically, we'll have to pull out the clock and data lines onto this device, small hardware, and connect it to a Windows PC or a Ubuntu PC. And then what it does is it actually snoops onto the I2C bus and it captures all the transactions that happen on that bus. So, it's a bus specific device wherein once you attach it, all the transactions of all the multiple slaves that are connected on that bus get captured. So, you can see that all of them are getting very nicely captured with what is the data, which type of transaction, etc. So, this is actually a precursor of the read bug which I actually found. So, there are basically matching things. I can actually match things like what happened in this transaction. Finally, we see that there was a read nag here. The same is being captured here as well. We see that the last read transaction actually never happened because there was no data that was received. So, this kind of helps us help it to snoop and get us what was really buggy at the hardware level. So, finally to summarize my debug. So, we don't need really a sledge hammer to break open the X. So, we can start off with simple prints, use the regulator framework, CISFS nodes, and only if the kernel is crashing or if there is a real hang where we have no control over it, we get to the multimeters and oscilloscopes. So, even the I2C protocol analyzer is a very useful tool for that kind of hardware debug. Thank you. Open for questions. What about PMICs with flashable firmware where you can do more stuff when the SoC goes into deep sleep? And when you want to wake it up, the PMIC needs to do the transitions for the supplies by itself. I'm asking if what you can tell us, maybe a bit about them, how you approach those types of PMICs. With the firmware? Yeah. I'm sorry, I've never really used that kind of PMICs with the firmware actually. I've used only with Linux drivers and stuff like that. Okay. I think this. Can you use the device tree, the device tree file you write for Linux, can you use them in Uboot? Yeah, I'm using the device tree in Uboot as well. We can use device tree in Uboot as well. Yeah. The same thing applies to kernel can be used in Uboot. The drivers are capable. Uboot framework is device tree ready. All right then. Thank you. Thank you for coming in. That's a big number. Thank you.