ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
stikonas has quit [Ping timeout: 268 seconds]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
archetyp has quit [Remote host closed the connection]
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
lurchi__ has quit [Ping timeout: 252 seconds]
lurchi_ has joined #linux-rockchip
lurchi_ is now known as lurchi__
dsimic has quit [Ping timeout: 256 seconds]
mmind00_ has joined #linux-rockchip
archetyp has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
crabbedhaloablut has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
dsimic has joined #linux-rockchip
warpme__ has joined #linux-rockchip
mmind00_ is now known as mmind00
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
archetyp has joined #linux-rockchip
dsimic has quit [Quit: Client closed]
dsimic has joined #linux-rockchip
<CounterPumpkin> mmind00: will there be a second GIT PULL for dts changes this cycle?
<mmind00> CounterPumpkin: yep
<CounterPumpkin> Okay, thanks for confirming. Was worried my I2S/TDM driver would go without dts changes for 5.16 :D
<mmind00> CounterPumpkin: I'm still somehow struggling a bit with that reset-hack writing directly to the cru
<CounterPumpkin> I'd implement a generalised atomic assertion of two resets if literally any other driver needed this, but I don't see the benefit of adding an API for just one series of SoCs when they always come with that reset controller.
<CounterPumpkin> (plus, I don't have hardware that uses this feature of the controller right now, so testing would be a pain)
Rayyan6 has joined #linux-rockchip
<mriesch> mmind00: does it make sense to send out a driver skeleton that is correct but does not implement any functionality?
<mriesch> concrete example: i have a first commit at hand that introduces a vop2 driver (based on the mainline vop driver and the rockchip sdk). apart from probing and binding it does not do anything right now
<mmind00> CounterPumpkin: in that case it would be best to leave that stuff out until someone with relevant hardware comes along
<mriesch> but i think several people are working/might be working on that one, should we provide a clean basis to build up on that?
<mmind00> CounterPumpkin: i.e. mapping the cru inside a driver and writing to it's registers directly is pretty bad ... and the binding stuff will be with us for "eternity" ... and if there is actually no hardware to use that stuff it shouldn't make it into the kernel in the first place
Rayyan6 is now known as Rayyan
kevery1 has joined #linux-rockchip
<mmind00> mriesch: not really ... a possible vop2 driver should definitly provide some functionality
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
<mmind00> mriesch: and everything out of staging should be somewhat complete
<mmind00> mriesch: I remember Rockchip wanting to work on the vop2 as well, but don't know what became of that ... maybe kevery knows where it stands ;-)
<CounterPumpkin> mmind00: The driver has been merged, and as far as I know, the code is working as well as downstreams is as I was careful not to change the way it works. As far as I can tell, HDMI (i2s0) will need this synchronous reset due to having both lrcktx and lrckrx, but afaik we can't test this until vop2 is a thing and provides us with an HDMI clock.
<mmind00> CounterPumpkin: though the binding becomes "binding" essentially only after it got released with a full kernel release ... aka 5.16 I guess
<CounterPumpkin> as for the bindings being forever; it's simple to just make the rockchip,cru property a no-op.
<mriesch> mmind00: staging would be nice for this one, but i don't think that is an option for a component driver
<mmind00> CounterPumpkin: yeah ... which is why I'm "struggling" ... as I do understand where that need comes from ;-)
<mriesch> the thing is that there are different chicken-and-egg situations including the vop2. we need a basic driver e.g., to bring up the hdmi phy
<mriesch> so i thought i could send out something, maybe on rfc basis
<CounterPumpkin> mmind00: If you'd like I can send a patch series that guts out the synchronous reset code, makes the mode that requires the synchronous reset a probe error, removes rockchip,cru from the bindings, and also contains two adjusted device tree patches to add audio output on the Quartz64.
<mmind00> CounterPumpkin: that would ease my mind tremendously :-)
<mmind00> CounterPumpkin: adding this later on is always a possibility
<CounterPumpkin> Guess that's gonna be my weekend project
<mmind00> mriesch: of course you can always try that ... but I guess some sort of display-interaction should be there - not sure if it's possible to remove some more fancy part from the vendor vop2 driver
kevery has quit [Quit: kevery]
<mriesch> mmind00: the current goal is to provide a minimal driver to bring up the hdmi phy. let's see whether this works out in the first place. i can also share the work via a github repo, if anyone is interested
<CounterPumpkin> I'd be interested
<mriesch> CounterPumpkin: ok, i'll let you know (possibly in a few hours or so)
<CounterPumpkin> mmind00: nevermind, it actually seems like the sync reset code is already used. I misremembered. It's *inactive* when rockchip,trcm-sync-tx-only and rockchip,trcm-sync-rx-only are missing apparently (i.e. clk_trcm > 0).
<CounterPumpkin> err, clk_trcm == 0 when they're both missing
<CounterPumpkin> I'll try to do some debugging this weekend to make extra sure I actually know what this driver I've just listed myself as the maintainer for actually does
<CounterPumpkin> Yeah I absolutely need to go over this code again, it's possible that there is a big oopsie.
<CounterPumpkin> if (i2s_tdm->clk_trcm != TRCM_TXRX) {
<CounterPumpkin> cru_node = of_parse_phandle(node, "rockchip,cru", 0);
<CounterPumpkin> and yet, the bindings say exactly the opposite.
<mmind00> CounterPumpkin: ok
<mmind00> and good luck
<CounterPumpkin> thanks
<CounterPumpkin> ok yes the synchronous reset code is definitely needed, or otherwise you get chipmunk audio for some reason.
indy_ has quit [Ping timeout: 265 seconds]
chewitt has quit [Quit: Zzz..]
<CounterPumpkin> so, scary ugly code must stay unfortunately
indy has joined #linux-rockchip
<CounterPumpkin> Actually, since we're in a irqsave spinlock, I might as well try to just trigger those reset controls at the same time through the regular method.
<CounterPumpkin> aw, no dice.
matthias_bgg has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
<mmind00> CounterPumpkin: though I'd still think that the kernel reset-framework could also do with a "(de-)assert multiple resets at the same time"
<CounterPumpkin> Oh absolutely, I'm just not quite sure how I'd design this API in a way that makes it generally useful and not just a weird transplant of technical debt for this driver
<mmind00> CounterPumpkin: there is already reset_control_{array,bulk}_assert ... which would need a "shortcut"
<mmind00> CounterPumpkin: so you define in the reset_ops a new atomic_assert, atomic_deassert callback, and in the _array_ whatwever function you check if all rstc->rcdev are the same and if so call the atomic_assert functions
<CounterPumpkin> It might be better to have explicit array_atomic_assert functions though because something that wants to atomically assert resets probably wants to fail loud and proud if the cru doesn't implement it
<mmind00> CounterPumpkin: sounds sensible as well
<mmind00> CounterPumpkin: also to not break existing behaviour on other platforms
<CounterPumpkin> True
lurchi__ is now known as lurchi_
<mmind00> CounterPumpkin: also ... that whole approach sounds pretty neat, as I really don't think our usecase is the only one out there ... I'm pretty sure some other hw-engineer already got the same idea about doing resets ;-)
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
vagrantc has joined #linux-rockchip
lurchi_ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-rockchip
lurchi_ has quit [Client Quit]
<mriesch> CounterPumpkin: first attempt here: https://github.com/mriesch-wv/linux/commits/feature/vop2
<mriesch> this branch provides a basic skeleton (clean) and initial support for three crtcs and planes (crude hack). using these two patches and suitable dts changes i was able to bring the hdmi tx up (patches by benjamin gaignard) and read out the edid from my monitor
<CounterPumpkin> nice!
<mriesch> still about 6000 loc's remaining to be ported but i guess it is a start :-)
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<CounterPumpkin> reset controllers won't let me sleep so I will try to look into whether the reason why an atomic reset is even needed is because of a possible bug in the softrst controller
<CounterPumpkin> my hypothesis is: toggling two resets immediately after each other makes the reset controller overwrite the register value before it took any effect, which is bad news if your resets are in the same bank.
DavidHeidelberg has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
archetyp has joined #linux-rockchip
<mmind00> CounterPumpkin: difference may also be the writel(BIT(tx_offset) | BIT(rx_offset) | (BIT(tx_offset) << 16) | (BIT(rx_offset) << 16), cru_reset + (tx_bank * 4)); ... i.e. doing both in a single write, where the reset controller normally does 2 separate writes
<CounterPumpkin> Yeah, currently got sidetracked chasing another bug that I managed to introduce in v5 which I erroneously thought was down to my reset controller hackery
archetyp has quit [Quit: Leaving]
alpernebbi has joined #linux-rockchip
shailangsa has quit []
<CounterPumpkin> I can confirm that just calling the two reset controls separately seems to work fine. Maybe it'll break something when we're actually capturing audio and playing some back at the same time, but it seems very tempting to just remove the sync reset code for now.
shailangsa has joined #linux-rockchip
archetyp has joined #linux-rockchip
<mmind00> CounterPumpkin: +1, thumbs up, etc :-D ... adding stuff back in later is always an option
archetyp has quit [Quit: Leaving]
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 260 seconds]
stikonas_ is now known as stikonas
warpme__ has quit [Quit: Connection closed for inactivity]
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip