florianH has quit [Quit: Connection closed for inactivity]
fdcx has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
lemonzest has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
chlorine_ has quit [Ping timeout: 258 seconds]
<Net147>
wens: the difference in threshold handling for A31 is for TX_THRESHOLD, not RX_THRESHOLD
FergusL has quit [Ping timeout: 240 seconds]
<Net147>
wens: RX_THRESHOLD handling is the same on both A20 and A31
msimpson has quit [Quit: Leaving]
<wens>
surely you shouldn't try to read 16 bytes when it's possible there's only 15 bytes?
<Net147>
on A20, RX_THRESHOLD is 15. the FIFO request bit is set when the fifo level is above RX_THRESHOLD (which is when the fifo level is 16)
diego71_ is now known as diego71
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
<Net147>
also on A31 there is DDC_TRANSFER_TIMEOUT (bit 8) in HDMI_DDC_INT_STATUS which you include in SUN4I_HDMI_DDC_INT_STATUS_ERROR_MASK
<Net147>
*which you should include
<Net147>
I am interested to know what kind of timeout would cause this bit to be set though...
<wens>
there is another register which is used to set the timeout
chlorine has quit [Ping timeout: 260 seconds]
<wens>
Net147: yes, but on the A31, RX_THRESHOLD is still 15, but triggers the request bit when FIFO level >= 15
<wens>
so it could be 15
<Net147>
wens: so the documentation is wrong then?
<wens>
hmm, the doc is conflicting :/
<wens>
I hate that
<wens>
let me run a test
<Net147>
wens: can you also check before "regmap_field_write(hdmi->field_ddc_start, 1)" that the interrupt status register has been cleared? none of the error bits, fifo request or transfer complete bits should be set.
yann-kaelig has joined #linux-sunxi
BenG83 has joined #linux-sunxi
<Net147>
wens: RX_FIFO_TRIGGER_THRES description conflicts with FIFO_REQ_INT description...
msimpson has joined #linux-sunxi
<wens>
doesn't look good... request bit is set as long as there is data in the FIFO
<wens>
shit... I think I crashed my board
<Net147>
you mentioned that the other day as well, that the request bit is set as long as there is data in the FIFO
<Net147>
which would be the same if the rx_threshold was at default value of 0, and if the request bit is set if fifo level > rx_threshold
<wens>
well, we'll have to try tomorrow :/
<Net147>
developing on the board remotely?
<wens>
it's at the office
deep-book-gk_ has joined #linux-sunxi
<Net147>
okay
<Net147>
well at least we know where to look...
chlorine_ has quit [Read error: Connection reset by peer]
deep-book-gk_ has left #linux-sunxi [#linux-sunxi]
Ntemis has quit [Remote host closed the connection]
yann-kaelig has quit [Quit: yann-kaelig]
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
<Net147>
wens: I will give rebase my changes on your branch and give it a test on A20
<Net147>
wens: do you cross compile or build on target?
<Net147>
wens: fails to read edid on A20 after rebasing on your branch
<wens>
cross compile
<Net147>
wens: "i2cdump -y 2 0x50 i" gives "Error: Block read failed, return code -1" for me
<Net147>
checking...
dave0x6d has joined #linux-sunxi
<Net147>
wens: is it possible to update both several regfields at once if they are in same register?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
diego_r has quit [Remote host closed the connection]
diego_r has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Leepty has quit [Ping timeout: 240 seconds]
<Net147>
does regmap_write do a read?
Leepty has joined #linux-sunxi
<Net147>
wens: I think the problem may be regmap_field_write on the interrupt status register
<wens>
Net147: no for the first, probably for the second
<Net147>
wens: you should never read interrupt status register before writing
<wens>
uh, the register is not the clear on read type
yann has joined #linux-sunxi
<Net147>
I reverted entire fifo_transfer function and it works. I am now going to try just replacing the regmap_field_write with writel for interrupt status register.
<Net147>
wens: works
<wens>
:/
<wens>
what about just setting the reg_field to cover the whole register, instead of just a part of it?
<Net147>
wens: we really shouldn't be clearing "reserved" bits...
<Net147>
what is probably happening is that some bits in the register other than the fifo request bit is set to 1. so when we clear fifo request bit, it ends up clearing other bits that were read as 1.
<Net147>
I made this mistake too when developing the driver
<Net147>
it needs to write to the whole register without reading it at all
<wens>
I see
<wens>
so expanding the interrupt status reg_field to cover the whole register should do the trick
<wens>
then it won't have any unwanted bits
<Net147>
wens: you mean extending into the "reserved" bits?
<Net147>
wens: to ".field_ddc_int_status = REG_FIELD(SUN4I_HDMI_DDC_INT_STATUS_REG, 0, 31)," ?
cnxsoft has quit [Quit: cnxsoft]
<Net147>
wens: doesn't work
<wens>
argh :/
<Net147>
wens: no driver uses regmap_field_write for clearing bits in interrupt status register. they all use regmap_write.
Leepty has quit [Ping timeout: 240 seconds]
<Net147>
wens: or it could be reading that the fifo request bit is already 1, so it doesn't try to update it because it is already 1...
<wens>
without _force_ it won't do anything if there is no change
<wens>
Net147: thanks!
<wens>
I'll try it tomorrow
<Net147>
wens: good luck =)
Leepty has quit [Ping timeout: 255 seconds]
BenG83 has quit [Quit: Leaving]
BenG83 has joined #linux-sunxi
<Net147>
wens: we would be the first driver to use that function =P
<Net147>
wens: other way would be to somehow mark the regmap as volatile
reinforce has quit [Quit: Leaving.]
Leepty has joined #linux-sunxi
BenG83 has quit [Ping timeout: 260 seconds]
msimpson has quit [Quit: Leaving]
<wens>
mripard: a whole lot of patches!
willmore has quit [Remote host closed the connection]
<Net147>
wens: what patches?
JohnDoe_71Rus has joined #linux-sunxi
yann has quit [Ping timeout: 246 seconds]
chlorine_ has quit [Read error: Connection reset by peer]
gaby has quit [Ping timeout: 248 seconds]
Leepty has quit [Ping timeout: 240 seconds]
Leepty has joined #linux-sunxi
<wens>
Net147: DRM patches fixing some bits and adding MIPI DSI support
Andy-D_ has joined #linux-sunxi
Leepty has quit [Quit: Cassos !]
lkcl has quit [Ping timeout: 240 seconds]
Andy-D__ has joined #linux-sunxi
Andy-D__ is now known as Andy-D
ganbold has quit [Ping timeout: 240 seconds]
Andy-D_ has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-sunxi
<MoeIcenowy>
wens: where?
engideavr has quit [Quit: Konversation terminated!]
gaby has joined #linux-sunxi
<MoeIcenowy>
oh see it on linux-arm-kernel
chlorine has joined #linux-sunxi
BenG83 has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
phipli has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
matthias_bgg has quit [Quit: Leaving]
lennyraposo has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 246 seconds]
rwmjones has quit [Ping timeout: 258 seconds]
atsampson has quit [Ping timeout: 240 seconds]
rwmjones has joined #linux-sunxi
rwmjones has quit [Ping timeout: 258 seconds]
chrisf_ has joined #linux-sunxi
rwmjones has joined #linux-sunxi
jernej has quit [Ping timeout: 258 seconds]
rwmjones has quit [Ping timeout: 276 seconds]
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
atsampson has joined #linux-sunxi
matthijs has joined #linux-sunxi
matthijs is now known as Matth
rwmjones has joined #linux-sunxi
atsampson has quit [Ping timeout: 240 seconds]
<Matth>
Does anyone know how to get the UART pins working on the Orange PI Zero? I added "overlays=sun8i-h3-uart1" in /boot/armbianEnv.txt and it is still not working.
leviathan_ has quit [Remote host closed the connection]
rwmjones has quit [Ping timeout: 240 seconds]
rwmjones has joined #linux-sunxi
atsampson has joined #linux-sunxi
marble_visions has joined #linux-sunxi
marble_visions has left #linux-sunxi [#linux-sunxi]
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
jernej has joined #linux-sunxi
<mripard>
wens: yeah, sorry :)
Gerwin_J has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
atsampson has quit [Ping timeout: 240 seconds]
atsampson has joined #linux-sunxi
jmcneill has joined #linux-sunxi
<jmcneill>
Hi! Has anybody ever successfully booted a 32-bit kernel on Pine64?
<jmcneill>
U-Boot seems happy with the image, I get the "Starting kernel ..." message, and then an error, like it hasn't switched to aarch32 mode or something.
<chrisf_>
Matth: No idea of the build you're using but everything I've used has the UART working out of the box. I did see a diagram of the NanoPi board that I'm using with the UART pins mislabelled though. Worth checking?
afaerber has joined #linux-sunxi
<Matth>
chrisf_ I don't want to use UART for the console. I'm using version 4.11
BenG83 has quit [Quit: Leaving]
<Matth>
but the problem is that cant open them, screen terminates when I try
<KotCzarny>
check if you dont have anything using ttyS0 in services
<Matth>
but the uart1 and 2 are ttyS1 and ttyS2 I think, so it doesn't matter?
<KotCzarny>
then i missed your original problem
<Matth>
the problem is that I can't open those ports
<KotCzarny>
if you are using 4.11 then you dont use script.bin, you use DT (dts/dtb)
<KotCzarny>
in case of armbian there is a chance you have to enable some dt overlay
<Matth>
yes, i added "overlays=sun8i-h3-uart1" in /boot/armbianEnv.txt like I found here: https://forum.armbian.com/index.php?/topic/3651-uart-on-orange-pi-zero/
<Matth>
but it still doesn't work
<Matth>
but someone said on that forum that 'this feature is not yet announed'.
<Matth>
*announced
<Net147>
mripard: wens: clock protection patch series seems useful for multiple display pipeline support