<Mis012[m]>
specifically changes with the purpose of making the qcom,usb-hs-28nm-femtophy compatible suitable for use with SoCs/boards which do not need any initialization
<Mis012[m]>
it seems logical to me that applying overrides shouldn't be the default
<Mis012[m]>
that's why they are called overrides
<Mis012[m]>
bamse: what do you think? is ABI breaking allowed when it makes the driver fairer to the binding?
<bamse>
Mis012[m]: am i understanding correctly that you want to add a qcs405 specific compatible, so that you can change the meaning of the generic compatible?
<Mis012[m]>
yes
<bamse>
that's frowned upon, but given good motivation possible
<Mis012[m]>
the generic compatible shouldn't do qcs405-specific stuff
<aka_[m]>
bamse: there was small mistake
<aka_[m]>
qcs driver uses different binding for init seq
<aka_[m]>
its in 4.19 and do reg writes
<bamse>
right, and getting the platform-specifics out of the generic compatible is preferred in the long run over adding platform-specifics for every other platform imho
<aka_[m]>
other socs like 8952 family does ULPI writes
<aka_[m]>
with diferent binding
<aka_[m]>
Konrad probably made mistake and added init seq which should be written with ULPI
<Mis012[m]>
bamse: well, ideally I'd like to contvert the ugly magic init sequence into override properties
<Mis012[m]>
right now I'm looking into why does one of the writes need a magic delay
<bamse>
Mis012[m]: if that's what it is, then i support such improvement :)
<aka_[m]>
also 28nm driver had note about also maybe supporting picophy in future
<aka_[m]>
but picophy is already there
<aka_[m]>
in qcom usb hs driver
<bamse>
aka_[m]: i see, it's not always clear what variation of these ip blocks goes where :)
<aka_[m]>
yes
<Mis012[m]>
bamse: aka_ is talking about the errorneous mdm compatible in the femtophy driver
<aka_[m]>
and i spend 3 days to find i tried to overwrite register instead of writing to ULPI
<Mis012[m]>
just for context
<aka_[m]>
it was 32bit register with 8bits available
<aka_[m]>
writing anything to 8bits ended with entire register getting same value all over place
<aka_[m]>
this register(one written by MDM init seq) was about PLLPTUNE/PLLITUNE/BYPASS for 1.8V regulator
<Mis012[m]>
actually for the mdm, it's probably a safe bet that the ULPI registers will be the same as in 8916 TRM?
<aka_[m]>
well noone knows what is a diff between Pico and Femto but we can risk saying they are same extensions.
<Mis012[m]>
bamse: might need someone with qcs405 to test, in case I can't correctly decipher which part of the sequence actually need to be sequential :P
<Mis012[m]>
well, certain someone probably knows if they're the same, and can attest to whether that's the case, even if unable to say what the difference would be
<bamse>
Mis012[m]: i believe the phy maintainer has a qcs405
<Mis012[m]>
what a coincidence :P
<aka_[m]>
uh,
<aka_[m]>
I send some small patch and its applied now inside for-next, but it got comment by Marijn what will be with it.
<aka_[m]>
bamse i would like to ask.
<aka_[m]>
oh turns out you have added fixes tag.
<Mis012[m]>
bamse: do you think the femtophy even has those ULPI vendor registers, since it seems to have at least some of that stuff directly in MMIO
<aka_[m]>
Sorry for bothering you then.
<aka_[m]>
And sorry for not following guidelines im pretty new to it and noone had objections for that patch after i posted it for review.
<Mis012[m]>
the ones that the 8916 TRM explains and that are even still used as magic in picophy driver
<aka_[m]>
and getting any freakin review is hard.
<aka_[m]>
I kinda think on sending RFC for probably almost finished ICC driver for MSM8976
<aka_[m]>
i feel bit broken by 8976
<bamse>
Mis012[m]: i don't know, and it's not clear to me where in "the documentation" to look...
<aka_[m]>
ULPI extensions
<aka_[m]>
of 8016 TRM
<Mis012[m]>
bamse: in 8916 TRM it's under ULPI
<Mis012[m]>
and I'd bet that it's copied from "the documentation"
<bamse>
Mis012[m]: that's unfortunately not how the documentation i have is structured :/
<aka_[m]>
Table 6-87 Extended ULPI register map out of that one
<Mis012[m]>
bamse: well, I'd probably use pdfgrep
<bamse>
Mis012[m]: that would have been nice
<Mis012[m]>
they copied the ram training section, I wonder if that's why for db820c there was no TRM project :P
<Mis012[m]>
I'd pdfgrep for either ULPI or something more specific like `Access Extended Register Set`
<Mis012[m]>
which is exclusively found in that table
<Mis012[m]>
or PARAMETER_OVERRIDE_A
<Mis012[m]>
which is the thing at 0x80, and will likely be called that on femtophy as well even if the bits inside are different
<Mis012[m]>
bamse: I've compiled the POR vs what is being changed
<Mis012[m]>
wrt 8976 POR
<Mis012[m]>
could you or someone check what the POR values are on qcs405?
<Mis012[m]>
since at least 5 writes seem to be NOPs wrt 8976 POR
<Mis012[m]>
and I'd hedge a bet that setting the POR bit in USB_PHY_UTMI_CTRL5 should set the registers to POR values
<Marijn[m]>
<aka_[m]> "oh turns out you have added..." <- But what about the XO addition that may now get backported?
<Mis012[m]>
how old would the kernel have to be to be affected?
<Mis012[m]>
inb4 it's "no one but stubborn downstream-first vendors uses this" old
jhovold has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
<aka_[m]>
<Mis012[m]> "how old would the kernel have to..." <- these clocks came about 5.9 version
<aka_[m]>
so might be backported to 5.10/5.15 from what i understand?
<aka_[m]>
but who te f runs anything newer than 3.10 on that soc
<aka_[m]>
excluding these 4.9/4,4 xperias
<Mis012[m]>
aka_: well, the rpm name thing might be backported since it apparently fixes some issue
<Mis012[m]>
but the XO thing might break older kernels if the whole patch is backported?
<Mis012[m]>
Marijn: can't the patch be split by someone who cares about old kernels? :P
<Marijn[m]>
Mis012: Speaking of kernel etiquette...
<Mis012[m]>
what did I do? :P
<Mis012[m]>
doesn't seem fair for people to have to think about old kernels when submitting things...
<Mis012[m]>
there's a reason there are dedicated maintainers for caring about old kernels
<Marijn[m]>
That's not the point. The point is missing fixes tag during submission, not cc'ing the original author, nor splitting the patch. If you have to write drive-by sentences like "Also fix/add/do X", it's time to put that in a different commit instead.
<Marijn[m]>
I'm curious if the clock framework is now going to give us XO shutdown as long as this RPM clock is not used by anything
<aka_[m]>
<Marijn[m]> "That's not the point. The..." <- With how orginal author is hard to come by i doubt he will have time to respond.
<aka_[m]>
It's not like i put gun around someone's head and forced to apply, if i were told to split then i would do it.
<aka_[m]>
s/orginal/original/
<Marijn[m]>
Not CC'ing someone because you assume they won't read it at all is such a non-argument. The patch was just merged quickly and I only spotted it when it appeared on for-next. No one here is mentioning a patch being applied by force?
<Marijn[m]>
It's just miscommunication (and in general shows how hard it is to filter/channel a massive mailing list to the right people), but it can still be rectified if it only landed on -next
<Marijn[m]>
The dream and goal is upstream-first... But then you enable this and that and make "a few" dirty patches, end up with 130 patches on top of master and all motivation is gone to clean it up and sort it all out :)
<aka_[m]>
some 660 folks who are unable to rebase care about these branches too much
<Marijn[m]>
aka_[m]: I had ninges on 5.16 somewhere
<Marijn[m]>
(Sony's sdm630 platform)
<Marijn[m]>
Hehe yes of course
<Marijn[m]>
I have no idea then, there are too many random branches up there
<Marijn[m]>
What's broken? I don't think I have any patch for that
<aka_[m]>
max state is too high
<Marijn[m]>
How'd that came to be? This branch is filled with 8998 8150 and 8250 stuff :)
<aka_[m]>
its only mentioned once inside rpm-regulator dtsi
<aka_[m]>
later they restrict it to tubo
<aka_[m]>
*turbo
<aka_[m]>
once some driver request max state(wcnss subsystem hehehe) it blinks blue screen and die.
<aka_[m]>
i tried to increase spmi regulator loads to max what its possible
<aka_[m]>
they are all under smpa node with same resource name
<aka_[m]>
which is SMPA just like in upper definition for levels
<aka_[m]>
pinctrl have leftover function groups from some other driver.
<aka_[m]>
konradybcio: why you didn't mention about 2 weeks of pushing for 8976 patches so i could save my time and pain.
<aka_[m]>
😴
<lumag_>
Marijn[m], btw: I have been playing with the sda660-based device today. (How does lumag spend his holiday? Enabling another device in the queue). I got most of the things working, except the gpu. The kgsl_smmu hangs/resets the board during the probe. Does that ring any bell to you
<aka_[m]>
some tablet?
<lumag_>
aka_[m], ifc6560
<aka_[m]>
sbc, nice.
<Marijn[m]>
I've been pushing, and just asking Konrad some casual questions along the way...
<Marijn[m]>
Also it's been 3 years, how come we end up upstreaming the same patches at the same time and not asking for a statusupdate?
<Marijn[m]>
Perhaps the MMU patches that keep getting rejected?
<Marijn[m]>
I don't fully remember the details nor if it was pulled in after all, will have to look this up
<Marijn[m]>
Also can you explain to me what a holiday is 😳
<lumag_>
Marijn[m], that would be great.
<lumag_>
Marijn[m], a holiday is when you spend your time on the hardware that you wanted to play with for the last half of the year
<Marijn[m]>
I wonder how everyone on IRC clients is receiving these Matrix threaded replies... Is it messy? Should I stop with it before it's too late?
<Marijn[m]>
Also aka_ that's a 5.14 tree with all my messy commits on it
<aka_[m]>
Marijn[m]: with nothing for 8976 on it after first look
<Marijn[m]>
No, we were talking about 660 users a little while ago. Don't think there's anything recent for 8976 on there
<aka_[m]>
ah.
<aka_[m]>
Its kinda old tho.
<lumag_>
Marijn[m], thanks, this looks similar enough to what I oversee.
<Marijn[m]>
Everything is old there, and it makes me sad if you hadn't noticed yet. And I don't think this includes the sm6125/sm8150/sm8250/sm8350 progress trees
<lumag_>
I'll check later.
<aka_[m]>
Marijn[m]: i don't think these are in big demand across pmos community.
<aka_[m]>
whatever.
<Marijn[m]>
I'm not doing this for anyones demand, nor pmos, fwiw
<Marijn[m]>
Personally I'd rather work on the newer SoCs, much more activity upstream and makes for a nice daily driver.
<aka_[m]>
Marijn[m]: i think you are not alone in that.
<aka_[m]>
Newer stuff probably need less hacks than old stuff.
<Marijn[m]>
The hardware is more complicated with more stuff offloaded though
svarbanov has joined #linux-msm
<lumag_>
Marijn[m], konradybcio: another question that might ring a bell in your memory: the 660 resets soon after probing the bam-dma device. Even if I remove it from all uarts
<konradybcio>
didn't face taht
<lumag_>
konradybcio, ack
<lumag_>
konradybcio, what was the last kernel that you used for 660/630?
<konradybcio>
last I remember I used my 630 device as a flashlight when power went out, maybe Marijn is the better person to ask
<lumag_>
DDD
<Marijn[m]>
lumag_: 5.16
<Marijn[m]>
That's what I tested Bjorn's LPG series on
<Marijn[m]>
It's "queued up" for a rebase, but as said I have no time for anything
svarbanov has quit [Ping timeout: 480 seconds]
<lumag_>
Marijn[m], thanks, I'll try using that as a base.
<lumag_>
I had to use a holiday to play with the device. The next step would be to find another holiday to play the mdp5 vs dpu game on it.
<Marijn[m]>
lumag_: Perhaps I could rebase it on 5.18 and see what happens
<Marijn[m]>
I might as well publish the dirty result, since those dirty commits are on a public github already 😅
<lumag_>
Marijn[m], if/when you have time.
<lumag_>
For me it's not the very urgent item.
<Marijn[m]>
lumag_: I'd like to send 8976 first and clean up the DSI clock cleanup as promised :)
<Marijn[m]>
But rebasing is usually pretty quick
<lumag_>
Marijn[m], but then testing is not
<Marijn[m]>
If it runs it runs, I don't have very specific compatibility tests
<Marijn[m]>
lumag_: That does raise a concern though. With android (latest mesa) 5.17 is fine, 5.18 hangchecks the a510. On gnome however, both kernels hangcheck. On 5.18 some boots still result in sometimes working display but occasional hiccups or corrupted triangles shown on screen.
<Marijn[m]>
(I have yet to retest whether some boots are actually fine on 5.17, or older)
<aka_[m]>
I see junk after upgrading to gnome 42
<aka_[m]>
In setting app mostly
<aka_[m]>
Happens on 8976 and 8956
<aka_[m]>
s/8956/8953/
<lumag_>
Marijn[m], this question better be asked on the #freedreno