lucaswang has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
domidumont has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
premoboss has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
cubeast has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<rellla>
ssvb: is DISP_CMD_LAYER_SET_SCN_WINDOW and DISP_CMD_LAYER_SET_SRC_WINDOW enough to resize a layer during playback?
<rellla>
or do we need to do the whole DISP_CMD_LAYER_GET_PARA / .._SET_PARA ioctl?
<rellla>
i need to fix this in my libvdpau-sunxi branch, when it is used with window manager. there are problems with resizing/ moving because i kicked out doing a _SET_PARA for every frame
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
sehraf has joined #linux-sunxi
bobby_ has joined #linux-sunxi
<bobby_>
ssvb: I think I managed to kill my A10 LIME using cpufreq-ljt-stress-test this morning :)
<bobby_>
I switched from mainline to sunxi 3.4
<bobby_>
1008 MHz was not stable, so I tried 960 MHz
gianMOD has joined #linux-sunxi
<bobby_>
and board died, or at least nothing on serial console
JohnDoe_71Rus has joined #linux-sunxi
<bobby_>
I'll troubleshoot it when I'm back home this evening, I hope it is the PSU or SD card
<wens>
ouch
<ssvb>
bobby_: it should not kill the board, this test does nothing out of ordinary
<ssvb>
that's just jpeg decoding and checksum verification
<bobby_>
ssvb: yes, I know, it is just a coincidence
<bobby_>
I have heatsink, so I doubt it overheated the SoC
diego_r has joined #linux-sunxi
FR^2 has joined #linux-sunxi
lerc has joined #linux-sunxi
_massi has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
hansg has joined #linux-sunxi
<hansg>
wens, mripard_, since all 3 of us are online now lets discuss the cpufreq vs hstimer thing in realtime ?
<mripard_>
hansg: hi
<wens>
hi
<mripard_>
I don't really know what's left to discuss actually :)
<mripard_>
yes, the hstimer are currently broken, but my patches should fix it
<mripard_>
at least it does on the A31
<hansg>
What is left to discuss is: 1) do we really want to remove sched_clock support, I think it has merits on sun5i (but not on sun7i)
<hansg>
2) Do we want to reparent the ahb to a non cpu-core freq dependent pll (I say yes we do)
<hansg>
3) What to do for 4.0
<mripard_>
the sched_clock does not support rate changing
<hansg>
Also see the mail I just send in the thread
<mripard_>
and we have 2 others in the system anyway
<hansg>
Do we have a sched_clock on sun5i if we take the hstimer one away ?
<mripard_>
so if the hstimer doesn't provide it, we will use the arch timers one, or the sun4i timer one anyway
<wens>
iirc hstimer sched_clock has lower priority than sun4i_timer
<mripard_>
wens: sched_clock doesn't have any kind of priority
<mripard_>
which is why we ended up discussing this ;)
paulk-collins has joined #linux-sunxi
<hansg>
Right, that is what I was about to say, so its all about registration order
<wens>
oh, then that was the other part
<mripard_>
wens: clock source and clock events do, but not sched_clock
* wens
still doesn't quite understand that subsystem
<hansg>
Ah yes we have the sun4i-timer.c schedclock on sun5i, ok so lets just remove sched_clock then
<mripard_>
for 2), we already discussed this with wens
<mripard_>
and yeah, that would be a good thing to do
<mripard_>
the only thing we need to make sure is that we enfore this before any driver is loaded
<hansg>
mripard_, so maybe we should just do this in u-boot, with the other fixes we do not need this in the kernel perse, it is just a good thing to have, so we can fix it in u-boot and wait for users to get a newer u-boot
gianMOD has quit [Read error: Connection reset by peer]
Andy-D has quit [Ping timeout: 252 seconds]
<wens>
it's fixable using the dts assigned clocks stuff, but iirc mripard_ didn't think setting them on the clock provider was a good thing
<mripard_>
hansg: that would make our life easier in the code, but we will end up having to deal with older u-boot that don't enforce this
<wens>
this was brought up when we were doing sun6i ahb clock stuff
<mripard_>
wens: iirc, the clk-assigned stuff is enforced when the driver is loaded / clk claimed
<wens>
mripard_: depends on where the properties are
<mripard_>
so you'll already be halfway through the device probing when you'll have your clock reparented
<mripard_>
oh?
<wens>
and the clock driver implementation iirc :(
<hansg>
mripard_, right, but with your hstimer changes for clk rate changes + dropping of sched-clock older u-boot would just work, it would only be slightly sub-optimal. Does have the downside of having to keep both scenarios in mind whenever dealing with ahb clk stuff, so fixing this in the kernel might indeed be better ...
ricardocrudo has quit [Ping timeout: 245 seconds]
<hansg>
Either way I would be happy to write + merge a patch for u-boot for this
<hansg>
Ok, so lets assume that we can fix things in the dts to reparent ahb on sun5i / sun7i to ahb, what about sun6i, there we still have the problem of the ahb clk being changed by the dma driver, right ?
<hansg>
So there we still need to not register sched_clock, and need Maxime's other patches to react to clk-speed changes.
<wens>
we can also do the reparenting in the clock provider, instead of when the dma is probed
<mripard_>
hansg: it's what we were doing on the A31
<mripard_>
except we were doing at the time the DMA controller driver was probed
<hansg>
ah, I see
<hansg>
So we were not dynamically changing just adjusting it once
<mripard_>
which was obviously wait after the timer
<mripard_>
s/wait/way/
<mripard_>
yep
<mripard_>
we were forcing it because otherwise the DMA controller doesn't work for some reason
<hansg>
That still leaves us with the fact that on sun5i we're registering 2 sched_clocks and on sun6+i 3 sched-clocks, I would like us to be more explicit in which sched_clock should be used.
<rellla>
ssvb: ^
<hansg>
Specifically on sun6i+ I believe using the arch-timer is best, as that is part of the cpu-core
<hansg>
Which would mean not registering the sun4i / sun5i timer sched_clocks on sun6i+
<hansg>
Note any sched-clock changes would not be 4.0 material :)
awe00 has joined #linux-sunxi
Nyuutwo has quit [Read error: Connection reset by peer]
<mripard_>
hansg: yeah, and in theory, that would mean we would be able to shut down the sun4i timer clock entirely
<mripard_>
it's a shame there's no priority for the sched_clocks.
<hansg>
Yeah
<hansg>
Is there a way to find out if we're on sun6i+ / Cortex A7 without adding new compatibles for the timers just for this ? It feels wrong to add a new compatible even thought the hardware is the same just to avoid registering the sched_clock
<mripard_>
if (of_machine_is_compatible()) ? :/
lucaswang has joined #linux-sunxi
<mripard_>
that doesn't look very nice, but it's the best I can come up with
bobby_ has left #linux-sunxi [#linux-sunxi]
<hansg>
mripard_, that should actually work quite nicely, as we only want the sun4i sched-clock on sun4i, and the sun5i on sun5i so the patch should actually look quite acceptable :)
<mripard_>
actually, the sun4i sched_clock would work on both
<hansg>
Work yes, but the preferred one on sun5i would be the sun5i timer one I believe, and since we do not have priorities ...
<hansg>
I'll put comments above the checks to explain why they are thee.
<hansg>
s/thee/there/
<mripard_>
well, if we're removing the sched_clock on sun5i, it doesn't really apply anymore
<mripard_>
and I had a quite long discussion about which timer was best around two years ago
<mripard_>
and the outcome was that for the common case, sun4i would be better
<mripard_>
while the hstimer would be better for specific applications requiring a better resolution
<mripard_>
so I'd say we can just add a machine check in the sun4i, and register the sched_clock only for sun4i and sun5i
<mripard_>
and sun6i and later will use the arch timer ones
<mripard_>
which makes me think of something
<mripard_>
do we have arch timer support for sun8i and sun9i yet?
naobsd has joined #linux-sunxi
<mripard_>
hmmm, no
<mripard_>
it's not really important though, you can perfectly run Linux without a sched_clock
<wens>
sun8i should run arch timer like sun6i
<ssvb>
mripard_: are we now exclusively using the arm-linux mailing list for the sunxi kernel development?
naobsd1 has joined #linux-sunxi
<mripard_>
ssvb: it's the only ml that is official, but that has been the case since forever
<ssvb>
rellla: just check this DISP_CMD_LAYER_SET_SCN_WINDOW and DISP_CMD_LAYER_SET_SRC_WINDOW stuff yourself, I have not looked into the sunxi-3.4 disp driver for ages and my memory is a bit fuzzy :)
<mripard_>
why do you ask?
<rellla>
ssvb: ok then. thanks. fuzzy :p
<ssvb>
mripard_: just to know which mailing list to track and where to send the sunxi patches
naobsd has quit [Ping timeout: 264 seconds]
naobsd1 has quit [Client Quit]
<plaes>
having linux-sunxi in CC would be nice though...
naobsd has joined #linux-sunxi
<ssvb>
mripard_: I'm not sure whether you have really understood the question, but thanks anyway :)
<ssvb>
plaes: if we can't rely on linux-sunxi being in CC, then watching the linux-sunxi list is not very useful
<plaes>
mhm
Renard has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 252 seconds]
<Seppoz>
whats the best way in an embedded env to get the console output via ssh?
<Seppoz>
the output to /dev/ttyS0 e.g
wickwire has joined #linux-sunxi
<plaes>
Seppoz: separate machine with multiple usb-serial sticks?
<ssvb>
plaes: I'm not very much thrilled about closely monitoring the higher traffic list, but there are filters to the rescue :)
paulk-collins has quit [Ping timeout: 252 seconds]
<Seppoz>
no
<Seppoz>
just device in field
<Seppoz>
we ssh to and now i want to read the serial port
<plaes>
ssvb: neither do I
<hansg>
<mripard_> well, if we're removing the sched_clock on sun5i, it doesn't really apply anymore
<hansg>
But I thought we were not removing it since the reparent from dts fix wens is working on will make it reliable
<Seppoz>
does linux3.4 have support for H3 or H8 soc?
<hansg>
And if it is reliable it seems to me that the sun5i hstimer sched_clock is better (higher resolution, rolls over less often) then the sun4i-timer one. But if you believe that the sun4i sched_clock is the better one to use on sun5i too, then yes everything you just said makes sense
kaspter has joined #linux-sunxi
deffrag has joined #linux-sunxi
<wens>
my board hangs with ahb reparenting :(
<ssvb>
wens: which board?
<wens>
cubieboard2
<hansg>
wens have you noticed that the a20 and a13 ahb mux bits are different ?
<hansg>
(see the user manual for both)
<wens>
i did
<wens>
it hangs after some late_init call
<wens>
i'm guessing unprotected clocks :(
<hansg>
Ah could it be that pll6 is getting turned off ?
<hansg>
Try protecting pll6 by explictly enabling it or some such
<wens>
i'm guessing pll1 ....
<wens>
anyway, adding some debug output to be sure
<hansg>
Ah yes, because it now no longer is ahb parent, so nothing is claiming it.
<hansg>
But if you get that far, then the actual reparenting does seem to work :)
<ssvb>
is it documented to be safe?
<hansg>
mripard_, about arch-timer on sun8i, good point it seems that sun8i-a23.dtsi does not enable it. This is something one of us should put on its todo list, probably is easy to fix.
<wens>
again, i have a patch somewhere
<wens>
should be on my github
<wens>
this was when psci was preferred over just enabling arch timer
<wens>
yup, pll1 got disabled
lucaswang has quit [Read error: Connection reset by peer]
<ssvb>
:)
<mripard_>
hansg: we would still need it if some device need to change the AHB frequency
<mripard_>
hansg: it's still hypothetical at that point, but if we have the patches, and it can save the troubles if that ever happen...
<mripard_>
hansg: it's actually not that hard now that the property to force the use of the physical timers has been introduced
<mripard_>
ssvb: I tend to send all the important stuff to linux-sunxi, and the boring patches just to lakml, but yeah, if you don't want to miss anything, you would have to track the lakml
<mripard_>
(or lkml even.)
Hencke has quit [Quit: WeeChat 1.0.1]
<hansg>
mripard_, ok, so to summarize the plan is to remove clock_sched from the sun5i hstimer code because ahb is not constant speed + apply your clock change detect patchset since it is good to have that to be future proof against future ahb clock speed changes.
<hansg>
That leaves us with just sun4i-timer and arch-timer as clock_sched sources, and we want to use sun4i on sun4i+sun5i and arch-timer elsewhere
<ssvb>
mripard_: ok, I think that I have missed some revised patch series before and it made me a bit puzzled when they landed in a bit modified form, but now the mystery is resolved :)
<hansg>
But before we can do that we must first fix arch-timer on sun8i & sun9i
<hansg>
Or live with using the fallback sched_clock implementation there, which is just jiffies I believe, I guess we can live with the fallback
<hansg>
wens, it sounds like you've a much better grasp of what needs to be done for arch-timer support on sun8i so I'll leave that to you :)
<wens>
hmm, i never pushed that series out
Hencke has joined #linux-sunxi
<mripard_>
hansg: no, we can send the patches today
<mripard_>
sun8i and sun9i will boot just fine without a sched_clock
<mripard_>
the printk timestamps and the scheduler decisions will be based on jiffies, and not on a more precise value
<mripard_>
so performances might be a bit degraded
<mripard_>
but it's just until we add the arch_timer node
<hansg>
mripard_, ack. I'll put whipping up a patch to only register sched_clock from sun4i-timer on sun4i + sun5i soon. I assume you will (eventually) take care of removing sched_clock from the sun5i hstimer code since you already have a patch for that.
<mripard_>
I don't really know what to think of it. We're not lawyers, so we're probably not the best judges to say if a device is counterfeited in the first place
ricardocrudo has joined #linux-sunxi
<mripard_>
and even if we're making such judgement, devices might slip through, like this one.
<ssvb>
wens: is "hyundai" possibly a common Chinese word?
<plaes>
Korean
<ssvb>
right, it means "modern" in Korean :)
<ssvb>
might be ok as a name for a tablet, but on the other hand, "Apple" is a common English word too...
jinzo has joined #linux-sunxi
<rellla>
jemk: it's only some work in the meantime. but we were able to gather some more people around libvdpau, that look into it :p
wickwire_ has joined #linux-sunxi
wickwire has quit [Ping timeout: 272 seconds]
<ssvb>
haha, this "Hyundai" tablet also says "GT-I9100" as the "Model Number" in Settings->About Tablet
<ssvb>
now the "A7" part of the name also seems a bit suspicious
<JohnDoe_71Rus>
ssvb: may be custom rom
<ssvb>
JohnDoe_71Rus: how can this possibly happen? who would deliberately put the identifier from the Samsung Exynos based Galaxy S2 there?
imcsk8 has quit [Quit: Reconnecting]
<JohnDoe_71Rus>
old master of tablet :)
imcsk8 has joined #linux-sunxi
<JohnDoe_71Rus>
or this from stock
<ssvb>
the old master is libv :)
<JohnDoe_71Rus>
build.prop edition for more apps in play google
<ssvb>
ok, then this might make at least some sense