03-11-2021, 04:13 PM
(This post was last modified: 03-14-2021, 02:56 PM by dsimic.
Edit Reason: Fixed a typo
)
My first proposal for the hardware fix would be to revert the backlight circuit changes introduced after the revision 1.0 of PinePhone.
Please, have a look at the attached couple of excerpts from the schematic of two PinePhone revisions, 1.0 and 1.2b. As a note, all post-1.0 revisions of the PinePhone are exactly the same when it comes to the backlight control circuit. For the sake of completeness, additional information is available in the Pine64 wiki.
Quite frankly, it makes very little sense to have the feedback of the AP3127B (datasheet) altered by the LCD backlight PWM signal (PH10-LCD-BL-EN), instead of simply driving the CE input of AP3127B with the backlight PWM signal, which is the intended way for using AP3127B. The post-1.0 backlight circuit actually treats the CE input of AP3128B as "chip enable", driving it with the separate PH10-LCD-BL-EN signal. However, the currently separate "blacklight enable" is the same as driving the CE input with a 0% PWM signal, which makes PH10-LCD-BL-EN redundant and the proposed hardware fix feasible.
Reverting the backlight circuit changes introduced in the post-1.0 revisions of the PinePhone would be fairly straightforward, but unfortunately may not be easily reversible back to the original PCB state. In more detail, one of the changes would require a pin of the AP3127B to be unsoldered and lifted, which is the step that would make the reversal troublesome.
It might be possible to leave the aforementioned pin in place, but (if possible at all) that would require significant changes to the DTS file, which would turn the whole hardware fix into a "fork" of the hardware and make the later software support troublesome. Also, it would make the hardware fix somewhat dangerous if the fixed phone is booted with the unmodified DTS file, because it would result in shorting two GPIO lines that both serve as power/signal outputs.
In short, the list of changes would be as follows:
1. Unsolder R1109, R1117, R1118, R1119, R1120, R1529 and C1110
2. Solder three 0R resistors in the places of R1117, R1118 and R1529
3. Solder a 10K resistor (already removed R1109 may be reused) in the place of C1110
4. Unsolder and lift the pin #4 (EN / CE) of the AP3127B
5. Solder a small piece of wire between the lifted pin #4 and the "left" pad of NC R1120
Of course, small "blobs" of solder may be placed instead of 0R resistors, which would make no new components required for the entire hardware fix. We can probably not count a small piece of wire as a new component.
Also, there should be no issues caused by the lack of available space.
Depending on the actual PCB layout, it may also be possible to avoid unsoldering and lifting of the pin #4 of AP3127B. Instead, it would be needed to cut a PCB trace, separating the PH10-LCD-BL-EN signal from the pin #4. A piece of wire would then be soldered between the "upper" pad of NC R1109 and the "left" pad of NC R1120, which may also look neater.
The DTS file may eventually need to be changed, to adjust the definition of brightness levels (i.e. the PWM duty cycles). That itself would not be difficult, but it would be much better if no changes would be required at all, so we don't end up with a "fork" of the PinePhone hardware. However, we would need to give the hardware fix a go, in order to determine the need for any changes to the DTS file.
Thoughts? Is there a way to make this simpler?
Edit: According to the source of the Linux kernel driver for the screen backlight and the backlight configuration documentation, the original, unchanged PinePhone DTS file could be used after applying the above-described hardware fix. This actually means that no new "fork" of the PinePhone hardware would be created by applying the proposed hardware fix, which is very good from the point of retaining software compatibility.
In more detail, the PinePhone DTS file expectedly contains the definition of the "enable-gpios" property, which is according to the post-1.0 backlight circuit. To turn the screen backlight off, the Linux kernel driver properly applies both 0% PWM duty cycle to the PWM control and drives the enable/disable GPIO line low. Turning the backlight on is done in a similar way, by applying a non-zero PWM duty cycle and driving the GPIO line high, which is again two separate actions.
In our case, those two separate actions are in fact the same thing, due to the way AP3127B works, so the "enable-gpios" property could be safely left unused (quite literally, dangling), while applying the PWM duty cycle would properly take care of everything.
Please, have a look at the attached couple of excerpts from the schematic of two PinePhone revisions, 1.0 and 1.2b. As a note, all post-1.0 revisions of the PinePhone are exactly the same when it comes to the backlight control circuit. For the sake of completeness, additional information is available in the Pine64 wiki.
Quite frankly, it makes very little sense to have the feedback of the AP3127B (datasheet) altered by the LCD backlight PWM signal (PH10-LCD-BL-EN), instead of simply driving the CE input of AP3127B with the backlight PWM signal, which is the intended way for using AP3127B. The post-1.0 backlight circuit actually treats the CE input of AP3128B as "chip enable", driving it with the separate PH10-LCD-BL-EN signal. However, the currently separate "blacklight enable" is the same as driving the CE input with a 0% PWM signal, which makes PH10-LCD-BL-EN redundant and the proposed hardware fix feasible.
Reverting the backlight circuit changes introduced in the post-1.0 revisions of the PinePhone would be fairly straightforward, but unfortunately may not be easily reversible back to the original PCB state. In more detail, one of the changes would require a pin of the AP3127B to be unsoldered and lifted, which is the step that would make the reversal troublesome.
It might be possible to leave the aforementioned pin in place, but (if possible at all) that would require significant changes to the DTS file, which would turn the whole hardware fix into a "fork" of the hardware and make the later software support troublesome. Also, it would make the hardware fix somewhat dangerous if the fixed phone is booted with the unmodified DTS file, because it would result in shorting two GPIO lines that both serve as power/signal outputs.
In short, the list of changes would be as follows:
1. Unsolder R1109, R1117, R1118, R1119, R1120, R1529 and C1110
2. Solder three 0R resistors in the places of R1117, R1118 and R1529
3. Solder a 10K resistor (already removed R1109 may be reused) in the place of C1110
4. Unsolder and lift the pin #4 (EN / CE) of the AP3127B
5. Solder a small piece of wire between the lifted pin #4 and the "left" pad of NC R1120
Of course, small "blobs" of solder may be placed instead of 0R resistors, which would make no new components required for the entire hardware fix. We can probably not count a small piece of wire as a new component.
Also, there should be no issues caused by the lack of available space.Depending on the actual PCB layout, it may also be possible to avoid unsoldering and lifting of the pin #4 of AP3127B. Instead, it would be needed to cut a PCB trace, separating the PH10-LCD-BL-EN signal from the pin #4. A piece of wire would then be soldered between the "upper" pad of NC R1109 and the "left" pad of NC R1120, which may also look neater.
The DTS file may eventually need to be changed, to adjust the definition of brightness levels (i.e. the PWM duty cycles). That itself would not be difficult, but it would be much better if no changes would be required at all, so we don't end up with a "fork" of the PinePhone hardware. However, we would need to give the hardware fix a go, in order to determine the need for any changes to the DTS file.
Thoughts? Is there a way to make this simpler?
Edit: According to the source of the Linux kernel driver for the screen backlight and the backlight configuration documentation, the original, unchanged PinePhone DTS file could be used after applying the above-described hardware fix. This actually means that no new "fork" of the PinePhone hardware would be created by applying the proposed hardware fix, which is very good from the point of retaining software compatibility.
In more detail, the PinePhone DTS file expectedly contains the definition of the "enable-gpios" property, which is according to the post-1.0 backlight circuit. To turn the screen backlight off, the Linux kernel driver properly applies both 0% PWM duty cycle to the PWM control and drives the enable/disable GPIO line low. Turning the backlight on is done in a similar way, by applying a non-zero PWM duty cycle and driving the GPIO line high, which is again two separate actions.
In our case, those two separate actions are in fact the same thing, due to the way AP3127B works, so the "enable-gpios" property could be safely left unused (quite literally, dangling), while applying the PWM duty cycle would properly take care of everything.
