From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Leela Krishna Amudala <l.krishna@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
kgene.kim@samsung.com, ben-linux@fluff.org,
dri-devel@lists.freedesktop.org, m.szyprowski@samsung.com
Subject: Re: [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/
Date: Tue, 07 Aug 2012 15:05:30 +0000 [thread overview]
Message-ID: <50212EBA.5000600@samsung.com> (raw)
In-Reply-To: <20120807143342.GD18957@n2100.arm.linux.org.uk>
On 08/07/2012 04:33 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 07, 2012 at 06:04:30PM +0530, Leela Krishna Amudala wrote:
>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --------------------
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>> drivers/video/s3c-fb.c | 2 +-
>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +++++++++++++++++--
>
> Isn't include/video for framebuffer drivers? Isn't this more a DRM thing?
> Wouldn't include/drm therefore be more appropriate?
Those headers are now used by both: framebuffer and Exynos DRM
driver. And probably the framebuffer driver has more users, as it
also covers older FIMD devices than those found on exynos4/5 SoCs.
So include/video seems equally right (or wrong) as include/drm.
There have been some efforts, or at least requirements raised, to
create some common low level API for framebuffer and DRM drivers,
but nothing has clarified yet AFAICS.
WARNING: multiple messages have this Message-ID (diff)
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Leela Krishna Amudala <l.krishna@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
kgene.kim@samsung.com, ben-linux@fluff.org,
dri-devel@lists.freedesktop.org, m.szyprowski@samsung.com
Subject: Re: [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/
Date: Tue, 07 Aug 2012 17:05:30 +0200 [thread overview]
Message-ID: <50212EBA.5000600@samsung.com> (raw)
In-Reply-To: <20120807143342.GD18957@n2100.arm.linux.org.uk>
On 08/07/2012 04:33 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 07, 2012 at 06:04:30PM +0530, Leela Krishna Amudala wrote:
>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --------------------
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>> drivers/video/s3c-fb.c | 2 +-
>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +++++++++++++++++--
>
> Isn't include/video for framebuffer drivers? Isn't this more a DRM thing?
> Wouldn't include/drm therefore be more appropriate?
Those headers are now used by both: framebuffer and Exynos DRM
driver. And probably the framebuffer driver has more users, as it
also covers older FIMD devices than those found on exynos4/5 SoCs.
So include/video seems equally right (or wrong) as include/drm.
There have been some efforts, or at least requirements raised, to
create some common low level API for framebuffer and DRM drivers,
but nothing has clarified yet AFAICS.
WARNING: multiple messages have this Message-ID (diff)
From: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/
Date: Tue, 07 Aug 2012 17:05:30 +0200 [thread overview]
Message-ID: <50212EBA.5000600@samsung.com> (raw)
In-Reply-To: <20120807143342.GD18957@n2100.arm.linux.org.uk>
On 08/07/2012 04:33 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 07, 2012 at 06:04:30PM +0530, Leela Krishna Amudala wrote:
>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --------------------
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>> drivers/video/s3c-fb.c | 2 +-
>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +++++++++++++++++--
>
> Isn't include/video for framebuffer drivers? Isn't this more a DRM thing?
> Wouldn't include/drm therefore be more appropriate?
Those headers are now used by both: framebuffer and Exynos DRM
driver. And probably the framebuffer driver has more users, as it
also covers older FIMD devices than those found on exynos4/5 SoCs.
So include/video seems equally right (or wrong) as include/drm.
There have been some efforts, or at least requirements raised, to
create some common low level API for framebuffer and DRM drivers,
but nothing has clarified yet AFAICS.
next prev parent reply other threads:[~2012-08-07 15:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 12:34 [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/ Leela Krishna Amudala
2012-08-07 12:46 ` Leela Krishna Amudala
2012-08-07 12:34 ` Leela Krishna Amudala
2012-08-07 12:34 ` [PATCH V4 1/2] include/video: move fimd register headers from platform to include/video Leela Krishna Amudala
2012-08-07 12:46 ` Leela Krishna Amudala
2012-08-07 12:34 ` Leela Krishna Amudala
2012-08-07 14:28 ` Arnd Bergmann
2012-08-07 14:28 ` Arnd Bergmann
2012-08-07 14:28 ` Arnd Bergmann
2012-08-07 15:25 ` Arnd Bergmann
2012-08-07 15:25 ` Arnd Bergmann
2012-08-07 15:25 ` Arnd Bergmann
2012-08-07 12:34 ` [PATCH V4 2/2] include/video: Add register offsets for FIMD version 8 Leela Krishna Amudala
2012-08-07 12:46 ` Leela Krishna Amudala
2012-08-07 12:34 ` Leela Krishna Amudala
2012-08-07 14:33 ` [PATCH V4 0/2] arm: samsung: Move FIMD headers to include/video/ Russell King - ARM Linux
2012-08-07 14:33 ` Russell King - ARM Linux
2012-08-07 14:33 ` Russell King - ARM Linux
2012-08-07 15:05 ` Sylwester Nawrocki [this message]
2012-08-07 15:05 ` Sylwester Nawrocki
2012-08-07 15:05 ` Sylwester Nawrocki
2012-08-08 6:20 ` Kukjin Kim
2012-08-08 6:20 ` Kukjin Kim
2012-08-08 6:20 ` Kukjin Kim
-- strict thread matches above, loose matches on Subject: below --
2012-08-07 12:26 Leela Krishna Amudala
2012-08-07 12:38 ` Leela Krishna Amudala
2012-08-07 12:26 ` Leela Krishna Amudala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50212EBA.5000600@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=ben-linux@fluff.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kgene.kim@samsung.com \
--cc=l.krishna@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.