ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<apritzel> as planned, the resets property of the PHY node triggers probing and intialisation of the AC200 "EPHY control" driver
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
<jernej> apritzel: nice!
Daanct12 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
ftg has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
Daanct12 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
<LordKalma> it's missing the two complicated functions and fixing whatever the `struct st7701s` ought to be
<DuClare> It probably looks like struct st7701s { struct drm_panel panel; struct spi_device *spi; struct gpio_desc *reset_gpiod; struct regulator *regulator; };
<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> correct
<jernej> well, I think so
<jernej> supposedly AXP806 works only on I2C bus, but not RSB
<jernej> I still doubt it, but I can't test anything without board
samespoon has quit []
<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> your tips have been great
apritzel has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
Danct12 has quit []
Danct12 has joined #linux-sunxi
JoaoSchim has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
JohnDoe_71Rus has quit []
tllim has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
<LordKalma> I could use your help
<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
<LordKalma> those were L17 and L21
<megi> I'd compare locations with what that for connector->display_info.height_mm were, it shall bne pretty close
<LordKalma> wait, if 0x1b was connector->display_info.height_mm
<megi> 0x1a for vs 0x22 / 0x1c
<LordKalma> yeah
<megi> yeah, it's inside display_info
<LordKalma> if 0x1b was connector->display_info.height_mm * it's whatever is next
<jernej> .bpc = 8 makes total sense
<LordKalma> what's bpc?
<LordKalma> okay, that makes sense
<LordKalma> and 0x22 would be?
<jernej> and counting onwards, 0x22 is indeed bus_flags
<LordKalma> yeah, seems so
<LordKalma> interesting
<LordKalma> thanks!
<LordKalma> yet again you've been the most helpful
<LordKalma> you collectively :)
<jernej> DRM_BUS_FLAG_PIXDATA_POSEDGE
<LordKalma> now called DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE apparently
<jernej> ah, yes, that was renamed
<jernej> btw, according to bpc comment, it shouldn't be needed
<jernej> but you can play with that once everything works
<LordKalma> "Used by HDMI and DP outputs." yeah
<LordKalma> so idk, whatever
<jernej> only probe left, right? that shouldn't be too hard
<LordKalma> yes, probe left
<LordKalma> probe is the largest one, and the one that will have a lot of nuance to deal with I bet
<LordKalma> including (I think) figuring out how the parameters you write in the DTB like the reset pins are actually passed onto the driver
<LordKalma> really, again, thank you all for your continued support. This is literally my first time messing with the linux kernel
anarsoul|2 is now known as anarsoul
gsz has quit [Quit: leaving]
rajkosto has joined #linux-sunxi
tllim has quit []
hlauer has quit [Ping timeout: 480 seconds]
ftg has quit [Ping timeout: 480 seconds]