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
<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