rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
sunshavi has joined #linux-sunxi
arc_phasor has quit [Ping timeout: 246 seconds]
gaston_ has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
suprothunderbolt has joined #linux-sunxi
Andy-D has quit [Ping timeout: 246 seconds]
Andy-D has joined #linux-sunxi
cristian__c has quit [Ping timeout: 245 seconds]
cristian_c has joined #linux-sunxi
gnufan_home has quit [Ping timeout: 258 seconds]
gnufan_home has joined #linux-sunxi
gnufan_home has quit [Ping timeout: 245 seconds]
gnufan_home has joined #linux-sunxi
sunshavi has quit [Ping timeout: 272 seconds]
gnufan_home has quit [Ping timeout: 268 seconds]
megi has quit [Ping timeout: 248 seconds]
gnufan_home has joined #linux-sunxi
sunshavi has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
gnufan_home has quit [Ping timeout: 248 seconds]
<wens> I don't think it was ever tested
sunzone has joined #linux-sunxi
kaspter has joined #linux-sunxi
sunzone_ has joined #linux-sunxi
gnufan_home has joined #linux-sunxi
gnufan_home has quit [Ping timeout: 272 seconds]
sunzone93 has joined #linux-sunxi
sunzone has quit [Quit: Page closed]
sunzone93 has left #linux-sunxi [#linux-sunxi]
sunzone has joined #linux-sunxi
gnufan_home has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 258 seconds]
sunzone has left #linux-sunxi [#linux-sunxi]
gnufan_home has quit [Ping timeout: 248 seconds]
sunzone_ has left #linux-sunxi [#linux-sunxi]
sunzone_ has joined #linux-sunxi
sunzone_ has quit [Client Quit]
sunzone93 has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
<sunzone93> Hi guys, this question is regarding xradio_wlan driver
<sunzone93> I have configured My Orange Pi Zero onboard wlan chip (xradio_wlan driver) to work on both Ap mode and Client modes simultaneously.
<sunzone93> When both Ap and Client interfaces are up and working, and when the connected wifi channel of the Client interface changes, kernel hang occurs.
<sunzone93> [20149.090066] [<bfb2d42d>] (wsm_handle_rx [xradio_wlan]) from [<bfb29e05>] (xradio_bh_exchange+0x27c/0x588 [xradio_wlan]) In the error logs, it seems program stalled on wsm_handle_rx in xradio_wlan.
<sunzone93> I checked the fifteenhex wlan_driver code for "wsm_handle_rx" and found this line in wsm.c
<sunzone93> if (raceCheck == 0xFFFF) { /* If wsm_handle_rx got stuck in _confirm we will hang * system there. It's better than silently currupt * stack or heap, isn't it? */ BUG_ON(wait_event_timeout( hw_priv->wsm_cmd_wq, hw_priv->wsm_cmd.done, WSM_CMD_LAST_CHANCE_TIMEOUT) <= 0); }
<sunzone93> It seems like kernel hang is done on purpose.
<sunzone93> After removing the following part from the wsm.c i recompiled and reran the test.
<sunzone93> Still the kernal hang occurs.
GrimKriegor has joined #linux-sunxi
GrimKriegor has joined #linux-sunxi
GrimKriegor has quit [Changing host]
<sunzone93> any idea how I can further test the driver to stop the kernel hang?
<sunzone93> p.s: I am ok with the dropped packets of the driver.
<sunzone93> I also posted about this on armbian forum
gnufan_home has joined #linux-sunxi
Putti has quit [Ping timeout: 246 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 258 seconds]
chewitt has quit [Quit: Zzz..]
jernej__ has joined #linux-sunxi
nashpa has quit [Ping timeout: 248 seconds]
jernej__ has quit [Quit: Konversation terminated!]
jernej_ has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
nashpa has joined #linux-sunxi
selfbg has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
airwind has joined #linux-sunxi
jernej has joined #linux-sunxi
fl_0 has quit [Ping timeout: 250 seconds]
Asara has quit [Ping timeout: 258 seconds]
fl_0 has joined #linux-sunxi
Asara has joined #linux-sunxi
chewitt has joined #linux-sunxi
reinforce has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
ldevulder_ has joined #linux-sunxi
default__ has quit [Ping timeout: 245 seconds]
ldevulder_ is now known as ldevulder
AneoX has joined #linux-sunxi
diego_r has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-sunxi
scelestic has quit [Quit: Lost terminal]
tllim has quit [Read error: Connection reset by peer]
Putti has joined #linux-sunxi
hipboi has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
scelestic has joined #linux-sunxi
<fALSO> bom dia
gaston_ has joined #linux-sunxi
msimpson has joined #linux-sunxi
Putti has quit [Ping timeout: 272 seconds]
jbizcocho has joined #linux-sunxi
airwind has quit [Quit: airwind]
airwind has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
kaspter has quit [Ping timeout: 248 seconds]
pmpp_ has joined #linux-sunxi
pmpp has quit [Disconnected by services]
msimpson has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
ganbold has joined #linux-sunxi
msimpson has joined #linux-sunxi
ganbold has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
AneoX_ has joined #linux-sunxi
kaspter has joined #linux-sunxi
ganbold has quit [Client Quit]
ganbold has joined #linux-sunxi
AneoX has quit [Ping timeout: 248 seconds]
ganbold has quit [Client Quit]
suprothunderbolt has quit [Ping timeout: 245 seconds]
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
afaerber has joined #linux-sunxi
jbizcocho has quit [Quit: WeeChat 2.4]
OutBackDingo has quit [Ping timeout: 252 seconds]
OutBackDingo has joined #linux-sunxi
dddddd has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
aalm has quit [Read error: Connection reset by peer]
\\Mr_C\\ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<MoeIcenowy> KotCzarny: looks very unstable -- CTS needed for higher than 9600
<MoeIcenowy> remember Rockchip uses 1.5M baud for their debug port ;-)
Putti has joined #linux-sunxi
<KotCzarny> still, interesting idea, and you wont be playing ascii-quake on that ;)
<MoeIcenowy> KotCzarny: remember serial debug port is usually 115200 now ;-)
msimpson has joined #linux-sunxi
<KotCzarny> and if one doesnt need vga specifically, opi1/lite could be made into such adapter much cheaper ;)
<KotCzarny> still, a neat idea
<KotCzarny> especially size wise
popolon has joined #linux-sunxi
cnxsoft1 has quit [Quit: cnxsoft1]
AneoX_ has quit [Ping timeout: 248 seconds]
AneoX has joined #linux-sunxi
megi has joined #linux-sunxi
airwind has quit [Quit: airwind]
msimpson has quit [Read error: Connection reset by peer]
msimpson has joined #linux-sunxi
lurchi_ is now known as lurchi__
return0e has quit []
return0e has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
ArunJoseph has joined #linux-sunxi
ArunJospeh has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
popolon has quit [Quit: WeeChat 2.4]
reinforce has quit [Quit: Leaving.]
popolon has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
aalm has joined #linux-sunxi
aalm has quit [Read error: Connection reset by peer]
popolon is now known as Popoline
reinforce has joined #linux-sunxi
lurchi__ is now known as lurchi_
Putti has quit [Remote host closed the connection]
<Mangy_Dog> anyone here have adafruits tfp401 board? Need a little help identifying a couple of solder jumpers and what theyre for
Putti has joined #linux-sunxi
<Mangy_Dog> that board yeah
<mru> I don't have one, but what's your question?
<Mangy_Dog> https://cdn-learn.adafruit.com/assets/assets/000/020/621/original/adafruit_products_tfp401sch.png?1414183039 in the schematic theres 2 solder jumpers near the top left.... on the tfp401 chip. Any idea what theyre for?
<Mangy_Dog> sj1 sj2
<Mangy_Dog> there part of the config but no idea what to do with them
<KotCzarny> probably panel specific
<mru> the tfp401 datasheet is your friend
<mru> pin 3 (ST) sets the drive strength
<mru> that's SJ2
<mru> pin 100 / SJ1 / OCK_INV sets the pixel clock polarity
<mru> the correct setting depends on the panel
<Mangy_Dog> yeha
<Mangy_Dog> i think i now know whwat these are for
<Mangy_Dog> i mean IE from when i did some other DPI panel stuff before
<Mangy_Dog> its ringing bells
<Mangy_Dog> though i mostly remember being it a trial and error thing
<mru> only if you don't read the panel datasheet
<Mangy_Dog> some panels done have them
<Mangy_Dog> not the ones i used before anyway
<Mangy_Dog> just some random chinese panel
<mru> don't buy parts without datasheet
<Mangy_Dog> though the one im currently using does so ill have a look :p
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
<Mangy_Dog> ok
<Mangy_Dog> it doesnt say
<Mangy_Dog> :D
<Mangy_Dog> in teh datasheet
<mru> of course it does
<mru> otherwise it isn't a datasheet
<Mangy_Dog> i cant link it to you as it was emailed to me
<Mangy_Dog> anyway it would hardly be difficult to figure out
<Mangy_Dog> like i said before i did it by trial and error
arc_phasor has joined #linux-sunxi
<libv> Mangy_Dog: there is a png with a schematic
<libv> Mangy_Dog: and it says what it does on the backside of the board
<Mangy_Dog> yeah i dont have the board thats why i had to ask
<Mangy_Dog> im using its design as a reference
<libv> as a reference for?
<Mangy_Dog> my handheld im making
<Mangy_Dog> im doing a retro gaming handheld
<libv> what function will this dvi to parallel rgb chip have there?
<Mangy_Dog> to take the hdmi off the orange pi and into the display
<Mangy_Dog> :)
<Mangy_Dog> id rather use dpi over gpio but thats not suported outside of raspberrys
<libv> is there a reason why you cannot use either one of the two parallel rgb connections of many allwinner SoCs?
<Mangy_Dog> you refering to mipi?
<libv> you could grab an olimex lime2 and drive 2 parallel rgb lcds
arc_phasor has quit [Ping timeout: 246 seconds]
<Mangy_Dog> well this board only has the csi out
<libv> then change boards
<Mangy_Dog> and as far as i knew that cant be used to run any kind of display
<Mangy_Dog> umm no?
<Mangy_Dog> im using small boards for a reason
<Mangy_Dog> because theyre small
<libv> get a small allwinner board with a cfp40 connector
<libv> it's going to be a lot easier
ArunJoseph_ has joined #linux-sunxi
<Mangy_Dog> is there one as small as the orange pi zero?
<Mangy_Dog> plus2...
<libv> anyway, for fosdem, we are about to use the tfp401 to test the stability of the parallel rgb24 bus of csi1
<libv> and to see whether we can reach a minimum of 1280x720@60Hz
<libv> before we go off and design an adv7611 based lime2 daughterboard
<Mangy_Dog> i dont know how csi is laid out....
<libv> Mangy_Dog: make sure that you get a DE enabled display
<KotCzarny> csi is for camera
<Mangy_Dog> but the tfp401 sends out the common parallal display signal
<Mangy_Dog> kotz my point
<Mangy_Dog> kotc
<libv> the olimex 10" display is sync driven and the tfp401 is not nice with sync on the first line
<libv> it is a few pixels off
<Mangy_Dog> im just using a new ips based display from buydisplay who ive used there displays a fair bit
<Mangy_Dog> cheap but decent
<libv> the bpi 3.5" lcd is purely DE driven as i had the sync lines swapped and it just did not care
<Mangy_Dog> as far as i know the dpi interface is all the same
<libv> ...
<libv> did you read any of my statements about DE and sync?
ArunJoseph has quit [Ping timeout: 256 seconds]
<Mangy_Dog> you mean the one line you just wrote here?
<Mangy_Dog> yes
<libv> some lcds are purely sync driven, and there you might have some nasties on the first line
<libv> with the tfp401
<Mangy_Dog> this has DE
<libv> other lcds are purely DE driven
<libv> that does not mean that the signal is actively used
<Mangy_Dog> we will see
<libv> both the mentioned lcd modules have both DE and H/VSync
<Mangy_Dog> yes as does mine
<libv> +lines
<libv> but one ignores DE and the other ignores sync
<libv> and the tfp401 is a bit slow/dumb
<libv> the first line has display start a few clocks later, all subsequent lines keep the right offset.
<libv> Mangy_Dog: did you find the schematic?
<Mangy_Dog> for what?
<libv> tfp401
<Mangy_Dog> yes
<Mangy_Dog> its been loaded on my other screen for a few weeks now
<Mangy_Dog> for glancing
<libv> those two pads are for the backlight driver
<Mangy_Dog> ock inv isnt
<Mangy_Dog> thats signal polatiry
<Mangy_Dog> signel polarity
<Mangy_Dog> and the tfp401 doesnt drive the backlight
<libv> oh
<libv> ok
<libv> the top left of the schematic
<Mangy_Dog> it does have an active out that can be used to trigger the backlight
<Mangy_Dog> but im using my stm32 topwm it
<libv> not the top left (more mid) of the board
<Mangy_Dog> the board or schematic
<Mangy_Dog> ?
<libv> i have the board in hand
<libv> anyway, the tfp401 soc documentation is public
<libv> err, s/soc/chip/
<Mangy_Dog> yeah
<Mangy_Dog> i have it
<libv> ST is drive strenght, if you are pushing pixels over a noisy or long bus, you might want to have high drive strenght, but you will use more power
<libv> OCK is the pixel clock
<libv> OCK_INV is pretty self-explanatory
<Mangy_Dog> nods
<Mangy_Dog> the drive strength ill set low... its only going about 2 or 3 inches
diego_r has quit [Ping timeout: 248 seconds]
lurchi_ is now known as lurchi__
victhor has joined #linux-sunxi
vagrantc has joined #linux-sunxi
megi has quit [Ping timeout: 248 seconds]
arc_phasor has joined #linux-sunxi
<arc_phasor> anyone have experience or know of any "gotchas" with using an allwinner R16 in a multimaster i2c bus?
<mru> multimaster i2c is rather rare
<mru> so expect trouble from something or other
<karlp> "when in doubt, don't use i2c"
<KotCzarny> lol
<arc_phasor> well damn
<arc_phasor> kinda just designed an entire board around it
<solderfumes> karlp: I'm curious what lead you to be a critic of I2C, and what alternatives you think are viable
<karlp> what does the spec even say abotu multi master? how is it arbitrated, is there any in i2c itself, or is just application level?
<karlp> solderfumes:spi, uart. i2c periphs often have gotchas, and the reliance on drive strengths and the right pullups makes what you thought was a digital interface more of an analog interface.
f0xx has joined #linux-sunxi
<mru> spi needs more wires
<mru> and then you have chipselect hell
<solderfumes> uart is point to point
<karlp> spi works though :) rs485 for multipoint.
<mru> I was about to suggest rs485
<mru> i2c works well enough between chips on a pcb though
<karlp> you don't _need_ chipselects either, you can do that in protocols too.
<mru> show me one spi slave that supports that
<solderfumes> I've seen I2C level shifters that turn the signals on the bus into a square waves
<karlp> now you're adding parts :)
<solderfumes> I was debugging that thing for half an hour thinking the pin controller was set up incorrectly :)
warpme_ has joined #linux-sunxi
<arc_phasor> i was totally ja-baited by the spec
<arc_phasor> way to go philips
<arc_phasor> and stm32
lurchi__ is now known as lurchi_
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
<arc_phasor> wens: you're saying the allwinner r16 i2c driver was never tested in a multi-master scenario?
<anarsoul> arc_phasor: is it even a thing?
<anarsoul> multiple masters on i2c
Putti has quit [Ping timeout: 248 seconds]
<arc_phasor> anarsoul yes, it's a multimaster spec
<anarsoul> arc_phasor: are you sure that allwinner's i2c controller supports it?
<mru> allwinner doesn't even officially support i2c, only "two-wire interface" :)
<mru> that said, the H3 manual which I happened to have open says multi-master is supported
<mru> the question then becomes, does it actually work?
<mru> and does the linux driver support it?
Putti has joined #linux-sunxi
<arc_phasor> mru: the r16 user manual also says it's supported on page 417
<arc_phasor> where does the mv64xxx fit into all of this. i know that's what is loading for i2c
deesix has quit [Ping timeout: 248 seconds]
deesix has joined #linux-sunxi
<mru> welcome to irrationally named drivers
<mru> I guess whatever the controller actually is, it was first supported by linux in some marvell chip
<arc_phasor> so the question is also, does the marvel driver support it
<mru> same thing
<mru> there's only one driver
Putti has quit [Remote host closed the connection]
<arc_phasor> oh. yea i'm seeing sun4i within the i2c-mv64xxx.c
<anarsoul> mru: allwinner just used someone else's IP in their SoC
<MoeIcenowy> anarsoul: Mentor Graphics'
<mru> yes, I know
<mru> everybody does
<anarsoul> so there's nothing irrational in driver naming
<mru> but when it's not known who actually made it, people tend to just use a random chip name
<anarsoul> it was named after the first hardware it supported
<mru> exactly what I said
Putti has joined #linux-sunxi
<MoeIcenowy> but I think neither Marvell nor Allwinner mentions mentor
<mru> precisely
<MoeIcenowy> the controller is called mi2cv by mentor
<mru> so that would have been the logical name for the driver
<mru> but whoever wrote it probably didn't know that
<mru> and possibly had no way of finding out
<MoeIcenowy> in Linux usually driver name is kept traditional
<mru> which makes it nearly impossible to guess which option you need to enable
<MoeIcenowy> no problem, you cannot either know if it's named i2c-mi2cv ;-)
<mru> if I happened to know that a chip used that IP block, I would
<mru> which doesn't mean I'd know every other chip also using it
<anarsoul> mru: check your dts
warpme_ has quit [Quit: warpme_]
<mru> what dts?
<anarsoul> for your target device
<mru> suppose it's a previously unsupported chip
<mru> hell, maybe I even work for the chip vendor
<mru> so I know exactly what's in it
<anarsoul> mru: then you know where it came from
<mru> yes, but I wouldn't know that marvell also used it
<anarsoul> it's a bit more difficult if you work for IP vendor
<mru> I don't actually work for a chip vendor
<mru> but I've been in almost that situation
<anarsoul> mru: I usually grep for register names first
<mru> I'm not saying it's impossible to figure out
<mru> only that it's more effort than it should be
<anarsoul> haha
DonkeyHotei has joined #linux-sunxi
<mru> and nobody ever updates the kconfig help when support for new chips is added to drivers
<anarsoul> say it to IP vendors
<mru> not really their fault
<anarsoul> "Designware OTG 2.0"
<anarsoul> "Designware OTG 3.0"
<mru> unless they forbid chip integrators revealing what they used
<anarsoul> "Designware Ethernet 100M"
<anarsoul> :D
<mru> if I see those, I know they are generic IP blocks that could show up anywhere
<mru> so if I'm looking for a driver, it makes sense to check those
* anarsoul still remembers all the issues he hit with designware otg 2.0
<anarsoul> I've never seen an IP with that long errata list
<mru> whereas there's nothing to suggest that "Netlogic XLR I2C support" also covers mediatek and sigma designs
<anarsoul> and IIRC they never fixed control transfers even in later revisions
<anarsoul> mru: the problem is that in case of sunxi most of upstream stuff is done by community, not by soc vendor
<anarsoul> same is true for amlogic
<arc_phasor> so i'm basically screwed?
<mru> clockwise
<MoeIcenowy> don't forget Designware Ethernet driver is called stmmac
<MoeIcenowy> ;-)
<mru> yes, that's another one
<MoeIcenowy> in Linux the original name of the driver is usually kept
<mru> yes, so people really should try harder to get it right the first time
<willmore> Said on #linux-sunxi where none of the parts have full datasheets..... "<mru> don't buy parts without datasheet"
lurchi_ is now known as lurchi__
<mru> I'm not using allwinner stuff by choice
<MoeIcenowy> willmore: it's user manual which is not full
<MoeIcenowy> not datasheet
<MoeIcenowy> ;-)
<mru> both are somewhat lacking
<mru> and occasionally plain wrong
lurchi__ is now known as lurchi_
<willmore> MoeIcenowy, :P
iamfrankenstein has joined #linux-sunxi
warpme_ has joined #linux-sunxi
lurchi_ is now known as lurchi__
\\Mr_C\\ has quit [Ping timeout: 252 seconds]
\\Mr_C\\ has joined #linux-sunxi
\\Mr_C\\ has quit [Client Quit]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
freemangordon has quit [Ping timeout: 246 seconds]
freemangordon has joined #linux-sunxi
arc_phasor has left #linux-sunxi [#linux-sunxi]
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
iamfrankenstein has quit [Quit: iamfrankenstein]
f0xx has quit [Ping timeout: 268 seconds]
megi has joined #linux-sunxi
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
warpme_ has quit [Quit: warpme_]
Wizzup has quit [Ping timeout: 252 seconds]
afaerber has quit [Quit: Leaving]
lynxis has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
aalm has joined #linux-sunxi
Wizzup has joined #linux-sunxi
gaston__ has joined #linux-sunxi
gaston_ has quit [Ping timeout: 258 seconds]
gaston_ has joined #linux-sunxi
gaston__ has quit [Ping timeout: 246 seconds]
gaston__ has joined #linux-sunxi
gaston_ has quit [Ping timeout: 248 seconds]
Putti has quit [Ping timeout: 248 seconds]
Mangy_Dog has quit [Ping timeout: 258 seconds]
chewitt has quit [Quit: Adios!]
jstein has quit [Quit: quit]
Mangy_Dog has joined #linux-sunxi
lurchi__ is now known as lurchi_