Set necessary clocks automatically in pwm-bcm2835.c #1175
Comments
|
No support in current kernel, but it may be possible in later kernels. |
|
Seems this is being worked on (yay): http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-November/002499.html |
|
@gohai has your issue been resolved? If so, please close this issue. Thanks. |
|
@Ruffio No, this is still an issue on latest released Raspbian. Try this: set Expecting a 1 kHz period with a 50% duty cycle on GPIO18, but no:
CC @repk |
|
Hi @gohai , Sorry to dig an old issue. Have you solved this issue now ? It appears that this repository does not have an appropriate overlay for my PWM clock patches to work. You can find a proper overlay in #1533 (it uses GPIO19 but you can modify fragment@0 to set the appropriate function on GPIO18). |
|
@repk Thanks for your reply! This is still unresolved for me, but I will re-test shortly. Is the pwm-overlay.dts from the raspberrypi kernel not sufficient? (Based on the time this was last modified I presume that I was testing this version). |
|
No the current bcm2708 devicetree creates a fixed clock named "pwm" which prevent the "proper" pwm clock to be initialized. To workaround this, you can create a overlay that renames this fixed clock such as the one in #1533 , the pwm-overlay.dts does not do that. |
|
@repk I just finished building the latest downstream 4.4 kernel with the overlay you mentioned attached. But before I tried booting into it, I gave the stock kernel (and overlay) a try: and it worked. My previous test was on an earlier Raspbian distribution, this now is the September release with kernel 4.4.21-v7+. Perhaps Raspbian's new window manager initializes the audio subsystem? I am inclined to close this bug - @repk, this is not an issue with upstream kernels anyway, I presume? |
|
Ok nice to know that, and yes this should not be an issue with upstream kernels that use different device tree. |
|
@repk I'll double check this in the coming days with the latest vanilla Raspbian and a logic analyzer, and will close the issue then. Great that upstream is unaffected in any way! |
|
@repk This is confirmed fixed (tested with vanilla Raspbian, which has 4.4.34-v7+ kernel, and no other overlays besides |
|
May I ask what is the default duty_cycle? Is there any way to change default value for boot? |
…right screen edge As described in the WA on GLK and CNL planes on the right edge of the screen that have less than 4 pixels visible from the beginning of the plane to the edge of the screen can cause FIFO underflow and display corruption. On GLK/CNL I could trigger the problem only if the plane was at the same time also aligned to the top edge of the screen (after clipping) and there were exactly 2 pixels visible from the start of the plane to the right edge of the screen (so couldn't trigger it with 1 or 3 pixels visible). Nevertheless, to be sure, I also applied the WA for these cases. I also couldn't see any problem with the cursor plane and later Art confirmed that it's not affected, so the WA is applied only for the other plane types. v2: - Use -ERANGE instead of -EINVAL. (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
While running the kms_plane clipping test I noticed a similar problem to the one described in Display WA raspberrypi#1175. In this case, similarly for planes other than the cursor, with 1 or 3 pixels visible from the left edge of the screen to the end of the plane and an odd plane X offset used for clipping causes the same kind of underflow and display corruption as described for WA raspberrypi#1175. Fix this in a similar way as that WA rejecting planes ending <4 pixels from the left screen edge. v2: - Rebase on v2 of patch 1/1. Testcase: igt/kms_plane/plane-clipping-pipe-*-planes Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Right now (Raspbian Jessie) it is necessary to make use of the audio output, e.g. by running
omxplayer example.mp3, before the PMW functionality can be used. With clocks-audio queued for 4.4, and RPi Upstreaming, would it be possible to remove this requirement and setup the clocks directly from the driver?(#1100 added the DT overlays for PWM)
The text was updated successfully, but these errors were encountered: