06:18 <narmstrong> xdarklight: all is ok

06:19 <narmstrong> I have concern about « pwm: meson: simplification based on Uwe's suggestion - WiP » where we need to be sure the new calculations gives the same results

06:19 <narmstrong> And i’ll use genmask for MISC_CLK_SEL_MASK

07:30 <ukleinek> narmstrong: you want "same" or "not worse"?

07:38 <ukleinek> narmstrong: is that the Subject of a mail? I don't find that one then.

07:39 <narmstrong> ukleinek: it's in https://github.com/xdarklight/linux/compare/1806e6f48ae65aaf869badcad5929f157c8f31b8...269d7e6a02a0d52d28e7c7d7d23873ce484d0c71

07:40 <narmstrong> ukleinek: i'd like same !!

07:41 <ukleinek> I like same iff it was correct before already :-)

07:41 <ukleinek> Otherwise I vote for improving and adapting the users if necessary.

07:41 <ukleinek> the first step is to evaluate the actual differences anyhow

07:42 <narmstrong> ukleinek: why incorrect ? AFAIK it always gave very precise results in our measurements

07:43 <ukleinek> narmstrong: I don't know if there is anything to fix.

07:49 <narmstrong> ukleinek: I'm ok to simplify the code, but f we change the calculations we must know the impact

07:49 <ukleinek> narmstrong: full ack

07:50 <ukleinek> and if there is a difference, it depends on why it is there.

07:51 <ukleinek> if the new calculation is more exact (what ever that means), weakening that just to keep the result identically would be sad

18:05 <xdarklight> narmstrong: thank you for having a look at the patches!

18:06 <xdarklight> narmstrong: ukleinek: so far the different calculation gave the same results in the cases I've tested (Meson8b VCCK regulator). testing on a GX SoC (PWM LED and 32.768kHz PWM clock) are still on my TODO-list

18:32 <xdarklight> narmstrong: also my video grabber arrived today (I got lucky and got one that exposes itself as UVC device). there's still something weird because I can't see the cursor blinking

18:32 <xdarklight> however, with "cat /dev/urandom > /dev/fb0" I get: https://abload.de/img/vlcsnap-2019-05-22-20hljdq.png

18:33 <xdarklight> when I then run "/fbtest -r0xff -g0x00 -b0x00" (https://github.com/jumpnow/fbtest) on top of that I get: https://abload.de/img/vlcsnap-2019-05-22-20nhjh8.png

18:34 <xdarklight> I tried various other tools (like fbv - framebuffer image viewer with a 720x576.png) to no avail :/

18:35 <xdarklight> to me it looks like there's two layers: only if the first layer (set with cat) displays something then the next layer will be shown on top (all red set by fbtest)

18:36 <xdarklight> I also applied "drm/meson: Add support for XBGR8888 & ABGR8888 formats", "drm/meson: Add zpos immutable property to planes" from the list and "WIP: drm/meson: fix primary plane disabling" from your github tree to make sure that you didn't accidentally fix the underlying problem