07:05 <narmstrong> Honestly since the emmc is already configured by the BL1, I think we should have a custom driver that only does direct reads like the BL2

08:51 <f_[xmpp]> a stripped down drivee

08:51 <f_[xmpp]> *driver

09:50 <rockosov> Hello guys, do you know is it possible to setup energy model with thermal gov power allocator if SoC is based on the SCPI protocol?

09:50 <rockosov> I know, it's possible for SCMI, because it support dynamic power2state mapping

09:51 <rockosov> But if I setup static OPP table for SCPI-based thermal model, will it work?

09:54 <narmstrong> good question, I was wondering if we could declare static OOP tables bypassing the SCPI tables at some point if the SCPI is buggy (.... Odroid-C2 ....), and I don't see why we couldn't

09:55 <narmstrong> I mean if the OPP entries matches the clocks frequencies of &scpi_dvfs then it's ok

09:58 <rockosov> Hmmm, sorry, it's may be stupid question, because I'm just learning these things now... But in the my situation power allocator doesn't work, because energy model is not registered. And based on my research conclusions, energy model can be registered from the DT OPP table or SCMI...

09:58 <rockosov> That's why I've started to search a way to register energy model with proper power2state and state2power translation for SCPI

09:59 <narmstrong> maybe you could simply try to register it from the scpi cpufreq ?

10:00 <rockosov> Hmm, not I see that scpi cpufreq driver has such callback, but somehow it's not registered

10:00 <rockosov> So, debugging...

10:00 <rockosov> s/not/now/

10:18 <rockosov> Looks like scpi cpufreq calls dev_pm_opp_of_register_em(), but this call is totally designed for of-based opp table only

10:25 <rockosov> Hmmm, <dynamic-power-coefficient> is required to make this workable.. I will try to run some experiments to calculate appropriate DPC value for axg. And looks like it's required to be calculated for all other SoCs

14:07 <phh> our board has several variants. only change concerning mainline driver is wifi, so we did it like this: meson-g12a-fbx8am.dtsi with a compatible "freebox,fbx8am", and then meson-g12a-fbx8am-broadcom.dts for the variant using broadcom wifi that includes the dtsi and with compatible "freebox,fbx8am-broadcom", "freebox,fbx8am", "amlogic,g12a"] but dtc_chk is unhappy with:

14:07 <phh> ['freebox,fbx8am-brcm', 'freebox,fbx8am', 'amlogic,g12a'] is too long

14:08 <phh> should we just move to ["freebox,fbx8am-brcm", "amlogic,g12a"]?

16:02 <f_[xmpp]> phh: I'll have to say..I'm glad to see yet another vendor interested in mainline linux.

16:03 <f_[xmpp]> as for the compatible "brcm" should be fine..

16:14 <narmstrong> phh: you may need to properly specify both compatible variants set in the bindings

16:15 <narmstrong> phh: can you share the changes you did in the amlogic.yaml bindings ?

16:28 <phh> f_[xmpp]: well, mainline is the natural thing that comes out when you want long term support. and long term support is part of our business model with a 13 yrs old device still being given to our new customers

16:28 <f_> :D

16:28 <phh> narmstrong: well we currently do https://gist.github.com/phhusson/a5429008a9713191a114e1789b9c2c7d

16:29 <f_> If only other vendors were like that...

16:29 <f_> and I didn't know that. Not really familiar with free.fr...

16:35 <narmstrong> OK so yeah this won't work, so either you add a separate entry with something like:

16:35 <narmstrong> https://www.irccloud.com/pastebin/tEWPLJ2o/

16:35 <narmstrong> and either `"freebox,fbx8am-brcm", "freebox,fbx8am", "amlogic,g12a"` or `"freebox,fbx8am-realtek", "freebox,fbx8am", "amlogic,g12a"`

16:36 <narmstrong> or you can simply add `broadcom` to the amlogic,g12a list and add the broadcom and realtek variants as dtbos

16:36 <narmstrong> and merge the dtbo at runtime or before flashing

16:37 <narmstrong> *add `broadcom` to the amlogic,g12a list and add the broadcom and realtek variants as dtbos

16:37 <narmstrong> damn copy paste

16:37 <narmstrong> * add freebox,fbx8am to the amlogic,g12a list and add the broadcom and realtek variants as dtbos

16:38 <narmstrong> adding dtbos for variants seems to be the new preferred way to handle such case

16:39 <narmstrong> the fdtoverlay utility works well for this case

16:39 <phh> I did think of dtbos, but our bootloader is erm, yeah well. I didn't think of merging them before flashing though, I'll look at it thanks

16:40 <f_> amlogic downstream u-boot?

16:40 <phh> dtbo should definitely be the way to go for us, because we might get new hardware changes later, and we already have non-described hardware changes (like dvb which isn't supported in mainline)

16:40 <phh> f_: yeah

16:41 <narmstrong> phh: if it could fit then yes it would help for future board revisions

16:43 <phh> btw, our downstream kernel auto-detects between broadcom and realtek wifi using mmc pid/vid, and we could use that with dynamic overlays, but that's not a thing in mainline

17:10 <chewitt> narmstrong: phh: I have this in my tree at the moment https://github.com/chewitt/linux/commit/23e74f62e6760a231daf3ebf1033f39e44538fc0

17:12 <chewitt> I have a few patches that I need to group into a logical set and send

17:12 <chewitt> that's one of them..

17:13 <chewitt> the BT part of the modules isn't so simple, sadly

17:25 <phh> chewitt: yeah the reason the dtbo exists is for bluetooth, not wifi