07:19 <narmstrong> Marijn[m]: yes the rate should be reduced by 3 when used with dsc

08:14 <Marijn[m]> narmstrong: I don't recall seeing the code in dsi_host that takes care of that... Are you looking into this?

11:41 <lumag> narmstrong, I don't see the corresponding code in downstream too, to lower the clocks in DSI case

11:41 <lumag> *DSC

11:50 <Marijn[m]> lumag: me neither but it's rather convoluted. Downstream hardcodes it in DT and it's only marginally lower than what mainline calculates for the same panel/device...

11:51 <Marijn[m]> Perhaps we should compare clk_summary and/or debugcc and make sure? Or are these devices having a far too high clock all the time, wasting energy (but perhaps improving latency...)?

13:40 <narmstrong> Marijn[m]: lumag: it's handled via dsi_h_active_dce() in dsi_panel_calc_dsi_transfer_time()

13:42 <narmstrong> dsi_h_active_dce() returns pclk_per_line which is DIV_ROUND_UP(total_bytes_per_intf, 3) which is equal to hdisplay/3 when bpp is 24

13:42 <narmstrong> dsi_h_total_dce() also retursn the htotal with hdisplay/3 for video mode

13:44 <Marijn[m]> narmstrong: saw that but dismissed it as "seen that code somewhere during DSC patch review, so we must already handle it" without further checking if h_active propagates into clock calculations anywhere

13:44 <narmstrong> we clearly don't have `dsi_panel_calc_dsi_transfer_time()` equivalent in upstream

13:45 <narmstrong> what we have in upstream is dividing hdisplay/3 when setting the video/cmd mode timings, but not the clk

13:47 <narmstrong> `Divide the display by 3 but keep back/font porch and pulse width same` in dsi_timing_setup()

13:55 <Marijn[m]> narmstrong: right, yes, I've seen and modified the code that writes this value into a register

13:56 <Marijn[m]> Are you onto a patch to apply it to the clk / transfer time as well?

13:56 <narmstrong> Marijn[m]: the next step is to try once I have a calculation that works

13:58 <Marijn[m]> narmstrong: looking forward to that, or will try my own hand at it when back home otherwise

16:12 <aka_[m]> How is modem done on Android mainline?

16:30 <aka_[m]> I see mm-radio on GloDroid git

16:58 <vknecht[m]> aka_: afaik from recent discussion in #_oftc_#aosp-developers:matrix.org mm-radio is not complete and parts have to be "emulated" just to show network icon. with QRTR modem one could follow up on Caleb's qrild (aospm repo)

19:53 <lumag> anybody having experience with pwm setup on pm8994/8996 ?

19:53 <lumag> konradybcio, Marijn[m] ^

19:53 <konradybcio> no

19:56 <Marijn[m]> lumag: listing two socs I don't own ;)

19:57 <lumag> :D

19:57 <Marijn[m]> lumag: is Bjorn's LPG driver applicable to these?

19:57 <lumag> Marijn[m], yes, but I'm stuck with parameters / pinctrl

19:58 <lumag> bamse, ^^

20:05 <Marijn[m]> lumag: parameters as in, no idea what to fill in inside the driver structure?

20:06 <lumag> Marijn[m], no, qcom,dtest, function etc.

20:07 <Marijn[m]> lumag: hmm, I recall somehow finding definitive info downstream whether or not to use dtest on pm660l

20:07 <Marijn[m]> lumag: unfortunately I don't recall having any pinctrl...?

20:15 <lumag> Marijn[m], ack, thanks anyway

20:17 <lumag> Tooniis[m], maybe you remember details? I'm trying to get PWM output on pm8996 GPIO5

20:17 <lumag> But config from your xiaomi dtsi doesn't seem to work

20:18 <Marijn[m]> Any idea when the first 8550-based boards/devices start coming out? I haven't kept up at all :)

20:18 <Marijn[m]> Seen the OP11 at least

20:21 <lumag> Marijn[m], I'm waiting for Xiaomi to provide 8550-based phone. Or for updating their DTS repo :D

20:22 <Marijn[m]> lumag: lol :D

20:36 <lumag> ok, by manually setting gpio666 to out / 1 I got the image.

20:38 <konradybcio> that's a lot of gpios

20:51 <lumag> ok, fixed it now :-)

20:51 <lumag> Got simultaneous HDMI and DSI :-)

20:52 <lumag> The issue was that I was adding options to &ls_exp_gpio_f, while there is an extra pinconf { ... } level.

20:59 <Marijn[m]> lumag: Ah, also a backlight via PWM?

21:00 <lumag> yes

21:02 <lumag> https://pastebin.ubuntu.com/p/QDzZZqW4g7/

21:42 <aka_[m]> <lumag> "Marijn, I'm waiting for Xiaomi..." <- buying one?

21:43 <Marijn[m]> Make them pay you to upstream it :)

21:44 <aka_[m]> Marijn: why do you think there is any vendor who would pay for upstreaming their device? its quite counter-intuitive

21:44 <aka_[m]> they want you to replace it after max 2 years

21:44 <Marijn[m]> aka_: sorry for being sarcastic ;)

21:44 <aka_[m]> Marijn[m]: sounds pretty much like Mis012

21:45 <aka_[m]> but he isn't sarcastic

21:45 <aka_[m]> i still don't get what Lumag meant with DTS repo of xiaomi

21:46 <aka_[m]> xiaomi only provides kernel sources and lately not much.

21:53 <lumag> aka_[m], https://github.com/MiCode/kernel_devicetree

21:54 <aka_[m]> oh

21:55 <aka_[m]> and what is use of these for you?

21:55 <aka_[m]> i find xiaomeme flagships to kinda sucks, they probably don't have single usb 3.1 enabled device

21:56 <aka_[m]> s/sucks/suck/

22:00 <Mis012[m]> here I am thinking I got pinged by someone who can help me with pin stimulation :(

22:01 <aka_[m]> Mis012[m]: pin

22:01 <aka_[m]> deez nuts

22:01 <Mis012[m]> you mean stimulate?

22:01 <Mis012[m]> pinning sounds painful

22:23 <Mis012[m]> https://github.com/Rashed97/caf-kernel-msm-3.10/blob/0b88ce25d98d3ff7bf0c3691e4521f811e094844/arch/arm/boot/dts/qcom/msm8992-coresight.dtsi#L54

22:23 <Mis012[m]> same shit here, it says sw

22:23 <Mis012[m]> and no QDSD registers

22:24 <Mis012[m]> don't fucking tell me qcom removed pin stimulation support

22:25 <Mis012[m]> I guess I should try on 8916, but that's a samsung device so who knows if they decided to disable NIDnT just cause