09:54 <aka_[m]> krzk: how do i do it if gpu.yaml no longer contains adreno gpus in it, there is no reason to include adreno-common in it

09:59 <krzk> aka_[m]: first, it does cntain them, please carefully read the steps I suggested... but if the result is to remove adreno from it, then steps would be different

10:00 <krzk> neither cover letter nor commit explains what you want to achieve

10:53 <aka_[m]> krzk: so:split gpu.yaml into adreno-common and include it, then move each oneof match into separates and at the end convert imageon to standalone schema?

10:55 <krzk> aka_[m]: I don't know what you want to achieve, so I will not give advise.

10:55 <krzk> Cover letter also did not tell me what is the problem and what you want to achieve

11:09 <aka_[m]> 1)Try to document one clock for gpu 2)be told it's new gpu and you should enforce clocks order with -if on compatible, 3)but you know we don't want one file to be full of ifs you should split them, 4)split it into separate schema files 5) be confused because you were told to do things you don't understand and expect to know exactly what you want.

11:13 <krzk> aka_[m]: When you send any patch or any patchset, it is important to explain why you are doing it. For a bit more complex work, sometimes it is important to explain also the overall architecture or bigger picture.

11:13 <krzk> It seems in this case, neither me nor you know these...

11:14 <krzk> So probably lumag, who I think asked you to do this, could help with some explanation.

11:14 <aka_[m]> I would say we want to reduce complexity of schema

11:14 <krzk> What I am looking is: what are these devices and what do you want to achieve at the end. What is going to be in each schemas you touch?

11:14 <lumag> krzk, I think it was you in one of your review letters.

11:14 <lumag> more or less so

11:15 <krzk> lumag: yeah, but I have no clue about this particular device

11:15 <krzk> aka_[m]: also does not know, so who knows?

11:15 <lumag> which device are we talking about?

11:15 <aka_[m]> We want to: reduce schema complexity(less ifs), and enforce clock orders

11:16 <krzk> for example in typical cases my advice from email works. Here it aparently is not valid...

11:16 <aka_[m]> lumag: it's gpu.yaml being split into adreno-common and adreno-xyz.yaml

11:17 <aka_[m]> Gpu.yaml ends as imageon schema

11:17 <lumag> imageon = a2x

11:17 <lumag> a2xx

11:17 <lumag> See imx51/imx53 devices

11:17 <aka_[m]> I described them in examples

11:18 <aka_[m]> Its a bit frustrating yaml keeps me away from dts part

11:19 <aka_[m]> Ok have to get back to work

11:19 <lumag> aka_[m], you might as well rename gpu.yaml to amd,imageon.yaml, if that's the question

11:20 <lumag> I think the general krzk's comment was to move things one by one.

11:20 <krzk> the schema stayed as msm/gpu.yaml, thus obviouos confusion - how could it be not an Adreno?

11:21 <aka_[m]> Naming is confusing

11:21 <aka_[m]> Ok I have some idea

11:21 <aka_[m]> Will try do it later

11:22 <aka_[m]> So gpu.yaml should also include common or should I also rename it to a200.yaml?

11:23 <krzk> aka_[m]: if gpu.yaml is not adreno at the end, then rather do not include

11:24 <krzk> And that's one of confusions all this started. Your patchset should explain this.

11:26 <aka_[m]> So in theory I should make adreno 2xx which will pick imageon and drop gpu.yaml at the end

11:26 <aka_[m]> I will need to mod gpu.yaml each time I move each Gen into separate schema set

11:26 <aka_[m]> Would it hurt to move 2 or 3 schemas per commit?

11:27 <aka_[m]> Then I can replace pattern matching in gpu.yaml

11:28 <aka_[m]> lumag: what do you think?

11:28 <aka_[m]> I might have poc ~6pm

11:28 <lumag> aka_[m], there is no hurry :-)

11:29 <lumag> krzk, Imageon-2xx = Adreno-2xx. Qualcomm just licensed the IP and then bought it from AMD.

11:29 <krzk> aka_[m]: In case I did not link it before, my recommended way of doing is: https://lore.kernel.org/linux-devicetree/20240126-dt-bindings-pci-qcom-split-v3-0-f23cda4d74c0@linaro.org/

11:30 <aka_[m]> lumag: tbh I really want to ship all patches I have they are in stale form for year already, Its 3y I'm messing with this platform and we aren't anywhere still on upstream

11:30 <lumag> :-)

11:30 <lumag> aka_[m], A question from my side would be, do we really need adreno-common.yaml?

11:31 <krzk> another way is to include common in original schema, it all depends. Patchset must be readable, reviewable and split into logical chunks.

11:31 <aka_[m]> lumag: That was not my idea

11:31 <aka_[m]> But i dont mind not having shared

11:31 <krzk> lumag: yes, you need single definition of qcom,gmu

11:32 <aka_[m]> I will need to love props

11:32 <lumag> Hmm, if I was originator for that idea, then feel free to yell on me :-)

11:32 <aka_[m]> *move

11:32 <krzk> aka_[m]: drop all "Device tree bindings for" from descriptions. Bindings should describe hardware, not bindings.

11:33 <lumag> krzk, there will be a single definition, at a6xx

11:34 <lumag> We might be more concerned about the zap-shader, which is used by a5xx and a6xx. But literally, I think having it duplicated might be less trouble compared to adreno-common.

11:34 <aka_[m]> lumag: a540 no gmu?

11:34 <lumag> aka_[m], no.

11:34 <lumag> It has built-in GPMU

11:35 <lumag> a530 (8996) and a540 (8998) do

11:35 <lumag> ... have a built-in GPMU

11:35 <krzk> lumag: then common schema might not be needed.

11:35 <krzk> Kind of depends whether it saves any code...

11:37 <aka_[m]> Ok so I get some general idea now

11:37 <aka_[m]> But still describing reasoning is kinda ehh

11:38 <aka_[m]> Validating clock order when gpus are already being defined in shared soc dtsi feels odd

11:38 <aka_[m]> Unless someone uses this schema to build new dts

11:38 <aka_[m]> Or if ip is shared on other socs

11:39 <aka_[m]> Like a610 being used on sm6115, 6125,6225

11:40 <lumag> krzk, is it possible to reference properties from the earlier schema in the latter generation?

11:40 <lumag> Or we'd better stay away from that?

11:42 <aka_[m]> lumag: if then allof? But that would work with file only

11:43 <lumag> You don't need allOf in such case

11:46 <lumag> aka_[m], I'd say, ignore duplication for now

16:31 <aka_[m]> lumag: is it any better now?

16:31 <aka_[m]> https://github.com/Kiciuk/linux/tree/temp_reworked_schemas

18:00 <krzk> lumag: each property should have just one definition (type/description), so if two schemas use a vendor property, then probably some sort of common schema should be used

18:00 <krzk> referencing other schema properties could work... I saw such patterns, but I am not sure if it is more readable.

19:52 <lumag> aka_[m], I took a glance at the first few patches.

19:52 <lumag> Hope that helps

19:54 <aka_[m]> noticed,thanks

19:55 <aka_[m]> still probably need different commit msgs and stuff

19:55 <aka_[m]> somehow now i got stuck with something else, motorola bootloaders are so big pain to work, anything else in dtbs and it fails to boot lk2nd

19:55 <aka_[m]> wish i had confidental bl sauce lol

20:28 <konradybcio> what if you change the dtb without changing the size

20:28 <konradybcio> e.g. change a character in a string

20:31 <aka_[m]> konradybcio: managed to make lk2nd somehow wipe it out

20:31 <aka_[m]> it got flash locked

20:31 <aka_[m]> how?

20:31 <aka_[m]> made two dtbs with different board-id

20:31 <aka_[m]> normal image have multiple dtbs

20:32 <aka_[m]> and its fine

20:32 <aka_[m]> probably have board to replace

20:32 <aka_[m]> unless i can restore with unsaved data xD

20:32 <aka_[m]> atleast i have imei on tray

20:32 <aka_[m]> but just one

20:33 <aka_[m]> maybe lk2nd should have cog to not touch moto stuff

20:36 <aka_[m]> konradybcio: uff seems like new version of moto recovery allows to enter imei

20:36 <aka_[m]> and it downloads firmware

20:36 <aka_[m]> wonder if i will get data restored

20:36 <aka_[m]> fuck

20:36 <aka_[m]> cannot do it

20:36 <aka_[m]> shows error

20:38 <konradybcio> do motos have non-fastboot flashmodes?

20:38 <konradybcio> or is the problem lack of fw?

20:39 <aka_[m]> edl

20:39 <aka_[m]> but i doubt i can fix cid/imei with it

20:56 <aka_[m]> konradybcio: blank flash brought it back to live

20:58 <aka_[m]> imei is also back

20:58 <aka_[m]> i need to backup shit

21:06 <konradybcio> remember to not include userdata in your backup

21:06 <konradybcio> unless you wanna compress it :P

21:07 <aka_[m]> konradybcio: i was kinda hot when seen it was flash locked