Hi, I did some initial booting of the latest Letux kernel. We again have no display but this time the backlight PWM is missing. Only the keyboard backlight PWM works. There are no reports from omapdrm about panel failures and X11 is starting.
Secondly, Tony has suggested a fix for some interrupt issue.
Applying his patch plus two more where I think he was referring to [1] makes the interrupt reports during initial boot go away. So I'll take this for 5.0-rc3.
There will be a new single report from pcal6524 that nobody cares about some interrupt. This is likely be the ts3a227 headset detection interrupt which was never working properly before.
And maybe have a look into the backlight issue. And maybe we can make the ts3a227 work better now.
BR, Nikolaus
[1]: 29ec027f335f (HEAD -> work-regmap-irq) regmap-irq: do not write mask register if mask_base is zero dc657b4e5398 regmap: regmap-irq: silently ignore unsupported type settings c7551981ac24 ARM: OMAP5+: Fix inverted nirq pin interrupts with irq_set_type 7ed965e3d926 (origin/letux-5.0-rc2, github/letux-5.0-rc2) Merge branch 'letux/omap5-idle' into letux-5.0-rc2
Hi Tony,
Am 16.01.2019 um 22:19 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi, I did some initial booting of the latest Letux kernel. We again have no display but this time the backlight PWM is missing. Only the keyboard backlight PWM works. There are no reports from omapdrm about panel failures and X11 is starting.
Secondly, Tony has suggested a fix for some interrupt issue.
Applying his patch plus two more where I think he was referring to [1] makes the interrupt reports during initial boot go away. So I'll take this for 5.0-rc3.
There will be a new single report from pcal6524 that nobody cares about some interrupt. This is likely be the ts3a227 headset detection interrupt which was never working properly before.
And maybe have a look into the backlight issue.
First result on changes for this:
There has been a significant rework of the omap5.dtsi.
THis has changed the DTB definitions of timers1..4 and 9..12 to use ti,sysc-omap4-timer while timer5..8 are still ti,omap5430-timer.
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
And maybe we can make the ts3a227 work better now.
BR, Nikolaus
[1]: 29ec027f335f (HEAD -> work-regmap-irq) regmap-irq: do not write mask register if mask_base is zero dc657b4e5398 regmap: regmap-irq: silently ignore unsupported type settings c7551981ac24 ARM: OMAP5+: Fix inverted nirq pin interrupts with irq_set_type 7ed965e3d926 (origin/letux-5.0-rc2, github/letux-5.0-rc2) Merge branch 'letux/omap5-idle' into letux-5.0-rc2
BR and thanks, Nikolaus
[2]:
root@letux:~# dmesg|fgrep backlight [ 5.517680] pwm-backlight keyboard-backlight: keyboard-backlight supply power not found, using dummy regulator [ 5.538792] pwm-backlight keyboard-backlight: Linked as a consumer to regulator.0 [ 5.674258] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 5.700572] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 5.717573] pwm-backlight backlight: Dropping the link to regulator.0 [ 5.772733] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 5.781804] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 5.790023] pwm-backlight backlight: Dropping the link to regulator.0 [ 5.843633] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 5.873626] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 5.890691] pwm-backlight backlight: Dropping the link to regulator.0 [ 5.929008] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 5.945003] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 5.954180] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.011288] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.029750] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.038994] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.095427] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.106264] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.115262] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.302004] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.311499] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.323951] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.592987] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.618723] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.625933] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.781206] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.790891] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.801874] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.870237] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.880857] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.888541] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.917594] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 6.926802] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 6.934109] pwm-backlight backlight: Dropping the link to regulator.0 [ 6.994053] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 7.003249] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 7.010398] pwm-backlight backlight: Dropping the link to regulator.0 [ 7.120567] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 7.142695] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 7.142914] pwm-backlight backlight: Dropping the link to regulator.0 [ 7.488049] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 7.497051] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 7.504288] pwm-backlight backlight: Dropping the link to regulator.0 [ 33.311153] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 33.320514] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 33.334458] pwm-backlight backlight: Dropping the link to regulator.0 [ 33.779150] pwm-backlight backlight: backlight supply power not found, using dummy regulator [ 33.789005] pwm-backlight backlight: Linked as a consumer to regulator.0 [ 33.796810] pwm-backlight backlight: Dropping the link to regulator.0 root@letux:~# ls -l /sys/class/backlight/ total 0 lrwxrwxrwx 1 root root 0 Jan 17 11:04 keyboard-backlight -> ../../devices/platform/keyboard-backlight/backlight/keyboard-backlight root@letux:~# lsmod | fgrep pwm pwm_omap_dmtimer 16384 1 pwm_bl 16384 0 root@letux:~#
* H. Nikolaus Schaller hns@goldelico.com [190117 11:07]:
Hi Tony,
Am 16.01.2019 um 22:19 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi, I did some initial booting of the latest Letux kernel. We again have no display but this time the backlight PWM is missing. Only the keyboard backlight PWM works. There are no reports from omapdrm about panel failures and X11 is starting.
Secondly, Tony has suggested a fix for some interrupt issue.
Applying his patch plus two more where I think he was referring to [1] makes the interrupt reports during initial boot go away. So I'll take this for 5.0-rc3.
There will be a new single report from pcal6524 that nobody cares about some interrupt. This is likely be the ts3a227 headset detection interrupt which was never working properly before.
And maybe have a look into the backlight issue.
First result on changes for this:
There has been a significant rework of the omap5.dtsi.
THis has changed the DTB definitions of timers1..4 and 9..12 to use ti,sysc-omap4-timer while timer5..8 are still ti,omap5430-timer.
Yes the ABE changes still need a bit more work for mcpdm clock.
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Oops sorry about that.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
I need to look. Sounds like there might be some optional clock missing in the dts. I'll take a look.
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
OK
Regards,
Tony
* Tony Lindgren tony@atomide.com [190117 14:28]:
- H. Nikolaus Schaller hns@goldelico.com [190117 11:07]:
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Oops sorry about that.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
I need to look. Sounds like there might be some optional clock missing in the dts. I'll take a look.
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
Adding Tero and linux-omap to Cc.
Nikolaus, care to try the below patch with also timer9 configured in your board specific dts file depending what the timer source clock should be:
&timer9 { assigned-clocks = <&l4_per_clkctrl OMAP5_TIMER9_CLKCTRL 24>; assigned-clock-parents = <&sys_clkin>; };
If that works you might as well configure it for timer8 too for future :)
Earlier we had TIMER9_CLKCTRL bit 0 have TIMER9_CLKCTRL bit 24 as it's parent. But I think we actually have bit 0 as the module clock and bit 24 as the timer functional clock. So bit 24 is not a parent of bit 0.
Tero can you check the above assumption?
If that's not the case then we need more patching..
Regards,
Tony
8< ---------------- diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c --- a/drivers/clocksource/timer-ti-dm.c +++ b/drivers/clocksource/timer-ti-dm.c @@ -154,6 +154,10 @@ static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer) if (IS_ERR(parent)) return -ENODEV;
+ /* Bail out if both clocks point to fck */ + if (clk_is_match(parent, timer->fclk)) + return 0; + ret = clk_set_parent(timer->fclk, parent); if (ret < 0) pr_err("%s: failed to set parent\n", __func__);
On Fri, 18 Jan 2019 12:01:43 -0800 Tony Lindgren tony@atomide.com wrote:
- Tony Lindgren tony@atomide.com [190117 14:28]:
- H. Nikolaus Schaller hns@goldelico.com [190117 11:07]:
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Oops sorry about that.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
I need to look. Sounds like there might be some optional clock missing in the dts. I'll take a look.
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
Adding Tero and linux-omap to Cc.
Nikolaus, care to try the below patch with also timer9 configured in your board specific dts file depending what the timer source clock should be:
&timer9 { assigned-clocks = <&l4_per_clkctrl OMAP5_TIMER9_CLKCTRL 24>; assigned-clock-parents = <&sys_clkin>; };
diff --git a/arch/arm/boot/dts/pyra-display.dtsi b/arch/arm/boot/dts/pyra-display.dtsi index b219b2961020..9fc793785b89 100644 --- a/arch/arm/boot/dts/pyra-display.dtsi +++ b/arch/arm/boot/dts/pyra-display.dtsi @@ -249,6 +249,11 @@ /* set to e.g. 8300 if display uses a TPS6116x instead of TPS61040 (which is limited to 500 Hz PWM) */ #define BACKLIGHT_FREQ_HZ 83
+&timer9 { + assigned-clocks = <&l4per_clkctrl OMAP5_TIMER9_CLKCTRL 24>; + assigned-clock-parents = <&sys_clkin>; +}; + / { backlight: backlight { compatible = "pwm-backlight";
together with the patch sheds light literally on this issue.
If that works you might as well configure it for timer8 too for future :)
Earlier we had TIMER9_CLKCTRL bit 0 have TIMER9_CLKCTRL bit 24 as it's parent. But I think we actually have bit 0 as the module clock and bit 24 as the timer functional clock. So bit 24 is not a parent of bit 0.
Tero can you check the above assumption?
If that's not the case then we need more patching..
Regards,
Tony
8< ---------------- diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c --- a/drivers/clocksource/timer-ti-dm.c +++ b/drivers/clocksource/timer-ti-dm.c @@ -154,6 +154,10 @@ static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer) if (IS_ERR(parent)) return -ENODEV;
- /* Bail out if both clocks point to fck */
- if (clk_is_match(parent, timer->fclk))
return 0;- ret = clk_set_parent(timer->fclk, parent); if (ret < 0) pr_err("%s: failed to set parent\n", __func__);
Regards, Andreas PS nit: why we have l4_per_clkctrl on omap4 and l4per_clkctrl on omap5?
* Andreas Kemnade andreas@kemnade.info [190121 21:24]:
On Fri, 18 Jan 2019 12:01:43 -0800 Tony Lindgren tony@atomide.com wrote:
- Tony Lindgren tony@atomide.com [190117 14:28]:
- H. Nikolaus Schaller hns@goldelico.com [190117 11:07]:
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Oops sorry about that.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
I need to look. Sounds like there might be some optional clock missing in the dts. I'll take a look.
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
Adding Tero and linux-omap to Cc.
Nikolaus, care to try the below patch with also timer9 configured in your board specific dts file depending what the timer source clock should be:
&timer9 { assigned-clocks = <&l4_per_clkctrl OMAP5_TIMER9_CLKCTRL 24>; assigned-clock-parents = <&sys_clkin>; };
diff --git a/arch/arm/boot/dts/pyra-display.dtsi b/arch/arm/boot/dts/pyra-display.dtsi index b219b2961020..9fc793785b89 100644 --- a/arch/arm/boot/dts/pyra-display.dtsi +++ b/arch/arm/boot/dts/pyra-display.dtsi @@ -249,6 +249,11 @@ /* set to e.g. 8300 if display uses a TPS6116x instead of TPS61040 (which is limited to 500 Hz PWM) */ #define BACKLIGHT_FREQ_HZ 83
+&timer9 {
assigned-clocks = <&l4per_clkctrl OMAP5_TIMER9_CLKCTRL 24>;assigned-clock-parents = <&sys_clkin>;+};
/ { backlight: backlight { compatible = "pwm-backlight";
together with the patch sheds light literally on this issue.
OK good to hear.
If that works you might as well configure it for timer8 too for future :)
Earlier we had TIMER9_CLKCTRL bit 0 have TIMER9_CLKCTRL bit 24 as it's parent. But I think we actually have bit 0 as the module clock and bit 24 as the timer functional clock. So bit 24 is not a parent of bit 0.
Tero can you check the above assumption?
If that's not the case then we need more patching..
Regards,
Tony
8< ---------------- diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c --- a/drivers/clocksource/timer-ti-dm.c +++ b/drivers/clocksource/timer-ti-dm.c @@ -154,6 +154,10 @@ static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer) if (IS_ERR(parent)) return -ENODEV;
- /* Bail out if both clocks point to fck */
- if (clk_is_match(parent, timer->fclk))
return 0;- ret = clk_set_parent(timer->fclk, parent); if (ret < 0) pr_err("%s: failed to set parent\n", __func__);
Regards, Andreas PS nit: why we have l4_per_clkctrl on omap4 and l4per_clkctrl on omap5?
No idea.. Is that maybe to follow the TRM naming?
Regards,
Tony
On 21/01/2019 23:27, Tony Lindgren wrote:
- Andreas Kemnade andreas@kemnade.info [190121 21:24]:
On Fri, 18 Jan 2019 12:01:43 -0800 Tony Lindgren tony@atomide.com wrote:
- Tony Lindgren tony@atomide.com [190117 14:28]:
- H. Nikolaus Schaller hns@goldelico.com [190117 11:07]:
This seems to break dmtimer/pwm mode for timer9 which we use for driving display backlight while timer8 for keyboard backlight still works.
Oops sorry about that.
Is there an upcoming patch not yet merged in 5.0-rc2 or what makes the difference in 5.0 between timer8 and timer9?
I need to look. Sounds like there might be some optional clock missing in the dts. I'll take a look.
PS: the symptom is that we don't even see a /sys/class/backlight node for the display backlight [2].
Adding Tero and linux-omap to Cc.
Nikolaus, care to try the below patch with also timer9 configured in your board specific dts file depending what the timer source clock should be:
&timer9 { assigned-clocks = <&l4_per_clkctrl OMAP5_TIMER9_CLKCTRL 24>; assigned-clock-parents = <&sys_clkin>; };
diff --git a/arch/arm/boot/dts/pyra-display.dtsi b/arch/arm/boot/dts/pyra-display.dtsi index b219b2961020..9fc793785b89 100644 --- a/arch/arm/boot/dts/pyra-display.dtsi +++ b/arch/arm/boot/dts/pyra-display.dtsi @@ -249,6 +249,11 @@ /* set to e.g. 8300 if display uses a TPS6116x instead of TPS61040 (which is limited to 500 Hz PWM) */ #define BACKLIGHT_FREQ_HZ 83
+&timer9 {
assigned-clocks = <&l4per_clkctrl OMAP5_TIMER9_CLKCTRL 24>;assigned-clock-parents = <&sys_clkin>;+};
- / { backlight: backlight { compatible = "pwm-backlight";
together with the patch sheds light literally on this issue.
OK good to hear.
If that works you might as well configure it for timer8 too for future :)
Earlier we had TIMER9_CLKCTRL bit 0 have TIMER9_CLKCTRL bit 24 as it's parent. But I think we actually have bit 0 as the module clock and bit 24 as the timer functional clock. So bit 24 is not a parent of bit 0.
Tero can you check the above assumption?
If that's not the case then we need more patching..
Regards,
Tony
8< ---------------- diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c --- a/drivers/clocksource/timer-ti-dm.c +++ b/drivers/clocksource/timer-ti-dm.c @@ -154,6 +154,10 @@ static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer) if (IS_ERR(parent)) return -ENODEV;
- /* Bail out if both clocks point to fck */
- if (clk_is_match(parent, timer->fclk))
return 0;- ret = clk_set_parent(timer->fclk, parent); if (ret < 0) pr_err("%s: failed to set parent\n", __func__);
Regards, Andreas PS nit: why we have l4_per_clkctrl on omap4 and l4per_clkctrl on omap5?
No idea.. Is that maybe to follow the TRM naming?
Same reason why we have l4_per_clkdm vs. l4per_clkdm. Basically the hwmod codebase is autogenerated from design data, and for some reason the design team decided to rename the instance.
-Tero
Regards,
Tony
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
-
Andreas Kemnade -
H. Nikolaus Schaller -
Tero Kristo -
Tony Lindgren