Re: hdmi on 4430 (kernel 3.4)
Hi Jon, Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter jon-hun...@ti.com ha scritto: I wanted to check the HDMI registers, but I didn't find the hdmi registers table on the TRM. Does someone have some hint, comment or previous experience on that? Where can I find the hdmi registers list on the manual or other documentation? Note that as far as i know, the 2.6.35 kernel was working correctly (I can't check right now, unfortunately). Thank you. I would recommend posting this query on the TI E2E forum for Linux [1]. You may get better help there seeing that this is with regard to a specific TI development kernel branch. Thank you very much for the suggestion! I'll post there. Can you confirm that the kernel version I am using works without problem with HDMI-1080p? Thanks Cheers Federico -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hdmi on 4430 (kernel 3.4)
Hi Everybody, I am working on a custom OMAP4430 board with HDMI support. I am using the latest omapzoom ubuntu-integration kernel (3.4.0-1487.6) I tested the same on the pandaboard with the same cpu, with the same result. Both are lacking the HDMI Companion chip (U6 on pandaboard with 4430), because on our custom board we don't need EDID support (we are using an HDMI to VGA chip converter), for testing purpose it was removed from the pandaboard. I am unable to make HDMI working. I was assured that this kernel is correctly working with HDMI on pandaboard, so I'd guess that the problem is due to the missing edid, but I am not 100% sure. For simplicity, I removed the DVI configuration on the panda board file, by removing the DVI display configuration, and changing the default device to HDMI. The hdmi interface seems to be configured correctly , the overlay/manager/display chain is correctly setup and enabled, but no signal is detected by the monitor, and the screen is black. No errors are present in the logs - I'll send a copy of it with omapdss.debug=y tomorrow, eventually. I wanted to check the HDMI registers, but I didn't find the hdmi registers table on the TRM. Does someone have some hint, comment or previous experience on that? Where can I find the hdmi registers list on the manual or other documentation? Note that as far as i know, the 2.6.35 kernel was working correctly (I can't check right now, unfortunately). Thank you. best regards Federico Fuga -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rpmsg bus subsys_initcall initialization ordering
Hi Ohad, Il giorno 10/lug/2012, alle ore 18:22, Ohad Ben-Cohen ha scritto: On Tue, Jul 10, 2012 at 7:07 PM, Federico Fuga f...@studiofuga.com wrote: omaprpc depends on the rpmsg bus. Sorry for the ignorance, but what's omaprpc ? :) You're right, I should have explained this! :-) omaprpc is the Omap Remote Procedure Call driver. Quoting the Kconfig file, An rpmsg driver that exposes the Remote Procedure Call API to User Space, in order to allow applications to distribute remote call to more power efficient remote processors on OMAP4+ systems. It depends on rpmsg system. I guess it's some out-of-tree module (which I've never seen) so I'm not sure we want change mainline code to fix issues with it. omaprpc is out of the official mainline code, it's inside the official ti/omap branch/project. I guessed that the easier solution had been to change the initialization level, in a similar way it's done by the i2c bus driver for example. I don't know if this is the best solution to solve this, maybe the problem could be solved in the omaprpc driver (maybe this could be the right solution). If your code is anyway out-of-tree, it'd probably make more sense if this patch stays out of tree too (plus I have no way to review this patch, and understand the issue it fixes, without seeing the relevant code). If this really is about mainline kernel, let me know. Really, I don't have enough experience to say if it should be solved this way or not. For what I can see, this seems absolutely logic that busses are initialized before other drivers, so subsys_initcall should be perfectly logic. But I don't have the complete view of the system, so I could be wrong. On the other hand, I didn't find another way to solve this dependency problem. I know there is also a Makefile approach, but the dependent driver (omaprpc) is in the staging driver directory, so I think is not feasible. Any other solution? Thanks Federico -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
