Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this email is to share what we have to do so that other guys can be involved without duplicated work.
1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler device instead of VP device. And now exynos drm driver has gscaler module as a sub module of IPP framework. However, this gscaler module is very specific to IPP framework so it's not easy to reuse this module. So maybe we need so many works for it.
Video play back path using post process (AS IS): MFC--------IPP--------KMS---------FIMD or HDMI
Ideal video play back path using post process (TO BE): MFC--------KMS--------FIMD or HDMI
The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP framework in case of using gscaler as VP. All we have to do is to call kms interface (setplane) for it like we did before.
2. More features for HDMI sound support - we need to implement Exynos ALSA SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit rate, and so on from user side should be sent to drm hdmi driver via ALSA interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces of DSS driver directly. I think we could implement ALSA SoC DAI driver in more generic way if we first implement common framework for it.
Welcome to any volunteer and other opinions.
Thanks, Inki Dae
Hi Mr. Dae,
Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being the single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time.
I would like to work on this to provide a more refined solution.
regards, Rahul Sharma.
On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae inki.dae@samsung.com wrote:
Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this email is to share what we have to do so that other guys can be involved without duplicated work.
- gscaler based on KMS interfaces - exynos5250 and later use the gscaler
device instead of VP device. And now exynos drm driver has gscaler module as a sub module of IPP framework. However, this gscaler module is very specific to IPP framework so it's not easy to reuse this module. So maybe we need so many works for it.
Video play back path using post process (AS IS): MFC--------IPP--------KMS---------FIMD or HDMI
Ideal video play back path using post process (TO BE): MFC--------KMS--------FIMD or HDMI
The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP framework in case of using gscaler as VP. All we have to do is to call kms interface (setplane) for it like we did before.
- More features for HDMI sound support - we need to implement Exynos ALSA
SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit rate, and so on from user side should be sent to drm hdmi driver via ALSA interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces of DSS driver directly. I think we could implement ALSA SoC DAI driver in more generic way if we first implement common framework for it.
Welcome to any volunteer and other opinions.
Thanks, Inki Dae
-- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----Original Message----- From: Rahul Sharma [mailto:r.sh.open@gmail.com] Sent: Tuesday, June 18, 2013 6:46 PM To: Inki Dae Cc: linux-samsung-soc@vger.kernel.org; DRI mailing list Subject: Re: exynos-drm-next todo work.
Hi Mr. Dae,
Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being the single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time.
I would like to work on this to provide a more refined solution.
Thanks. However, I think it's not good to use the CDF framework to interface between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to Linux framebuffer and DRM KMS based display controller drivers as long as I know. So my opinion is to implement ALSA Soc DAI driver-it seems like possible to use as is-based on a new common framework that the other can also use it.
Thanks, Inki Dae
regards, Rahul Sharma.
On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae inki.dae@samsung.com wrote:
Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this
is to share what we have to do so that other guys can be involved
without
duplicated work.
- gscaler based on KMS interfaces - exynos5250 and later use the
gscaler
device instead of VP device. And now exynos drm driver has gscaler
module as
a sub module of IPP framework. However, this gscaler module is very
specific
to IPP framework so it's not easy to reuse this module. So maybe we need
so
many works for it.
Video play back path using post process (AS IS): MFC--------IPP--------KMS---------FIMD or HDMI
Ideal video play back path using post process (TO BE): MFC--------KMS--------FIMD or HDMI
The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP
framework
in case of using gscaler as VP. All we have to do is to call kms
interface
(setplane) for it like we did before.
- More features for HDMI sound support - we need to implement Exynos
ALSA
SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq,
bit
rate, and so on from user side should be sent to drm hdmi driver via
ALSA
interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI
driver:
in case of OMAP, it seems like that ALSA SoC audio driver calls
interfaces
of DSS driver directly. I think we could implement ALSA SoC DAI driver
in
more generic way if we first implement common framework for it.
Welcome to any volunteer and other opinions.
Thanks, Inki Dae
-- To unsubscribe from this list: send the line "unsubscribe linux-samsung-
soc" in
the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 19, 2013 at 01:48:15PM +0900, Inki Dae wrote:
Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being the single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time.
I would like to work on this to provide a more refined solution.
Thanks. However, I think it's not good to use the CDF framework to interface between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to Linux framebuffer and DRM KMS based display controller drivers as long as I know. So my opinion is to implement ALSA Soc DAI driver-it seems like possible to use as is-based on a new common framework that the other can also use it.
You guys really want to be discussing this on the ALSA list and CCing the ASoC maintainers... I do note that OMAP and SH both have HDMI support in mainline, whatever they're doing seems like a good place to start.
On Fri, Jul 5, 2013 at 2:12 PM, Mark Brown broonie@kernel.org wrote:
On Wed, Jun 19, 2013 at 01:48:15PM +0900, Inki Dae wrote:
Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being the single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time.
I would like to work on this to provide a more refined solution.
Thanks. However, I think it's not good to use the CDF framework to interface between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to Linux framebuffer and DRM KMS based display controller drivers as long as I know. So my opinion is to implement ALSA Soc DAI driver-it seems like possible to use as is-based on a new common framework that the other can also use it.
You guys really want to be discussing this on the ALSA list and CCing the ASoC maintainers... I do note that OMAP and SH both have HDMI support in mainline, whatever they're doing seems like a good place to start.
I don't know about SH, but at least OMAP (and I've seen same on MSM non-upstream driver, and I guess it is the same elsewhere), there end up being some calls from audio driver to functions exported by the display driver. I guess there is probably some better way to do it compared to how the existing drivers work.
BR, -R
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2013년 7월 8일 월요일에 Rob Clarkrobdclark@gmail.com님이 작성:
On Fri, Jul 5, 2013 at 2:12 PM, Mark Brown broonie@kernel.org wrote:
On Wed, Jun 19, 2013 at 01:48:15PM +0900, Inki Dae wrote:
Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being
the
single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time.
I would like to work on this to provide a more refined solution.
Thanks. However, I think it's not good to use the CDF framework to
interface
between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to
Linux
framebuffer and DRM KMS based display controller drivers as long as I
know.
So my opinion is to implement ALSA Soc DAI driver-it seems like
possible to
use as is-based on a new common framework that the other can also use
it.
You guys really want to be discussing this on the ALSA list and CCing the ASoC maintainers... I do note that OMAP and SH both have HDMI support in mainline, whatever they're doing seems like a good place to start.
I don't know about SH, but at least OMAP (and I've seen same on MSM non-upstream driver, and I guess it is the same elsewhere), there end up being some calls from audio driver to functions exported by the display driver. I guess there is probably some better way to do it compared to how the existing drivers work.
Agree with you. we had looked into omap driver that audio driver calls callbacks of dss driver. For this, it seems possible to use common framework between audio and hdmi driver like PHY framework does.
exynos audio---+ +--exynos hdmi omap audio ----+--common fw--+--omap dss other audio----+ +--other hdmi
Thanks, Inki Dae
BR, -R
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Inki Dae -
Mark Brown -
Rahul Sharma -
Rob Clark