<z3ntu>
Dylan Van Assche: Do you get any bnep prints in dmesg? Looking at the code there should be "BNEP socket layer initialized" and "BNEP (Ethernet Emulation) ver %s", VERSION
<z3ntu>
The code is getting built by CONFIG_BT_BNEP
<DylanVanAssche>
z3ntu: On the PinePhone (different BT chip), I get that line in dmesg, but not in the Qualcomm device I have here
<DylanVanAssche>
Both have CONFIG_BT_BNEP as y
<z3ntu>
Looking at net/bluetooth/bnep/core.c there's not really anything that can go wrong if the code runs so that the message doesn't appear
<DylanVanAssche>
z3ntu: So probably the code never runs for some reason... Not sure how it initialized
<DylanVanAssche>
z3ntu: Ah CONFIG_BT_BNEP is a module on the PinePhone instead of builtin, will try that
<z3ntu>
BT_INFO calls bt_info which calls pr_info 🤷
<DylanVanAssche>
z3ntu: Aha! Building it as module solves the problem, now it gets properly initialized!
<Mis012[m]>
fun
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
Daanct12 is now known as Danct12
pespin has quit []
<Marijn[m]>
Mis012: Yes, perhaps we can have a framework/driver that receives a mapping of ADC ranges to panel nodes (in DTS). Then we "give" that driver to e.g. the DSI node, and it'll receive the right panel from the ADC "selector" driver?
<Marijn[m]>
It doesn't seem all too complex, but it perhaps is :P
<Mis012[m]>
Marijn: I guess the most generic approach would be overlays
<Marijn[m]>
Overlays of what?
<Mis012[m]>
then you only need drivers for the "mux" inputs
<Mis012[m]>
Marijn: devicetree overlays
<Marijn[m]>
And those would need to be patched in or something? Seems overly complicated to me...
<Mis012[m]>
Marijn: linux has a framework to dynamically apply overlays
<Mis012[m]>
guess the question would be where from
<Marijn[m]>
In my eyes you can just write three panel driver nodes all in the same device tree. Set their phandles in the node that controls this adc "mux" driver, and provide the phandle to this adc "mux" driver to e.g. a `dsi0` node. When it retrieves the panel it unknowingly calls through the adc driver which returns the right panel some way or another
<Marijn[m]>
Or does the dsi node look inside its `panel` child node?
<Marijn[m]>
(Then you might need DTS patching or rework the driver)
<Mis012[m]>
well, fwiw dts patching might not be out of question
<Marijn[m]>
And we also have to do this for touchscreen
<Mis012[m]>
but yeah, I'm a bit sceptical about the process being transparent
<Mis012[m]>
i2c is kinda easy
<Marijn[m]>
Transparent in the sense that the DSI driver - nor any other driver that accepts / deals with a generic panel - should have to be modified for this specific use-case
<Mis012[m]>
Marijn: you might be able to add some 'if "mux" then return child' to generic devicetree parsing
<Mis012[m]>
but it doesn't seem particularly clean
<Marijn[m]>
No, I'd first like to know if the DSI driver looks into its child node. Or just has it there and uses the `port` nodes to communicate
<Mis012[m]>
right, I get what you mean now
<Marijn[m]>
Looking at one of my device trees, I see nothing inside `panel@0` that would be of interest to i.e. the DSI driver
<Marijn[m]>
It's just a compatible, a reg, a port, and some GPIOs specific to the panel driver
<Mis012[m]>
the question is probably more "do we have the authority to say that this can never happen" than "does any existing driver do it"
<Marijn[m]>
We'd have to disallow it, I guess. There's probably a whole lot more to consider and discuss, though. Perhaps some maintainers have already toyed with the idea and came up with many more possibilities and pros/cons than I/we can in our spare time, and we might have to go through a little RFC writing to find a proper solution
<Marijn[m]>
(TIL Matrix/element has syntax highlighting on `dts`)
<Mis012[m]>
lol, I always use C highlighing
<Marijn[m]>
This has nicer colors ^^
<Mis012[m]>
yeah...
<Marijn[m]>
Consider also that on Sony we're seemingly not doing the ADC reading on every platform, but also rely on the bootloader to set it in cmdline
<Marijn[m]>
Though that'd just be a second mux driver or a different mode, we could have strings in dts to match on for example
<Mis012[m]>
since panel/ts could easily be one assembly with one connector
<Mis012[m]>
as for bootloader, the bootloader has to figure out which panel is connected and imho we should just do whatever the bootloader does, but in Linux
<Marijn[m]>
Mis012: With my approach you could decide to add an unlimited amount of phandles to the `adc-ranges` property, and access them through a `#xxx-cells` property on `<&panel_adc_mux PHANDLE_INDEX>` :)
<Mis012[m]>
doesn't sound all that sane...
<Mis012[m]>
guess not the worst thing
<Marijn[m]>
Either way, let's come up with the ergonomics later. we probably have to decide up-front whether to use actual DTS overlays, or multiple nodes and references (phandles)
<Mis012[m]>
if you're relying on bootloader, you might as well port u-boot and have it apply the overlays
<Marijn[m]>
Meh, I just want the kernel to run OOTB on a locked system
<Mis012[m]>
so cmdline-reading anything seems like a no
<calebccff>
Mrijn[m]: a mux driver exists for picking display at runtime?!
<calebccff>
or is that just an idea?
<Mis012[m]>
doesn't, we're discussing what could be a sane way to implement it
<Marijn[m]>
calebccff: We're just thinking up the idea of it :)
<Mis012[m]>
Marijn: you could wrap Linux in u-boot and call that your "ootb working kernel"
<calebccff>
ah right
<calebccff>
i had the idea for something more generic that could parse cmdline too
<calebccff>
hard to upstream though :P
<Mis012[m]>
parsing cmdline in Linux is absolutely not upstreamable
<calebccff>
but considering the amount of ACPI hacks in Linux....
<Mis012[m]>
if the bootloader can put stuff in cmdline, there is no reason it cannot apply dts overlay
<Mis012[m]>
so...
<calebccff>
tell that to my oneplus 6
<Mis012[m]>
the point would be to have it done completely inside Linux
<calebccff>
ye
<Mis012[m]>
the bootloader is doing something to figure out which display is connected, and I sincerely doubt Linux can't do the same thing
<Marijn[m]>
If that's the "only way" to make our device properly boot a usable mainline kernel.. Wasn't there some saying/"unwritten rule" to allow this? Considering that the vast majority of devices can't really easily get their BLs changed out? And the whole point is to not chainload yet another one?
<Mis012[m]>
Mis012[m]: which means it's *not* the only way
<Mis012[m]>
and designating the devices as different boards probably also counts as a way
<aka_[m]>
Allocate some memory in secondary bl, write some data to it, then read it inside linux, ugly complicated but maybe xd
<Mis012[m]>
secondary bl can just apply overlays
<Marijn[m]>
Mis012: Sure, we could also "figure out" how the BL does the ADC reading (or whatever else) and replicate that in Linux, but it could be complicated
<Mis012[m]>
which is the only sane way to pass the information from bootloader
<aka_[m]>
We need to learn lk2nd probing entire stacks or provide hardcoded overlays
<Mis012[m]>
Marijn[m]: well, it's the only way to make it make sense
<aka_[m]>
I doubt we can probe cci devices just like that
<Mis012[m]>
weelll...
<aka_[m]>
In theory it's bus
<aka_[m]>
So we can i2c gpio and get mclk clocks up
<Mis012[m]>
but it's not a discoverable bus
<Mis012[m]>
if the sensors are on different i2c addresses, you can kinda just let the unconnected ones fail to probe
<Mis012[m]>
if they're not, then surely there must be some mux-like indication to Linux / the bootloader
* Mis012[m]
should really sleep()
<aka_[m]>
Qcom cci just load userspace bins and execute probe on data doesn't it.
<calebccff>
Marijn[m]: I think it's a strong argument, im not sure it's enough. I think i've seen some strong views along the lines of always "fixing" the bootloader, but idk
<calebccff>
it's a discussion I think needs to happen