exynos-drm-next todo work.

[Inki Dae]

> -----Original Message-----
> From: Rahul Sharma [mailto:r.sh.open at gmail.com]
> Sent: Tuesday, June 18, 2013 6:46 PM
> To: Inki Dae
> Cc: linux-samsung-soc at 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 at 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.
> >
> > 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
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html