<JoelSelvaraj[m]>
bamse: I m trying to get notification LED working in Xioami Poco F1 but its not working. Its bit different from the others, bcoz it doesnt use a RGB LED, but instead use a white LED connected to the red channel. the downstream driver disables the blue and green led. Like this:
<JoelSelvaraj[m]>
and maybe it could also be related to the issue calebccff faces with pmi8998 and Oneplus 6. although it has a proper RGB LED unlike the poco f1.
<JoelSelvaraj[m]>
one small note would be, i m testing your patches on top of 5.17 kernel. Hope that's fine?
luci has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
marvin24 has joined #linux-msm
<luci>
what's the best way to get a mainline linux kernel (with gpu support) on a nexus 5?
Danct12 has quit [Quit: Leaving]
<aka_[m]>
Fix iommu yourself
<aka_[m]>
There is no other way
<aka_[m]>
It's not like someone hide fully working kernel somewhere
<mirsal[m]>
the dreaded msm8974 iommu
<mal>
we have code which appears to work quite well
<mal>
for msm8974 iommu
<aka_[m]>
mal: time to upstream it i think?
<mirsal[m]>
I'd like to help review / test it
<mal>
we have tested it on fp2 so far, need to check the latest version of it and test again
<mirsal[m]>
Would you mind sending a link?
<mal>
I think we had some issues with the very latest version so I need to check it before sharing
<mirsal[m]>
okay, thanks :)
<mal>
I think there are still some issues in the gpu code for msm8974, I think there was talk about that in the past
<Mis012[m]>
>the dreaded msm8974 iommu
<Mis012[m]>
pretty sure it's the same iommu as every other iommu. so you just need hypervisor code exec :P
<Mis012[m]>
and if 8974 isn't PoP, then it wouldn't be that hard to swap in a blank
<aka_[m]>
8974 isn't arm v8
pevik has quit [Ping timeout: 480 seconds]
<bamse>
JoelSelvaraj[m]: the RGB LED is just 3 different LEDs placed close enough, so it does sound like you have the same problem
<bamse>
JoelSelvaraj[m]: if you want i can take it for another boot, just to double check that i looked at the right board blinking :)
<Marijn[m]>
Joel Selvaraj @joelselvaraj:matrix.org: notice that bamse 's patches don't have a multi-led+RGB subnode but define the single-color led directly inside the lpg node
<Mis012[m]>
bamse: who did you say has a qcs40x board?
<bamse>
Mis012[m]: vkoul (but it might be that he only have remote access to it...)
<bamse>
Marijn[m]: right, so in his case with the single white LED one of those channels should be exactly what he's looking for
jhovold has quit [Ping timeout: 480 seconds]
<Marijn[m]>
bamse: Yes, afaik it does not make sense to use the TRILED block if you don't have multiple colors hence don't need synchronization? I don't fully remember the details of your driver but the patterns etc are still available on non-RGB leds too
<bamse>
Marijn[m]: we still use the triled...because that's actually only 3 current sinks
<bamse>
Marijn[m]: the pattern syncrhonization is actually completely independent of that and can apply to any combination of the available channels
<Marijn[m]>
Fair enough, the channel is still "physically on the TRILED block" if I understood that correctly
<Marijn[m]>
And bamse yes exactly, there's nothing lost by not using an RGB led...
<bamse>
Marijn[m]: you have N channels in the LPG, wired up to various different things in the PMIC...among the options (and expected configuration) are the three channels feeding the three current sinks that makes up the triled
<bamse>
Marijn[m]: typical other use cases is to use the output of a lpg channel as control signal for the enable-bit in a gpio/mpp
<Marijn[m]>
Right, because the LPG on its down doesn't supply enough current to drive an LED?
<bamse>
right, the LPG output is just a digital signal, so you need to pair it with something to get it out of the chip
<bamse>
and you're right, you wouldn't be able to pull that amount of current
<JoelSelvaraj[m]>
bamse: Marijn i tried specifying the led without the multi-led node too. it didnt work that way either.
<bamse>
JoelSelvaraj[m]: do you have the qcom,power-source defined?
<Marijn[m]>
Joel Selvaraj: Anything in dmesg? Does the LED show up in sysfs?
<JoelSelvaraj[m]>
bamse: yes. as <1>
<JoelSelvaraj[m]>
Marijn: dmesg nothing. but sysfs entries yes. i tried setting brightness to max-brightness and intensity to 256
<bamse>
JoelSelvaraj[m]: with your single-color LED you should not mix in the RGB subnode
<bamse>
JoelSelvaraj[m]: but that shouldn't affect the end result
<JoelSelvaraj[m]>
bamse: ok. so ideally i should specify the led without the multi-led node. and how do i know if i am using the current power-source?
<Marijn[m]>
Joel Selvaraj: Unless I misremember the mapping, the downstream DT you linked uses ID 3 for the red LED but you used ID 5 in mainline
<Marijn[m]>
Are you perhaps powering a channel that has nothing connected? What if you change it to @3 and reg = <3>?
<bamse>
JoelSelvaraj[m]: the power-sources are something like 0=GND, 1=vdd_rgb, 3=some internal source
<bamse>
JoelSelvaraj[m]: and vdd_rgb is typically bob, which typically is used for a whole bunch of other things that you would notice if they aren't powered
<JoelSelvaraj[m]>
Marijn: qcom,id in downstream is different from reg i think..? it should be `pmi8998_pwm_5` that matters?
<bamse>
so the channel numbering sounds like a more reasonable lead
<Marijn[m]>
Joel Selvaraj: Oh I missed that. Double-check that `pmi8998_pwm_5` doesn't sneakily use reg=<3> :P
<JoelSelvaraj[m]>
I have tried 3,4,5 and nothing worked inside the mult-led node. maybe i ll try once more outside.
<Marijn[m]>
Otherwise I think you may be right
<bamse>
JoelSelvaraj[m]: the pin RGB_RED is reg = <5>
<JoelSelvaraj[m]>
Mmm. so the function being status is fine? i saw some other boards use indicator or heartbeat or something
<bamse>
3 being blue, 4 being green
<bamse>
if i got my function-enumerator right to match the schematics ;)
<JoelSelvaraj[m]>
bamse: ok. i have used reg=<5> too.
<JoelSelvaraj[m]>
bamse: what's the function-enumerator..........?
<bamse>
JoelSelvaraj[m]: that's the index of the "indicator"...
<bamse>
JoelSelvaraj[m]: we use to just say green:led1 - per the schematics
<JoelSelvaraj[m]>
bamse: ok.... so it shouldnt matter what i put right?
<bamse>
JoelSelvaraj[m]: but then the LED maintainers came up with color and function instead and when you have multiple leds with the same function the -enumator is supposed to identify each one
<bamse>
no
<bamse>
it will only affect what's presented to the user
Danct12 has joined #linux-msm
luci has quit [Remote host closed the connection]
<JoelSelvaraj[m]>
bamse: ok. thanks. i am gonna try this. sounds abt right i guess?
<bamse>
(and you can omit the -enumerator if you only have the one function of a particular type, but that's irrelevant for now)
<JoelSelvaraj[m]>
bamse: ok. it didnt work but. i tried setting the brightness to max_brightness. the led didnt come up
<calebccff>
apparently LPG works fine on the SHIFT6mq, so it not working on the op6/poco doesn't seem to be an 845 specific issue...
<JoelSelvaraj[m]>
maybe we are missing some regulators.....?
<bamse>
JoelSelvaraj[m]: it's always good to test with not only the extreme values...in case the author screwed up his math ;)
<bamse>
JoelSelvaraj[m]: the current sink is driven by a dedicated input pin...so it's possible that it's not powered...
<JoelSelvaraj[m]>
bamse: i tried other values now. it didnt work either.
<bamse>
JoelSelvaraj[m]: but it's also possible that i've missed something else
<JoelSelvaraj[m]>
bamse: so which input pin is that?
<JoelSelvaraj[m]>
ok.......
<bamse>
JoelSelvaraj[m]: there's a pin named vdd_rgb which is the power pin for the r, g and b outputs
<bamse>
JoelSelvaraj[m]: and typically vdd_rgb is driven by &vreg_bob...but that's not a requirement
<calebccff>
JoelSelvaraj[m]: bamse: seems to be powered directly for us
<bamse>
calebccff: power-source = 3 downstream?
<JoelSelvaraj[m]>
bamse: right. i have not configured the vreg_bob
<JoelSelvaraj[m]>
it was used when testing camss, which needed that regulator. but otherwise, it wasnt added into our tree.
<JoelSelvaraj[m]>
i ll go try specifying that.
<calebccff>
bamse: how would you check that?
<calebccff>
JoelSelvaraj[m]: vreg_bob is always on, it supplies basically everything on device.. i think
<JoelSelvaraj[m]>
calebccff: i see.....?
<bamse>
calebccff: ohh, it's hard coded to 1 in msm-4.9
<calebccff>
bamse: it's vin-ctrl right? pretty sure that's unset for us
<bamse>
calebccff: i think vin-ctrl applies to the mpp (if one is used)
<bamse>
calebccff: power-source is the value that goes into RGB_LED_SRC_SEL, which is 1 in msm-4.9
<JoelSelvaraj[m]>
bamse: i dont quite understand regmap and stuffs. but there was also a mask 3 sent to LED_SRC_SEL along with value 1. will that affect it?
<JoelSelvaraj[m]>
like downstream code has `qpnp_led_masked_write(led, RGB_LED_SRC_SEL(led->base), RGB_LED_SRC_MASK, RGB_LED_SOURCE_VPH_PWR);`
<JoelSelvaraj[m]>
s/LED_SRC_SEL/RGB_LED_SRC_SEL/
<bamse>
JoelSelvaraj[m]: the mask will tell update_bits to only touch those bits
<bamse>
JoelSelvaraj[m]: so it will read out the register value, drop the bits defined in the mask and then | in the value you specified
<bamse>
and then write the updated value back to the register
<JoelSelvaraj[m]>
bamse: but in mainline we just regmap_write value 1? will that both be equal?
<JoelSelvaraj[m]>
thanks for the explanation :)
<bamse>
JoelSelvaraj[m]: double checked, at least on pmi8998 only the lower 2 bits are used in that register
<Mis012[m]>
Joel Selvaraj: do you want pmi8998 FLAT?
<JoelSelvaraj[m]>
bamse: ok. i tried specifying all the regulators. vreg_bob and others. but still it didnt work. So maybe LED driver code is missing something.
<JoelSelvaraj[m]>
Mis012: what's flat?
<Mis012[m]>
tl;dr register map
<Mis012[m]>
without a "description" section though :P
<JoelSelvaraj[m]>
Mis012: yeah that would be nice.
<JoelSelvaraj[m]>
Mis012: without a description --- Meh.............
<JoelSelvaraj[m]>
like will i be able to understand anything of it?
<Mis012[m]>
Joel Selvaraj: well... it's better than nothing :P
<Marijn[m]>
JoelSelvaraj[m]: Did you give the regulator to the lpg driver? It doesn't turn on any regulators yet so you might want to turn it on through other means?
<Mis012[m]>
`always_on` go brrr
<Marijn[m]>
Exactly
<JoelSelvaraj[m]>
ok will try that on the vreg_bob
<calebccff>
I'm 99.9% sure it doesn't need some external regulator
<Mis012[m]>
vkoul: would you be able to test some femtophy driver modifications on qcs40x?
<Mis012[m]>
I have a few variations on one function, so would need to test maybe four times?
<Mis012[m]>
calebccff: depends on the board design
<Mis012[m]>
but iirc we have schematics?
<Mis012[m]>
calebccff: I think a3u has an analog amplifier for some bizarre reason, so there's always a way the board design can subvert your assumptions...
<Mis012[m]>
vkoul: would you be able to test something on qcs40x for me?
<Mis012[m]>
I have a femtophy refactor with a few variations on one function, so would need to test maybe four times?
<Mis012[m]>
and for each case test if USB (2.0) works
<JoelSelvaraj[m]>
bamse : this is what my schmatics looks like. (check the link below) seems like what u mentioned. the vdd_rgb uses vreg_bob for powering them. only RGB_RED is connected as charge led.
<Mis012[m]>
btw who though that connecting VBUS to those GND pads is a good idea...?
<Mis012[m]>
*thought
<Mis012[m]>
are those even supposed to be connected to their own lanes on the FPC?
<bamse>
Mis012[m]: better hope that GND1/2 and GND3/4 aren't connected :)
<Mis012[m]>
something tells me that would have manifested already :P
<bamse>
yes :)
<Mis012[m]>
bamse: are the DWC3 gpi/gpo signals ever used?
<Mis012[m]>
like... ever
<Mis012[m]>
seems like a weird feature
<bamse>
Mis012[m]: i didn't know it had that feature
<Mis012[m]>
well... it's sadly just dedicated lines
<Mis012[m]>
which are probably NC in 99% of SoCs with dwc3
<Mis012[m]>
femtophy has DP/DM bitbanging, that one is <3
<Mis012[m]>
sadly nothing like that on 8998 afaict
<Mis012[m]>
and my AMD SoC with femtophy doesn't expose the bitbanging signal via resiters 🤡
<Mis012[m]>
bamse: when I first saw the GPI/GPO register I hoped it would be for USB3 singal bitbanging :(
<Mis012[m]>
*signal
luci has joined #linux-msm
pespin has quit []
<DavidHeidelberg[m]>
robclark: Hey Rob, when we get the msm CI, is there chance finding somewhere few boards with mdp4 to have sure, it's not breaking by new changes? (still looking at possibility to have few machines with apq8064 running mainline)
<robclark>
so, gitlab CI is decentralized, in that it is possible for others to setup some runners that get added.. already what we have is split between two CI farms.. but that said, if someone had some mdp4 devices which (a) had good upstream kernel support, and (b) where amenable to remote power control (ie. vs relay switched power supply, etc.. ie. something battery powered would probably not be good), then it is possible..
<robclark>
oh, and they need some sort of debug serial.. and probably need to be able to nfsroot (and tftpboot or fastboot boot)
<bamse>
Mis012[m]: cc-pins?
<Mis012[m]>
bamse: ?
<bamse>
Mis012[m]: or you mean that it's dedicated gpio pins on the controller, which isn't connected?
<Mis012[m]>
for DWC3, the latter
<Mis012[m]>
I mean, you tell me if it's conmected
<Mis012[m]>
but I doubt it
<bamse>
okay, so it's not for controlling the datalines...
<Mis012[m]>
bamse: femtophy lets you bitbang DP/DM
<Mis012[m]>
on qcom anyway
<Mis012[m]>
AMD didn't expose those signals 🤡
<Mis012[m]>
bamse: but as I said, sadly don't see anything like that on 8998
<DavidHeidelberg[m]>
robclark yeah, question is -> who has at least two devices (devboards) with mdp4...
<Mis012[m]>
granted, I don't have a databook for qusb2 with a chapter called "let's bitbang UART"
<Mis012[m]>
and I wouldn't guess it just from FLAT
<bamse>
Mis012[m]: that would be a nice chapter to have
<robclark>
DavidHeidelberg[m]: idk.. and at least if you also want the devices in mesa CI you'll need more than two.. we have 7 to 10 of each board type in our local CI farm (db410c, db820c, cheza) and collabora has, I think, a similar # of sc7180 devices
<robclark>
I guess for _only_ kernel CI (igt) you could get away with less
<robclark>
since igt only takes a few minutes to run
<robclark>
(for deqp/piglit we shard across a bunch of boards)
<Mis012[m]>
bamse: I don't have any qcom femtophy device personally, otherwise I would surely add support for that in Linux
<Mis012[m]>
nothing like 3v3 TX and -3v3 RC
<DavidHeidelberg[m]>
robclark: hmm, I don't know either, I guess I'm out of the luck. Anyway, could be two enough, if we run there just some basic tests (e.g. the drm tests)?
<Mis012[m]>
*RX
<Mis012[m]>
bamse: I mean, it makes sense that it would be the PHY that would have that functionality and not DWC3, but a man can hope
<bamse>
Mis012[m]: i don't know, but that looks interesting
<Mis012[m]>
it's called UART, but it's really just bitbanging
<Mis012[m]>
bamse: well, if you could tell me that something like that exists on 8998, that would be nice
<bamse>
i have no idea, never seen this before
<Mis012[m]>
I'm pretty sure I could implement it on femtophy with these lovely docs, but I have no qcom femtophy device so I will probably do other stuff with my time
<Mis012[m]>
unless someone really needs UART on such a device
<Mis012[m]>
bamse: is qusb2 really qcom's own thing and not some rebrand?
<robclark>
DavidHeidelberg[m]: yeah, I suppose for just igt, maybe even one would be enough.. although I guess we would also need to setup an armv7 kernel build (everything else is armv8), but at least that could run in the 'cloud
<Mis012[m]>
it would seem that getting synopsys docs is a bit easier since they actually expect external developers to need them :P
<Mis012[m]>
qcom be like "we already wrote all the sw for you, do you not like it"