libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
twitch153 has quit [Ping timeout: 240 seconds]
twitch153 has joined #linux-exynos
_whitelogger has joined #linux-exynos
D1337d has quit [Ping timeout: 256 seconds]
D1337d has joined #linux-exynos
Wizzup_ is now known as Wizzup
Wizzup has quit [Quit: Reconnecting]
Wizzup has joined #linux-exynos
zombah has joined #linux-exynos
azer_ has left #linux-exynos [#linux-exynos]
amitk has quit [Quit: Lost terminal]
amitk has joined #linux-exynos
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
prahal has quit [Remote host closed the connection]
afaerber has joined #linux-exynos
amitk has quit [Quit: leaving]
zombah has quit [Quit: Leaving]
prahal has joined #linux-exynos
leming has quit [Read error: Connection reset by peer]
leming has joined #linux-exynos
leming has quit [Remote host closed the connection]
leming has joined #linux-exynos
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
leming has quit [Ping timeout: 248 seconds]
leowt has joined #linux-exynos
<leowt> javier__ you there?
<javier__> leowt: I'm
<javier__> leowt: you should just ask your questions here and people will answer you when possible
<leowt> ;)
<leowt> i got both the "pseudo"ported kernel and the mainline one booting
<leowt> since the ported one seems functional, i want to use it meanwhile
<leowt> but both are not outputing hdmi
<javier__> leowt: the pseudo ported was the frankestein 3.8 odroid tree + board files?
<leowt> yep
<javier__> leowt: you are missing the vdd-supply regulator
<javier__> the board file should provide the correct one
<javier__> but I would really not spend time on that tree and try to use mainline instead
<leowt> mainline is having the exact same issue, i am using the odroidx dt
leming has joined #linux-exynos
<javier__> leowt: arch/arm/boot/dts/exynos4412-odroidx.dts?
<leowt> yes
<leowt> it has the same cpu clock and memory
<javier__> it defines the vdd-supply vdd-supply = <&ldo8_reg>
<leowt> i cant find no reference to a regulator on the boardfile
<javier__> leowt: 517 is EPROBE_DEFER btw which means that the driver probe has been deferred
<javier__> so it could be that succeeds later if the regulator is found again
<javier__> which probably is the case for the mainline DTS since the regulator is defined there
<leowt> sorry, im not catching, you are saying that later on the boot process it works?
<leowt> the mainline one with exynos4412-odroidx.dts, just hangs here
<leowt> for about 10 secs and then reboots
<javier__> leowt: no, what I'm saying is that EPROBE_DEFER (-517) is not necessarily an error code
<javier__> leowt: at some point you will have to figure out the differences between the odroidx and your board to adapt the DT correctly
<javier__> using a DT from another board may give you a serial console but unless the schematic is the same, you need to adapt the hw description
<leowt> tiny4412 is from the same vendor, i found that for example leds gpio matches
<leowt> but if i boot with it, it fails setting the cpus
<leowt> i suppose that there is something to do with clock, but if so, is clock defined in dt files?
<javier__> leowt: yes, there are some clocks that are defined in the DT
<javier__> others that are setup by the firmware or boot-loader
<javier__> leowt: max77686 0-0009: device not found on this channel (this is not an error)
<javier__> this is interesting, does your board use the same max77686 PMIC?
<javier__> and if so, it is in the same i2c bus and address?
<leowt> yes it does
<leowt> i will go check
<leowt> im checking pmic-77686.h
afaerber has quit [Quit: Verlassend]
<leowt> i can get no reference to an address or gpio
<leowt> :/
<leowt> found one
<leowt> gpx
<leowt> .irq_gpio= EXYNOS4_GPX3(2),
<leowt> .ono=EXYNOS4_GPX1(2),
<leowt> should regulator_p3v3 on dts be with one of those?
liquidAcid has joined #linux-exynos
<leowt> this is the output with tiny4412 dts
<leowt> yeyy
<leowt> got it booting with another frankenstein hack
<leowt> j
<leowt> deteled the regulator and sdhc stuff from odroid-common.dtsi (the parts that didnt work at first with odroidx dtb)
<leowt> and added the sdhc from tiny
<liquidAcid> leowt, you should probably just add the right regulators
<leowt> i have to learn first, but since i have at least booted to the rootfs, i can now dig into it :)
<leowt> brb
leowt has quit [Quit: Textual IRC Client: www.textualapp.com]
leowt has joined #linux-exynos
zombah has joined #linux-exynos
afaerber has joined #linux-exynos
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
<liquidAcid> prahal, ping!
bzyx has quit [Remote host closed the connection]
bzyx has joined #linux-exynos
bzyx has quit [Remote host closed the connection]
bzyx has joined #linux-exynos
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
leowt has quit [Quit: Textual IRC Client: www.textualapp.com]
<prahal> liquidAcid: hi
<liquidAcid> prahal, yo!
<liquidAcid> prahal, can you do me a favor and test something?
<prahal> yes, but should fit in the few hours left of today (tomorrow I will be away
leowt has joined #linux-exynos
leowt has quit [Client Quit]
<liquidAcid> prahal, gustavo is looking for more people to test the atomic patches: http://www.spinics.net/lists/linux-samsung-soc/msg43989.html
leowt has joined #linux-exynos
<liquidAcid> prahal, if you find some time, you could run some checks and then report back on the ml
<prahal> fine with me
<liquidAcid> i hope this accelerates the merging process
<prahal> liquidAcid: I still get page fault with drm iommu here (on restart of gdm3)
<liquidAcid> prahal, hmm, i'm not running X here, so all my test are apps from libdrm (mostly modetest)
<liquidAcid> have you managed to trigger this with modetest?
<prahal> I have not tested , will do
<liquidAcid> if you don't want to apply the series yourself
<liquidAcid> prahal, do you have dmesg from the page fault?
<prahal> yes , still the exynos iommu irq dump is not that helpfull , the later oops gives a better clue as of the issue (but it turned out the page fault was in the drm initial dma mapping (the one created by drm_create_iommu_mapping, ie EXYNOS_DEV_ADDR_START
<prahal> the sysmu was _tv one , ie the one attached to mixer
<prahal> then I worked around it and now I get a page fault about an address below 0x10000000
<prahal> the whole coneption seems to contradict the sysmmu dt binding doc
<prahal> that is ' one System MMU can handle transactions from only one peripheral device'
<liquidAcid> prahal, i think i have an idea why that happens
<liquidAcid> prahal, did you say it happens when you restart gdm?
<prahal> if we attach the first subdevice to drm device , then drm device to all other subdevice ..
<prahal> yes
<liquidAcid> you should revert that one
<liquidAcid> + mode_cmd.height = sizes->surface_height * NUM_BUFFERS;
<liquidAcid> that doesn't work anymore
<liquidAcid> in particular it leads to this scenario:
<liquidAcid> if a user of the drm restores the crtc after cleanup the drm tries to restore the attached framebuffer, which is the one from the fbdev emulation
<liquidAcid> this fails, so the mixer is never configured to scan out this buffer, it's still scanning out the last configured one
<liquidAcid> then the drm user deallocates it's buffers, and voila, pagefault
<liquidAcid> you should see this more clearly with drm.debug=0xff
<liquidAcid> pagefault probably happens shortly after the scanout buffer is deallocated
<prahal> got a page fault (different one), will drm.debug
<liquidAcid> should fix the pagefault that happens due to register dumping
<prahal> no , trying right now
<prahal> with those two patches : "fb_ioctl + num_buffers" and "drm mixer dump"
<prahal> and drm.debug on , I was unable to reproduce the page fault :)
<prahal> time to try without drm.debug
<prahal> bah , got the page fault without the drm.debug (gdm3 restart ok , then login X session <- failed )
<liquidAcid> hmm, strange
<prahal> still the new page fault now match the previous run debug output
<liquidAcid> i guess there are still more racing bugs in the mixer and surrounding code
<prahal> page fault is at 0x900000 by 12e20000.sysmmu while previous run had : [drm:exynos_drm_fb_buffer] dma_addr = 0x900000
<prahal> a lot of instance of the drm fb buffer in the previous run had this address
<liquidAcid> still, my guess would be that mixer is still scanning out from 0x900000 when the buffer is already deallocated
liquidAcid has quit [Quit: Leaving]
prahal has quit [Quit: prahal]