Linux/DRA72: Issue with backlight levels

Michel,

Any updates?

Paul,

I don't see my answer to your question, strange indeed because I did respond to your question.

I do not use the TI SDK. We have a custom board with too many difference swith the EVM that it required a custom yocto tree. I first based it on automotive SDK 3.02. I later updated it with bbappend files to 3.03 except for the kernel and u-boot which have too much stuff that would break our system.
For example TI broke the eMMC access on the beagleboard X15, our eMMC is similar to that one. I will have to add my own patches to get eMMC to work. The original kernel 3.02 would not boot on 95% or our boards until I hardcoded the kernel mmc files to never allow switching below 3.0V. Our original boards had a hardware error with QSPI so booting on a uSD was necessary. Our supply for the uSD is fixed at 3.3V.
I had some Samsung uSD that would sometimes boot on some boards. The sandisk ones would not on any of them.

As we noticed with the scope the voltage was dropping for a short period and that is when the board would die. We spent several weeks blaming the hardware until I patched the kernel which fixed the problem.

I have two different yocto trees, one using arago and one using poky. Both have the same problem with the backlight.

What are the basic changes between the kernel in 3.02 and in 3.04 besides the eMMC and uSD parts?

Michel

ok, that clears things up a bit. So it is a custom board, and I assume the LCD and backlight are also not from the EVM.

Does the backlight driver datasheet say anything about such an issue? Can you manually excite teh LCD driver using different voltages and verify the behaviour?

Paul,

The LCD is from US Micro. It is using the same video port as used on the beagleboard X15. The video signal is converted to LVDS for the displays. We have two version, a 7 inch display and a 12 inch display.

To control the backlight I use ehrpwm0 on the DRA726, there is no backlight controller device used.

Apparently the PWM output is 100% between count 1 and 7

Michel

Michel,

I have no experience with DRA PWM module. Let me see if I can find a solution to your question

Michel,

Sorry to hear you have had issues with TI SDK.  Customers typically use eMMC for HS200 (192 MHz) operation, as a result the default voltage for eMMC is set to 1.8 V.  There are options --- as you have found --- in the board support files to customize the voltage support based on individual customer applications.

As for ePWM, please share your exact setup and how you are programming the registers to achieve the pulse width you desire.

Have a great day!

Best Regards,

Shiou Mei

Shiou Mei,

I do not do anything special, I haven't changed the driver for the PWM, just using the device tree to set the range and frequency. Where it differs from the EVM or beableboard X15 is that we use a GPIO to enable or disable the backlight.

Would the frequency choosen be an issue? If so what would be an acceptable range? It appears to wrap around when below 7. Earlier I wrote the count 1-7, it is actually 1-6 where it gets back to 100%.

I was going to check to see if I had the same problem on one of my own beagleboards X15 but then realized that only the TI EVM supports the TI LCD display. I had several EVM at ACTIA but the one not at a customer has been blown by a member of the software team.

I will need to adapt one of my own rootfs based on arago to support the TI LCD and try it out on the beagleboard X15 revB1 I have at ACTIA or one of my own boards at home. I will get let you know if I have the same results.



lcd_bl: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
pinctrl-0 = <&bl_pwm_pins>;

pwms = <&ehrpwm0 0 50000 0>;

enable-gpios = <&gpio6 6 GPIO_ACTIVE_HIGH>;

/* 0 to 255 */
brightness-levels =
<0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118
120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138
140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178
180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
220 221 222 223 224 225 226 227 228 229 230 231 233 232 234 234 236 237 238
240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255>;

default-brightness-level = <127>;
};

Michel Catudal
ACTIA Corp

Michel,

Please reduce the number of elements in the brightness-levels array and verify if the issue is still reproducible. I checked with the SW team and majority of the time dts file only has ~10 values listed under the array.

Have a great day!


Best Regards,
Shiou Mei

Shiou Mei,

It makes no difference. The problem is at low level. For regular customers that is not an issue but for military applications I need to be able to have the brightness very low.

In blackout mode we bring the brightness to the minimum, with the night viewing googles, the current lowest brightness, at 7 out of 255 is too bright. We have that working nicely with the boards with the Renesas processor but it is a problem with the ones with the TI processor.

Michel

Michel,

Can you probe the PWM output signals to measure the duty cycle for ratio values 0 - 6?  This will tell us exactly what the hardware is doing, and whether the PWM duty cycle is not changing or if the screen backlight is not reacting to the changes correctly.  

Best Regards,

Shiou Mei

Shiou Mei,

I checked the signal with a scope (OWON Smart DS7102V)

The backlight control device is a TPS61196. PWM1 to PWM6 are connected together to ehrpwm1A (G6)
There is a pulldown of 10k on the line.

Frequency is 19.92khz at 128 of 255 (50.4%)
Lowest duty cycle possible is a count of 7 of 255 (2.8%)

Count Duty cycle
0 0
1 98.0%
2 98.4%
3 98.8%
4 99.2%
5 99.6%
6 99.6%
7 2.8%
8 3.2%
249 98.0%
250 98.4%
251 98.8%
252 99.2%
253 99.2%
254 99.6%
255 99.6%

Michel Catudal
ACTIA Corp

Shiou Mei,

Everything seems to look perfect when running the tests except that the output duty cycles are not what they are supposed to be.

Any suggestions beside a hardware change?

Output are

1 98.0%
2 98.4%
3 98.8%
4 99.2%
5 99.6%
6 99.6%
7 2.8%
8 3.2%


Some printk in kernel

[ 89.080467] Duty cycle = 196 ns Period = 50000 ns
[ 89.085189] Period cycles = 6650 Duty Cycles = 26
[ 99.875939] The brightness is = 2 out of 255
[ 99.880232] Duty cycle = 392 ns Period = 50000 ns
[ 99.884953] Period cycles = 6650 Duty Cycles = 52
[ 103.617716] The brightness is = 3 out of 255
[ 103.622009] Duty cycle = 588 ns Period = 50000 ns
[ 103.637398] Period cycles = 6650 Duty Cycles = 78
[ 107.763432] The brightness is = 4 out of 255
[ 107.770130] Duty cycle = 784 ns Period = 50000 ns
[ 107.774860] Period cycles = 6650 Duty Cycles = 104
[ 111.311948] The brightness is = 5 out of 255
[ 111.318651] Duty cycle = 980 ns Period = 50000 ns
[ 111.323381] Period cycles = 6650 Duty Cycles = 130
[ 114.754884] The brightness is = 6 out of 255
[ 114.761612] Duty cycle = 1176 ns Period = 50000 ns
[ 114.774837] Period cycles = 6650 Duty Cycles = 156
[ 118.862192] The brightness is = 7 out of 255
[ 118.868845] Duty cycle = 1372 ns Period = 50000 ns
[ 118.873662] Period cycles = 6650 Duty Cycles = 182
[ 131.816543] The brightness is = 8 out of 255
[ 131.820835] Duty cycle = 1568 ns Period = 50000 ns
[ 131.836537] Period cycles = 6650 Duty Cycles = 208
[ 2038.579998] The brightness is = 1 out of 255
[ 2038.586699] Duty cycle = 196 ns Period = 50000 ns
[ 2038.599808] Period cycles = 6650 Duty Cycles = 26
[ 2079.892339] The brightness is = 2 out of 255
[ 2079.896632] Duty cycle = 392 ns Period = 50000 ns
[ 2079.912338] Period cycles = 6650 Duty Cycles = 52
[ 2107.238813] The brightness is = 3 out of 255
[ 2107.245507] Duty cycle = 588 ns Period = 50000 ns
[ 2107.258484] Period cycles = 6650 Duty Cycles = 78
[ 2128.489429] The brightness is = 4 out of 255
[ 2128.493722] Duty cycle = 784 ns Period = 50000 ns
[ 2128.509142] Period cycles = 6650 Duty Cycles = 104
[ 2169.847189] The brightness is = 5 out of 255
[ 2169.851490] Duty cycle = 980 ns Period = 50000 ns
[ 2169.856211] Period cycles = 6650 Duty Cycles = 130
[ 2200.029445] The brightness is = 6 out of 255
[ 2200.033737] Duty cycle = 1176 ns Period = 50000 ns
[ 2200.049685] Period cycles = 6650 Duty Cycles = 156
[ 2225.521466] The brightness is = 7 out of 255
[ 2225.528161] Duty cycle = 1372 ns Period = 50000 ns
[ 2225.532970] Period cycles = 6650 Duty Cycles = 182
[ 2262.452481] The brightness is = 8 out of 255
[ 2262.459162] Duty cycle = 1568 ns Period = 50000 ns
[ 2262.463971] Period cycles = 6650 Duty Cycles = 208
[ 2545.636505] The brightness is = 1 out of 255
[ 2545.643224] Duty cycle = 196 ns Period = 50000 ns
[ 2545.656300] Period cycles = 6650 Duty Cycles = 26
[ 2569.901393] The brightness is = 7 out of 255
[ 2569.905685] Duty cycle = 1372 ns Period = 50000 ns
[ 2569.921328] Period cycles = 6650 Duty Cycles = 182

Reading of registers

root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A600D0
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 1 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A6001A
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 2 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A60034
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 3 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A6004E
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 4 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A60068
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 5 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A60082
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 6 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A6009C
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 7 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A600B6
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 8 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e20a
000019FA
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e212
00A600D0
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e216
0000065A
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 1 >brightness
root@actia-dra726-12inch:/sys/class/backlight/backlight# omapconf read 0x4843e216
0000065A
root@actia-dra726-12inch:/sys/class/backlight/backlight# echo 7 >brightness


Michel Catudal
ACTIA Corp

Michel,

Our SW team tried to replicate your issue but did not see any problems with brightness values from 1~6 out of 255 when operated at the exact frequency as your setup.  LCD remained dark with very low back-light intensity.  The registers reads were:

EPWM_CMPA = 0x001A

EPWM_TBPRD = 0x19FA 

I noticed your EPWM_CMPA is reading back 0x00A6 009C.  This register is only supposed to be 16 bits wide.  Are you ORing the read result with 0x00A6 0000?  If not, can you make sure you are only writing 16 bits value to the register?  Moreover, have you checked with the LCD vendor to see if they have any limitations with low intensity back-light levels?

Have a great day!

Best Regards,

Shiou Mei

Shiou Mei,

I have not modified the pwm kernel driver in this test. I used the omapconf application to read the register.

Using a scope I see the signal going to a high pwm at the input of the TPS61196 device.

The US Micro LCD has no problem with low PWM value.


In light of what you are saying I patched the kernel functions to see if that would make any difference. It made no difference. Are there any other functions to look at?

diff -rNuw kernel-source/drivers/pwm/pwm-tiecap.c kernel-source-backlight/drivers/pwm/pwm-tiecap.c
--- kernel-source/drivers/pwm/pwm-tiecap.c 2018-10-01 13:45:58.786995327 -0400
+++ kernel-source-backlight/drivers/pwm/pwm-tiecap.c 2018-10-01 15:01:50.190499905 -0400
@@ -95,6 +95,9 @@

writew(reg_val, pc->mmio_base + ECCTL2);

+ duty_cycles &= 0xFFFF;
+ period_cycles &= 0xFFFF;
+
if (!pwm_is_enabled(pwm)) {
/* Update active registers if not running */
writel(duty_cycles, pc->mmio_base + CAP2);
@@ -266,8 +269,8 @@
static void ecap_pwm_save_context(struct ecap_pwm_chip *pc)
{
pc->ctx.ecctl2 = readw(pc->mmio_base + ECCTL2);
- pc->ctx.cap4 = readl(pc->mmio_base + CAP4);
- pc->ctx.cap3 = readl(pc->mmio_base + CAP3);
+ pc->ctx.cap4 = readl(pc->mmio_base + CAP4) & 0xFFFF;
+ pc->ctx.cap3 = readl(pc->mmio_base + CAP3) & 0xFFFF;
}

static void ecap_pwm_restore_context(struct ecap_pwm_chip *pc)
diff -rNuw kernel-source/drivers/pwm/pwm-tiehrpwm.c kernel-source-backlight/drivers/pwm/pwm-tiehrpwm.c
--- kernel-source/drivers/pwm/pwm-tiehrpwm.c 2018-10-01 13:45:58.786995327 -0400
+++ kernel-source-backlight/drivers/pwm/pwm-tiehrpwm.c 2018-10-01 13:48:44.032855341 -0400
@@ -312,7 +312,7 @@
/* Channel 0 configured with compare A register */
cmp_reg = CMPA;

- ehrpwm_write(pc->mmio_base, cmp_reg, duty_cycles);
+ ehrpwm_write(pc->mmio_base, cmp_reg, duty_cycles & 0xFFFF);

pm_runtime_put_sync(chip->dev);
return 0;



Michel

Michel, 

Is there a schematic you can share with us that shows the SoC to LCD connection?  Given we cannot replicate the issue on our end, hardware is the most likely cause of the phenomenon you are seeing.

Best Regards,

Shiou Mei 

Shiou Mei,

You will need to send me an EMAIL with your EMAIL address. I cannot send the schematic online. We do have an NDA with Texas Instruments thru our parent company in Toulouse France.

Michel Catudal
ACTIA Corp

Michel,

Before we check into board schematics, please test out the PWM outputs using a simple CCS project file. This will truly isolate Linux dependency and confirm whether the PWM modules can operate properly. The test should be simple: Update duty cycle value , check duty cycle on board, repeat.

How many boards have you tested this feature and how many boards have shown failure?


Best Regards,
Shiou Mei

Shiou Mei,

The values I had given was read with a scope at the input of the TPS61196 and not at the LCD. This means that Linux is messing up with the PWM.

All 7 inch and 12 inch display have the same issue. The board is the same for both LCD displays.
We ship close to 40 a week sometimes more.

Michel

Michel,

I have asked the SW team to sanity check the code you shared against our standard driver code and am waiting on the feedback. If the result indicates the two are the same, then that will point issue to the customized Linux fs you have. Could there be any functions accidentally updating the PWM registers, or disabling pinmux, causing the pin output to be unexpected?

Best Regards,
Shiou Mei

Shiou Mei,

I set the PWM in u-boot and in the device tree it is set not to reinitialize the PWM.
For u-boot I based my code on the TI-RTOS code provided to me by Venkat.

If I let Linux reinitialize the PWM there is a blank screen for several seconds when the kernel is being loaded and initialized which defeats the purpose of having a splash screen during boot.

My u-boot and kernel are those from TI-SDK 3.02 with our local patches. I have not updated to 3.04 kernel and u-boot because I didn't have time. The SDCARD support in TI's latest SDK would need to be patched again as I had to do with the older ones. Out of about 60 boards only 3 would boot. The problem had to do with the voltage going below 3.3V on certain devices which were the ones we were using.

Even on a newer yocto where I use Poky instead of arago I have the same issue. I do use a similar kernel for that one too. The board is different than our current production board as it has 5 CAN instead of 4, it has wifi and ethernet which our current production boards do not have.



Michel

Michel,

Here is a summary of SW team's feedback:

The kernel's eHRPWM driver expects all eHRPWM register values to be in reset defaults, otherwise behavior is unknown.  This means the programming model for eHRPWM may be different in u-boot compared to that of kernel.  For next steps, recommendation is to remove u-boot initialization of eHRPWM module and test the module only with pure kernel driver (i.e. without DT hacks to avoid Linux reinitialization) to rule out u-boot side effects.  

Let me know if you have any questions on the testing.

Best Regards,

Shiou Mei

Shiou Mei,

I will test that but be that cannot be used for our production. We would lose our major customer if we bring back a 2-3 seconds or longer black screen during power up. Having a splash screen from power up to the start of that application was a must and not negotiable.

One of the arguments was that we had no such issue with our Renesas ARM board. Switching to RTOS is not an option.

Michel

Shiou Mei,

I created a boot micro SD that has a u-boot without splash screen support and removed the support in the kernel for the splash screen.

The device tree is not the only thing about the display that is different. Basically we have two screen, during boot the normal screen is in the background. Once the application assumes that everything is OK, it brings the it's display to the foreground.

Backlight is correct then

My next step is to have the splash screen back and let linux reinit the pwm.

If the backlight is still correct then that will point to the difference between the two. If not then the problem is more complicated.

I cannot ship any board with a black screen during the boot process. This would be unacceptable for our customers.

Michel

Shiou Mei,

I got both u-boot and kernel same as before except that I commented out the call to set the backlight in u-boot and letting the kernel initialize the PWM. That worked as expected but with a black screen on startup.

I also tried leaving the setting of the PWM in u-boot and allowing the kernel to initialize the PWM, the problem existed then.


I get those that seem to last forever, after I shut the power and re-powered it worked OK,
What is with that? It is not related to the backlight problem but something that comes in once in a while.

[** ] A start job is running for dev-ttyS2.device ........

I am familiar with this annoying thing on SuSE and Fedora but that is usually related to it setting up the nvidia driver.

That is debug port

Michel

Vishal,

That is what I use. What I have explained is that in order not to have almost 100% backlight at range 1-6 of 255 I cannot have u-boot setting the PWM. If I do not do that my splash screen is not visible for 10-13 seconds.

Somehow u-boot and linux kernel handle the PWM differently and something gets messed up. The solution is not obvious. Even if I just let Linux reinitialize the PWM the problem doesn't go away, even if that would have worked it is not an acceptable solution for the customer since the screen would go black for 2-3 seconds.

Michel Catudal
ACTIA Corp

Vishal,

I did a few experiment and found a partial solution

Here is part of the code (after my comments) from TI-RTOS code that I used to set the pwm

Originally I had

#define APP_EHRPWM_OUT_FREQ (50U * 1000U)

and I tried different frequencies until it was acceptable

#define APP_EHRPWM_OUT_FREQ (325U * 1000U)


With 300 or 325 I get 1 out of 255 going to near 100%
2 out of 255 is very low but visible with night vision.

If I set to 350 it seems to go off at 1 but I can't get the backlight back on unless I reboot.

I could work with that and block the 1 to force to 2 in the linux device tree but would like to know what is the actual value that would make sense to use.

This is my entry in the linux device tree

pwms = <&ehrpwm0 0 50000 0>;




/* ========================================================================== */
/* Macros */
/* ========================================================================== */

/*
* Configurable parameters
*/
/**
* \brief PWM instance base address.
*
* Note: If changed to other instance, PRCM and pinmux changes needs to be
* taken care in the application.
*/
#define APP_EHRPWM_INST_BASE_ADDR (PWMSS1_IPWMSS_BASE)

/**
* \brief Output channel - A or B.
*
* Note: If changed to channel B, pinmux changes needs to be taken care
* in the application.
*/
#define APP_EHRPWM_OUTPUT_CH (EPWM_OUTPUT_CH_A)

/** \brief Frequency of PWM output signal in Hz - 325 KHz is selected */
#define APP_EHRPWM_OUT_FREQ (325U * 1000U)

/** \brief Duty Cycle of PWM output signal in % - give value from 0 to 100 */
#define APP_EHRPWM_DUTY_CYCLE (50U)

/**
* \brief Functional clock to the PWMSS.
* Fixed for the platform - can't be changed.
*/
#define SOC_EHRPWM_MODULE_FREQ (133U * 1000U * 1000U)

/** \brief TB frequency in Hz - so that /4 divider is used */
#define APP_EHRPWM_TB_FREQ (SOC_EHRPWM_MODULE_FREQ / 4U)

/**
* \brief PRD value - this determines the period
*
* PRD = (TBCLK/PWM FREQ) / 2
* NOTE: /2 is added becasue up&down counter is selected. So period is 2 times
*/
#define APP_EHRPWM_PRD_VAL ((APP_EHRPWM_TB_FREQ / APP_EHRPWM_OUT_FREQ) / 2U)
/**
* \brief COMPA value - this determines the duty cycle
*
* COMPA = (PRD - ((dutycycle * PRD) / 100)
*/
#define APP_EHRPWM_COMPA_VAL (APP_EHRPWM_PRD_VAL - ((APP_EHRPWM_DUTY_CYCLE * APP_EHRPWM_PRD_VAL) / 100U))







Michel Catudal
ACTIA Corp

Sriram,

Please provide the latest response on this thread.

Regards
Karthik

Karthik,

As I described in previous email, if I use those values and in the the device tree have 1 being the same as 2 it works the way we want so that issue should be seen as closed.

We cannot remove the PWM control in u-boot as it would give us a short black screen on boot which would be unacceptable to our customers. If TI has a version that would be more in line with what the kernel does and doesn't create a problem at the lowest non zero setting I would be willing to look at it.

Michel Catudal

ACTIA Corp