[PATCH 0/3] add mie driver for exynos

Stéphane Marchesin stephane.marchesin at gmail.com
Tue Dec 18 05:59:50 EST 2012 

On Tue, Dec 11, 2012 at 8:01 PM, Inki Dae <inki.dae at samsung.com> wrote:
>
>
> 2012/12/12 Stéphane Marchesin <stephane.marchesin at gmail.com>
>>
>> On Mon, Dec 10, 2012 at 1:27 AM, Inki Dae <inki.dae at samsung.com> wrote:
>> >
>> >
>> > 2012/12/10 Stéphane Marchesin <stephane.marchesin at gmail.com>
>> >>
>> >> On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae <inki.dae at samsung.com> wrote:
>> >> >
>> >> >
>> >> > 2012/12/6 R. Chandrasekar <rcsekar at samsung.com>
>> >> >
>> >> >> From: "R. Chandrasekar" <rcsekar at samsung.com>
>> >> >>
>> >> >> this patch set adds the driver support for the dithering
>> >> >> functionality
>> >> >> of
>> >> >> the
>> >> >> mobile image enhancement (mie) module.
>> >> >>
>> >> >> device tree support is added for mie.
>> >> >>
>> >> >> fimd adds the mie module as plugin and calls the dithering function.
>> >> >> dithere is
>> >> >> required when the panels bpp is less then fimd output.
>> >> >>
>> >> >> though mie mie has other functionalities, current system uses only
>> >> >> dithereing.
>> >> >>
>> >> >
>> >> > Please, move mie module into drivers/video/exynos. The mie is a
>> >> > interface
>> >> > between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
>> >> > displayed. And it seems like that this doesn't need drm
>> >> > framework-relevant
>> >> > interfaces, such as gem.
>> >>
>> >> Well, if you want to support it from the DRM, it should live in
>> >> drivers/gpu/drm, and I don't think you should add another platform
>> >> driver in the first place. The profusion of platform drivers in exynos
>> >> makes it really difficult to support suspend/resume and initialization
>> >> properly as many devices which operate separately need to sync through
>> >> global variables.
>> >>
>> >
>> > MIE could be used by linux framebuffer-based specific driver(s3c-fb)
>> > also.
>>
>> Yes, but it is a DRM driver we're talking about here. Again it is
>> really difficult to work with it across suspend-resume. I don't think
>
>
> You want to use Exynos drm core framework just for suspend/resume to MIE
> module? as I mentioned before, I think the framework suitable to MIE is
> Common Display Framework. Of course, maybe you should add new features to
> Common Display Framework for it like MIPI DBI bus support framework because
> current Common Display Framework supports only display bus. Logically, MIE
> should be used without dependency of any frameworks such as Linux
> Framebuffer or DRM frameworks. And see the below hardware path,
>
> fimd--------mie-----------------------------lcd panel
> fimd--------mie--------mipi-dsi----------lcd panel
> fimd--------mie--------eDP---------------lcd panel
>
> Thus, the MIE is placed between fimd and lcd panel, mipi dsi or eDP.

But for example the MIE only affects one of the layers. So your
drawing doesn't match reality. You'd need to pass a layer number
somehow which the API doesn't seem to allow...

> And
> fimd, as display controller, could be controlled by linux framebuffer or drm
> framework.
>

I don't think it's a valid point. If the framebuffer is properly done
on top of the DRM, you don't need all of that at all.

Stéphane


>>
>> the DRM was ever meant to be a collection of independent platform
>> drivers.
>>
>>
>> > If linux framebuffer-based driver want to use this mie module, should
>> > the
>> > mie module be placed in drivers/video coping it? I think it's not good
>> > so
>> > it's better way to use this mie module commonly without duplicated
>> > codes.
>> > And mipi-dsi and eDP drivers also have their own platform device/driver
>> > and
>> > are being used by exynos drm driver or s3c-fb driver. Of course, for
>> > some
>> > IPs such as mie between display controller and lcd panel, It seems like
>> > that
>> > there should be proper framework or interfaces in drivers/video/exynos
>> > or
>> > somewhere so that other frameworks can use it commonly. And drm and
>> > linux
>> > framebuffer drivers should call the interfaces.
>>
>> For the short term, I think it's fine to duplicate the code.
>>
>> For the longer term, I think framebuffer support should be provided by
>> the drm framebuffer compat layer, and s3c-fb should disappear. This is
>> what has been done with all the other DRM drivers.
>>
>> Stéphane
>>
>>
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> >> Stéphane
>> >>
>> >>
>> >> >
>> >> > And also, please refer to the below link, Common Display Framework,
>> >> > for
>> >> > more
>> >> > generic way.
>> >> >
>> >> >
>> >> >
>> >> > http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
>> >> >
>> >> > Thanks,
>> >> > Inki Dae
>> >> >
>> >> >>
>> >> >> R. Chandrasekar (3):
>> >> >>   DTS: exynos: add device tree support for exynos mie
>> >> >>   drm: fimd: add mie plugin support for dithering
>> >> >>   drm: mie: add mie driver for exynos
>> >> >>
>> >> >>  arch/arm/boot/dts/exynos5250.dtsi               |    7 +-
>> >> >>  drivers/gpu/drm/exynos/Kconfig                  |    7 +
>> >> >>  drivers/gpu/drm/exynos/Makefile                 |    1 +
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_fimd.c        |   58 +++++-
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_mie.c         |  250
>> >> >> +++++++++++++++++++++++
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_mie.h         |   50 +++++
>> >> >>  drivers/gpu/drm/exynos/exynos_regs-mie.h        |   75 +++++++
>> >> >>  8 files changed, 465 insertions(+), 3 deletions(-)
>> >> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h
>> >> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c
>> >> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h
>> >> >>  create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h
>> >> >>
>> >> >> --
>> >> >> 1.7.9.5
>> >> >>
>> >> >> _______________________________________________
>> >> >> dri-devel mailing list
>> >> >> dri-devel at lists.freedesktop.org
>> >> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > dri-devel mailing list
>> >> > dri-devel at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >> >
>> >> _______________________________________________
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> >
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

More information about the devicetree-discuss mailing list