tl_lim has quit [Read error: Connection reset by peer]
anarsoul|2 has quit [Ping timeout: 256 seconds]
tllim has joined #linux-rockchip
nashpa has joined #linux-rockchip
tllim has quit [Read error: Connection reset by peer]
tllim has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
tllim has quit [Ping timeout: 252 seconds]
tllim has joined #linux-rockchip
nots has quit [Quit: Page closed]
tl_lim has joined #linux-rockchip
tllim has quit [Ping timeout: 276 seconds]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
wzyy2 has joined #linux-rockchip
lerc has quit [Remote host closed the connection]
lerc has joined #linux-rockchip
vstehle has joined #linux-rockchip
PoueT has quit [Quit: Ping timeout (120 seconds)]
PoueT has joined #linux-rockchip
tl_lim has quit [Read error: Connection reset by peer]
tl_lim has joined #linux-rockchip
tl_lim has quit [Ping timeout: 276 seconds]
tl_lim has joined #linux-rockchip
tl_lim has quit [Ping timeout: 255 seconds]
tl_lim has joined #linux-rockchip
tl_lim has quit [Read error: Connection reset by peer]
aalm has quit [Ping timeout: 260 seconds]
aalm has joined #linux-rockchip
xerpi has joined #linux-rockchip
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-rockchip
<maz>
Esmil: yes, I know of that splat. that's because the driver is using a shared interrupt, which on its own is really bizarre. the same driver seem to request the interrupt twice
<maz>
Esmil: another issue is that the interrupt is shared with the iommu, which would tend to indicate that the iommu itself serves as some form of irqchip for what is behind it.
<maz>
Esmil: looking at the VOP interrupt handler, it is quite obvious that this serves as a demultipler, and thus quite likely that the VOP driver is build on the wrong abstraction.
wadim_ has joined #linux-rockchip
<Esmil>
Ah I see
matthias_bgg has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
matthias_bgg has quit [Client Quit]
matthias_bgg has joined #linux-rockchip
lkcl has joined #linux-rockchip
SleepyMario has joined #linux-rockchip
<SleepyMario>
hello, i have a question concerning the rockchip rk3288 on the tinkerboard. Just to be sure: is "-mfpu=neon-vfpv4" a valid CFLAG?
nighty- has quit [Quit: Disappears in a puff of smoke]
BenG83 has joined #linux-rockchip
<Ke>
vfpv4 is in cpuinfo
<Ke>
if it does not mean that the SoC supports vfpv4, someone has some explaining to do
xerpi has quit [Quit: Leaving]
nighty- has joined #linux-rockchip
<SleepyMario>
sure. and adding neon to it is fine I presume?
cnxsoft has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-rockchip
<mmind00>
maz: where did you see "the same driver" requesting the irq twice? I only see the request in vop_bind (and of course the iommu)
afaerber has joined #linux-rockchip
<maz>
mmind00: on my setup, GIC interrupt 151 appears to be claimed by ff8f0000.vop twice. is the second one the iommu? that's not what the DT seems to indicate.
<maz>
mmind00: vopl_mmu is at ff8f3f00, which doesn't match what /proc/interrupt reports.
<Esmil>
Do you guys know where I could potentially read up on all this vop/iommu stuff? I found the Rockchip_RK3399TRM_V1.4_Part1-20170408.pdf but it doesn't seem to mention it
<maz>
Esmil: I asked the same question two days ago, and it doesn't seem that there is any form of reliable information.
<maz>
mmind00: that's a bit bonkers, but hey... I suspect that the iommu is completely integrated with the vop, and that they share some status registers...
<mmind00>
yep ... before the rk3288 the vops where the same and with rk3288 they "just" bolted the iommus onto various IPs
<mmind00>
maz: aka vops, rga and quite some more got their own per-ip iommus (which are all the same and hence got the separate driver)
tllim has joined #linux-rockchip
<maz>
mmind00: right. that explains a lot.
<maz>
mmind00: bingo: VOP_INTR_CTRL0/1 have all you need to implement an irqchip, which would go a long way avoiding the shared interrupt issues.
<maz>
mmind00: too bad the iommu itself doesn't share the same control register, that'd have been really cool.
<mmind00>
maz: not sure I understand what you mean ... aka the iommu is situated at the end of the vop register space, hence the strange size for the vop, offset for the iommu
<maz>
mmind00: what I mean is that in an ideal situation, the VOP interrupt control registers would have controlled the IOMMU interrupt as well, removing the need for a shared interrupt line.
<maz>
mmind00: if we move the VOP interrupts to have their own irqchip, we can then control their masking independently of that of the IOMMU, and would allow us to plug the horrible request/disable race.
<mmind00>
maz: alternatively just mask them in the driver before requesting the irq? [stopgap, I know, but might be less intrusive?]
<maz>
mmind00: that's what my initial patch does (more or less), but the core code screams that this is wrong because it is a shared interrupt (and it is absolutely right).
<mmind00>
maz: I actually meant masking in the VOP_INTR_* registers
<mmind00>
maz: i.e. normally these interrupts start as disabled in the VOP_INTR registers on reset
<mmind00>
maz: aka "vop_line_flag_irq_disable()" and "vop_dsp_hold_valid_irq_disable()"
<maz>
mmind00: ah, yes. that'd be correct.
<mmind00>
maz: i.e. the enable_irq voodoo is in the driver since the initial commit in 2014, so there is a possibility that they just fired with a big gun at a smaller problem :-)
tl_lim has joined #linux-rockchip
xerpi has joined #linux-rockchip
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-rockchip
tllim has quit [Ping timeout: 276 seconds]
SleepyMario has quit [Remote host closed the connection]
<eballetbo>
mmind00: thanks for the review, not sure if I follow you regarding last comment for the rockchip-typec ... /me needs to look at the inno-usb2-phy driver