#cubox irc log of Thu 13 Aug 2015

IRC log of #cubox of Thu 13 Aug 2015. All times are in CEST < Back to index

09:52 jnettlet mk01_, no the exact opposite. rmk had originally written a patch to add this functionality to the kernel but realized that it didn't belong there.

09:52 jnettlet The same functionality used to exist for x86 in the kernel but was removed a long while back at this point.

10:08 mk01_ jnettlet: btw the new renderer in v15 - I'm very close to decision to re-implement the one from v14. the image quality is BAD, we lot shaders layer completely (so no picture control, no filters), with deinterlacing it downsizes colors to 16bit, the vanilla code can't play to non-CEA resolutions, duoble rate deinterlacing is shaking picture (no compensation for odd/even first starting line). honestly I don't understand why it was changed (as

10:08 mk01_ I personally have no video which was "slow" in v14 and is OK in v15)

10:21 mk01_ btw: I added a general calculation to the fractional mode support code as a fall back in case of "odd" pixclock (not being found in precalculated table) and it works so well I haven't found a mode with broken audio (so any mode works like 1600x900, 1440x800, 1280x1024, 1366x768 ....)

10:26 mk01_ 19:21 jnettlet: I have worked around that in the IPU driver by always allocating aligned memory, but the Kodi problem needs to be tracked down

10:26 mk01_ 19:21 jnettlet: it causes some glitching at the top of the screen when the overlay is being shown.

10:26 mk01_ jnettlet: ach from the logs I see you found the same problem with jumping screen or how to call it. ^^^^

10:29 mk01_ the problem is even worse if x-res is not aligned. IPU blacks fb1 out and doesn't show anything.

10:31 mk01_ padding to bigger doesn't work (each line is shifted +those aligned pixels), but with padded down IPU correctly crops.

10:37 jnettlet mk01_, yes I know about the glitching. Like I said it keeps things stable but the problem needs to be fixed in kodi.

10:38 jnettlet everything needs to be aligned to 8 pixels and then clipped

10:39 jnettlet mk01_, at this point I actually think reviving the gstreamer video plugin makes the most sense. dv_, has already fixed almost all of these problems.

10:40 mk01_ I have PR standing by - only issue open is the "jumping" on double rate - I can nicely compensate for content with topfieldfirst, but not bottom :(

10:40 jnettlet A PR for reverting the video playback?

10:40 mk01_ "reverting" ?

10:40 jnettlet to the v14 render

10:41 mk01_ no no

10:41 mk01_ with v15 fixes

10:41 mk01_ I will just push it to the one PR for resolution change fix

10:42 jnettlet okay. I also need to track down why everything stutters when you are watching video and bring up the overlay.

10:42 mk01_ exactly this is the problem

10:42 jnettlet they should be completely separate threads and maybe on a single core system they stutter like that

10:43 jnettlet and the pause is way to long for it to be an AXI qos issue where the IPU is being starved

10:43 jnettlet actually I did bump up the IPU's priority and it made no difference

10:46 jnettlet mk01_, do you have a link to your PR?

10:46 mk01_ ok, wait, will push

10:55 mk01_ give me 20mins. I have to pick hunks - I started with the v14 renderer already

10:55 jnettlet sure no hurry

11:02 dv_ jnettlet: taking about kodi?

11:02 jnettlet dv_, yeah

11:03 dv_ jnettlet: could you ask them what they think about adopting libimxvpuapi? I tried, got no response.

11:04 jnettlet I think in general they would have no problems with it, if it didn't break anything and someone else wrote the patch.

11:05 dv_ ok

11:21 mk01_ jnettlet: https://github.com/mk01/xbmc/commits/master_fb_screen_reconf_WIP

11:24 jnettlet mk01_, that looks much better. But are we setting the proper clip region for the g2d blit?

11:24 mk01_ I spent no time on g2d yet

11:24 jnettlet okay.

11:25 jnettlet well the main application render routine is a complete mess, that explains a lot of this.

11:26 mk01_ basically, I was trying to remove the nonsense logic (to pass 3 (three) bits of info

11:26 jnettlet we are doing a lot of settings logic inside the render call.

11:26 jnettlet yeah we are doing that a lot as well

11:27 mk01_ btw update to V5 - I couldn't resist and tried again.

11:28 jnettlet and?

11:28 mk01_ (so to double check I took the correct gal folder, etc etc etc)

11:28 mk01_ I tried HB1 first

11:28 jnettlet drivers/gpu/galcore

11:28 mk01_ and was running for 2d nonstop

11:28 mk01_ so I wanted to check with you and huraaah

11:28 mk01_ but tried on Cub & HB2ex first

11:29 mk01_ and the same as all mine reports

11:29 mk01_ 2-3 changes and bye

11:29 mk01_ ut the HB1

11:29 mk01_ I now use for development

11:29 mk01_ and it simply works

11:30 jnettlet hmmm, because fritsch, jelle, and vpeter have tested my OE image and reported no problems. Even passed fritch's torture test of videos with resolution switching.

11:30 jnettlet most likely they have changed something with CMA.

11:31 mk01_ but now tell me.

11:31 jnettlet I also want to dump the in driver gpu sleeping and just rely on runtime PM

11:32 mk01_ just tell me, ... why it works on HB1/512total mem

11:32 mk01_ and doesn't work on the other two

11:32 jnettlet oh, mk01_ I bet I know what is broken for you.

11:32 mk01_ tell me

11:33 jnettlet if you don't have my latest u-boot images then you need this patch. http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v4.1-rc1-20150606/0004-ARM-imx6q-hack-to-allow-memory-accesses-to-wrap.patch

11:33 jnettlet see if that fixes things up.

11:33 mk01_ HAVE

11:34 mk01_ that

11:34 jnettlet hmmm

11:34 jnettlet well do you have an image? I can take a look over the weekend.

11:35 mk01_ https://github.com/xbianonpi/xbian-sources-kernel/blob/imx6-4.1.y/arch/arm/mach-imx/mach-imx6q.c#L287

11:35 mk01_ don't have with v5 drivers, but for sure can click to generate it

11:37 jnettlet mk01_, drop that stupid 352Mhz vpu patch and use the one I added. The VPU can just be directly parented to the 352mhz pll and you don't have to worry about slowing down the 398Mhz pll

11:37 mk01_ but don't want to waste anyones capacity on that if it WORKS for all others. we don't have currently any eminent pushing to update XBian to V5

11:37 mk01_ jnettlet: funny thing. I wanted to do it like you a way back.

11:37 mk01_ just have problem with this

11:37 mk01_ (with this solution)

11:37 jnettlet That is a bit slower for the DL/S clocks to 306Mhz

11:38 mk01_ nope

11:38 mk01_ on HB1 i have it 306 without setting rate

11:38 mk01_ on DL/Q, I have it at 352 without setting rate

11:38 jnettlet yes, that is what my patch does

11:38 mk01_ hmmm

11:38 jnettlet I think that makes sense

11:39 mk01_ yes from clock perspectie

11:39 mk01_ but what about the poping voltage ?

11:39 mk01_ I was a bit affraid to just keep it like that

11:39 jnettlet I have yet to make it crash.

11:39 jnettlet which is really all that would happen

11:40 mk01_ ok, taking back

11:40 mk01_ it was stupid

11:40 jnettlet plus if you are running the VPU that hard...my guess is the CPU will ramp up normally

11:40 mk01_ the clock IS 352

11:40 mk01_ so the design of the board should stand it natively, or ?

11:40 jnettlet the VPU runs up to 400Mhz...after that it would crash

11:41 jnettlet I have found that yes it can.

11:41 mk01_ ok so basically you are saying

11:41 jnettlet I want to add clock stepping to the VPU driver anyways.

11:42 mk01_ just rehook vpu to native 352 clock

11:42 jnettlet that is what I am doing now.

11:42 mk01_ and don't fiddle anything else (as original patch was doing)

11:42 mk01_ OK

11:42 jnettlet I may add some fiddling, but I really don't find it necessary.

11:43 jnettlet if we are worried we should just add some runtime_pm hooks that fix up the voltage...or limit the min cpufrequency to 800Mhz

11:43 jnettlet but I have found no test case where it is necessary.

11:43 mk01_ (((btw we anyhow don't use that active by default))) i have not seen any 'BIG' gains so

11:44 jnettlet mk01_, I think the gains that are seen are actually due to the cpu floor being changed to 800Mhz

11:45 mk01_ ah ok.

11:45 jnettlet but anyways...there is no reason not to clock the VPU from that pll...nothing else is using it

11:45 mk01_ Q: I don't have any deep knowledge about clks in linux kernel, but during the time I was moving the drivers to 4.1 (via 3.17, 3.19 etc)

11:46 mk01_ the clks API changed a lot - for instance in older kernels there was no possible to setrate

11:46 mk01_ on already running clock

11:46 mk01_ now there are functions for that in clk.h

11:46 jnettlet yeah...and in their new 3.14 kernel freescale tried to re-add that.

11:47 jnettlet completely broke lots of things

11:47 mk01_ and the HW ?

11:47 mk01_ hw-wise it is no problem ?

11:47 jnettlet it actually depends on the pll

11:47 mk01_ ((i mean you would export some clocks via sysfs and allowed fidling with it))

11:48 mk01_ some might some other not ?

11:48 jnettlet generally the way it works is you gate the clock upstream, change the divider, and then ungate it

11:48 jnettlet yes, it depends how they are implemented

11:49 mk01_ ok

11:49 jnettlet obviously if the clk is a mux and a lot of things use it, you can't just change that

11:49 jnettlet then you have to shut everything down, change it and reparent everything.

11:50 mk01_ yes this I learned from the original FSL clk code (and I keep that function for myself for reference still in the clk-imx6q.c...

11:51 mk01_ so FSL reverted the code ? because when you now telling that (about backport) I have the feeling I have seen DOMAINS records in fsl/imx-3.14 dtbs

11:52 mk01_ (power domains)

11:54 mk01_ btw: is it needed to run the RENDER_FLAGS through all the layers in Kodi ? when I was cutting the code in linuxrendererGLES I realised even the flags are moving thorugh the chain, finally it was again fetched via GetFieldType() from VPU so ???

11:54 jnettlet yes they reverted the patch to allow clks to be changed while running. Or re-added it

11:54 jnettlet I reverted it

11:55 mk01_ ad reverting, if you still have SPDIFS open, ... it was the four commits around clk & registers changes around MEGA and new chip

11:56 mk01_ I removed them and SPDIF is ok again

11:56 mk01_ ..... and last Q: did you manage the HDMI sound at last ?

11:56 mk01_ was the .bits = 24 a help ?

12:01 jnettlet mk01_, these patches. https://github.com/SolidRun/linux-fslc/commits/3.14-1.0.x-mx6-sr?page=15

12:02 jnettlet yeah, hdmi sound was a problem with broken edid parsing by fsl's code. I re-implemented my old method and it fixed it.

12:02 jnettlet they weren't parsing the edid correctly.

12:04 mk01_ uh, this is another topic I wanted to shortly discuss

12:05 mk01_ 1) the FSL 'fix' was really doing weird stuff (but for specific devices)

12:06 mk01_ 2) but during the 1-2w you updated the mxc-hdmi part back, I realised, that I don't have cases anymore with "no edid read"

12:06 mk01_ to elaborate a bit

12:06 mk01_ I have AVR with CEC passive switch.that means during being OFF, HDMI has no passthrogh

12:07 mk01_ and EDID provided in it's ports is something "general"

12:07 mk01_ one HPE coms, it "opens" the port and EDID from TV get's passed to the endde

12:07 mk01_ end device

12:08 mk01_ what happens for 10%-20% cases is

12:08 mk01_ that the final plugin event (and triggered i2cread)

12:08 mk01_ fails - leaving the device with "default modelist"

12:13 mk01_ this happened only ONCE with the FSL "fix"

12:13 mk01_ (I implemented dynamic modes into XBMC & passing HP events - so once it happens I just turn off/on TV and I get proper modes - so never really followed WHY this is happening, but it got mine attention when it was full ok before you reverted mxc-hdmi part)

12:13 jnettlet mk01_, yeah I need to fix that. My hotplug jitter patch is too long and needs to be cut down to 200ms. That is what these devices use to trigger an edid read to pass the new EDID

12:13 jnettlet if you want you can try dropping that patch and testing.

12:13 mk01_ ((and this happens ONLY if passive switch is between. if TV attached directly there is never issue of course))

12:13 mk01_ I can between stuff try that

12:14 mk01_ but with 200ms

12:14 mk01_ all the niceness of your jitter patch will be lost

12:14 jnettlet well, the EDID parsing on new connections isn't 100% correct either now.

12:14 mk01_ (at least with mine HW)

12:14 jnettlet well it will still buffer some of it.

12:15 mk01_ because with 1s postpone, I get just two DOWN/UP cycles

12:15 mk01_ and mostly at the right time (after all is settlet)

12:16 jnettlet well that is why I added it :) but.... we could have two timers

12:16 mk01_ if I cut it to 200ms, I will hit EACH IRQ

12:16 mk01_ ok, tell me

12:16 mk01_ (two timers)

12:16 jnettlet and with the 200ms timer just try reading the EDID and not doing a full hotplug event until we hit 1second

12:17 mk01_ AH

12:17 mk01_ ok

12:17 mk01_ good point

12:17 jnettlet I think that will handle all cases properly

12:17 mk01_ I will try it later home

12:24 mk01_ vey last thing

12:24 mk01_ I prepared for you for review https://github.com/xbianonpi/xbian-sources-kernel/commits/3.14-1.0.x-mx6-sr--fractional-modes

12:26 jnettlet okay will give it some eyeballs. thanks

12:27 mk01_ I pushed again - removed the fbsysfs export into 3rd patch. so 1 and 2nd are the "core"

12:27 mk01_ the 3rd is for now to get the modes out

12:28 mk01_ (out to user space)

12:31 mk01_ ((and here for completeness https://github.com/mk01/xbmc/commit/f20bf25a1a6b7796d48919a702affbc426a02cba#diff-ddd0bb7ae3a5f98f91357e3bdc5adc82R469 to read them into XBMC))

12:34 mk01_ jnettlet: 200ms after plugout, or plugout -> 1s jitter -> plugin + 200ms and read ?

12:40 jnettlet it is if plugin lasts for 200ms

12:42 mk01_ OK

19:33 jnettlet mk01, I think that glitching at the top of the screen is actually the IPU's alpha blending when it is is compositing the two framebuffers together.

19:34 jnettlet I need to test a few methods to see what is going on.

09:52	jnettlet	mk01_, no the exact opposite. rmk had originally written a patch to add this functionality to the kernel but realized that it didn't belong there.
09:52	jnettlet	The same functionality used to exist for x86 in the kernel but was removed a long while back at this point.
10:08	mk01_	jnettlet: btw the new renderer in v15 - I'm very close to decision to re-implement the one from v14. the image quality is BAD, we lot shaders layer completely (so no picture control, no filters), with deinterlacing it downsizes colors to 16bit, the vanilla code can't play to non-CEA resolutions, duoble rate deinterlacing is shaking picture (no compensation for odd/even first starting line). honestly I don't understand why it was changed (as
10:08	mk01_	I personally have no video which was "slow" in v14 and is OK in v15)
10:21	mk01_	btw: I added a general calculation to the fractional mode support code as a fall back in case of "odd" pixclock (not being found in precalculated table) and it works so well I haven't found a mode with broken audio (so any mode works like 1600x900, 1440x800, 1280x1024, 1366x768 ....)
10:26	mk01_	19:21 jnettlet: I have worked around that in the IPU driver by always allocating aligned memory, but the Kodi problem needs to be tracked down
10:26	mk01_	19:21 jnettlet: it causes some glitching at the top of the screen when the overlay is being shown.
10:26	mk01_	jnettlet: ach from the logs I see you found the same problem with jumping screen or how to call it. ^^^^
10:29	mk01_	the problem is even worse if x-res is not aligned. IPU blacks fb1 out and doesn't show anything.
10:31	mk01_	padding to bigger doesn't work (each line is shifted +those aligned pixels), but with padded down IPU correctly crops.
10:37	jnettlet	mk01_, yes I know about the glitching. Like I said it keeps things stable but the problem needs to be fixed in kodi.
10:38	jnettlet	everything needs to be aligned to 8 pixels and then clipped
10:39	jnettlet	mk01_, at this point I actually think reviving the gstreamer video plugin makes the most sense. dv_, has already fixed almost all of these problems.
10:40	mk01_	I have PR standing by - only issue open is the "jumping" on double rate - I can nicely compensate for content with topfieldfirst, but not bottom :(
10:40	jnettlet	A PR for reverting the video playback?
10:40	mk01_	"reverting" ?
10:40	jnettlet	to the v14 render
10:41	mk01_	no no
10:41	mk01_	with v15 fixes
10:41	mk01_	I will just push it to the one PR for resolution change fix
10:42	jnettlet	okay. I also need to track down why everything stutters when you are watching video and bring up the overlay.
10:42	mk01_	exactly this is the problem
10:42	jnettlet	they should be completely separate threads and maybe on a single core system they stutter like that
10:43	jnettlet	and the pause is way to long for it to be an AXI qos issue where the IPU is being starved
10:43	jnettlet	actually I did bump up the IPU's priority and it made no difference
10:46	jnettlet	mk01_, do you have a link to your PR?
10:46	mk01_	ok, wait, will push
10:55	mk01_	give me 20mins. I have to pick hunks - I started with the v14 renderer already
10:55	jnettlet	sure no hurry
11:02	dv_	jnettlet: taking about kodi?
11:02	jnettlet	dv_, yeah
11:03	dv_	jnettlet: could you ask them what they think about adopting libimxvpuapi? I tried, got no response.
11:04	jnettlet	I think in general they would have no problems with it, if it didn't break anything and someone else wrote the patch.
11:05	dv_	ok
11:21	mk01_	jnettlet: https://github.com/mk01/xbmc/commits/master_fb_screen_reconf_WIP
11:24	jnettlet	mk01_, that looks much better. But are we setting the proper clip region for the g2d blit?
11:24	mk01_	I spent no time on g2d yet
11:24	jnettlet	okay.
11:25	jnettlet	well the main application render routine is a complete mess, that explains a lot of this.
11:26	mk01_	basically, I was trying to remove the nonsense logic (to pass 3 (three) bits of info
11:26	jnettlet	we are doing a lot of settings logic inside the render call.
11:26	jnettlet	yeah we are doing that a lot as well
11:27	mk01_	btw update to V5 - I couldn't resist and tried again.
11:28	jnettlet	and?
11:28	mk01_	(so to double check I took the correct gal folder, etc etc etc)
11:28	mk01_	I tried HB1 first
11:28	jnettlet	drivers/gpu/galcore
11:28	mk01_	and was running for 2d nonstop
11:28	mk01_	so I wanted to check with you and huraaah
11:28	mk01_	but tried on Cub & HB2ex first
11:29	mk01_	and the same as all mine reports
11:29	mk01_	2-3 changes and bye
11:29	mk01_	ut the HB1
11:29	mk01_	I now use for development
11:29	mk01_	and it simply works
11:30	jnettlet	hmmm, because fritsch, jelle, and vpeter have tested my OE image and reported no problems. Even passed fritch's torture test of videos with resolution switching.
11:30	jnettlet	most likely they have changed something with CMA.
11:31	mk01_	but now tell me.
11:31	jnettlet	I also want to dump the in driver gpu sleeping and just rely on runtime PM
11:32	mk01_	just tell me, ... why it works on HB1/512total mem
11:32	mk01_	and doesn't work on the other two
11:32	jnettlet	oh, mk01_ I bet I know what is broken for you.
11:32	mk01_	tell me
11:33	jnettlet	if you don't have my latest u-boot images then you need this patch. http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v4.1-rc1-20150606/0004-ARM-imx6q-hack-to-allow-memory-accesses-to-wrap.patch
11:33	jnettlet	see if that fixes things up.
11:33	mk01_	HAVE
11:34	mk01_	that
11:34	jnettlet	hmmm
11:34	jnettlet	well do you have an image? I can take a look over the weekend.
11:35	mk01_	https://github.com/xbianonpi/xbian-sources-kernel/blob/imx6-4.1.y/arch/arm/mach-imx/mach-imx6q.c#L287
11:35	mk01_	don't have with v5 drivers, but for sure can click to generate it
11:37	jnettlet	mk01_, drop that stupid 352Mhz vpu patch and use the one I added. The VPU can just be directly parented to the 352mhz pll and you don't have to worry about slowing down the 398Mhz pll
11:37	mk01_	but don't want to waste anyones capacity on that if it WORKS for all others. we don't have currently any eminent pushing to update XBian to V5
11:37	mk01_	jnettlet: funny thing. I wanted to do it like you a way back.
11:37	mk01_	just have problem with this
11:37	mk01_	(with this solution)
11:37	jnettlet	That is a bit slower for the DL/S clocks to 306Mhz
11:38	mk01_	nope
11:38	mk01_	on HB1 i have it 306 without setting rate
11:38	mk01_	on DL/Q, I have it at 352 without setting rate
11:38	jnettlet	yes, that is what my patch does
11:38	mk01_	hmmm
11:38	jnettlet	I think that makes sense
11:39	mk01_	yes from clock perspectie
11:39	mk01_	but what about the poping voltage ?
11:39	mk01_	I was a bit affraid to just keep it like that
11:39	jnettlet	I have yet to make it crash.
11:39	jnettlet	which is really all that would happen
11:40	mk01_	ok, taking back
11:40	mk01_	it was stupid
11:40	jnettlet	plus if you are running the VPU that hard...my guess is the CPU will ramp up normally
11:40	mk01_	the clock IS 352
11:40	mk01_	so the design of the board should stand it natively, or ?
11:40	jnettlet	the VPU runs up to 400Mhz...after that it would crash
11:41	jnettlet	I have found that yes it can.
11:41	mk01_	ok so basically you are saying
11:41	jnettlet	I want to add clock stepping to the VPU driver anyways.
11:42	mk01_	just rehook vpu to native 352 clock
11:42	jnettlet	that is what I am doing now.
11:42	mk01_	and don't fiddle anything else (as original patch was doing)
11:42	mk01_	OK
11:42	jnettlet	I may add some fiddling, but I really don't find it necessary.
11:43	jnettlet	if we are worried we should just add some runtime_pm hooks that fix up the voltage...or limit the min cpufrequency to 800Mhz
11:43	jnettlet	but I have found no test case where it is necessary.
11:43	mk01_	(((btw we anyhow don't use that active by default))) i have not seen any 'BIG' gains so
11:44	jnettlet	mk01_, I think the gains that are seen are actually due to the cpu floor being changed to 800Mhz
11:45	mk01_	ah ok.
11:45	jnettlet	but anyways...there is no reason not to clock the VPU from that pll...nothing else is using it
11:45	mk01_	Q: I don't have any deep knowledge about clks in linux kernel, but during the time I was moving the drivers to 4.1 (via 3.17, 3.19 etc)
11:46	mk01_	the clks API changed a lot - for instance in older kernels there was no possible to setrate
11:46	mk01_	on already running clock
11:46	mk01_	now there are functions for that in clk.h
11:46	jnettlet	yeah...and in their new 3.14 kernel freescale tried to re-add that.
11:47	jnettlet	completely broke lots of things
11:47	mk01_	and the HW ?
11:47	mk01_	hw-wise it is no problem ?
11:47	jnettlet	it actually depends on the pll
11:47	mk01_	((i mean you would export some clocks via sysfs and allowed fidling with it))
11:48	mk01_	some might some other not ?
11:48	jnettlet	generally the way it works is you gate the clock upstream, change the divider, and then ungate it
11:48	jnettlet	yes, it depends how they are implemented
11:49	mk01_	ok
11:49	jnettlet	obviously if the clk is a mux and a lot of things use it, you can't just change that
11:49	jnettlet	then you have to shut everything down, change it and reparent everything.
11:50	mk01_	yes this I learned from the original FSL clk code (and I keep that function for myself for reference still in the clk-imx6q.c...
11:51	mk01_	so FSL reverted the code ? because when you now telling that (about backport) I have the feeling I have seen DOMAINS records in fsl/imx-3.14 dtbs
11:52	mk01_	(power domains)
11:54	mk01_	btw: is it needed to run the RENDER_FLAGS through all the layers in Kodi ? when I was cutting the code in linuxrendererGLES I realised even the flags are moving thorugh the chain, finally it was again fetched via GetFieldType() from VPU so ???
11:54	jnettlet	yes they reverted the patch to allow clks to be changed while running. Or re-added it
11:54	jnettlet	I reverted it
11:55	mk01_	ad reverting, if you still have SPDIFS open, ... it was the four commits around clk & registers changes around MEGA and new chip
11:56	mk01_	I removed them and SPDIF is ok again
11:56	mk01_	..... and last Q: did you manage the HDMI sound at last ?
11:56	mk01_	was the .bits = 24 a help ?
12:01	jnettlet	mk01_, these patches. https://github.com/SolidRun/linux-fslc/commits/3.14-1.0.x-mx6-sr?page=15
12:02	jnettlet	yeah, hdmi sound was a problem with broken edid parsing by fsl's code. I re-implemented my old method and it fixed it.
12:02	jnettlet	they weren't parsing the edid correctly.
12:04	mk01_	uh, this is another topic I wanted to shortly discuss
12:05	mk01_	1) the FSL 'fix' was really doing weird stuff (but for specific devices)
12:06	mk01_	2) but during the 1-2w you updated the mxc-hdmi part back, I realised, that I don't have cases anymore with "no edid read"
12:06	mk01_	to elaborate a bit
12:06	mk01_	I have AVR with CEC passive switch.that means during being OFF, HDMI has no passthrogh
12:07	mk01_	and EDID provided in it's ports is something "general"
12:07	mk01_	one HPE coms, it "opens" the port and EDID from TV get's passed to the endde
12:07	mk01_	end device
12:08	mk01_	what happens for 10%-20% cases is
12:08	mk01_	that the final plugin event (and triggered i2cread)
12:08	mk01_	fails - leaving the device with "default modelist"
12:13	mk01_	this happened only ONCE with the FSL "fix"
12:13	mk01_	(I implemented dynamic modes into XBMC & passing HP events - so once it happens I just turn off/on TV and I get proper modes - so never really followed WHY this is happening, but it got mine attention when it was full ok before you reverted mxc-hdmi part)
12:13	jnettlet	mk01_, yeah I need to fix that. My hotplug jitter patch is too long and needs to be cut down to 200ms. That is what these devices use to trigger an edid read to pass the new EDID
12:13	jnettlet	if you want you can try dropping that patch and testing.
12:13	mk01_	((and this happens ONLY if passive switch is between. if TV attached directly there is never issue of course))
12:13	mk01_	I can between stuff try that
12:14	mk01_	but with 200ms
12:14	mk01_	all the niceness of your jitter patch will be lost
12:14	jnettlet	well, the EDID parsing on new connections isn't 100% correct either now.
12:14	mk01_	(at least with mine HW)
12:14	jnettlet	well it will still buffer some of it.
12:15	mk01_	because with 1s postpone, I get just two DOWN/UP cycles
12:15	mk01_	and mostly at the right time (after all is settlet)
12:16	jnettlet	well that is why I added it :) but.... we could have two timers
12:16	mk01_	if I cut it to 200ms, I will hit EACH IRQ
12:16	mk01_	ok, tell me
12:16	mk01_	(two timers)
12:16	jnettlet	and with the 200ms timer just try reading the EDID and not doing a full hotplug event until we hit 1second
12:17	mk01_	AH
12:17	mk01_	ok
12:17	mk01_	good point
12:17	jnettlet	I think that will handle all cases properly
12:17	mk01_	I will try it later home
12:24	mk01_	vey last thing
12:24	mk01_	I prepared for you for review https://github.com/xbianonpi/xbian-sources-kernel/commits/3.14-1.0.x-mx6-sr--fractional-modes
12:26	jnettlet	okay will give it some eyeballs. thanks
12:27	mk01_	I pushed again - removed the fbsysfs export into 3rd patch. so 1 and 2nd are the "core"
12:27	mk01_	the 3rd is for now to get the modes out
12:28	mk01_	(out to user space)
12:31	mk01_	((and here for completeness https://github.com/mk01/xbmc/commit/f20bf25a1a6b7796d48919a702affbc426a02cba#diff-ddd0bb7ae3a5f98f91357e3bdc5adc82R469 to read them into XBMC))
12:34	mk01_	jnettlet: 200ms after plugout, or plugout -> 1s jitter -> plugin + 200ms and read ?
12:40	jnettlet	it is if plugin lasts for 200ms
12:42	mk01_	OK
19:33	jnettlet	mk01, I think that glitching at the top of the screen is actually the IPU's alpha blending when it is is compositing the two framebuffers together.
19:34	jnettlet	I need to test a few methods to see what is going on.