Interrupt and I2C read/write

The content to be written seems to have the title party's meaning.

In the morning, I received an email asking me to log in 860x_irq to see if the charger was plugged in. The final result is that no interruption is received. This problem is a bit tangled. There is no need to write anything. It is estimated that the hardware is defective.

In the morning, the server bought three hard disks and made a RAID 5. I extended the hard disk to the partition. The three 600 GB servers are changed to GB after raid. Fortunately, the/Work work partition was made into LVM during the last modification of the server. This expansion is much more convenient. Pvcreate, vgextend, and lvresize. They all went smoothly. There was a lot of important data in the partition, so I was afraid it would be broken. Several project managers had to cut me down again. So I threw the partition to umount, and then made resize2fs to prevent me from resize. It was said that the device was busy and I was puzzled. I almost restarted the server, later, I tried to mount the partition and used the online mode extension to find that I could. But the expansion of G is really a little slow. It takes about 10g a minute. But fortunately, I finally finished it, and made a sweat.

In the afternoon, I checked the setting of Interrupt registers on 8607. Use three interrupt registers, 0x [3-5], and each bit uses a mask to set an interrupt. Every one is 8 bits. There are also 24 interruptions. This is read and write using I2C. I was a bit confused when I was writing registers. When I was writing I2C, bulk_write made three bytes at a time. Then, a byte Reg address is added to the front to form an I2C transmission format, and then the i2c_message_send is used. At that time, I was dumb to think about how an 8-bit register could be when I had three registers at a time. Later, I looked at spec and asked my colleague again. He said that he could give an address and write it in the following order based on the address register. This seems to be awesome, and some of them support it, i'm not sure about this. But here we use two bulk_write statements and six bytes. We can set both 0x3-0x8 and six registers, which is really awesome.

Then SPEC also said the I2C communication format here, with a byte slave at the top. This is the default one. I am not sure about it. I will check it tomorrow, next, let's take a byte Register address, which is the data, and finally the stop mark. I2C looks really good. Check the code, get a Buf [bytes + 1], Buf [0] = reg, and get the register in. memcpy (& Buf [1], SRC, bytes ), the data is also involved. Then, use i2c_master_send (I2C, Buf, bytes + 1) and use I2C. This is also true for reg_write, except that bytes is 1. Well, the code should be in 88pm860x-i2c.c. In fact, the last time in the book looked at I2C communication, not very clear understanding, and then forget, next time still have to carefully look at the i2c-core.

During the afternoon's battery temperature protection, a tint and tbat played printk for a long time. here I used a gpadc1 pipe angle for temperature. The read data is the same as other registers, and a formula is used to create the unit of the music video, then an array is created to match the MV with the temperature. In my opinion, I should confirm with my hardware colleagues which temperature resistor is used to determine the voltage. This is a good thing.

When I smoked a cigarette today, I asked my hardware colleagues to understand the principle. When a thermistor got to the battery, the temperature and the resistance changed, I knew the temperature when I measured the voltage, it seems quite reasonable. It reminds me of a Yuxin project some time ago. They made two positive and negative poles for the battery, so they could not detect the temperature. This is a cup .. Haha.

Write a log. Haha. At night, I looked at the kernel email queue, too much, and I couldn't finish it. I 'd like to pick a few ..