<Marijn[m]>
lumag: I can try... will have to dig out my 8998 device from under a pile
<lumag>
Marijn[m], a r-b will be enough
<Marijn[m]>
lumag: ack, yes, doesn't seem like a test would make sense here as I'd have to figure out how to specifically poke at those SSPPs
<Marijn[m]>
lumag: interesting
<Marijn[m]>
shouldn't you use the non-cursor mask here?
<Marijn[m]>
I'm looking at downstream and those two entries are indeed DMA2 and 3 at xin 9 and 13... But there's also two cursors at xin 2 and 10
<Marijn[m]>
(And the clk controls for that are defined too)
<lumag>
Marijn[m], I think the initial submission lacked support for cursor planes (which are very lightweight SSPP blocks). So msm8998 followed the rest of the platforms which don't have separate cursor planes and just repurpose DMAn for hardware cursor
* lumag
would have preferred if Qualcomm had kept cursor SSPPs at least for resource-limited platforms like sc7x80 or sm6115/qcm2290/etc.
<Marijn[m]>
Yes I see what you mean in patch 2/2
<lumag>
rawoul, interesting. What is your platform? Do you have any additional details (like CPU speed bin, etc)?
<Marijn[m]>
lumag: fwiw the cursor planes weren't ported from `msm8998-mdss.dtsi` to `msm8998-sde.dtsi` on our sonyxperiadev (SODP) downstream kernel, that may have caused this confusion :)
<lumag>
rawoul, would, I'd enjoy seeing these patches on the mailing list
<rawoul>
I wish I had more time to clean up the patches...
<Marijn[m]>
Ah yup, should have checked my notes instead of failing to recall the abbreviation
<Marijn[m]>
rawoul: yeah, would love to see those as well - seems you found and fixed the same issue as Dmitry with the DMA2/3
<konradybcio>
be careful when taking inspiration out of open devices device trees.. some creativity usually happened when they were ported..
<lumag>
konradybcio, :D
<lumag>
rawoul, we can really hope that find more time. The patches look good. And CEC support is a great addon :-)
<Marijn[m]>
konradybcio: yeah exactly... Unless you say creativity was placed in -mdss, and removed/skipped in -sde :)
pevik_ has quit [Quit: Reconnecting]
pevik_ has joined #linux-msm
swdefrgthfgjhk has quit [Ping timeout: 480 seconds]
<mal>
krzk: apq8026 devices also include msm8226, both apq8026 and msm8926 are very close to msm8226, main difference is the type of modem
<krzk>
mal: yes, which can mean that apq8026 is not compatiblel with msm8226
<krzk>
and now how is it in your case?
<Newbyte>
krzk: if I recall correctly, in the vendor sources the apq8026 and msm8926 dtsis include the msm8226 dtsi, but I'd have to check again
<Newbyte>
either way, you have a point
<Newbyte>
I will investigate
<krzk>
Newbyte: what vendor sources are doing is secondary thing... They are many times not correct and they do stuff which is aesier for them. Or convenient. They do not design how it should be designed.
<Newbyte>
krzk: very true. do you have any better sources to suggest?
<Newbyte>
for information
swdefrgthfgjhk has joined #linux-msm
<krzk>
Newbyte: vendor sources might tell you how similar the devices are, e.g. whether modem is the same or not. wikichip.org and some other sources in internet might also indicate whether same blocks are used or not
minecrell has quit [Read error: Connection timed out]
minecrell has joined #linux-msm
<z3ntu>
To my knowledge all these chips 8x26 are the same chip essentially, with just RF being different
<z3ntu>
Same with 8x74
indy has joined #linux-msm
indy has left #linux-msm [Leaving]
<konradybcio>
i believe all corresponding msm/apq chips should be the same, modulo revisions (e.g. msm rev 2.0 may map to apq rev 1.0 or so)
<konradybcio>
the only exception is the cancelled apq8092 which had newer mdss than msm8992..
<konradybcio>
source: lk
pevik_ has quit [Ping timeout: 480 seconds]
pevik_ has joined #linux-msm
pespin has quit [Remote host closed the connection]
deathmist2 has quit [Remote host closed the connection]