-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add overlay for Adafruit 1.8" TFT LCD on SPI1 with tinydrm st7735r #68
Conversation
This file was copied from src/arm/BB-SPIDEV1-00A0.dts and modified by Drew Fustini based on an exmample from David Lechner. This Adafruit 1.8" TFT LCD should be connected to SPI1 bus: https://www.adafruit.com/products/358 This overlay will load the inydrm st7735r driver by David Lechner: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/tinydrm/st7735r.c Tested with 4.16.0-rc2-bone3 kernel on Debian 9.3 image Run libdrm modetest for colorbar test based on instructions from: https://github.com/notro/tinydrm/wiki/Development#modetest modetest -M "st7735r" -c #this will display connector id modetest -M "st7735r" -s 28:128x160 #connector id and resolution Mailing list post with more information: https://groups.google.com/d/msg/beagleboard/GuMQIP_XCW0/b3lxbx_8AwAJ GitHub Gist with testing results: https://gist.github.com/pdp7/aee5664598059c9b9a9020f107957f80 Discussion with notro on how to test tinydrm driver: notro/tinydrm#1 (comment) Signed-off-by: Drew Fustini <drew@pdp7.com>
@RobertCNelson @dlech @notro I would appreciate any feedback on this device tree overlay for Adafruit 1.8" TFT LCD with tinydrm st7735r |
It would be useful to add some info on how to set up a backlight too, at least in the comments. You could give an example for both compatible = "gpio-backlight" and compatible="pwm-backlight". |
@pdp7 looks pretty good, replace this:
Which actually isn't utilized, with this:
That's needed for the rewrite.. (you'll have to increment the fragment #'s)
it's not used in the kernel anymore.. |
and make sure to declare these too:
as
and create a pinmux node, otherwise they'll get stolen by gpio-of-helper/cape-universal for userspace access with the rewrite i'm working on.. |
Add a fragment for ocp overlay and declare use of spi1, dc, and reset pins. Based on feedback from @RobertNelson in my pull request #68: #68 (comment) Signed-off-by: Drew Fustini <drew@pdp7.com>
Signed-off-by: Drew Fustini <drew@pdp7.com>
Add a fragment for ocp overlay and declare use of spi1, dc, and reset pins. Based on feedback from @RobertNelson in my pull request #68: #68 (comment) Signed-off-by: Drew Fustini <drew@pdp7.com>
and merged! thanks @pdp7 !!! |
@dlech @RobertCNelson I tried to configure a gpio backlight per David's suggestion, but it seems I haven't gotten it quite right. I added this to the dts file:
and Here is the full dts file: BB-LCD-ADAFRUIT-18-SPI1-00A0.dts However, the BeagleBone fails to boot. From the serial console:
Any ideas as to what I am doing wrong? Thanks! |
You need angle braces.
|
@dlech thanks. I made that change in syntax. The boot still failed with the same error. I looked at some of the other overlay files in the repo, and realized I probably needed to put the definition adafruitblacklight inside a fragment. I added:
And the BeagleBone then booted OK, and LCD correctly displays the console and the blacklight turns on. Here is the full dts file: BB-LCD-ADAFRUIT-18-SPI1-00A0.dts Any additional feedback? Thanks for you help @dlech! |
@dlech @RobertCNelson I'm looking into how to add PWM backlight to this overlay. Is this a good example from
|
I have tried adding pwm backlight. Here is the updated dts: However, I get this at bootup:
I connected the LCD lite pin to P9.14 but there is no backlight. |
This is what the output looks like when cape universal is active and set PWM output to P9_14. BB-LCD-ADAFRUIT-18-SPI1-00A0.dts is not loaded during this test.
|
This is normal. The reason the message shows more than once is probably because the driver probe is being deferred because some other device is not ready yet.
I've noticed that setting a duty cycle of 0 in DT tends to cause the PWM to not be initialized correctly. Try this:
Also, you are missing the
After you get it working, you may want to play with the brightness levels. 5 or 10 levels is plenty for me and usually, it needs to be non-linear so that the apparent brightness looks linear. |
@dlech Thanks for the suggestions. Here is the dts file for the overlay that I am using: I added some print statements in tinydrm code. dmesg when overlay has
dmesg when overlay has
Any ideas how I can make |
It looks like you have It looks to me like the GPIO backlight is working? |
Also, the GPIO backlight node doesn't have |
@dlech GPIO backlight control does work OK. I made the changes you suggested for PWM backlight: I added some pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm) && PTR_ERR(pb->pwm) != -EPROBE_DEFER && !node) {
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
}
if (IS_ERR(pb->pwm)) {
ret = PTR_ERR(pb->pwm); /******** LINE 328 ********/
if (ret != -EPROBE_DEFER)
dev_err(&pdev->dev, "unable to request PWM\n");
goto err_alloc;
} Any idea how I could troubleshoot further? Thanks! |
I think I mislead you earlier. I forgot there are 2 PWMs per EHRPWM, so the first parameter of the phandle is the index.
should be
if you are using EHRPWM1A (500000 is the value that should be non-zero, so it is OK) |
@dlech Thanks, I made that change to the overlay but the results are still the same. It seems the issue is still that this call fails in the probe: I'll have to dig deeper to try to learn why it fails. |
What is the error code that is returned? |
@dlech Thanks. I've added more print statements and
Here is the complete output related to the display and backlight:
|
It looks like the error is getting propagated as it should. I'm not sure why the driver is not getting probed again later. Is it possible that something like universal cape manager is tying up the PWM later in boot? |
@dlech It looks like the problem was that I was failing to activate epwmss1. I've added that now:
And the st7735r driver loads OK! |
cool beans |
@dlech Here is the dts overlay I am using for PWM backlight: While no errors appeared to occur, the pwm backlight would not turn on. I found the issue is with I found that the following would evaluated to true and thus set
I removed the above lines: diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1c2289ddd555..68c039614892 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -98,11 +98,6 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
int brightness = bl->props.brightness;
int duty_cycle;
- if (bl->props.power != FB_BLANK_UNBLANK ||
- bl->props.fb_blank != FB_BLANK_UNBLANK ||
- bl->props.state & BL_CORE_FBBLANK)
- brightness = 0;
-
if (pb->notify)
brightness = pb->notify(pb->dev, brightness); and the backlight does now turn on OK, and I can set brightness via It seems unlikely this is actually a bug in Any suggestions as to how to address this issue? Maybe I need to add something to |
Do you know which condition specifically is keeping it off? I wonder if you create an "always-on" regulator in device tree if that would help.
|
@dlech thanks, I will try that out. BTW, will you be at ELC next week? |
No, I won't sadly. I really enjoyed it last year and have been wishing I was going again. |
@dlech Thanks, I added the power regulator to It seems the issue is that pwm is not enabled when From
From
From
From
Here is the if statement with the values:
|
@dlech I'm looking at occurrences of Do you think think that needs to be done in st7735r driver? Here are some examples I was looking at within
|
@dlech I added Do you think this is a good approach? diff --git a/drivers/gpu/drm/tinydrm/st7735r.c b/drivers/gpu/drm/tinydrm/st7735r.c
index 98ff447f40b4..65e6cd4e801d 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -171,6 +171,7 @@ static int st7735r_probe(struct spi_device *spi)
mipi->backlight = tinydrm_of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
+ mipi->backlight->props.power = FB_BLANK_UNBLANK;
device_property_read_u32(dev, "rotation", &rotation);
Related dmesg output with printk()'s for debugging:
|
The backlight helper functions in tinydrm are gone now in linux-next. You could try to apply the 6 first patches in this series: Add backlight helper functions |
@notro thanks. I will apply the patch set and see if the result changes. In regards to /sys/class/backlight, I did write to the brightness file. Are there other files that I could try writing to? |
I was thinking of |
@notro thanks. The backlight does turn on when I set
Is the expectation that userspace will do this as needed and that the driver probe should not? |
No, the tinydrm driver should make sure the backlight turns on when the display pipeline is enabled. I mentioned it just as an aid in debugging the problem. |
Add defintion for PWM backlight control on Adafruit 1.8" TFT LCD. Connect lite pin on lcd to P9.14. Turn on backlight on by setting bl_power to 0 (FB_BLANK_UNBLACK): echo 0 > /sys/devices/platform/backlight_pwm/backlight/backlight_pwm/bl_power That value is specified in: https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight What: /sys/class/backlight/<backlight>/bl_power Date: April 2005 KernelVersion: 2.6.12 Contact: Richard Purdie <rpurdie@rpsys.net> Description: Control BACKLIGHT power, values are FB_BLANK_* from fb.h - FB_BLANK_UNBLANK (0) : power on. - FB_BLANK_POWERDOWN (4) : power off Thanks to @notro for the suggestion in PR #68 comment: #68 (comment) Signed-off-by: Drew Fustini <drew@pdp7.com>
@notro @dlech Thanks. Do you think I should create an issue in the tinydrm repo to further discuss a patch for st7735r driver? |
Starting a new issue sounds like a good idea since this PR has been merged. |
Summary
src/arm/BB-SPIDEV1-00A0.dts
and modified by Drew Fustini (@pdp7) based on an exmample from David Lechner (@dlech).Testing
Resources: