ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
junari has joined #linux-msm
junari has quit [Remote host closed the connection]
svarbanov has quit [Remote host closed the connection]
pespin has joined #linux-msm
<marc|gonzalez> bryanodonoghue: no one picked up the msm8998 venus series, meaning it won't be in 6.10-rc1 right? (grumble)
<krzk> marc|gonzalez: yep, usually cut off is 1 or 2 weeks before merge window, but definitely no features/new things should be picked up after merge window starts.
<marc|gonzalez> krzk: since merge window opening is variable, a cutoff before such an event makes little sense
<krzk> marc|gonzalez: really please do not ping after merge window starts (so today...) for anything else than fixes
<krzk> and such fixes should not be combined with regular work
<krzk> marc|gonzalez: what do you mean? merge window is not variable... it's almost fixed/known
<krzk> There are at least two crystal balls telling the time :)
<marc|gonzalez> krzk: sometimes it's 7 candidates, sometimes 9.
<krzk> marc|gonzalez: anyway, even if you believe it is variable, the cut off is then rc6 for most maintainers.
<marc|gonzalez> krzk: thanks, that's good to know!
<krzk> That was media right? So unfortunately folks are very busy :(
<marc|gonzalez> media is a broken subsystem
<marc|gonzalez> I once posted a patch which was quite well done and factorized lots of open code with DT equivalents
<marc|gonzalez> and got not one comment until 20 months later
<marc|gonzalez> (and it looked like some automated patchwork reply)
<krzk> One more hint: please do not put DTS patch in the middle of patchset, as this suggest dependency which is either frowne upon or no allowed.
<marc|gonzalez> which series?
<krzk> So please send v5 after the merge window, moving the DTS patch to the end.
<krzk> Your venus, isn't this what we talk about?
<marc|gonzalez> I don't understand your point about moving the patch
<marc|gonzalez> DT first then driver fixups made sense to me
<krzk> You do not understand the reason behind or the action?
<marc|gonzalez> I do not understand what you meant about DT patch last
<krzk> I did not write about DT. I said DTS.
<krzk> Please read again: DTS.
<marc|gonzalez> dude
<marc|gonzalez> I am failing to understand the finer points you are trying to make
<marc|gonzalez> since I can't submit device tree binaries, it seems obvious in this context that device tree and device tree source are synonymous
<krzk> DTS shoudl be the last patch in the series, not the middle. Why? I said: it suggests dependenct which is NOT ALLOWED.
<krzk> No, DT by many people are is understood as DT bindings. How do I know what you understand by this?
<marc|gonzalez> so patch 1 the binding should go first, then patch 2 should be driver fixup, then patch 3 should be the DTS nodes?
<marc|gonzalez> would make more sense to have all DT related crap contiguous to me
<krzk> Ssrsly, you are not helping your case and then surprised patches got not merged...
<krzk> DTS is independent hardware descripion. I would argue it should not even be part of these series, but if you put it as part of the series, it is ALWAYS independent thus always at the end.
<marc|gonzalez> I'll blow up the series in single patches
<marc|gonzalez> I am growing tired of jumping through these hoops
<travmurav[m]> marc|gonzalez: I think it's more like "stuff gets documented" -> "stuff is implemented per documentation" -> "newly added stuff gets used"
<travmurav[m]> and afaiu we're trying to always make sure new drivers don't break old dts, so if you change dts first; then change the driver, it may look like you're avoiding a breakage of old dts
<travmurav[m]> but speaking of dts and bindings
<travmurav[m]> say I have a display panel - an assembly of glass; digitizer and touch controller; lcd cell and lcd controller. We consider digitizer separate already; but glass+lcd+controller as an assembly is kind of a "dedicated device"
<travmurav[m]> Vendors sometimes multi-source the lcd+controllers from different vendors
<travmurav[m]> so from OS pov there may be display compatible=x or display comaptible=y depending on what was put into the device; but otherwise the binding would be the same, same list of resets and regulators
<krzk> marc|gonzalez: single patches? Then I don't think we understood each other... Please read submitting patches - the kernel one and the one in the bindings directory.
<travmurav[m]> and generally how we handle most displays like that is we just hardcode the (almost always device(phone not panel)-specific) init sequence in the driver since the documentation for the controller is usually nonobtainium afaik
<travmurav[m]> say I have a device with 5 such known possible display panels, and I use the bootloader to detect which one is used and fixup the dtb accordingly, by addign the correct compatible. Bootloader finds the panel by a "generic" compatible (i.e. "<board_compatible>-panel") and adds a specific compatible to the list
<travmurav[m]> krzk: do you think it's fair to then treat the generic compatible + 5 specific compatibles as the same binding doc? i.e. have enum of 1+5 values or i.e. 1 + 5 pairs of <specific>, <generic>?
<krzk> one more remark, although repeated on the lists many times: if you send patchsets separately, please always provide link to the bindings in DTS path, in its changelog (---), otherwise you will get a question where the bindings are
<krzk> travmurav[m]: I don't understand the question - how using or not using 5 compatibles make a binding the same?
<krzk> The choice of binding doc - whether it is one or multiple - is organisational and readability
<travmurav[m]> krzk: I'm asking if having "display of phone x" as a dedicated compatible is fine, where "display of phone x" may be "lcd_a+controller_a" or "lcd_b+controller_b" that have same gpios and regulators
<travmurav[m]> so "display of phone x" is a "generic" compatible that means "one of 5 actual displays"
<krzk> You almost always need specific compatible, I hope that's clear (and provide serious explanation why specific compatible is dropped/not suitable)
<krzk> Usually combination of devices is not really a device... so compatible for a thing called "display" seems confusing. snd card is a bit exception here, but snd card is semi-software construct
<krzk> or rather view of multiple components tied together in some typical way
<krzk> but I really don't get what it has anything to do with venus... or you just hijacked the topic?
<travmurav[m]> krzk: nothing to do with venus, just saw you here and wanted to ask
<travmurav[m]> : (specific compatible) <- yeah of course, current setup is that we have 5 specific compatibles (and thus 5 drivers) but in dts we only have generic one, that at runtime (in bootloader) gets amended with specific one
<krzk> there is a dedicated channel for DT talk...
<krzk> 5 specific compatibles doe snot mean you have 5 drivers... that's quite independent
<travmurav[m]> krzk: yeah, of course, "our implementation" of those bindings is, just putting into the context
<travmurav[m]> but those are downstream and I wanted to check in to make sure I'm not doing anything that you think won't fly
sskras has joined #linux-msm
<travmurav[m]> krzk: so in my case as an implementer, the "generic" compatible is a convenience for the bootloader to find the node and fixup it to have the actual specific compatible, and I'm trying to also justify it semantically as a more overarching compatible for "any display panel of this device"
<travmurav[m]> (of course replacing compatible is only my implementation of that, and another implementation could match the generic compatible and do different magic)
<krzk> travmurav[m]: then that sounds like not a proper hardware description, but hack for your software/firmware stack
<travmurav[m]> krzk: so having generic compatible is not acceptable in your opinion? Is there some better way I can model this then?
ungeskriptet is now known as Guest6325
ungeskriptet has joined #linux-msm
ungeskriptet is now known as Guest6327
ungeskriptet has joined #linux-msm
Guest6325 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest6329
ungeskriptet has joined #linux-msm
ungeskriptet is now known as Guest6330
ungeskriptet has joined #linux-msm
Guest6327 has quit [Ping timeout: 480 seconds]
Guest6329 has quit [Ping timeout: 480 seconds]
Guest6330 has quit [Ping timeout: 480 seconds]
<bryanodonoghue> marc|gonzalez need to get Acked-by from stan or vikash
<marc|gonzalez> bryanodonoghue: what?
<marc|gonzalez> bryanodonoghue: Vikas Acked the patches a week ago.
<bryanodonoghue> so you have all the acked and rb you need
<marc|gonzalez> Right. I had expected Bjorn to pick up the series (or at least the msm8998 bits) before the end of the week
<marc|gonzalez> Since the series had been in dev for 2 months...
<marc|gonzalez> And it had been mostly cosmetic trivial change requests for the past several weeks
<marc|gonzalez> oh well, it doesn't matter in the grand scheme of things
f_ has joined #linux-msm
marc|gonzalez has quit [Quit: Leaving.]
jessica_24 has joined #linux-msm
pespin has quit []
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
<Marijn[m]> <luka177[m]> "Very interesting, apparently..." <- That's why I suggested to turn _off_ the reset: you're probably not taking it _out of reset_ correctly and that is why it remains black.
<Marijn[m]> <luka177[m]> "it seems like some data gets..." <- Does this colorful pattern move/change when new frames are presented?
<luka177[m]> Marijn[m]: yes it do
<Marijn[m]> Then there's a clear desync in how the DSC hardware blocks are configured, versus how the panel is interpreting it (based on the PPS that is sent)
<Marijn[m]> At least it seems both interfaces are sending data
<Marijn[m]> I really don't dare to say where we stand on this, given that neither of the duality of DSI nor DSC seems to have been tested in video mode. Nor even single-DSI DSC on video mode :/
<luka177[m]> Marijn[m]: single dsi dsc was tested as far as i know
<luka177[m]> on poco x3
<Marijn[m]> Bundling them all together is probably only asking for more trouble
<luka177[m]> as well as dual dsi non dsc video mode on xiaomi pad 5+ aka xiaomi elish
<luka177[m]> both with out of tree patches for sure
<Marijn[m]> Exactly: none of it is ready enough to be merged upstream. Maybe they work in isolation. Maybe they work by magic on one specific device
<luka177[m]> Marijn[m]: well lumag's patches to improve active CTL support are for sure used more then one device
<Marijn[m]> Those are specifically patches I am not referring to (because I modified/updated those patches, and have them actively tested/used on many devices). They are all command mode though.
<luka177[m]> <luka177[m]> "image.png" <- just to clarify, bottom part of screen is static
<luka177[m]> around 1/3
<luka177[m]> (a "black" screen)
<luka177[m]> and kmscube, weirdly not centered
<Marijn[m]> Yeah because it cannot decode the image. What would really help is to compare some common register values (DSC block, DSI host) with a known-working downstream kernel, together with the PPS and other DCS that it sends to the panel
<Marijn[m]> Also CTL and PP block register values are useful
adomerle has joined #linux-msm
<adomerle> Marijn[m]: Well, I compared dumps, I didn't find anything suspicious.
<adomerle> Although it is possible that this is not the case on the latest next branch
<Marijn[m]> I don't know what you classify as "anything suspicious". Sometimes the differences/details are miniscule