Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
ahalaney has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
bhsharma has joined #linux-msm
cmeerw has joined #linux-msm
bhsharma_ has joined #linux-msm
bhsharma_ has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
hey, anyone has new (or some non-linaro and non-codeaurora) email of Lina Iyer ?
<bamse>
DavidHeidelberg[m]: may i ask why you're asking?
<DavidHeidelberg[m]>
RFC: dt-bindings: arm/msm/qcom,idle-state convert to YAML
<DavidHeidelberg[m]>
she was author of the original dt, so I kept her as a maintainer, but the mail returned
<bamse>
nice work
<bamse>
unfortunatley i don't think she will do any maintainership over this these days
<DavidHeidelberg[m]>
meh, I just try to reduce make dtbs_check output to something reasonable
<bamse>
feel free to put Bjorn Andersson <bjorn.andersson@linaro.org> as maintainer for now
<DavidHeidelberg[m]>
ok
<DavidHeidelberg[m]>
that's a solution, thx
<bamse>
i think Maulik might be the right person to "own" it long term, but let's do this for now
<DavidHeidelberg[m]>
kk
<bamse>
DavidHeidelberg[m]: i much appreciate any efforts on shrinking the dtbs_check warnings
<DavidHeidelberg[m]>
btw. are u on Linaro conf?
<bamse>
yeah, by some definition of "on"...given that it's virtual
<DavidHeidelberg[m]>
bamse yeah, I believe it can be very useful, just it mustn't print 1000 lines of warnings around important stuff
<bamse>
right, if we actually where able to squash those warnings it would be a very useful test
<DavidHeidelberg[m]>
yup, just listening tuxsuite talk
<DavidHeidelberg[m]>
*lkft
<bamse>
it does find and warn about useful bugs when you write dts files...
<DavidHeidelberg[m]>
bamse have u seen the patch, should I adjust also something else or can I send v2 w/ different maintainer?
<bamse>
but there's too much noise as it is now
<DavidHeidelberg[m]>
exactly
<bamse>
there's an unnecessary newline in the example
<DavidHeidelberg[m]>
removed ;-)
<bamse>
is there an actual requirement that the states must be named "ret", "spc" and "pc"?
<bamse>
i mean, there is in your binding
<bamse>
i don't mind, but if those are the full names, you should be able to add a $ at the end of that pattern as well
<DavidHeidelberg[m]>
bamse $ be it, I don't see it being used differently than " spc "
<DavidHeidelberg[m]>
not even "ret" or "pc"
<DavidHeidelberg[m]>
yeah, ret and pc are never used
<bamse>
we'll get there, some day :)
<DavidHeidelberg[m]>
well, for these 2011-2014 devices, maybe if someone really enthausist with lot of knowledge gets around :D
<DavidHeidelberg[m]>
my goal is just get Nexus 7 working at least stable without any magic around :D
<bamse>
that would be nice
<DavidHeidelberg[m]>
do u have idea what to do about " idle-states: 'spc' does not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+'
<DavidHeidelberg[m]>
" ?
<DavidHeidelberg[m]>
since it collides with arm/idle-states.yaml namespace
<bamse>
no, sorry...that would be a question for rob herring
<DavidHeidelberg[m]>
ok, I'll send it and lets read what he'll think about it
<DavidHeidelberg[m]>
thanks for feedback
<DavidHeidelberg[m]>
btw. what about when I have lot of small fixes? One liners, but mostly for specific area, should I group them somehow before I send them or it's fine when I firing them as I create them to ML?
<bamse>
DavidHeidelberg[m]: if they have dependencies on eachother send them as a series, but otherwise just fire them off
<DavidHeidelberg[m]>
ok, no dep
<DavidHeidelberg[m]>
I feel like spammer with these oneline changes, but ... yeah it fixes the warning, so..
svarbanov has joined #linux-msm
<DavidHeidelberg[m]>
bamse I see you have talk in 10 minutes, good luck! Looking forward to it
<bamse>
DavidHeidelberg[m]: yeah i understand, but i will have to spend 5 seconds applying that dts patch, so i'm happy
<Mis012[m]>
someone here might know, is there any good reason for why Linux doesn't automatically add runtime-enumerated devices into the device tree?
<bamse>
Mis012[m]: dt is "firmware" telling the OS about the hardware in the machine, so i don't think there's a reason for the OS to put things back in to tell itself about additional things
<Mis012[m]>
an example usecase would be that you have a usb to i2c bridge or a usb gpio expander, stuff that you might want to configure using device tree, but you can easily end up with it connected over a hub, or even connected to a usb port provided by a removable PCI-E card, and it doesn't seem logical that the overlay should need to model these when Linux has all the information to add those nodes itself
<bamse>
right, but why would you actually need a dt representation for that chain of hardware?
<Mis012[m]>
eh, "the overlay" should be "a hypothetical overlay"
<Mis012[m]>
bamse: well, say I have a usb to i2c adapter, which also provides an irq line
<bamse>
you have two cases, in one i see that you only expose those gpios to userspace, in which case the kernel doesn't need to have a dt-like representation...and the other is when the kernel is using one of those resources
<Mis012[m]>
and I want to connect something to that, something that needs the interrupt and happens to have a nice kernel driver
<Mis012[m]>
maybe a touchscreen
<bamse>
in this latter case you as a developer knows that it's there - or need to patch other parts of the dt to recognize that it's there
<bamse>
so i think either you write the whole thing as an overlay, or for some enumerable busses you can describe the thing you know is on the bus and that's enough to tie it to the other part of the kernel
<Mis012[m]>
well, currently I started with booting my x86 laptop using device trees to begin with, but arguably Linux can't really do that for me
<Mis012[m]>
seems to work surprisingly well, but I assume my journey will end on pesky SCIs because of course ACPI wasn't complex enough without that
<Mis012[m]>
>for some enumerable busses you can describe the thing you know is on the bus and that's enough to tie it to the other part of the kernel
<Mis012[m]>
hmm, is that a thing? how would that work?
<Mis012[m]>
bamse: I believe there was a discussion about this with FPGAs, which might be a situation where an end-user would need this
<bamse>
Mis012[m]: one such case that we support today is rpmsg providing a communication bus with a remoteproc, exposing a discoverable service for regulators
<bamse>
Mis012[m]: so all nodes in dt that needs regulators has to have phandles to something exposed by this discoverable thing
<bamse>
Mis012[m]: but we know that it's there, so we represent this discoverable thing in dt and expose the regulators
<Mis012[m]>
maybe I should make a company that will sell stuff like a usb-i2c adapter with an eeprom for a device tree overlay xD
<Mis012[m]>
could probably do that in sw with an stm32
<bamse>
in that case i do believe you will end up in the very same spot as the fpga people
<bamse>
that you will need some way to describe what hangs on that i2c bus
<Mis012[m]>
a device tree :/
<Mis012[m]>
a device tree overlay stored in an eeprom on the adapter
<Mis012[m]>
that can be read out
<Mis012[m]>
speaking of things that should just be device tree and not it's own thing, vbios
<Mis012[m]>
but i2c etc is already being done with device trees, so there it doesn't seem too far fetched to NOT develop a new thing...?
<bamse>
right, if you inject a dt snippet you can rely on existing support
<Mis012[m]>
I was reading the OF documents, and they were suggesting putting FCode in PCI ROMs? I'd say that device tree overlays would be nicer there, maybe make the "ROM" r/w, not sure if that would work on all PCI implementation
<Mis012[m]>
* I was reading the OF documents, and they were suggesting putting FCode in PCI ROMs? I'd say that device tree overlays would be nicer there, maybe make the "ROM" r/w, not sure if that would work on all PCI implementations
<Mis012[m]>
actually VBIOS comes on PCI ROMs, so if it was in dt overlay format... :)
<Mis012[m]>
imagine Linux automatically adding the node for the PCI card, and then dumping the VBIOS overlay over it... <3
<bamse>
well, as long as there's no standardized way to extract and install it, i guess you can pick what fits your needs
<Mis012[m]>
unfortunately I don't think making standards is as easy as "I have a neat idea that looks a lot less like a pile of hacks than what we're currently doing"
<Mis012[m]>
especially if what we're currently doing is working out for a lot of cases, and users aren't supposed to look at internal details so how dare they care if they are ugly
<Mis012[m]>
bamse: though speaking of standards, I wanted to get some HID-over-i3c standard going that's free of M$'s patents xD
<Mis012[m]>
using the in-band interrupts and all
<bamse>
sounds nice
<Mis012[m]>
if Linaro wants to steal that idea, feel free :P
<Mis012[m]>
if I try to make a standard as an individual, that won't really work
<Mis012[m]>
a standard for device tree overlays in PCI expansion ROMs and in USB devices also sounds nice :P
<Mis012[m]>
actually HID is one devicetree-like approach that works extremely well
<Mis012[m]>
except when vendors fuck it up
<Marijn[m]>
<bamse> "it does find and warn about..." <- There's `DT_SCHEMA_FILES` to only check a specific schema, but do you happen to know if there's also a flag to check just a specific DTB?
<Marijn[m]>
Besides running the command twice and `touch`ing the relevant file in between?
<bamse>
Marijn[m]: lumag posted a patch that allows you to target specific .dtbs, but in general there's no way to do this
<Marijn[m]>
bamse that would be useful, but it looks like I should also be able to invoke the dtschema binaries directly to accomplish this
<Marijn[m]>
bamse since you're here now, anything to say on my DT backwards compatibility questions from friday?
<Marijn[m]>
And before I forget, nice update on LVC! Glad to see a constant increase in traffic upstream
<bamse>
Marijn[m]: i think you just use both .fw_name and .name and in the case where that results in breakage we just say that there's nothing we can do and moves on
<bamse>
Marijn[m]: thanks and many thanks for all the contributions
<Marijn[m]>
bamse the main problem is that I don't exactly know when/where to expect breakage. For example removing the "xo" global clock may break things and no .name can solve that
<Marijn[m]>
Though I guess the only way to find out is by asking users of the socs/devices that are currently upstream whether the firmware/kernel are updated in parallel. If so we can make breaking changes anytime we want
<Marijn[m]>
Sdm6xx seems to be in that boat. Konrads cleanup to 8994 assumes the same, and I prefer to do it that way for 8998 as well
<Marijn[m]>
bamse: (we'll get 8976 on that list in spring, pinky swear 😉)
<bamse>
Marijn[m]: nah, you don't need to ask people...just try to be backwards compatible and if it doesn't work..then there's nothing to do about it
<Mis012[m]>
bamse: you never replied to my proposal of simple binary patch to hypervisor for SSC that would be *almost* without side effects
<bamse>
Mis012[m]: what was my expected input?
<Marijn[m]>
bamse: Basically saying: for the DSI PLL change we can be backwards-compatible for devices that only had their DT dependencies added recently, but for gcc changes where we decide to remove the "xo" clock all backwards-compat is out of the window already so we might as well omit .name. Or we don't drop "xo" at all.
<Mis012[m]>
bamse: if it's too wacky, or if you see someone being willing to use that
<bamse>
Mis012[m]: i don't know, it might be interesting to some people
<Mis012[m]>
bamse: right now all the people that I know of that would be willing to use it don't own their devices
<Mis012[m]>
and are not willing to swap SoCs
<bamse>
Marijn[m]: having .name and keeping "xo" in gcc for a while would limit the risk of people picking an older dtb and having issues...so if that's possible for 1-2 releases that would be perfect
<bamse>
Marijn[m]: and would work if someone is trigger happy and backports the patch, right?
<Marijn[m]>
bamse: Sounds good, I'm all for adding .name temporarily and removing it, together with "xo" where applicable, a few kernel releases down the line
<bamse>
Marijn[m]: in particular the dts, pll and clock changes goes through different maintainers, so trying to make it so that things doesn't break during it's life in linux-next and the merge window is a good idea
<Marijn[m]>
bamse: Yeah, that too is a thing to consider especially when having `Fixes:` in there on patches that were also backported and/or landed in earlier changes
<Mis012[m]>
bamse: it would be really useful for devboards, but those are not priced sanely so they're only really used by device vendors
<Marijn[m]>
bamse: And that's another good point, thanks for your input! Will take that into account when sending more cleanup / re-spinning the DSI patches
<Marijn[m]>
Speaking of re-spinning, you mentioned LPG in your talk - any updates on re-spinning that?
svarbanov has quit [Ping timeout: 480 seconds]
<bamse>
Marijn[m]: Uwe as feedback on v9 that i started to address, looks fairly straight forward to finish up though...
<bamse>
Marijn[m]: and i want backlight on my laptop, so better land it ;)
<Marijn[m]>
bamse great, we'll test and review it as soon as it lands in our inbox
<Marijn[m]>
Don't need it per-se as it's only for our notification led, but nice to get some patches off of our fork nonetheless
<Marijn[m]>
Still haven't heard anything from that pattern index/length fix either... It's not needed but makes for a little better sysfs api
<Marijn[m]>
Guess I'll just resend when v10 is accepted :)
<bamse>
Marijn[m]: that said, one of the tiny changes uwe asks for is probably going to screw up the idempotent test...
<bamse>
Marijn[m]: i started writing that driver 6 years ago, it was first posted 2017 (iirc) and has been there 9 times, i'd be very happy to get it off my todo list :)
<bamse>
Marijn[m]: which pattern fix was that? the repeat thing in the framework?
<Marijn[m]>
bamse ouch, we need that idempotent test...
<Marijn[m]>
Though on sm6125, besides using pbs we get a few more lut spaces but the reverse repeating bit is gone iirc :(
<bamse>
interesting
<Marijn[m]>
bamse yeah some patchsets carry on for way too long unfortunately. Would splitting it up have made it easier?
<bamse>
yeah i think it would make sense to follow up with a patch that does something clever to reuse pattern space
<bamse>
the natural thing would be to submit the pwm part first, but that patch has no reason to be in drivers/leds...and i just envisioned that it would be strange to implement the led patch by then moving the pwm driver
<bamse>
and i would implement a pwm-only driver differently
<bamse>
i looked at that quite a bit, given that the downstream driver has it split in a pwm and a led part
<bamse>
but last time i looked they where abusing the pwm api quite badly
<Marijn[m]>
bamse fair, and at this point it's only few comments remaining anyway, and they're all over the place afaik
<bamse>
the real issue why it sat for so long was the pattern and rgb support though
<bamse>
i had a proposal for patterns, it was rejected with a suggestion for something else...that was finally implemented and after countless iterations we where back to my original proposal
<bamse>
and for rgb handling, that took ~25 iterations before it landed
<bamse>
so i've spent quite a bit of time just waiting for others to get us through those obstacles
<bamse>
but in the end i like the outcome
<bamse>
i do have a concern with how we do rgb leds, as i don't see a way to control a single rgb led using multiple led drivers
<bamse>
or a led driver that wasn't supposed to be driving rgb leds
<bamse>
e.g. i have a 24 channel led driver...which on this devboard just happens to be wired to 8 rgb leds
<Marijn[m]>
At least the rgb leds are controlled in parallel now... No desyncs between colors like before
<bamse>
so if i want to expose rgb leds to userspace, i would need to implement rgb support in that driver...
<bamse>
right, that's good
<Marijn[m]>
(/me waves to my xperia xz3 that throws a discoball when it's supposed to be white breathing)
<Marijn[m]>
24 channels would be broken down into 8 rgb leds? Or 24 "single-color" leds?
<Marijn[m]>
Either way, individually controlling the r, g and b pattern as discussed before is also an open issue
<bamse>
the chip is intended to drive strips of 24 single color leds
<bamse>
so there's nothing "rgb" about the chip...but there will have to be in the driver
<bamse>
unless we come up with some other abstraction to expose arbitrary leds as rgbs
<Marijn[m]>
Seems like the dt bindings are already up for tha task?
<Marijn[m]>
With the way how we can define which lpg is for r, g and b, or for any separately controlled led?