willmore has quit [Remote host closed the connection]
willmore has joined #linux-sunxi
chomwitt3 has quit [Quit: WeeChat 1.0.1]
Andy-D has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 240 seconds]
riaqn has joined #linux-sunxi
<riaqn>
Hi, 请问linux的virtio提供的接口是pci还是pcie?
cnxsoft has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
KB3VGW has joined #linux-sunxi
KB3VGW has left #linux-sunxi [#linux-sunxi]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
iaglium has quit [Ping timeout: 245 seconds]
juri_ has quit [Ping timeout: 255 seconds]
Andy-D has quit [Ping timeout: 264 seconds]
iaglium has joined #linux-sunxi
juri_ has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Ntemis has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 260 seconds]
Nyuutwo has quit [Ping timeout: 276 seconds]
Nyuutwo has joined #linux-sunxi
juri_ has quit [Ping timeout: 240 seconds]
iaglium has quit [Ping timeout: 240 seconds]
firnsy has quit [Ping timeout: 258 seconds]
iaglium has joined #linux-sunxi
iaglium has quit [Ping timeout: 240 seconds]
firnsy has joined #linux-sunxi
firnsy has joined #linux-sunxi
firnsy has quit [Changing host]
iaglium has joined #linux-sunxi
juri_ has joined #linux-sunxi
pg12 has quit [Ping timeout: 240 seconds]
leviathan_ has joined #linux-sunxi
pg12 has joined #linux-sunxi
iaglium has quit [Ping timeout: 256 seconds]
juri_ has quit [Ping timeout: 264 seconds]
juri_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
iaglium has joined #linux-sunxi
iaglium has quit [Excess Flood]
juri_ has quit [Ping timeout: 255 seconds]
[7] has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
iaglium has joined #linux-sunxi
juri_ has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
florianH has joined #linux-sunxi
jernej has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
msevwork has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
lkcl has joined #linux-sunxi
f0xx has joined #linux-sunxi
fkluknav has joined #linux-sunxi
<jonkerj>
say what, riaqn?
<riaqn>
jonkerj: sorry that I assume all the users speak Chinese.
<riaqn>
my question was: how virtio on linux host is implemented? conventional PCI or PCI-express?
ErwinH has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
<riaqn>
I actually did some research and it seems that the host side implementation is in qemu instead of kernel.
ErwinH has joined #linux-sunxi
<riaqn>
so my question was actually invalid.
<jonkerj>
haha
<jonkerj>
but this is a allwinner/linux-specific IRC-channel, so unless it's virtio on ARM what you're talking about, I'm afraid you're adressing the wrong crowd
<riaqn>
yes you're right.
<riaqn>
just thought there may be some overlapping of users .
<MoeIcenowy>
riaqn: I think virtio on ARM is implemented as mmio
<MoeIcenowy>
on x86 may be PCI
<riaqn>
MoeIcenowy: hmm, do you happen to know the PCI version?
<MoeIcenowy>
nope.
<riaqn>
I'm browsing the qemu code and I think, maybe pci-e.
<riaqn>
but I'm not sure if writing the driver in pci-e instead of pci will bring any real benefits(performance wise).
<MoeIcenowy>
oh you got really off-topic here
<riaqn>
as pci-e is software compatible with pci 3.0, so pci 3.0 driver will run on pci-e device.
<riaqn>
haha, I'm disappear.
<MoeIcenowy>
for ARM KVM the PCI bus is on virtio-mmio ;-)
<MoeIcenowy>
(I have played with virtio-gpu on ARM KVM)
<riaqn>
MoeIcenowy: OK, I will checkout.
<riaqn>
Hmm, is this channel compatible with amlogic/linux questions?
<MoeIcenowy>
if you are really interested in ARM KVM and QEMU, maybe you can try to implement an A20 emulation for QEMU ;-)
<MoeIcenowy>
currently QEMU only have an A10 emulation with only SATA and EMAC support
<MoeIcenowy>
not so compatible
Andy-D has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<riaqn>
MoeIcenowy: ahh didn't know that.
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
f0xx has joined #linux-sunxi
<riaqn>
MoeIcenowy: sorry if sounds naive: so A20 is armv7 + what?
Nyuutwo_ has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 276 seconds]
<wens>
MoeIcenowy: do you notice any glitches in display for A33 drm?
<MoeIcenowy>
wens: freemangordon noticed
<MoeIcenowy>
I also noticed when doing video playback
<MoeIcenowy>
oh FMG disappeared from here
<MoeIcenowy>
riaqn: A20 is ARMv7 + many things ;-)
<MoeIcenowy>
A20 is one of the Allwinner SoCs that have most peripherals
IgorPec has quit [Ping timeout: 258 seconds]
<wens>
doesn't seem to be cpu related
<wens>
maybe lack of memory bandwidth?
<MoeIcenowy>
wens: I do not remember any glitches in stock Android.
<wens>
stock android uses the DE differently
<wens>
for 1, we do not use the frontend
<MoeIcenowy>
you mean the lack of FE may be the problem?
<wens>
lack of bandwidth for the BE
<MoeIcenowy>
I remembered I seen comments about BE memory bandwidth limit in U-Boot
<wens>
yeah, that was for A10
<MoeIcenowy>
but maybe other SoC will have even worse BE memory bandwidth?
<wens>
i get glitches when installing packages with aptitude :|
<MoeIcenowy>
or the way we use DRM will cost more memory bandwidth than simplefb?
<MoeIcenowy>
wens: R.I.P. so terrible
<wens>
or it could be just interference
<MoeIcenowy>
maybe...
<MoeIcenowy>
I remembered FMG mentioned he only say the glitches with >30fps with Mali GLES on Hildon-desktop
<wens>
looks like interference from mmc0 :/
<MoeIcenowy>
what the hell
<MoeIcenowy>
but it's also possible...
<MoeIcenowy>
but I remember mmc seems to have also a direct DMA that do not pass DMA controller?
IgorPec has joined #linux-sunxi
<wens>
but it doesn't happen with simplefb... very weird
<MoeIcenowy>
maybe it's because we have multiple planes with DRM driver
<MoeIcenowy>
at least we have a basic plane and a cursor plane
<wens>
nope
<wens>
we don't have a cursor plane atm
<wens>
and i'm just at the console, not in X11
<MoeIcenowy>
ah-oh
<MoeIcenowy>
but I found implement a proper driver for DE2 is a larger disaster
<MoeIcenowy>
(I mean DRM driver
<wens>
now the panel parameters are slightly different between simplefb and drm
<MoeIcenowy>
we have nearly no knowledge about the internal pipeline of DE2, except the mixer part
<MoeIcenowy>
and even different DE2 mixer have different channel configuration
<MoeIcenowy>
(I think you may be familiar about DRM driver implementation?
<wens>
not really
<MoeIcenowy>
and the DE2 itself seems to be like a MFD, there's some global controller registers, then lot of subengines
<MoeIcenowy>
but should it really be implemented as a display MFD?
<wens>
you can implement each function as a component
<MoeIcenowy>
but in order to enable any function
<MoeIcenowy>
the global controller registers should be set
<wens>
and maybe virtual devices / adapters to fit the drm/kms model
<wens>
i though it had just one address space?
<MoeIcenowy>
yes
<wens>
so? one driver
<MoeIcenowy>
the overall control regs are at <0x10000000 0x1c>
<wens>
one device
<MoeIcenowy>
but then engines are divided
<wens>
that's not really an issue
<wens>
you just share the base address, and use different offsets
<MoeIcenowy>
then some global controller at <0x11000000 0x1000>
<MoeIcenowy>
oh maybe I should said then the mixer at <0x11000000 0x10000>
<MoeIcenowy>
mixer0 *
<MoeIcenowy>
on A83T there's a mixer1 at <0x11010000 0x10000>
<MoeIcenowy>
then some magic engines that we can only know that write 0 to the 0x0 offset of it can disable it
<MoeIcenowy>
(it seems that mixer0 is connected to tcon0, and mixer1 is connected to tcon1
<MoeIcenowy>
(and they're alike, but with different channel cout
<MoeIcenowy>
count *
<MoeIcenowy>
mripard: could you give me some tips about such an architecture?
<MoeIcenowy>
the tcon part is nearly the same as early SoCs
<wens>
isn't there a mux between the mixers and tcons?
<wens>
in any case this seems much like the BEs and TCONs for DE 1.0
<MoeIcenowy>
TCON part is independent
<MoeIcenowy>
not at 0x01000000, but at 0x01c0c000 like the old SoCs
<MoeIcenowy>
mixers are like BEs
<wens>
right
<mripard>
MoeIcenowy: why would you need an MFD ?
<wens>
so look at how we split up stuff for DE 1.0
<MoeIcenowy>
but for DE1.0 they're all totally independent
<MoeIcenowy>
for DE2.0 they share a clock
<MoeIcenowy>
and share some 5 global registers
<wens>
so you either need some sharing or locking between 2 pipelines
<MoeIcenowy>
the 2 pipelines seems to be able to work consistently
<wens>
MoeIcenowy: look at DE 1.0, we have functions that control the hardware
<wens>
MoeIcenowy: then drm structures that expose other callbacks as part of the drm driver
<wens>
MoeIcenowy: these callbacks call the hardware control functions
<MoeIcenowy>
maybe we make a syscon or a stub driver at 0x01000000 for the DE2?
<wens>
mripard: remember i picked some random panel to use for q8?
<wens>
MoeIcenowy: just map the whole region in
<MoeIcenowy>
the things at 0x01000000 seems in fact like a CCU, which has its gate, reset and div part
<wens>
MoeIcenowy: you only have *1* device, that has *2* pipelines
<MoeIcenowy>
but except the CCU, mixer0 and mixer1 are independent
<MoeIcenowy>
their only relationship is sharing the CCU
<wens>
MoeIcenowy: try decoupling the number of hardware blocks vs the number of software constructs
matthias_bgg has joined #linux-sunxi
<MoeIcenowy>
?
<wens>
MoeIcenowy: so? it's still one piece of hardware
<MoeIcenowy>
yes...
<MoeIcenowy>
but we can have several driver parts for the one piece
<wens>
take the VPU for example, it has different engines
<wens>
do we have 1 driver per engine? no, we have 1 driver for the entire VPU
<MoeIcenowy>
for VPU the subengines seems to be mutual
<wens>
that driver then calls small libraries to control each engine
<MoeIcenowy>
but for DE2 the subengines are parallel or cooperation
<wens>
if stuff is shared, you deal with it in software
<MoeIcenowy>
at least, for our known part, it's parallel
<wens>
for instance, the layer/plane component of drm would, 1) program the BE, and 2) program the TCON
<MoeIcenowy>
there's another problem
<wens>
mripard: turns out some random panel causes gliching :/
<MoeIcenowy>
we won't have two drivers for DE1 and DE2 tcon
<wens>
MoeIcenowy: that can be shared
<MoeIcenowy>
so the TCON driver must be demuxed
<MoeIcenowy>
what I did on U-Boot sunxi_display.c to implement V3s video support is: write new sunxi_composer_* for DE2, then use the original sunxi_lcdc_*
<MoeIcenowy>
(V3s is the simplest case for DE2, like the case of A33 for DE1
<wens>
right
<wens>
so DRM is a bit more complicated
Leepty has joined #linux-sunxi
<wens>
you have stuff like framebuffers and KMS planes (see the talks from mripard and bbrezill1)
<wens>
which are entirely software constructs
<wens>
DRM/KMS operates on these constructs, which the driver exposes
<wens>
the driver then has to translate operations on these constructs to operations on the hardware
<MoeIcenowy>
how is different parts of a display pipeline coupled in DRM/KMS driver?
<wens>
so depending on the hardware, it may be a crazy setup (like ours)
<wens>
MoeIcenowy: see sun4i_drv.c on how the whole thing ties together
<wens>
MoeIcenowy: the probe and bind functions, and see what they call
<MoeIcenowy>
the sun.i-a..-display-engine compatible is only a virtual driver that do not have any hardware resources?
<wens>
i've not gone through the entire drm driver, so i don't know a lot of the specifics
<wens>
MoeIcenowy: correct, but that is because we have multiple FE/BE/TCONs
<wens>
for DE 2.0, with just one region for the mixer stuff, we can use that as the anchor node instead
<MoeIcenowy>
no there's two different regions for mixers, like two BEs
<MoeIcenowy>
but I think for DE2.0 we will have the sun8i-v3s-display-engine2 driver to have some regs resources -- the overall control part
<wens>
i thought on the datasheet it's just one?
<wens>
1 memory region, 1 clock, 1 reset
<MoeIcenowy>
yes, 1 clock, 1 reset
<MoeIcenowy>
but for memory region, it have a very big continous memory region that is sparse
<MoeIcenowy>
from 0x0100001c to 0x010fffff are wasted at all
<wens>
is that an issue? mmio doesn't cost us much, just page table entries
<MoeIcenowy>
yes it's not a big issue
<wens>
depending on the implementation, mapping the whole 4M region might even be better
<mripard>
wens: what glitches exactly ?
<wens>
mripard: on my Q8 A23 tablet, if mmc0 is accessed, part of the screen, or the whole screen, flashes and shifts to the left by almost a character
<wens>
mripard: maybe the hsync timing is off, making it susceptible to interference
<MoeIcenowy>
what the hell
<MoeIcenowy>
mripard: on my A33 1024x600 tablet when doing full-screen video playback with mpv, on freemangordon's 1024x600 tablet when doing full-screen Mali GLES, we see video glitches by some areas on the screen cannot update in time
<wens>
MoeIcenowy: tearing?
<MoeIcenowy>
yes
<MoeIcenowy>
tearing
<wens>
mine is just the screen moving around
* MoeIcenowy
afk for some minutes or hours
<wens>
kind of like when a monitor is auto-adjusting when you use vga
<wens>
using the timings from u-boot fixes the glitching, but the image is offset to the left
ErwinH has quit [Read error: No route to host]
ErwinH has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
<mripard>
wens: hmmm, weird :/
<mripard>
I guess you took the same timings in Linux?
yang has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
<wens>
mripard: ugh, what?
jelly has quit [Ping timeout: 258 seconds]
codekipper has joined #linux-sunxi
<wens>
hmm, besides the timings, the polarity is also different
<wens>
maybe that will make a difference
INdek has joined #linux-sunxi
<codekipper>
wens: mripard : How are we handling dual colour LEDs here?. My Beelink X2 with stock firmware lights up the LED as red(boots uboot) until the power button is pressed then kernel starts and it switches to blue.
<codekipper>
Shall I just have blue powered on in the dts(for uboot and kernel) and not care about the power on button?
cnxsoft has joined #linux-sunxi
<wens>
codekipper: it's 2 gpios right?
<codekipper>
yep
<wens>
i don't think linux has a special case for multi-color LEDs
yang has joined #linux-sunxi
<wens>
it's just represented as 2
cnxsoft has quit [Remote host closed the connection]
yang has quit [Changing host]
yang has joined #linux-sunxi
<codekipper>
does the pwr function do anything?
<wens>
pwr function?
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
<wens>
mripard: looks like i acked all your sun5i ccu patches? i'll rebase my sun9i ones on it and send them
Andy-D has quit [Ping timeout: 258 seconds]
<wens>
nope, definitely not h/v sync polarity
<codekipper>
wens: it's in the labelling an example of which is here 3d9e2b66cf9f1b0eda3cb0891a775a625c14bb9f
<wens>
does nothing
<wens>
just the name exposed in sysfs
<codekipper>
so nothing automatically changes the state?...Hans mentioned that the LED switched off.
<wens>
iirc by default they will be turned off, unless you set the default-state property
kaspter has quit [Ping timeout: 240 seconds]
<codekipper>
so we don't care for proper behaviour..just that they are described?..that makes it easier for me.
<wens>
:)
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
leviathan_ has quit [Remote host closed the connection]
florianH has quit [Quit: Connection closed for inactivity]
terra854 has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
<MoeIcenowy>
yes Linux do not have any case for multi-color LEDs
<MoeIcenowy>
I had two boards that uses an integrated RGB LED (3 GPIOs, one per color)
<MoeIcenowy>
and I modelled it as 3 LEDs in dt
yann-kaelig has joined #linux-sunxi
<rah>
I've got a Mele A1000G box with an A31, which I'm trying to do a git bisect with, to determine why the framebuffer is failing
<rah>
unfortunately, the commit I'm on won't bring up the husb-sunxi bus which has a USB disk attached with the root filesystem
<rah>
I've traced the driver probe with ftrace and apparently this call is failing:
<tkaiser>
codekipper: But Beelink exchanges hardware parts from time to time (eg. Ampak Wi-Fi on older X2 models replaced with RTL8189ETV on more recent ones). Which PCB rev do you have?
leviathan_ has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
IgorPec has quit [Ping timeout: 248 seconds]
dh1tw has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
|Jeroen| has quit [Quit: dada]
|Jeroen| has joined #linux-sunxi
IgorPec has quit [Ping timeout: 258 seconds]
ErwinH has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
ErwinH has quit [Ping timeout: 255 seconds]
IgorPec has joined #linux-sunxi
Amit_T has quit [Quit: ChatZilla 0.9.93 [Firefox 46.0.1/20160511224619]]
ErwinH has joined #linux-sunxi
Andy-D has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
ErwinH has quit [Read error: Connection reset by peer]
ErwinH_ has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
yann-kaelig has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 240 seconds]
likewise has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
lkcl has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 248 seconds]
valkyr1e has quit [Ping timeout: 248 seconds]
ErwinH has joined #linux-sunxi
arete74 has joined #linux-sunxi
valkyr1e has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
\\Mr_C\\ has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
fdcx has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
leviathan_ has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
jelly-home is now known as jelly
<likewise>
Can someone recommend a known working A13 U-Boot in NAND setup? I tried a few u-boot trees with NAND support on A13 Linuxino (WiFi) but they all fail during ecc_init() and nand erase.chip fails.
|Jeroen| has quit [Quit: dada]
rookieone has quit [Ping timeout: 258 seconds]
bugzc has joined #linux-sunxi
lkcl has quit [Ping timeout: 255 seconds]
rookieone has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 240 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
IgorPec2 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 255 seconds]
ErwinH has quit [Ping timeout: 252 seconds]
interrobangd has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
nove has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 240 seconds]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<likewise>
I just found out I had to add the DT properties nand-ecc-* for A13 Olinuxino to get beyond ECC init.
<deskwizard>
likewise: thats great, maybe it'll fix on my A20 as well, could you give me a little more details?
afaerber has joined #linux-sunxi
<deskwizard>
Oh nvm I think I get it, thanks for mentionning :)
<likewise>
deskwizard: please explain? Did you get NAND working already on your platform?
ErwinH has joined #linux-sunxi
<likewise>
deskwizard: I used the latest u-boot from CHIP, then needed to tweak the DTS and defconfig to get NAND going on A13 Olinuxino. On the DTS I added nand-ecc-strength = <40>; nand-ecc-step-size = <1024>;
<deskwizard>
likewise: I'm stuck at the nand init last time I tried, I'll have a look at the DT and try those
<likewise>
deskwizard: what NAND chip do you have? I just started with the A13 Olinuxino board. Apparently, at least some other NAND chips do not need the ecc directives in DTS.