curlybracket has quit [Read error: No route to host]
curlybracket has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
curlybracket has quit [Read error: Connection reset by peer]
curlybracket has joined #linux-sunxi
shfil has quit [Quit: Connection closed for inactivity]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
jaho__ has joined #linux-sunxi
random_yanek has joined #linux-sunxi
jaho_ has joined #linux-sunxi
jaho__ has quit [Ping timeout: 276 seconds]
suprothunderbolt has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
cnxsoft has joined #linux-sunxi
ndufresne has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
random_yanek has quit [Ping timeout: 276 seconds]
faisal has quit [Ping timeout: 245 seconds]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
[7] has joined #linux-sunxi
random_yanek has quit [Ping timeout: 255 seconds]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
ganbold has quit [Ping timeout: 246 seconds]
kaspter has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
kaspter has joined #linux-sunxi
random_yanek has joined #linux-sunxi
random_yanek has quit [Ping timeout: 245 seconds]
random_yanek has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 255 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 245 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 258 seconds]
jernej has joined #linux-sunxi
f0xx has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Putti has joined #linux-sunxi
random_yanek has quit [Ping timeout: 276 seconds]
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
airwind has joined #linux-sunxi
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
Putti has quit [Ping timeout: 245 seconds]
random_yanek has joined #linux-sunxi
cmeerw has joined #linux-sunxi
HeavyMetal has quit [Ping timeout: 264 seconds]
reinforce has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
clemens3_ has quit [Ping timeout: 245 seconds]
nuuuciano__ has quit [Ping timeout: 250 seconds]
tllim has quit [Read error: Connection reset by peer]
RichardG867_ has joined #linux-sunxi
RichardG867_ has quit [Changing host]
RichardG867_ has joined #linux-sunxi
msimpson has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 245 seconds]
cnxsoft has quit [Quit: cnxsoft]
clemens3_ has joined #linux-sunxi
<suprothunderbolt>
I'm a bit confused how to specify clocks to a codec. I see the pll-audio-base defined in code but I'm not sure how that maps to the DTS
<suprothunderbolt>
oh nice :) I'm just looking at your multichannel i2s code
<suprothunderbolt>
codekipper, does the TDM stuff work okay? I'm trying to get an 6 in 8 out codec to work
<codekipper>
pine64 is i2s master for their DAC. orangepi 2 is setup for slave with the audioinjector.
<codekipper>
What codec are you using?,
<suprothunderbolt>
TI 3168A
<codekipper>
connected to what board?
<suprothunderbolt>
sopine
<suprothunderbolt>
A64
<codekipper>
multi-channel works on the pine for HDMI but that has 4 output connections...not sure about how you would connect to an external codec like that
<suprothunderbolt>
I mean using TDM
<suprothunderbolt>
I haven't looked through your patch much but I saw mention of slot width etc
<codekipper>
older boards (A20) had multiple output pins
<suprothunderbolt>
ahh. I've just got it connected to 1 pin in and out.
<suprothunderbolt>
Does your code not support TDM?
<codekipper>
I would need to look at the specs and signalling diagrams...driver may not support it but the block might
<suprothunderbolt>
I'm porting from a AM3358. The datasheet for the A64 suggests it supports TDM fine
<suprothunderbolt>
and it's mentioned in the BSP code
<codekipper>
I've only had the need to use PCM
<suprothunderbolt>
with 2 channels in / out?
alexxy has quit [Ping timeout: 246 seconds]
<suprothunderbolt>
I think PCM / TDM are the same thing depending on data sheet description. :) I see there are 8 slots in / out defined in the PCM channel mapping
<suprothunderbolt>
codekipper, so you'd assume your multi channel code might need modification to work with a codec over a single pin?
<codekipper>
the multi-channel code is currently only used for HDMI using PCM.
<suprothunderbolt>
okay :)
<codekipper>
all of my codecs are pcm devices.
<codekipper>
I also don't see a 3168 codec in mainline....do see a pcm3168a!
popolon has joined #linux-sunxi
<suprothunderbolt>
yeah, that's what I meant sorry
<codekipper>
I would have to look at the signalling diagrams and then at the i2s registers to see what is possible...this is new territory for both of us
<suprothunderbolt>
yeah, I was planning to port the BSP code but maybe it's easier just to implement it from scratch.
<suprothunderbolt>
though I'm still confused about where the clock names come from. I have to specify the MCLK signal to the codec and would like to force it to be enabled,
faisal has quit [Ping timeout: 268 seconds]
<suprothunderbolt>
but any examples I can see are using clocks = <&ccu CLK_AC_DIG>; which makes sense, it's an alias for the PLL_AUDIO, but then the clock-names section I'm unsure about
Mangy_Dog has joined #linux-sunxi
<suprothunderbolt>
clock-names = "mod"; I'm not sure what this means, as I can't see in the clock code where that name is defined
<DuClare>
It's not in the clock code, it's in whatever uses the clock
<suprothunderbolt>
oh okay, so that's the output name of the clock?
<DuClare>
Just a name. If a driver needs multiple clocks, it'll select the one it needs by name
<suprothunderbolt>
clocks is the input and clock-names is what the device expects it to be called
<suprothunderbolt>
okay cool
<DuClare>
Grep for "mod" under drivers, you'll find lines like mixer->mod_clk = devm_clk_get(dev, "mod");
<DuClare>
Or of_get_clk_by_name(node, "mod")
<suprothunderbolt>
yep, so the device driver is looking for scki devm_clk_get(dev, "scki"); so I define clock-names = "scki"
<codekipper>
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi seems to use this codec
<DuClare>
Btw the required clocks should be documented somewhere under Documentation/devicetree/bindings/
<DuClare>
(grep for the driver compatible string)
<suprothunderbolt>
codekipper: I've got a working board using a TI AM3358 SOC
<codekipper>
do you have the schematic for it?
<suprothunderbolt>
yeah.
<suprothunderbolt>
DuClare: thanks, I didn't realise it was that way around. Makes sense now
<suprothunderbolt>
codekipper, that renesas example is defining the TDM slot mapping in a similar way to the AM3358. The Am3358 i2s system is a lot more complex than the sunxi one though, lots of data pins and you need to set the direction the serialisers
<libv>
jo0nas: this is only part of the explanation
<libv>
i will throw bpi u-boot on it again, and see how that fares, i had network before
<jo0nas>
correct
<jo0nas>
I provide infor for your 2nd message above, not for all of them
<libv>
thanks :)
<jo0nas>
...and I tried to make that very clear in my message
<jo0nas>
I am aware of others experiencing issues with recent revisions of lime2 - and can provide link to that information too if interested - but notice that you seem to request _official_ info so I only provided you what came officially from Olimex
<libv>
the rev. G that i got as well is just happy
<jo0nas>
good for you - there is an issue specific for that board as well, but good if you don't experience that
<jo0nas>
s/is/is rumored to be/
Gerwin_J has joined #linux-sunxi
<libv>
i have 5 Ks here, 2 of which were tested, and are acting the same
<libv>
jo0nas: this sort of info should live in the wiki
<jo0nas>
yes, agreed - and when I figure out what is what in those rumors I will add it (if noone beats me to it)
<libv>
i am still digging as well
<jo0nas>
still waiting for more detailed reports than "doesn't boot, didn't have a screen connected but maybe same issue as others talk about here..." from those owning those boards and experiencing those various issues
<libv>
# CONFIG_MICREL_PHY is not set
<libv>
that could explain a thing or two
<libv>
nah, still getting hot
<libv>
and no network
<libv>
going to the bpi config
<libv>
if that makes it magically work, we have a starting point
<libv>
before it was an oversight when i copied the sd card from the bpi to the lime2
<libv>
to test the bpi lcd on the lime2
<libv>
and whatdoyouknow
<libv>
network.
<libv>
with bpi-m1 uboot
<libv>
still getting pretty hot
<libv>
CONFIG_GMAC_TX_DELAY=3 in uboot config.
<libv>
fixes this
Net147 has quit [Quit: Quit]
megi has joined #linux-sunxi
Net147 has joined #linux-sunxi
<libv>
that chip gets pretty uncomfortably hot
<Mangy_Dog>
this reminds me for the handheld im designing im going to need to sort out some kind of heat sink for it
<Mangy_Dog>
but its going to have to be a custom job
<Mangy_Dog>
nothing over the top just a small alu block and a heat pipe
<libv>
this is hw that will need to run 24/7 for a long time
<libv>
as this is going in the fosdem video boxes
<Mangy_Dog>
no idea what that is
<Mangy_Dog>
other than it has something to do with video :D
<libv>
fosdem is the biggest and best open source conference on the planet
<Mangy_Dog>
oohh
<libv>
it streamed out 27 tracks in parallel this year
<micken>
anarsoul: still trying to find out what happens, but its hard since the guy is in uk without debug cable.
<libv>
and it has 54 boxes spread over a university campus in brussels
<libv>
we are about to severely improve the setup
<Mangy_Dog>
hmm
<libv>
if the lime2 itself is stable and reliable that is
<micken>
anarsoul: the most odd thing is that the card with u-boot + system works in other 1080p 11"
<libv>
we are designing a hdmi input daughterboard for it
<Mangy_Dog>
is there a media box type distro for these boards that work fully with netflix and amazon prime? I really need to replace my old crap slow stuttery amazon prime fire stick....
<libv>
i am hacking up a cable/adapter for running our existing bpi 3.5" lcds (we have 1/8th of the total production) so we have something to develop and test against while we nail down the design of the board
<libv>
Mangy_Dog: no
<libv>
this will hopefully manage 720p input
<libv>
which is good enough for fosdem
<libv>
err, not no to your actual question
afaerber has quit [Quit: Leaving]
<libv>
but no, this is not a project that will make your life better
Gerwin_J has quit [Ping timeout: 264 seconds]
<Mangy_Dog>
l;ol
<libv>
i do think there are linux distros tailored as media centers, some of them should work with some arm devices
<libv>
but i have no idea about those
lurchi_ is now known as lurchi__
<KotCzarny>
does kodi have netflix plugin?
Andy-D has quit [Ping timeout: 245 seconds]
msimpson has quit [Read error: Connection reset by peer]
markvandenborre has joined #linux-sunxi
<Tsvetan>
livb: not if you use our official images :)
<Tsvetan>
libv rev.K use KSZ9031 PHY I doubt uboot from other board will work
<jo0nas>
libv: CONFIG_GMAC_TX_DELAY=3 was reported in Debian to fix issue on newer board but possibly be a regression for older boards: https://bugs.debian.org/927397
<jo0nas>
Tsvetan: great to have working fork of u-boot specifically for Olimex products, but even better to have mainline u-boot which supports Olimex products!
<jo0nas>
libv, plaes: sunilmohan_ did the investigation and Debian bugreport about lime2 rev.C regression when fixing for rev.G boards
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
<libv>
jo0nas: yes/no
<libv>
the thing still gets pretty hot
<libv>
i have not tried the olimex u-boot yet
<libv>
but i fear it might just be the tx delay
cnxsoft has quit [Remote host closed the connection]
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 255 seconds]
cnxsoft has joined #linux-sunxi
paulliu has quit [Remote host closed the connection]
wigyori has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
netlynx has quit [Quit: Ex-Chat]
<jo0nas>
libv: uhm I think you read me wrong: I wasn't asking a question, but introducing you to sunilmohan_ :-)
<jo0nas>
...but too bad your board is still running too hot :-(
Gerwin_J has quit [Quit: Gerwin_J]
cnxsoft has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 245 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
clemens3_ has joined #linux-sunxi
afaerber has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
msde has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
msde has quit [Remote host closed the connection]
noblock has joined #linux-sunxi
<noblock>
anarsoul: It will work with MIN3
<anarsoul>
noblock: hey
<noblock>
Hi,
<anarsoul>
noblock: I think you can just replace blocknum calculation with your code in current code
<anarsoul>
and drop your compute_steps_generic() - it's basically equivalent of current code
<noblock>
OK I will try.
<anarsoul>
the only difference is that your code rounds up tile width/height before doing the shift
<noblock>
And the +1 you removed. Is this an issue?
<anarsoul>
(just check the code - it's functional equivalent of yours)
<noblock>
I can check with the tables.
<anarsoul>
noblock: basically if numblocks <= limit it either picks shift_w == shift_h or depending on which dimension is larger, shift_w = shift_h + 1 or shift_h = shift_w + 1
<anarsoul>
noblock: see your look up table from v1 - you'll notice the pattern :)
<noblock>
Yes.
<anarsoul>
noblock: and that's exactly what yuq's original code does, the only difference is in calculating numblocks. Your code rounds up shifted tile width/height, yuq's code doesn't
<noblock>
The implementation I have commited, is more compact.
<anarsoul>
anyway, thanks for working on this issue :)
<noblock>
numblock calcution is fine, I'm certain of it.
<anarsoul>
noblock: yeah, the only part that I don't understand is +1 in maskt
tlwoerner_ has joined #linux-sunxi
<anarsoul>
otherwise it looks reasonable
<noblock>
It may be a good idea to dump the h3 state.
<noblock>
or any other mali-400.
dev1990 has joined #linux-sunxi
<anarsoul>
noblock: your code works fine for me with MIN3 in place on A64
yann has quit [Ping timeout: 244 seconds]
<noblock>
The code was modified for the 260 issue.
<noblock>
Are we certain it covers all combination on the mali-400?
<anarsoul>
I tested some common resolutions. If you have a test that checks all the combinations - I can try it on mali-400.
<noblock>
My last test was to use the H5 workaround with the blob, and check if some PP errors were generated.
<anarsoul>
noblock: well, I don't get any PP errors with missing MIN3, but it misrenders shadow demo
<anarsoul>
(shadow is missing in this case)
<noblock>
I don't know, if we have something with piglit that check for misrendering.
<anarsoul>
I'm not sure if it covers all the possible resolutions
<noblock>
We can do a loop.
reinforce has quit [Quit: Leaving.]
<noblock>
If it can check for instance that the triangle is well processed. We can just add the loop for all rendering size.
<anarsoul>
technically there's only up to 16 cases all permutations of (0-3, 0-3)
gnufan_home has joined #linux-sunxi
<noblock>
Yes, but the blob has some condition like width = height, or with an offset and swaped (stepw,steph).
<noblock>
Maybe some limitations at the hardware level.
<anarsoul>
yeah, looks like max(abs(shift_w - shift_h)) = 1.
<noblock>
For now if the common resolution are working, and some texture resolutions like 256x256, 512x512.. are OK. This will be fine.
<noblock>
Yes, the algorithm set the lower values for (stepw, steph) with blocknum<=blockmax.
cmeerw has quit [Ping timeout: 264 seconds]
tlwoerner_ has quit [Quit: Leaving]
<noblock>
I have an H3, I can do some tests on the mali-400 part.
Putti has quit [Ping timeout: 245 seconds]
<noblock>
You are right not all (stepw, steph) values are generated.
lurchi__ has quit [Ping timeout: 258 seconds]
lurchi__ has joined #linux-sunxi
<anarsoul>
noblock: as I said earlier, looks like it tries to comply with max(abs(shift_w - shift_h)) = 1
<anarsoul>
so difference between shift_w and shift_h is either 0 or +-1
<noblock>
Yes, you are right,
<noblock>
This is what the last code does, it increments w or h, only one each time.
<anarsoul>
yes, and that's what original code does
<noblock>
Yes.
<anarsoul>
that's why I said your code is essentially equivalent of original code, the only difference is in blocknum calculation
victhor has joined #linux-sunxi
<noblock>
To check for blocknum; We have to dump all combinations on mali-400.
<noblock>
The calcutions must be right all the time.
<anarsoul>
noblock: I believe your is correct. It totally makes sense to round up width/height
<noblock>
It must be done, minimum pixel size is 16x16.
<jernej>
noblock: I just tested your v3 workaround for blob on H5 and it works better than previous
<noblock>
jernej: Good.
<noblock>
With the v3, I had no issue with PP errors anymore; The code must cover all cases now.
<anarsoul>
noblock: yeah
<anarsoul>
noblock: whatever it calculates for 16x16 is fine, we'll get shift_w = shift_h = 0 :)
cnxsoft has quit [Remote host closed the connection]
<noblock>
If we look at what lima does, it generate an array of pointer of blocknum size.
cnxsoft has joined #linux-sunxi
<anarsoul>
oh, OK
<noblock>
So this used internaly by the gpu.
<anarsoul>
noblock: btw, I suspect that GP in H5 is 2x slower than in other mali450 due to this maxblock limitation