<DuClare>
Assuming your probe function is decompiled correctly
<DuClare>
0xfffff000 < uVar2 looks liks IS_ERR()
<DuClare>
*(int *)(spi + 0x40) = iVar1; could be spi_set_drvdata() but that probably becomes clear when the rest of the functions are decompiled
<DuClare>
(Obviously iVar1 sould be struct st7701s*)
<DuClare>
Oh yea that's not the full struct, there's more stuff after
<DuClare>
Or not.
<DuClare>
Well, that's everything probe touches.
apritzel has joined #linux-sunxi
<LordKalma>
there's a bunch of stuff missing still
<LordKalma>
the probe function has to call `spi_set_drvdata` which will require more stuff
<LordKalma>
I have to create a dmr_panel_model
<LordKalma>
and some other stuff
<LordKalma>
I'm writing get_modes now
<LordKalma>
I'll leave probe to the end, since that's clearly where all the more complicated magic will be
<LordKalma>
thanks for the comments :D
<apritzel>
LordKalma: I would strongly recommend you find a similar driver (some other SPI panel) and copy that file, there you get all the Linux driver boiler plate for free
<LordKalma>
yes
<LordKalma>
for each function i'm making what I'm doing is searching, for example, int.*_probe( in regex mode
<LordKalma>
and look at how they are written
<LordKalma>
and putting pieces together
rajkosto has quit [Quit: Leaving]
JohnDoe_71Rus has quit []
samespoon has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
JoaoSchim has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
<jernej>
apritzel: can you push AC200 code somewhere? I'm eager to test it
<apritzel>
jernej: yeah, will do later tonight. There are open questions, still, for instance about the PHY clock (which I hack on the back of the reset controller atm)
<apritzel>
jernej: wasn't there some board where the PHY didn't have a 25 MHz oscillator, but was driven by the SoC, via some clock pin?
<apritzel>
I am looking for rationale to introduce a clocks property for the generic PHY binding, plus the respective driver code
<apritzel>
for the two (external GBit) PHYs I checked, they require an external clock input for the core logic (not MDIO nor *MII)
<apritzel>
which we don't model at the moment
<apritzel>
and get away with it because most board use an XTAL (so it would be fixed-clock anyway)
<jernej>
apritzel: that may be OrangePi 3 LTS, but I'm not sure
<jernej>
now, if I could only find schematic for it
<jernej>
apritzel: I actually don't know any board, where EPHY would need external clock
<jernej>
I checked all my suspects
<apritzel>
jernej: ok thanks, I thought I saw this somewhere, but even the OrangePi Zero2 has a 25 MHz crystal
<jernej>
yeah, but idea about introducing clock property seems legit
<apritzel>
and the OPi 3 LTS schematic also shows an oscillator (OrangePi website: Service&Support -> User manual -> schematic)
<jernej>
yeah, I found it at the end
<apritzel>
btw, is the OPi3 LTS any good? the specs sound reasonable, even though it's only one USB 3.0 port now. Does that use the same PHY timing requirement as its infamous predecessor?
<jernej>
I don't know, I don't have it
<jernej>
but it's different PHY, one that needs actual driver in order to be useful
<jernej>
although LTS wifi+bt combo is better on paper, it's far worse driver wise (not mainline, bad vendor code)
<apritzel>
that's the same one as on the OPi Zero2?
<jernej>
apritzel: why would PHY in AC200 need clock?
Hazematman[m] has left #linux-sunxi [#linux-sunxi]
<apritzel>
there is this clock gate, in AC200 I2C register 0x14
<apritzel>
I model this reset bit in there, by making the EPHY control driver a reset controller, and the PHY can use that already, without further code on the PHY side
<apritzel>
I feel the clock gate deserves the same treatment, but this requires extending the PHY code (short of various hacks, of course)
<jernej>
apritzel: I would say that clocks are actually part of PHY (reset) controller, not PHY itself
<apritzel>
yes, that's the plan, but they need to be enabled by the PHY
<jernej>
why?
<apritzel>
well, because the PHY is the clock consumer
<apritzel>
we could just enable the clock gate once, at probe time
<apritzel>
(that's what I do now)
<apritzel>
the point is that I use the same logic for the reset line, and we need that, because that creates the dependency that ensure the proper probe order
<jernej>
while PHY needs clock, I would say reset controller needs it too, so it's imo good enough to enable it in reset controller
<jernej>
we are talking about clocks in AC200 0x14 register, right?
<apritzel>
yeah, I need to double check, from what I saw the reset and clock gate affects the actual PHY, not the PHY controller (the I2C registers)
<apritzel>
so the AC200 EPHY registers at 0x6000 stay live, even when clock and reset at 0x14 are toggled
<apritzel>
but the PHY doesn't probe if they are down
<jernej>
oh, interesting
<apritzel>
I agree that this extra grouping in the AC200 register frame suggests otherwise
<apritzel>
and I was thinking about making the AC200 MFD parent a clock provider and reset controller, using indexes to select the other clocks (for audio, or this system PLL)
<apritzel>
but I am not sure this would create the dependency that we need, because the reset provider would be the parent of this EPHY control device
<apritzel>
jernej: you don't have any plans or ideas about a driver for the audio part, I guess?
<apritzel>
I wonder if it would help to sketch this at least, to see what we would need and how this would fit in
vagrantc has joined #linux-sunxi
<jernej>
no, I'm not familiar with analog audio. I hope that smaeul or megi would take a shot at it
<jernej>
I actually have ideas for CVBS part, but currently no time to tackle it
<apritzel>
jernej: can you briefly say what resources you would need, and if there would be two drivers involved, like with the PHY?
<jernej>
let me take a look again
Danct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
<jernej>
apritzel: CVBS encoder is only one driver. TCON LCD node would be connected to encoder and encoder to CVBS connector node via OF graph
<LordKalma>
these are the last two instructions that I'm missing
<LordKalma>
I can't seem to understand what they are
<megi>
connector type?
<LordKalma>
the struct for drm_connector is so nested that copying it into ghidra to see what's at 0x22 and 0x1C is a pain
<apritzel>
LordKalma: if I count correctly, then "struct drm_mode_object base;" starts at offset 0x1c
<LordKalma>
apritzel, this is from 5.8
<LordKalma>
that's important
<LordKalma>
since these structs have moved *a lot*
<jernej>
It's important that you tell what is definition of connector inside ghidra
<jernej>
index 0x1c means different location if array type is int or char
<LordKalma>
it would help, yes, even though sometimes ghidra decides to be annoying and for example, doesn't let me retype what it automatically decided it was an int as a pointer to something
<apritzel>
v5.8, was this before Covid? ;-)
<apritzel>
in v5.8 it looks like "struct drm_object_properties *properties;" is at 0x1c, so byte offsets are rather unlikely
<LordKalma>
what's weird is that no other function seems to have anything extra like this
<megi>
I doubt get_modes will be touching that
<megi>
it's likely just adding modes and modifying display_info or whatever
<LordKalma>
some set `connector->display_info.bus_flags =` and some `connector->display_info.bpc = 8`
<jernej>
I believe it's display_info.width_mm and display_info.height_mm
<LordKalma>
but never a =4 and an =8
<LordKalma>
jernej, those were there, and I've done them already