[linux-sunxi] Re: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
Hello Uwe, On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-König wrote: > > Hello Roman, > > On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Beránek wrote: > > Correct, the output may stay in an active state. I only discovered this > > bug as I investigated a report of unreliable screen timeout. The period > > we use the PWM with is 50 us. > > What I don't like here is that the delay is quite coarse and might still > be too short. (Maybe I miss something, but consider the current period > is quite long, then you configure a short one and then disable. In this > case the inital long setting might still be active.) The delay is calculated from the original period (cstate.period), not the one that was just written into PWM_CHx_PRD 2 lines above. > > Note: my apologies for the previous HTML message > > I didn't notice (because the message also contained a txt part). Another > thing to improve is to reply inline instead of top posting :-) Yeah, learning the conventions one reply at a time :-) Cheers, Roman -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAL8eAtqBzUt6fP2nr-Ppg%2BqwhvKWk13A0P3%2Bhoe07F%2B9VXCvmA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
Hello Uwe, Correct, the output may stay in an active state. I only discovered this bug as I investigated a report of unreliable screen timeout. The period we use the PWM with is 50 us. The PWMx_RDY bit stays 0 well after the last period ends, so if the bit has any function at all, this one is certainly not it. Cheers, Roman Note: my apologies for the previous HTML message On Wed, Apr 28, 2021 at 8:14 AM Uwe Kleine-König wrote: > > Hello Roman, > > On Wed, Apr 28, 2021 at 02:19:46AM +0200, Roman Beranek wrote: > > More often than not, a PWM period may span nowhere near as far > > as 1 jiffy, yet it still must be waited upon before the channel > > is disabled. > > I wonder what happens if you don't wait long enough. Is this a > theoretical issue, or do you see an (occasional?) breakage that is fixed > by this patch? > > I guess the problem is that if you disable too early the output freezes > and that might be in a state where the output is still active? Would > polling the PWMx_RDY bit in the control register help here? > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
Hello Uwe, Correct, the output may stay in an active state. I only discovered this bug as I investigated a report of unreliable screen timeout. The period we use the PWM with is 50 us. The PWMx_RDY bit stays 0 well after the last period ends, so if the bit has any function at all, this one is certainly not it. Cheers, Roman On Wed, Apr 28, 2021 at 8:14 AM Uwe Kleine-König < u.kleine-koe...@pengutronix.de> wrote: > Hello Roman, > > On Wed, Apr 28, 2021 at 02:19:46AM +0200, Roman Beranek wrote: > > More often than not, a PWM period may span nowhere near as far > > as 1 jiffy, yet it still must be waited upon before the channel > > is disabled. > > I wonder what happens if you don't wait long enough. Is this a > theoretical issue, or do you see an (occasional?) breakage that is fixed > by this patch? > > I guess the problem is that if you disable too early the output freezes > and that might be in a state where the output is still active? Would > polling the PWMx_RDY bit in the control register help here? > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAL8eAtopkMVmt8XDbzLRsJ_JgGNwZ-FgdNPOWkh-yboTqceUyw%40mail.gmail.com.
[linux-sunxi] Feasibility of using DE2 rotate core to rotate display output?
A good portion of LCD panels available on the market has a portrait orientation. Although the screen rotation can be performed in userspace, a system-wide solution would be much welcome. Seeing the DE2 rotate core be involved in the recently submitted media driver for rotating CSI camera input, a question comes to mind: is it feasible to write an alternative driver incorporating the core inside the DRM subsystem in order to facilitate screen rotation? Best Regards Roman -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/04c9fed8-e8f8-4e64-829c-e49b0db307ce%40googlegroups.com.
Re: [linux-sunxi] Re: [PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
On Wednesday, December 4, 2019 at 5:19:23 AM UTC+1, Vasily Khoruzhick wrote: > > On Mon, Jan 14, 2019 at 1:25 AM Marc Zyngier > wrote: > > > > Hi Samuel, > > Hi Samuel, > > > On 13/01/2019 02:17, Samuel Holland wrote: > > > The Allwinner A64 SoC is known[1] to have an unstable architectural > > > timer, which manifests itself most obviously in the time jumping > forward > > > a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a > > > timer frequency of 24 MHz, implying that the time went slightly > backward > > > (and this was interpreted by the kernel as it jumping forward and > > > wrapping around past the epoch). > > > > > > Investigation revealed instability in the low bits of CNTVCT at the > > > point a high bit rolls over. This leads to power-of-two cycle forward > > > and backward jumps. (Testing shows that forward jumps are about twice > as > > > likely as backward jumps.) Since the counter value returns to normal > > > after an indeterminate read, each "jump" really consists of both a > > > forward and backward jump from the software perspective. > > > > > > Unless the kernel is trapping CNTVCT reads, a userspace program is > able > > > to read the register in a loop faster than it changes. A test program > > > running on all 4 CPU cores that reported jumps larger than 100 ms was > > > run for 13.6 hours and reported the following: > > > > > > Count | Event > > > ---+--- > > > 9940 | jumped backward 699ms > > >268 | jumped backward 1398ms > > > 1 | jumped backward 2097ms > > > 16020 | jumped forward 175ms > > > 6443 | jumped forward 699ms > > > 2976 | jumped forward 1398ms > > > 9 | jumped forward356516ms > > > 9 | jumped forward357215ms > > > 4 | jumped forward714430ms > > > 1 | jumped forward 3578440ms > > > > > > This works out to a jump larger than 100 ms about every 5.5 seconds on > > > each CPU core. > > > > > > The largest jump (almost an hour!) was the following sequence of > reads: > > > 0x007f → 0x0093feff → 0x0080 > > > > > > Note that the middle bits don't necessarily all read as all zeroes or > > > all ones during the anomalous behavior; however the low 10 bits > checked > > > by the function in this patch have never been observed with any other > > > value. > > > > > > Also note that smaller jumps are much more common, with backward jumps > > > of 2048 (2^11) cycles observed over 400 times per second on each core. > > > (Of course, this is partially explained by lower bits rolling over > more > > > frequently.) Any one of these could have caused the 95 year time skip. > > > > > > Similar anomalies were observed while reading CNTPCT (after patching > the > > > kernel to allow reads from userspace). However, the CNTPCT jumps are > > > much less frequent, and only small jumps were observed. The same > program > > > as before (except now reading CNTPCT) observed after 72 hours: > > > > > > Count | Event > > > ---+--- > > > 17 | jumped backward 699ms > > > 52 | jumped forward 175ms > > > 2831 | jumped forward 699ms > > > 5 | jumped forward 1398ms > > > > > > Further investigation showed that the instability in CNTPCT/CNTVCT > also > > > affected the respective timer's TVAL register. The following values > were > > > observed immediately after writing CNVT_TVAL to 0x1000: > > > > > > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL > Error > > > > +++- > > > 0x00d4a2d8bfff | 0x10003fff | 0x00d4b2d8bfff | +0x4000 > > > 0x00d4a2d94000 | 0x0fff | 0x00d4b2d97fff | -0x4000 > > > 0x00d4a2d97fff | 0x10003fff | 0x00d4b2d97fff | +0x4000 > > > 0x00d4a2d9c000 | 0x0fff | 0x00d4b2d9 | -0x4000 > > > > > > The pattern of errors in CNTV_TVAL seemed to depend on exactly which > > > value was written to it. For example, after writing 0x10101010: > > > > > > CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL > Error > > > > +++- > > > 0x01ac3eff | 0x1110100f | 0x01ac4f10100f | +0x100 > > > 0x01ac4000 | 0x1010100f | 0x01ac5110100f | -0x100 > > > 0x01ac58ff | 0x1110100f | 0x01ac6910100f | +0x100 > > > 0x01ac6600 | 0x1010100f | 0x01ac7710100f | -0x100 > > > 0x01ac6aff | 0x1110100f | 0x01ac7b10100f | +0x100 > > > 0x01ac6e00 | 0x1010100f | 0x01ac7f10100f | -0x100 > > > > > > I was also twice able to reproduce the issue covered by Allwinner's > > > workaround[4], that writing to TVAL sometimes fails, and both CVAL and > > > TVAL are left with entirely
[linux-sunxi] Re: Allwinner H3 boot from eMMC boot partition
I have no experience with H3 itself, but A64 boots from these partitions in agreement with the eMMC 5.1 (JESD84) specs. Unlike booting from the user partition (the usual case), here BROM expects BOOT0/SPL to be located right at the first sector. On Thursday, May 23, 2019 at 8:13:40 AM UTC+2, Wei-Hung Yang wrote: > > Hi All, > > I found this wiki said SoC seems not boot via eMMC boot partition. > http://linux-sunxi.org/Bootable_eMMC > I have a Banana Pi M2+ with 8 GB eMMC. I try to write U-Boot (with SPL) to > eMMC boot partition, i.e. mmcblk2boot0 or mmcblk2boot1, and cannot get it > to work neither. > > Can H3 boot from boot0 or boot1 partition of eMMC? If yes, how to achieve > that? > > > Best regards, > Wei-Hung Yang > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/ca13d5ee-3141-40f1-8d08-78c238ba049a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
