Re: [PATCH v3 00/14] Rework OMAP4+ HDMI audio support
On 08/13/2014 08:26 PM, Mark Brown wrote: On Wed, Aug 13, 2014 at 03:51:54PM +0300, Jyri Sarha wrote: I guess then the least bad alternative would be cutting the cpu-dai driver away from drivers/video/fbdev/omap2/dss/hdmi_audio.c and placing it under sound/soc/omap and registering it from hdmi_audio.c the same way as hdmi-audio-codec and asoc-simple-card is now registered. There would be two devices for a single ip, but at least the ASoC side driver would receive its resources directly from the HDMI video driver with necessary tools to synchronize the access. Just a MFD really. This approach would work for other HDMI audio situation too, where there would usually (for tda998x and SiI9022 at least) be a need to register an i2s codec driver associated with the HDMI encoder. It would probably be possible to make a single codec driver to work with multiple HDMI encoders if the API between the codec and endcoder drivers is designed that in mind. How does this sound? This sounds like a way forward, I definitely think it's a good idea to standardise the interfaces as much as we can. After discussing with Peter and Tomi I decided to change the approach a bit. There should not be any new device registered, just ASoC components that are implemented under sound/soc as a library rather than a device driver. The library would export a register and unregister functions to be called from video driver directory. The functions will then register the necessary ASoC components under the video device. If there are no objections I'll go ahead implementing this approach, first for OMAP HDMI audio, and later for SiI9022 driver we are cooking. Best regards, Jyri -- 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: Questions about enabling dps(dynamic power switching) and SLM
* Deepa Raj draj...@hotmail.com [140813 06:16]: Hi, I am working on OMAP3 and OMaP4. I know we can do AVS by smartreflex. The Questions are as follows: 1) I have gone through TRM but could not find how can we enable/disable dps and slm. Can you please point out how can we do that? With the mainline tree we currently have omap3 working for DPS. For omap4 and later, features are not working at least not yet. To play with omap3 dps with mainline kernel, you need to consider the following: 1. Start with a board that's known to work, like beagleboard xm 2. Start with omap2plus_defconfig, keep EHCI disabled, and OTG cable disconnected 3. Enable UART timeouts and off-idle on the device with something like #!/bin/bash uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode Also the screen needs to be blanked if you have one. Once the system starts hitting deeper idle states, you can see that set off values in /sys/kernel/debug/pm_debug/count. 2) Does DPS and SLM only applies to MPU,IVA and core domains or it applies to all devices? We are now cutting off all voltages during idle if the twl4030 configuration is enabled with ti,twl4030-power-idle-osc-off in the board specific .dts file. 3) According to OMAP ppt, DPS (similar like run time power management and having wakeup latency in micro seconds). If we enable DPS, does hardware take care of switching on/off power domains means there is no need of powering on/off devices through software? Right, the devices will idle and save and restore their state using runtime PM. Once all the blocking devices are idle, the system will automatically start entering deeper idle states. 4) Will DPS only triggers to retention state only or off state also? Both work, depending on if /sys/kernel/debug/pm_debug/enable_off_mode is enabled or not. 5) If we enable SLM (according to omap ppt, suspend to ram) but wakeup latencies in milliseconds, if we enable this feature, does the hardware be able to power off all the devices when system is idle or it only applies to VDD1 (MPU-IVA) or VDD2 (Core domain)? What is automatically powered down depends on the twl4030 script configuration, see for example omap3_idle_rconfig. For omap4, and later the twl6040 control is only over I2C4 AFAIK. Hope to see answers from experts. Hopefully that will get you started :) Regards, Tony -- 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 v3 00/14] Rework OMAP4+ HDMI audio support
On Thu, Aug 14, 2014 at 12:28:07PM +0300, Jyri Sarha wrote: After discussing with Peter and Tomi I decided to change the approach a bit. There should not be any new device registered, just ASoC components that are implemented under sound/soc as a library rather than a device driver. The library would export a register and unregister functions to be called from video driver directory. The functions will then register the necessary ASoC components under the video device. If there are no objections I'll go ahead implementing this approach, first for OMAP HDMI audio, and later for SiI9022 driver we are cooking. That also sounds perfectly sensible. signature.asc Description: Digital signature
Re: DTR gpio handling removed by 985bfd54c826c0ba873ca0adfd5589263e0c6ee2
Hi, On Thu, Aug 14, 2014 at 11:04:58PM +0200, Belisko Marek wrote: during 3.15 release was removed by commit 985bfd54c826c0ba873ca0adfd5589263e0c6ee2 code which was added by 9574f36fb801035f6ab0fbb1b53ce2c12c17d100 by Neil Brown. We're using DTR gpio in gta04 device. I plan to post DT binding for DTR gpio + documentation and find out that Neil's code was removed by Felipe. Greg can you please revert mentioned commit? We're using DTR gpio in gta04 device. Or is there other way how to proceed? Thanks. there are *NO* users of that in tree, if you're using it, then please add a proper DTS for your device and figure out a way of passing DTR gpio through DT. Keep in mind, also, that we might be switching back to 8250 driver (see thread from Sebastian Siewior) so you might want to look into a way of adding *generic* gpio-based DTR handling. -- balbi signature.asc Description: Digital signature
