Re: [PATCH v3 0/7] drm/tegra: Miscellaneous enhancements
On Mon, Feb 18, 2013 at 03:42:39PM +0800, Mark Zhang wrote: > Hi Thierry, > > Which version is this patch set based on? I tried to apply it on > linux-next 0206 & tot 0215 but failed: This was based on next-20130213. Thierry pgppab5N2wus2.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/7] drm/tegra: Miscellaneous enhancements
Hi Thierry, Which version is this patch set based on? I tried to apply it on linux-next 0206 & tot 0215 but failed: Applying: drm: Add consistency check for page-flipping Applying: drm/tegra: Add plane support error: patch failed: drivers/gpu/drm/tegra/drm.h:121 error: drivers/gpu/drm/tegra/drm.h: patch does not apply Patch failed at 0002 drm/tegra: Add plane support When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Mark On 02/14/2013 12:04 AM, Thierry Reding wrote: > This patch series introduces a number of useful features for the Tegra > DRM driver. Patch 1 is a documentation update and adds a warning to the > page-flip IOCTL to catch buggy drivers that return success but failed to > update the crtc->fb field, which would cause the reference counting to > become unbalanced. > > Patch 2 adds support for the additional two planes available on Tegra > hardware, while patch 3 implement .mode_set_base() to allow for some > nice speed up when changing the framebuffer without actually changing > the resolution. Patch 4 adds VBLANK support and patch 5 builds on the > previous two to provide the page-flipping IOCTL. Patch 6 splits the > DC_CMD_STATE_CONTROL register writes into two consecutive writes as > required by the TRM. > > Finally patch 7 adds a new file, named "framebuffers" to debugfs which > can be used to dump a list of framebuffers attached to the DRM device. > This is most useful to inspect the reference count but could also be > helpful in diagnosing out-of-memory conditions and such. > > Thierry > > Thierry Reding (7): > drm: Add consistency check for page-flipping > drm/tegra: Add plane support > drm/tegra: Implement .mode_set_base() > drm/tegra: Implement VBLANK support > drm/tegra: Implement page-flipping support > drm/tegra: Split DC_CMD_STATE_CONTROL register write > drm/tegra: Add list of framebuffers to debugfs > > Documentation/DocBook/drm.tmpl | 6 + > drivers/gpu/drm/drm_crtc.c | 7 + > drivers/gpu/drm/tegra/dc.c | 489 > - > drivers/gpu/drm/tegra/dc.h | 2 +- > drivers/gpu/drm/tegra/drm.c| 103 + > drivers/gpu/drm/tegra/drm.h| 37 > 6 files changed, 533 insertions(+), 111 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapdrm: Make fixed resolution panels work
On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
working boards with fixed DPI panels. I could try the DSI video mode panel
on an OMAP5 sevm, but that will require me to patch a lot of things to get
omap5 dss work with DT. I can try if needed.
Signed-off-by: Archit Taneja
---
drivers/staging/omapdrm/omap_connector.c | 10 --
drivers/staging/omapdrm/omap_encoder.c |6 --
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
hmm, why not just have a default detect fxn for panel drivers which
always returns true? Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev->detect is null,
assume always connected. Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels. But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.
Same goes for check_timings/set_timings.. it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.
Maybe having default functions in omapdss might be a better idea. There
is an option of adding default functions in omap_dss_register_driver()
(drivers/video/omap2/dss/core.c).
Tomi, do you think it's fine to add some more default panel driver funcs?
Archit
BR,
-R
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/staging/omapdrm/omap_encoder.c
b/drivers/staging/omapdrm/omap_encoder.c
index e053160..871af12e 100644
--- a/drivers/staging/omapdrm/omap_encoder.c
+++ b/drivers/staging/omapdrm/omap_encoder.c
@@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ ret = dssdrv->check_timings ?
+ dssdrv->check_timings(dssdev, timings) : 0;
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
return 0;
}
--
1.7.9.5
___
dri-devel mailing lis
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:48 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> The sequence for replacing the scanout buffer is much shorter than a
> >>> full mode change operation so implementing this callback considerably
> >>> speeds up cases where only a new framebuffer is to be scanned out.
> >>>
> >>> Signed-off-by: Thierry Reding
> >>> ---
> >>> Changes in v3:
> >>> - split DC_CMD_STATE_CONTROL writes
> >>>
> >>> drivers/gpu/drm/tegra/dc.c | 31 +++
> >>> 1 file changed, 31 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >>> index 8f97b1c..cc4c85e 100644
> >>> --- a/drivers/gpu/drm/tegra/dc.c
> >>> +++ b/drivers/gpu/drm/tegra/dc.c
> >>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device
> >>> *drm, struct tegra_dc *dc)
> >>> return 0;
> >>> }
> >>>
> >>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> >>> + struct tegra_framebuffer *fb)
> >>> +{
> >>> + unsigned long value;
> >>> +
> >>> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> >>> +
> >>> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> >>> + x * fb->base.bits_per_pixel / 8;
> >>> +
> >>> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> >>> +
> >>> + value = GENERAL_UPDATE | WIN_A_UPDATE;
> >>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> >>> +
> >>> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> >>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> Again, what do you think about the "line stride" problem I mentioned:
> >>
> >> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
> >>
> >> Don't get me wrong that I also don't want to add a line stride update
> >> here because that doesn't make sense. It's just a workaround. But we
> >> need to find a way to make multi-head page flip working.
> >
> > I'm not sure that it's something we need to support. .mode_set_base() is
> > explicitly used only for cases where the framebuffer configuration
> > doesn't change. That is, only in cases where the only thing that changes
> > is the physical address of the framebuffer to be displayed.
> >
> > The current case where one framebuffer is used as scanout for both
> > outputs isn't something that page-flipping can support. Page-flipping is
> > always per-CRTC because typically each CRTC would run at a different
> > frequency (or even if both ran at the same frequency the VBLANK is very
> > unlikely to coincide anyway).
> >
> > So an application that wants to support page-flipping on two outputs
> > also needs to take care to set them up with different framebuffers, in
> > which case what you're describing here can't really happen.
>
> Yes, the userspace application needs to setup different framebuffers for
> different crtcs. So if LVDS & HDMI are connected, here is what the
> application does:
>
> 1. drm reports that 2 connectors: LVDS & HDMI are present in the system
> 2. The resolution of them are: 1366x768 & 1080p
> 3. Userspace application allocates 2 fbs according to the resolution got
> above.
> 4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
> created.
> 5. At this time, remember the line stride setting in dc which connects
> with LVDS is calculated according to the 1080p resolution. So finally we
> got a corrupt display because we're showing a 1366x768 fb but with
> 1080p's line stride.
I don't see how the 1080p stride would still be relevant here. Setting
the LVDS to the new 1366x768 framebuffer should trigger a full modeset
and therefore set the stride to the value required by the new 1366x768
framebuffer.
Thierry
pgpBvQuboH392.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/tegra: Add plane support
On 02/18/2013 03:01 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:40 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc
> *dc)
> +{
> + unsigned int i;
> + int err = 0;
> +
> + for (i = 0; i < 2; i++) {
> + struct tegra_plane *plane;
> +
> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
Using "devm_kzalloc" here seems like not a good idea. Everytime plane
disable or crtc disable, we should free "struct tegra_plane" which is
allocated here. But the memory which devm_kzalloc allocates is only
freed when the driver detach. This makes lots of memory can't be
recycled when the plane enable/disable frequently.
>>>
>>> Why would we want to do that? I don't think doing so would even work,
>>> since the planes are resources that need to be registered with the DRM
>>> core and therefore can't be allocated on-demand.
>>>
>>
>> I'm wondering if we add power management codes in the future, the
>> crtc/plane will be disabled/enabled frequently, e.g: system going to
>> suspend state then resume.
>
> In that case it makes even less sense to allocate and deallocate the
> plane every time around. However, any optimizations aside, the allocated
> memory is passed into the core via drm_plane_init(), which registers
> that plane with the given CRTC. So if we deallocate the memory when the
> plane when it is disabled, we'd have to make sure to remove it from the
> core as well. However that would also mean that it disappears from the
> list of planes supported by the CRTC and therefore we wouldn't be able
> to use it again.
>
Alright, I mixed up the "disable" & "remove" of planes and crtcs. You're
right. Just forget what I said in this thread.
Mark
> Thierry
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 02:48 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> The sequence for replacing the scanout buffer is much shorter than a
>>> full mode change operation so implementing this callback considerably
>>> speeds up cases where only a new framebuffer is to be scanned out.
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>>> Changes in v3:
>>> - split DC_CMD_STATE_CONTROL writes
>>>
>>> drivers/gpu/drm/tegra/dc.c | 31 +++
>>> 1 file changed, 31 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index 8f97b1c..cc4c85e 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
>>> struct tegra_dc *dc)
>>> return 0;
>>> }
>>>
>>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
>>> +struct tegra_framebuffer *fb)
>>> +{
>>> + unsigned long value;
>>> +
>>> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
>>> +
>>> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
>>> + x * fb->base.bits_per_pixel / 8;
>>> +
>>> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
>>> +
>>> + value = GENERAL_UPDATE | WIN_A_UPDATE;
>>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>>> +
>>> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>>> +
>>> + return 0;
>>> +}
>>
>> Again, what do you think about the "line stride" problem I mentioned:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>>
>> Don't get me wrong that I also don't want to add a line stride update
>> here because that doesn't make sense. It's just a workaround. But we
>> need to find a way to make multi-head page flip working.
>
> I'm not sure that it's something we need to support. .mode_set_base() is
> explicitly used only for cases where the framebuffer configuration
> doesn't change. That is, only in cases where the only thing that changes
> is the physical address of the framebuffer to be displayed.
>
> The current case where one framebuffer is used as scanout for both
> outputs isn't something that page-flipping can support. Page-flipping is
> always per-CRTC because typically each CRTC would run at a different
> frequency (or even if both ran at the same frequency the VBLANK is very
> unlikely to coincide anyway).
>
> So an application that wants to support page-flipping on two outputs
> also needs to take care to set them up with different framebuffers, in
> which case what you're describing here can't really happen.
Yes, the userspace application needs to setup different framebuffers for
different crtcs. So if LVDS & HDMI are connected, here is what the
application does:
1. drm reports that 2 connectors: LVDS & HDMI are present in the system
2. The resolution of them are: 1366x768 & 1080p
3. Userspace application allocates 2 fbs according to the resolution got
above.
4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
created.
5. At this time, remember the line stride setting in dc which connects
with LVDS is calculated according to the 1080p resolution. So finally we
got a corrupt display because we're showing a 1366x768 fb but with
1080p's line stride.
Hope I explained this clear. Try this test application if you still have
problems:
https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset-vsync.c
Mark
>
> Thierry
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/tegra: Add plane support
On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:40 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> Add support for the B and C planes which support RGB and YUV pixel
> >>> formats and can be used as overlays or hardware cursor. Currently
> >>> only 32-bit RGBA pixel formats are advertised.
> >>>
> >>> Signed-off-by: Thierry Reding
> >> [...]
> >>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc
> >>> *dc)
> >>> +{
> >>> + unsigned int i;
> >>> + int err = 0;
> >>> +
> >>> + for (i = 0; i < 2; i++) {
> >>> + struct tegra_plane *plane;
> >>> +
> >>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
> >>
> >> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
> >> disable or crtc disable, we should free "struct tegra_plane" which is
> >> allocated here. But the memory which devm_kzalloc allocates is only
> >> freed when the driver detach. This makes lots of memory can't be
> >> recycled when the plane enable/disable frequently.
> >
> > Why would we want to do that? I don't think doing so would even work,
> > since the planes are resources that need to be registered with the DRM
> > core and therefore can't be allocated on-demand.
> >
>
> I'm wondering if we add power management codes in the future, the
> crtc/plane will be disabled/enabled frequently, e.g: system going to
> suspend state then resume.
In that case it makes even less sense to allocate and deallocate the
plane every time around. However, any optimizations aside, the allocated
memory is passed into the core via drm_plane_init(), which registers
that plane with the given CRTC. So if we deallocate the memory when the
plane when it is disabled, we'd have to make sure to remove it from the
core as well. However that would also mean that it disappears from the
list of planes supported by the CRTC and therefore we wouldn't be able
to use it again.
Thierry
pgplzwLTjYpXR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/tegra: Add plane support
On 02/18/2013 02:40 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor. Currently
>>> only 32-bit RGBA pixel formats are advertised.
>>>
>>> Signed-off-by: Thierry Reding
>> [...]
>>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
>>> +{
>>> + unsigned int i;
>>> + int err = 0;
>>> +
>>> + for (i = 0; i < 2; i++) {
>>> + struct tegra_plane *plane;
>>> +
>>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>>
>> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
>> disable or crtc disable, we should free "struct tegra_plane" which is
>> allocated here. But the memory which devm_kzalloc allocates is only
>> freed when the driver detach. This makes lots of memory can't be
>> recycled when the plane enable/disable frequently.
>
> Why would we want to do that? I don't think doing so would even work,
> since the planes are resources that need to be registered with the DRM
> core and therefore can't be allocated on-demand.
>
I'm wondering if we add power management codes in the future, the
crtc/plane will be disabled/enabled frequently, e.g: system going to
suspend state then resume.
> Thierry
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > The sequence for replacing the scanout buffer is much shorter than a
> > full mode change operation so implementing this callback considerably
> > speeds up cases where only a new framebuffer is to be scanned out.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Changes in v3:
> > - split DC_CMD_STATE_CONTROL writes
> >
> > drivers/gpu/drm/tegra/dc.c | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 8f97b1c..cc4c85e 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
> > struct tegra_dc *dc)
> > return 0;
> > }
> >
> > +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> > +struct tegra_framebuffer *fb)
> > +{
> > + unsigned long value;
> > +
> > + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> > +
> > + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> > + x * fb->base.bits_per_pixel / 8;
> > +
> > + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> > +
> > + value = GENERAL_UPDATE | WIN_A_UPDATE;
> > + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> > +
> > + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> > + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> > +
> > + return 0;
> > +}
>
> Again, what do you think about the "line stride" problem I mentioned:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>
> Don't get me wrong that I also don't want to add a line stride update
> here because that doesn't make sense. It's just a workaround. But we
> need to find a way to make multi-head page flip working.
I'm not sure that it's something we need to support. .mode_set_base() is
explicitly used only for cases where the framebuffer configuration
doesn't change. That is, only in cases where the only thing that changes
is the physical address of the framebuffer to be displayed.
The current case where one framebuffer is used as scanout for both
outputs isn't something that page-flipping can support. Page-flipping is
always per-CRTC because typically each CRTC would run at a different
frequency (or even if both ran at the same frequency the VBLANK is very
unlikely to coincide anyway).
So an application that wants to support page-flipping on two outputs
also needs to take care to set them up with different framebuffers, in
which case what you're describing here can't really happen.
Thierry
pgpVopxrVGe0W.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/tegra: Add plane support
On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > Add support for the B and C planes which support RGB and YUV pixel
> > formats and can be used as overlays or hardware cursor. Currently
> > only 32-bit RGBA pixel formats are advertised.
> >
> > Signed-off-by: Thierry Reding
> [...]
> > +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
> > +{
> > + unsigned int i;
> > + int err = 0;
> > +
> > + for (i = 0; i < 2; i++) {
> > + struct tegra_plane *plane;
> > +
> > + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>
> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
> disable or crtc disable, we should free "struct tegra_plane" which is
> allocated here. But the memory which devm_kzalloc allocates is only
> freed when the driver detach. This makes lots of memory can't be
> recycled when the plane enable/disable frequently.
Why would we want to do that? I don't think doing so would even work,
since the planes are resources that need to be registered with the DRM
core and therefore can't be allocated on-demand.
Thierry
pgppxnamVJgvv.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 02:17 PM, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>> The sequence for replacing the scanout buffer is much shorter than a
>> full mode change operation so implementing this callback considerably
>> speeds up cases where only a new framebuffer is to be scanned out.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> Changes in v3:
>> - split DC_CMD_STATE_CONTROL writes
>>
>> drivers/gpu/drm/tegra/dc.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>> index 8f97b1c..cc4c85e 100644
>> --- a/drivers/gpu/drm/tegra/dc.c
>> +++ b/drivers/gpu/drm/tegra/dc.c
>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
>> struct tegra_dc *dc)
>> return 0;
>> }
>>
>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
>> + struct tegra_framebuffer *fb)
>> +{
>> +unsigned long value;
>> +
>> +tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
>> +
>> +value = fb->base.offsets[0] + y * fb->base.pitches[0] +
>> +x * fb->base.bits_per_pixel / 8;
>> +
>> +tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
>> +
>> +value = GENERAL_UPDATE | WIN_A_UPDATE;
>> +tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>> +
>> +value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>> +tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>> +
>> +return 0;
>> +}
>
> Again, what do you think about the "line stride" problem I mentioned:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>
> Don't get me wrong that I also don't want to add a line stride update
> here because that doesn't make sense. It's just a workaround. But we
> need to find a way to make multi-head page flip working.
Sorry, it's not "multi-head page flip", it should be "multi-head fb
change". For example, if LVDS & HDMI are connected, I can create 4 fbs
for them(every is double-buffered) and call drmModeSetCrtc to switch 2
fbs of LVDS & HDMI to show something.
Mark
>
> Mark
>> +
>> static const struct drm_crtc_funcs tegra_crtc_funcs = {
>> .set_config = drm_crtc_helper_set_config,
>> .destroy = drm_crtc_cleanup,
>> @@ -416,6 +437,15 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
>> return 0;
>> }
>>
>> +static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
>> +struct drm_framebuffer *old_fb)
>> +{
>> +struct tegra_framebuffer *fb = to_tegra_fb(crtc->fb);
>> +struct tegra_dc *dc = to_tegra_dc(crtc);
>> +
>> +return tegra_dc_set_base(dc, x, y, fb);
>> +}
>> +
>> static void tegra_crtc_prepare(struct drm_crtc *crtc)
>> {
>> struct tegra_dc *dc = to_tegra_dc(crtc);
>> @@ -495,6 +525,7 @@ static const struct drm_crtc_helper_funcs
>> tegra_crtc_helper_funcs = {
>> .disable = tegra_crtc_disable,
>> .mode_fixup = tegra_crtc_mode_fixup,
>> .mode_set = tegra_crtc_mode_set,
>> +.mode_set_base = tegra_crtc_mode_set_base,
>> .prepare = tegra_crtc_prepare,
>> .commit = tegra_crtc_commit,
>> .load_lut = tegra_crtc_load_lut,
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> - split DC_CMD_STATE_CONTROL writes
>
> drivers/gpu/drm/tegra/dc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 8f97b1c..cc4c85e 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
> struct tegra_dc *dc)
> return 0;
> }
>
> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> + struct tegra_framebuffer *fb)
> +{
> + unsigned long value;
> +
> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> +
> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> + x * fb->base.bits_per_pixel / 8;
> +
> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> +
> + value = GENERAL_UPDATE | WIN_A_UPDATE;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + return 0;
> +}
Again, what do you think about the "line stride" problem I mentioned:
http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
Don't get me wrong that I also don't want to add a line stride update
here because that doesn't make sense. It's just a workaround. But we
need to find a way to make multi-head page flip working.
Mark
> +
> static const struct drm_crtc_funcs tegra_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = drm_crtc_cleanup,
> @@ -416,6 +437,15 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> return 0;
> }
>
> +static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> + struct drm_framebuffer *old_fb)
> +{
> + struct tegra_framebuffer *fb = to_tegra_fb(crtc->fb);
> + struct tegra_dc *dc = to_tegra_dc(crtc);
> +
> + return tegra_dc_set_base(dc, x, y, fb);
> +}
> +
> static void tegra_crtc_prepare(struct drm_crtc *crtc)
> {
> struct tegra_dc *dc = to_tegra_dc(crtc);
> @@ -495,6 +525,7 @@ static const struct drm_crtc_helper_funcs
> tegra_crtc_helper_funcs = {
> .disable = tegra_crtc_disable,
> .mode_fixup = tegra_crtc_mode_fixup,
> .mode_set = tegra_crtc_mode_set,
> + .mode_set_base = tegra_crtc_mode_set_base,
> .prepare = tegra_crtc_prepare,
> .commit = tegra_crtc_commit,
> .load_lut = tegra_crtc_load_lut,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/tegra: Add plane support
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
> +{
> + unsigned int i;
> + int err = 0;
> +
> + for (i = 0; i < 2; i++) {
> + struct tegra_plane *plane;
> +
> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
Using "devm_kzalloc" here seems like not a good idea. Everytime plane
disable or crtc disable, we should free "struct tegra_plane" which is
allocated here. But the memory which devm_kzalloc allocates is only
freed when the driver detach. This makes lots of memory can't be
recycled when the plane enable/disable frequently.
> + if (!plane)
> + return -ENOMEM;
> +
> + plane->index = 1 + i;
> +
> + err = drm_plane_init(drm, &plane->base, 1 << dc->pipe,
> + &tegra_plane_funcs, plane_formats,
> + ARRAY_SIZE(plane_formats), false);
> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> static const struct drm_crtc_funcs tegra_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = drm_crtc_cleanup,
> };
>
> -static void tegra_crtc_dpms(struct drm_crtc *crtc, int mode)
> +static void tegra_crtc_disable(struct drm_crtc *crtc)
> {
> + struct drm_device *drm = crtc->dev;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(plane, &drm->mode_config.plane_list, head) {
> + if (plane->crtc == crtc) {
> + tegra_plane_disable(plane);
> + plane->crtc = NULL;
> +
> + if (plane->fb) {
> + drm_framebuffer_unreference(plane->fb);
> + plane->fb = NULL;
> + }
> + }
> + }
If what I mentioned above(about using devm_kzalloc to allocate "struct
tegra_plane") is correct, we need to free "struct tegra_plane" here.
> }
>
> static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> @@ -46,10 +144,11 @@ static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> return true;
> }
>
[...]
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 Beta
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #12 from Marek Ol??k --- Could you please attach an apitrace file showing the issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/8a971449/attachment.html>
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 Beta
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #11 from almos --- I just tried steam and tf2 on linux, and I didn't see any rendering error. The only abnormal thing was this line: This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer. HD6850, OpenGL version string: 3.0 Mesa 9.2-devel (git-b681ed6) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/675661b1/attachment.html>
[PATCH 9/9] drm: dvbe: add optional fbdev frontend
This adds a new fbdev frontend to the dvbe driver. It allows userspace to
access the dvbe driver via an fbdev frontend.
It is disabled by default so you can use dvbe without CONFIG_FB. It should
only be used for backwards-compatibility. Use the DRM dumb API to access
dvbe buffers properly.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 18 +++
drivers/gpu/drm/dvbe/Makefile | 1 +
drivers/gpu/drm/dvbe/dvbe.h | 23
drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 ++
drivers/gpu/drm/dvbe/dvbe_main.c | 2 +
5 files changed, 279 insertions(+)
create mode 100644 drivers/gpu/drm/dvbe/dvbe_fbdev.c
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
index e49df10..ca27455 100644
--- a/drivers/gpu/drm/dvbe/Kconfig
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -27,3 +27,21 @@ config DRM_DVBE
To compile this driver as a module, choose M here: the
module will be called dvbe.
+
+config DRM_DVBE_FBDEV
+ bool "VESA BIOS Extension DRM fbdev Compatibility Layer"
+ depends on DRM_DVBE && FB
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ This provides an fbdev frontend (via /dev/fbX) for the DVBE VESA
+ driver. Old userspace that depends on the fbdev API can access the
+ DVBE driver this way. It provides full backwards compatibility to the
+ old vesafb driver.
+
+ Newer userspace accesses graphics devices via the DRM API and the old
+ fbdev compatibility layer is not needed. Activate it only if you
+ really need to run old userspace programs.
+
+ If unsure, say N.
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
index f6fb888..e01aaa1 100644
--- a/drivers/gpu/drm/dvbe/Makefile
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -1,4 +1,5 @@
ccflags-y := -Iinclude/drm
dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o dvbe_vesa.o
+dvbe-$(CONFIG_DRM_DVBE_FBDEV) += dvbe_fbdev.o
obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
index 68fd452..dfe7c20 100644
--- a/drivers/gpu/drm/dvbe/dvbe.h
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -14,6 +14,7 @@
#define DVBE_DRV_H
#include
+#include
#include
#include
#include
@@ -47,6 +48,9 @@ struct dvbe_device {
struct drm_encoder enc;
struct drm_connector conn;
struct drm_display_mode *mode;
+
+ /* fbdev */
+ void *fbdev;
};
int dvbe_drm_load(struct drm_device *ddev, unsigned long flags);
@@ -95,4 +99,23 @@ int dvbe_vesa_damage(struct dvbe_device *dvbe, struct
dvbe_framebuffer *fb,
unsigned int flags, unsigned int color,
struct drm_clip_rect *clips, unsigned int num);
+/* fbdev helpers */
+
+#ifdef CONFIG_DRM_DVBE_FBDEV
+
+void dvbe_fbdev_init(struct dvbe_device *dvbe);
+void dvbe_fbdev_cleanup(struct dvbe_device *dvbe);
+
+#else /* CONFIG_DRM_DVBE_FBDEV */
+
+static inline void dvbe_fbdev_init(struct dvbe_device *dvbe)
+{
+}
+
+static inline void dvbe_fbdev_cleanup(struct dvbe_device *dvbe)
+{
+}
+
+#endif /* CONFIG_DRM_DVBE_FBDEV */
+
#endif /* DVBE_DRV_H */
diff --git a/drivers/gpu/drm/dvbe/dvbe_fbdev.c
b/drivers/gpu/drm/dvbe/dvbe_fbdev.c
new file mode 100644
index 000..0e22e12
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/dvbe_fbdev.c
@@ -0,0 +1,235 @@
+/*
+ * DRM VESA BIOS Extension Driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * fbdev compatibility layer
+ * This provides an fbdev framebuffer device for the DVBE driver. It is
+ * based on the old vesafb.c driver:
+ * (c) 1998 Gerd Knorr
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dvbe.h"
+
+struct dvbe_fbdev {
+ struct dvbe_device *dvbe;
+ u32 palette[256];
+};
+
+static int dvbe_fbdev_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ /*
+* Set a single color register. The values supplied are
+* already rounded down to the hardware's capabilities
+* (according to the entries in the `var' structure). Return != 0 for
+* invalid regno.
+*/
+
+ if (regno >= info->cmap.len)
+ return 1;
+ if (info->var.bits_per_pixel == 8)
+ return -EINVAL;
+ if (regno >= 16)
+ return 0;
+
+ switch (info->var.bits_per_pixel) {
+ case 16:
+ if (info->var.red.offset == 10) {
+ /* 1:5:5:5 */
+ ((u32*) (info->pseudo_palette))[regno]
[PATCH 8/9] drm: dvbe: implement VBE/VESA blitting backend
Extend the dvbe core driver by a VESA/VBE backend that simply blits the
data from a framebuffer into the hardware framebuffer on damage.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
On dirty-ioctls we simply vmap the framebuffer memory and copy each pixel
into the target framebuffer. Unfortunately, the VBE bpp/depth combinations
cannot easily be forwarded to the user via the DRM API as it allows a lot
more combinations. Hence, we need to convert each pixel from the user's
buffer format into the target format while blitting.
Fast-paths for xrgb32/etc. could be implemented if we want to improve
blitting performance.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 1 +
drivers/gpu/drm/dvbe/Makefile| 2 +-
drivers/gpu/drm/dvbe/dvbe.h | 25
drivers/gpu/drm/dvbe/dvbe_main.c | 39 +-
drivers/gpu/drm/dvbe/dvbe_vesa.c | 263 +++
5 files changed, 325 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/dvbe/dvbe_vesa.c
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
index bb3aa7b..e49df10 100644
--- a/drivers/gpu/drm/dvbe/Kconfig
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -3,6 +3,7 @@ config DRM_DVBE
depends on DRM
select DRM_KMS_HELPER
select DRM_SYSFB
+ select FB_BOOT_VESA_SUPPORT
help
This is a DRM/KMS driver for VESA BIOS Extension (VBE) compatible
cards. At least VBE 2.0 is needed. Older VBE 1.2 cards are not
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
index b053da3..f6fb888 100644
--- a/drivers/gpu/drm/dvbe/Makefile
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -1,4 +1,4 @@
ccflags-y := -Iinclude/drm
-dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o
+dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o dvbe_vesa.o
obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
index 0235a95..68fd452 100644
--- a/drivers/gpu/drm/dvbe/dvbe.h
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -25,6 +25,23 @@
struct dvbe_device {
struct drm_device *ddev;
+ /* vbe information */
+ unsigned long vbe_addr;
+ unsigned long vbe_vsize;
+ unsigned long vbe_size;
+ unsigned int vbe_depth;
+ unsigned int vbe_bpp;
+ unsigned int vbe_width;
+ unsigned int vbe_height;
+ unsigned int vbe_stride;
+ uint8_t vbe_red_size;
+ uint8_t vbe_red_pos;
+ uint8_t vbe_green_size;
+ uint8_t vbe_green_pos;
+ uint8_t vbe_blue_size;
+ uint8_t vbe_blue_pos;
+ uint8_t *vbe_map;
+
/* mode-setting objects */
struct drm_crtc crtc;
struct drm_encoder enc;
@@ -70,4 +87,12 @@ struct dvbe_framebuffer {
#define to_dvbe_fb(x) container_of(x, struct dvbe_framebuffer, base)
+/* vesa helpers */
+
+int dvbe_vesa_init(struct dvbe_device *dvbe);
+void dvbe_vesa_cleanup(struct dvbe_device *dvbe);
+int dvbe_vesa_damage(struct dvbe_device *dvbe, struct dvbe_framebuffer *fb,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips, unsigned int num);
+
#endif /* DVBE_DRV_H */
diff --git a/drivers/gpu/drm/dvbe/dvbe_main.c b/drivers/gpu/drm/dvbe/dvbe_main.c
index e73c77e..c418310 100644
--- a/drivers/gpu/drm/dvbe/dvbe_main.c
+++ b/drivers/gpu/drm/dvbe/dvbe_main.c
@@ -46,6 +46,15 @@ static bool dvbe_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct dvbe_device *dvbe = crtc->dev->dev_private;
+
+ if (mode->hdisplay != dvbe->vbe_width ||
+ mode->vdisplay != dvbe->vbe_height) {
+ dev_dbg(dvbe->ddev->dev, "invalid mode %ux%u\n",
+ mode->hdisplay, mode->vdisplay);
+ return false;
+ }
+
drm_mode_copy(adjusted_mode, mode);
return true;
}
@@ -66,6 +75,7 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
int x, int y,
struct drm_framebuffer *old_fb)
{
+ struct dvbe_device *dvbe = crtc->dev->dev_private;
struct dvbe_framebuffer *dfb = to_dvbe_fb(crtc->fb);
/* We can scan out any framebuffer that is given. The framebuffer
@@ -79,7 +89,7 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
if (x >= dfb->base.width || y >= dfb->base.height)
return -EINVAL;
- return 0;
+ return dvbe_vesa_damage(dvbe, dfb, 0, 0, NULL, 0);
}
/*
@@ -89,12 +99,13 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
static int dvbe_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
{
+ struct dvbe_device *dvbe = crtc->dev->de
[PATCH 7/9] drm: new VESA BIOS Extension DRM driver stub
This driver uses the VESA BIOS Extensions to control the display device.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
This patch only introduces the stub DRM driver without any VESA/VBE
backend that actually touches the hardware.
The driver simply provides a single crtc+encoder+connector combination
that user-space can use to access the VBE framebuffer. No page-flips are
supported and users must explicitly mark buffers as dirty to get them
copied into the framebuffer.
All buffer objects are backed by shmem so we can later add PRIME support.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/dvbe/Kconfig | 28 +++
drivers/gpu/drm/dvbe/Makefile| 4 +
drivers/gpu/drm/dvbe/dvbe.h | 73 +++
drivers/gpu/drm/dvbe/dvbe_drv.c | 104 ++
drivers/gpu/drm/dvbe/dvbe_main.c | 399 +++
drivers/gpu/drm/dvbe/dvbe_mem.c | 269 ++
8 files changed, 880 insertions(+)
create mode 100644 drivers/gpu/drm/dvbe/Kconfig
create mode 100644 drivers/gpu/drm/dvbe/Makefile
create mode 100644 drivers/gpu/drm/dvbe/dvbe.h
create mode 100644 drivers/gpu/drm/dvbe/dvbe_drv.c
create mode 100644 drivers/gpu/drm/dvbe/dvbe_main.c
create mode 100644 drivers/gpu/drm/dvbe/dvbe_mem.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2df448e..fbbdabc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -215,3 +215,5 @@ source "drivers/gpu/drm/mgag200/Kconfig"
source "drivers/gpu/drm/cirrus/Kconfig"
source "drivers/gpu/drm/shmobile/Kconfig"
+
+source "drivers/gpu/drm/dvbe/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9249b66..ec91ae8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -49,4 +49,5 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
obj-$(CONFIG_DRM_UDL) += udl/
obj-$(CONFIG_DRM_AST) += ast/
obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
+obj-$(CONFIG_DRM_DVBE) += dvbe/
obj-y += i2c/
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
new file mode 100644
index 000..bb3aa7b
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -0,0 +1,28 @@
+config DRM_DVBE
+ tristate "VESA BIOS Extension DRM Driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_SYSFB
+ help
+ This is a DRM/KMS driver for VESA BIOS Extension (VBE) compatible
+ cards. At least VBE 2.0 is needed. Older VBE 1.2 cards are not
+ supported.
+ Nearly all modern x86 graphics cards support VBE 2.0 so this driver
+ should work with all those graphics cards. However, it does not allow
+ mode-switching during runtime but requires the kernel to setup the
+ mode with the vga= kernel command line option. If you want full
+ support for your graphics card, please select a driver for your
+ specific model.
+
+ This driver can be enabled together with any other DRM graphics
+ driver. If another driver probes a device that conflicts with DVBE,
+ then DVBE will automatically drop the device and let the
+ model-specific driver take precedence.
+
+ This driver replaces the old vesafb framebuffer driver and provides
+ full backwards compatibility.
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the
+ module will be called dvbe.
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
new file mode 100644
index 000..b053da3
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -0,0 +1,4 @@
+ccflags-y := -Iinclude/drm
+
+dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o
+obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
new file mode 100644
index 000..0235a95
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -0,0 +1,73 @@
+/*
+ * DRM VESA BIOS Extension Driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#ifndef DVBE_DRV_H
+#define DVBE_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* dvbe devices */
+
+struct dvbe_device {
+ struct drm_device *ddev;
+
+ /* mode-setting objects */
+ struct drm_crtc crtc;
+ struct drm_encoder enc;
+ struct drm_connector conn;
+ struct drm_display_mode *mode;
+};
+
+int dvbe_drm_load(struct drm_device *ddev, unsigned long flags);
+int dvbe_drm_unload(struct drm_device *ddev);
+int dvbe_drm_mmap(struct file *filp, st
[PATCH 6/9] drm: new sysfb DRM bus module
This provides a new DRM bus helper for the system framebuffer bus. It is
very similar in its functionality to the DRM_USB helper. It allows to
write DRM drivers that register as SYSFB drivers to the system.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 5 ++
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_sysfb.c | 145
include/drm/drmP.h | 4 ++
include/drm/drm_sysfb.h | 35 +++
5 files changed, 190 insertions(+)
create mode 100644 drivers/gpu/drm/drm_sysfb.c
create mode 100644 include/drm/drm_sysfb.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 18321b68b..2df448e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -25,6 +25,11 @@ config DRM_USB
depends on USB_SUPPORT && USB_ARCH_HAS_HCD
select USB
+config DRM_SYSFB
+ tristate
+ depends on DRM
+ select SYSFB
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2ff5cef..9249b66 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -29,6 +29,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_USB) += drm_usb.o
+obj-$(CONFIG_DRM_SYSFB) += drm_sysfb.o
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
obj-$(CONFIG_DRM_R128) += r128/
diff --git a/drivers/gpu/drm/drm_sysfb.c b/drivers/gpu/drm/drm_sysfb.c
new file mode 100644
index 000..4e8a823
--- /dev/null
+++ b/drivers/gpu/drm/drm_sysfb.c
@@ -0,0 +1,145 @@
+/*
+ * DRM Bus for sysfb drivers
+ *
+ * Copyright 2013 David Herrmann
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+int drm_get_sysfb_dev(struct sysfb_device *sdev,
+ struct drm_driver *driver)
+{
+ struct drm_device *dev;
+ int ret;
+
+ DRM_DEBUG("\n");
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ dev_set_drvdata(&sdev->dev, dev);
+ dev->sysfbdev = sdev;
+ dev->dev = &sdev->dev;
+
+ mutex_lock(&drm_global_mutex);
+
+ ret = drm_fill_in_dev(dev, NULL, driver);
+ if (ret) {
+ DRM_ERROR("drm_fill_in_dev failed\n");
+ goto err_unlock;
+ }
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
+ if (ret)
+ goto err_unlock;
+ }
+
+ ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
+ if (ret)
+ goto err_ctrl;
+
+ if (dev->driver->load) {
+ ret = dev->driver->load(dev, 0);
+ if (ret)
+ goto err_primary;
+ }
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = drm_mode_group_init_legacy_group(dev,
+ &dev->primary->mode_group);
+ if (ret)
+ goto err_primary;
+ }
+
+ list_add_tail(&dev->driver_item, &driver->device_list);
+
+ mutex_unlock(&drm_global_mutex);
+
+ DRM_INFO("initialized %s %d.%d.%d %s on minor %d\n",
+driver->name, driver->major, driver->minor, driver->patchlevel,
+driver->date, dev->primary->index);
+
+ return 0;
+
+err_primary:
+ drm_put_minor(&dev->primary);
+err_ctrl:
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ drm_put_minor(&dev->control);
+err_unlock:
+ mutex_unlock(&drm_global_mutex);
+ kfree(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_get_sysfb_dev);
+
+static int drm_sysfb_get_irq(struct drm_device *dev)
+{
+ return 0;
+}
+
+static const char *drm_sysfb_get_name(struct drm_device *dev)
+{
+ return dev_name(&dev->sy
[PATCH 5/9] video: vesafb: use sysfb bus
Instead of using our own platform device, we now register as sysfb driver
and get notified whenever we are loaded on a system VBE device. This
allows other VBE drivers to be loaded at the same time and users can
bind/unbind drivers via sysfs. We also no longer need to fake a
platform-device because the sysfb bus provides all devices now.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 1 +
drivers/video/vesafb.c | 49 +++--
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d5723c2..5c23d32 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -776,6 +776,7 @@ config FB_VESA
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_BOOT_VESA_SUPPORT
+ select SYSFB
help
This is the frame buffer device driver for generic VESA 2.0
compliant graphic cards. The older VESA 1.2 cards are not supported.
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 4ad7b40..652858f 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -214,7 +215,7 @@ static int vesafb_setup(char *options)
return 0;
}
-static int vesafb_probe(struct platform_device *dev)
+static int vesafb_probe(struct sysfb_device *dev)
{
struct fb_info *info;
struct vesafb_par *par;
@@ -491,7 +492,7 @@ static int vesafb_probe(struct platform_device *dev)
}
printk(KERN_INFO "fb%d: %s frame buffer device\n",
info->node, info->fix.id);
- platform_set_drvdata(dev, info);
+ dev_set_drvdata(&dev->dev, info);
return 0;
err:
if (info->screen_base)
@@ -501,59 +502,39 @@ err:
return err;
}
-static int vesafb_remove(struct platform_device *dev)
+static void vesafb_remove(struct sysfb_device *dev)
{
- struct fb_info *info = platform_get_drvdata(dev);
+ struct fb_info *info = dev_get_drvdata(&dev->dev);
unregister_framebuffer(info);
- return 0;
}
-static struct platform_driver vesafb_driver = {
+static struct sysfb_driver vesafb_driver = {
+ .type_mask = SYSFB_VBE,
+ .allow_tainted = false,
+ .driver = {
+ .name = "vesafb",
+ .owner = THIS_MODULE,
+ .mod_name = KBUILD_MODNAME,
+ },
.probe = vesafb_probe,
.remove = vesafb_remove,
- .driver = {
- .name = "vesafb",
- },
};
-static struct platform_device *vesafb_device;
-
static int __init vesafb_init(void)
{
- int ret;
char *option = NULL;
/* ignore error return of fb_get_options */
fb_get_options("vesafb", &option);
vesafb_setup(option);
- vesafb_device = platform_device_alloc("vesafb", -1);
- if (!vesafb_device)
- return -ENOMEM;
-
- ret = platform_driver_register(&vesafb_driver);
- if (ret)
- goto err_dev;
-
- ret = platform_device_add(vesafb_device);
- if (ret)
- goto err_drv;
-
- return 0;
-
-err_drv:
- platform_driver_unregister(&vesafb_driver);
-err_dev:
- platform_device_put(vesafb_device);
- return ret;
+ return sysfb_register_driver(&vesafb_driver);
}
static void __exit vesafb_exit(void)
{
- platform_device_del(vesafb_device);
- platform_device_put(vesafb_device);
- platform_driver_unregister(&vesafb_driver);
+ sysfb_unregister_driver(&vesafb_driver);
}
module_init(vesafb_init);
--
1.8.1.3
[PATCH 4/9] video: vesafb: allow building as module
From: David Herrmann
Fix the vesafb module to no longer use any static __init data. Also add a
module_exit() function that destroys the platform device.
Note that fbdev hotplugging is broken and the self-reference actually
prevents sane module-unloading. Anyway, this at least allows delayed
module loading of vesafb and helps debugging vesafb a lot.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 2 +-
drivers/video/vesafb.c | 100 +++--
2 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index eac56ef..d5723c2 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -770,7 +770,7 @@ config FB_UVESA
If unsure, say N.
config FB_VESA
- bool "VESA VGA graphics support"
+ tristate "VESA VGA graphics support"
depends on (FB = y) && X86
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 501b340..4ad7b40 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -29,27 +29,10 @@
/* - */
-static struct fb_var_screeninfo vesafb_defined __initdata = {
- .activate = FB_ACTIVATE_NOW,
- .height = -1,
- .width = -1,
- .right_margin = 32,
- .upper_margin = 16,
- .lower_margin = 4,
- .vsync_len = 4,
- .vmode = FB_VMODE_NONINTERLACED,
-};
-
-static struct fb_fix_screeninfo vesafb_fix __initdata = {
- .id = "VESA VGA",
- .type = FB_TYPE_PACKED_PIXELS,
- .accel = FB_ACCEL_NONE,
-};
-
static int inverse__read_mostly;
static int mtrr __read_mostly; /* disable mtrr */
-static int vram_remap __initdata;/* Set amount of memory to be
used */
-static int vram_total __initdata;/* Set total amount of memory */
+static int vram_remap; /* Set amount of memory to be
used */
+static int vram_total; /* Set total amount of memory */
static int pmi_setpal __read_mostly = 1; /* pmi for palette changes ???
*/
static int ypan __read_mostly; /* 0..nothing, 1..ypan,
2..ywrap */
static void (*pmi_start)(void) __read_mostly;
@@ -58,6 +41,11 @@ static int depth __read_mostly;
static int vga_compat __read_mostly;
/* - */
+struct vesafb_par {
+ struct fb_ops ops;
+ u32 palette[256];
+};
+
static int vesafb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
@@ -182,7 +170,7 @@ static void vesafb_destroy(struct fb_info *info)
framebuffer_release(info);
}
-static struct fb_ops vesafb_ops = {
+static const struct fb_ops vesafb_ops = {
.owner = THIS_MODULE,
.fb_destroy = vesafb_destroy,
.fb_setcolreg = vesafb_setcolreg,
@@ -192,7 +180,7 @@ static struct fb_ops vesafb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int __init vesafb_setup(char *options)
+static int vesafb_setup(char *options)
{
char *this_opt;
@@ -226,13 +214,29 @@ static int __init vesafb_setup(char *options)
return 0;
}
-static int __init vesafb_probe(struct platform_device *dev)
+static int vesafb_probe(struct platform_device *dev)
{
struct fb_info *info;
+ struct vesafb_par *par;
int i, err;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
+ struct fb_var_screeninfo vesafb_defined = {
+ .activate = FB_ACTIVATE_NOW,
+ .height = -1,
+ .width = -1,
+ .right_margin = 32,
+ .upper_margin = 16,
+ .lower_margin = 4,
+ .vsync_len = 4,
+ .vmode = FB_VMODE_NONINTERLACED,
+ };
+ struct fb_fix_screeninfo vesafb_fix = {
+ .id = "VESA VGA",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .accel = FB_ACCEL_NONE,
+ };
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENODEV;
@@ -287,13 +291,14 @@ static int __init vesafb_probe(struct platform_device
*dev)
spaces our resource handlers simply don't know about */
}
- info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
+ info = framebuffer_alloc(sizeof(struct vesafb_par), &dev->dev);
if (!info) {
release_mem_region(vesafb_fix.smem_start, size_total);
return -ENOMEM;
}
- info->pseudo_palette = info->par;
- info->par = NULL;
+ par = info->par;
+ par->ops = vesafb_ops;
+ info->pseudo_palette = par->palette;
/* set vesafb aperture size f
[PATCH 3/9] video: sysfb: always provide vbefb device
From: David Herrmann
HACK: This should be provided by architecture setup code. But to show how it is
supposed to work, we now simply add a "vbefb" device during initialization.
The better way to do this is by moving this into arch-code. So for instance the
x86 boot initialization should create this platform-device after VBE/VESA screen
detection. Other architectures can do the same or introduce other framebuffer
types than SYSFB_VBE.
Signed-off-by: David Herrmann
---
drivers/video/sysfb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
index 5b47a9a..0c0a4e7 100644
--- a/drivers/video/sysfb.c
+++ b/drivers/video/sysfb.c
@@ -271,6 +271,8 @@ static struct platform_driver sysfb_vbe_driver = {
.remove = sysfb_vbe_remove,
};
+static struct platform_device *sysfb_vbe_device;
+
static int __init sysfb_init(void)
{
int ret;
@@ -287,6 +289,12 @@ static int __init sysfb_init(void)
goto err_bus;
}
+ sysfb_vbe_device = platform_device_register_data(NULL, "vbefb", -1,
+&screen_info,
+sizeof(screen_info));
+ if (!sysfb_vbe_device)
+ pr_warn("cannot create vbefb device\n");
+
return 0;
err_bus:
--
1.8.1.3
[PATCH 2/9] video: sysfb: new vbefb device type
From: David Herrmann
This adds the VESA BIOS Extension (VBE) device type. Platform code needs
to provide the "vbefb" platform-device with a screen_info structure as
platform code.
All drivers that depend on VBE can now register as bus drivers and bind
to SYSFB_VBE devices. There is no distinction between graphics
framebuffers or plain text VGA. Drivers ought to inspect the screen_info
and return -ENODEV during probe() is they cannot make use of the device.
Only one framebuffer of type SYSFB_VBE is available on a system at a time.
Signed-off-by: David Herrmann
---
drivers/video/sysfb.c | 77 +++
include/linux/sysfb.h | 5 +++-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
index 8249006..5b47a9a 100644
--- a/drivers/video/sysfb.c
+++ b/drivers/video/sysfb.c
@@ -205,6 +205,72 @@ void sysfb_taint(struct sysfb_device *sdev, bool set)
}
EXPORT_SYMBOL(sysfb_taint);
+static void sysfb_dev_release(struct device *dev)
+{
+ struct sysfb_device *sdev = to_sysfb_device(dev);
+
+ kfree(sdev);
+}
+
+static struct sysfb_device *sysfb_dev_new(struct device *parent)
+{
+ struct sysfb_device *sdev;
+
+ sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
+ if (!sdev)
+ return NULL;
+
+ device_initialize(&sdev->dev);
+ sdev->dev.release = sysfb_dev_release;
+ sdev->dev.bus = &sysfb_bus_type;
+ sdev->dev.parent = parent;
+
+ return sdev;
+}
+
+static int sysfb_vbe_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct sysfb_device *sdev;
+
+ sdev = sysfb_dev_new(&pdev->dev);
+ if (!sdev)
+ return -ENOMEM;
+
+ dev_set_name(&sdev->dev, "vbefb");
+ sdev->type = SYSFB_VBE;
+ sdev->screen = pdev->dev.platform_data;
+
+ ret = device_add(&sdev->dev);
+ if (ret)
+ goto err_free;
+
+ platform_set_drvdata(pdev, sdev);
+ return 0;
+
+err_free:
+ put_device(&sdev->dev);
+ return ret;
+}
+
+static int sysfb_vbe_remove(struct platform_device *pdev)
+{
+ struct sysfb_device *sdev = platform_get_drvdata(pdev);
+
+ device_del(&sdev->dev);
+ put_device(&sdev->dev);
+ return 0;
+}
+
+static struct platform_driver sysfb_vbe_driver = {
+ .driver = {
+ .name = "vbefb",
+ .owner = THIS_MODULE,
+ },
+ .probe = sysfb_vbe_probe,
+ .remove = sysfb_vbe_remove,
+};
+
static int __init sysfb_init(void)
{
int ret;
@@ -215,11 +281,22 @@ static int __init sysfb_init(void)
return ret;
}
+ ret = platform_driver_register(&sysfb_vbe_driver);
+ if (ret) {
+ pr_err("cannot register VBE framebuffer driver\n");
+ goto err_bus;
+ }
+
return 0;
+
+err_bus:
+ bus_unregister(&sysfb_bus_type);
+ return ret;
}
static void __exit sysfb_exit(void)
{
+ platform_driver_unregister(&sysfb_vbe_driver);
bus_unregister(&sysfb_bus_type);
}
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index 6cd3c24..1796c1e 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -20,6 +20,7 @@
/**
* sysfb_type
+ * @SYSFB_VBE: VESA BIOS Extension compatible device (includes VGA devices)
*
* Different types of available framebuffer devices. Only one device of each
* type can be available at a time. In most systems there even is only one
@@ -29,7 +30,9 @@
* devices.
*/
enum sysfb_type {
- SYSFB_TYPES = 0,
+ SYSFB_VBE = 0x01,
+
+ SYSFB_TYPES = SYSFB_VBE,
};
/**
--
1.8.1.3
[PATCH 1/9] video: introduce system framebuffer bus
From: David Herrmann For a long time now we have the problem that there are multiple drivers available that try to use system framebuffers (like EFI, VESA/VBE, ...). There is no way to control which driver gets access to the devices, but instead works on a first-come-first-serve basis. Furthermore, hardware drivers (eg., gpu/drm/*) that get loaded on the real hardware bus (eg., pci-bus) of the framebuffer devices have a hard time unloading other drivers that currently use system framebuffers. This introduces a new bus-type: sysfb (system framebuffer bus) Any available system framebuffer gets registered as a device on this bus. A bus-driver can then pick up the device and use it. Standard sysfs bind/unbind interfaces can be used to change drivers on-the-fly. There are actually two types of drivers: generic and real drivers Generic drivers use the generic framebuffer interface exclusively. They are often used as a fallback interface where no real driver for the hardware is available. Generic drivers register as sysfb drivers to the sysfb bus and will get loaded dynamically. User-space can bind/unbind them via sysfs to control which driver should get access. Only one driver can be active per device. During probe the driver can retrieve additional information via a screen_info object of the device. Generic drivers include: efifb, (u)vesafb, vgacon, ... Real drivers work differently. Instead of being loaded via sysfb, they register as drivers on the real bus (eg., pci-bus). During probe they should verify whether their real device provides a system-framebuffer. If it does, they call sysfb_claim() to claim exclusive access to the device. This guarantees that any generic driver gets unloaded and the real hardware driver can gain access. This also guarantees that a real hardware driver always takes precedence over generic fallback drivers. Real drivers include: i915, radeon, nouveau, ... Signed-off-by: David Herrmann --- drivers/video/Kconfig | 17 drivers/video/Makefile | 1 + drivers/video/sysfb.c | 230 + include/linux/sysfb.h | 134 4 files changed, 382 insertions(+) create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d08d799..eac56ef 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -27,6 +27,23 @@ config VGASTATE tristate default n +config SYSFB + tristate "System Framebuffer Bus" + help + Framebuffers like VGA, VESA/VBE, EFI and others can be handled by many + different drivers. This bus provides an infrastructure for drivers to + register themselves and then get bound/unbound to these system-wide + framebuffers. + This bus prevents framebuffers from being used by multiple drivers + simultaneously and also provides a sysfs API to bind/rebind different + drivers to each device from userspace. + + Chipset-specific drivers (like real GPU drivers) will always take + precedence over generic framebuffer drivers. + + A driver should normally select this bus-option automatically. Enable + it only if you need out-of-tree builds. + config VIDEO_OUTPUT_CONTROL tristate "Lowlevel video output switch controls" help diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 23e948e..f0eb006 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -5,6 +5,7 @@ # Each configuration option enables a list of files. obj-$(CONFIG_VGASTATE)+= vgastate.o +obj-$(CONFIG_SYSFB) += sysfb.o obj-y += fb_notify.o obj-$(CONFIG_FB) += fb.o fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \ diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c new file mode 100644 index 000..8249006 --- /dev/null +++ b/drivers/video/sysfb.c @@ -0,0 +1,230 @@ +/* + * System framebuffer bus + * Copyright (c) 2013 David Herrmann + */ + +/* + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + */ + +/* + * The system framebuffer bus (sysfb) provides a way to register global system + * framebuffers and load different drivers for it. This includes VESA/VBE and + * EFI framebuffers. + * Platform code is responsible of adding the framebuffer devices to the system + * platform bus. The sysfb bus will pick up known devices and provide them via + * the sysfb bus to system drivers. This guarantees that only one driver uses + * a single system framebuffer at a time. + * + * Drivers that can make use of the generic interfaces of system framebuffers + * should register as a sysfb driver. They will get not
[PATCH 0/9] System Framebuffer Bus (sysfb)
Hi This series tries to fix the mess with global system framebuffer access in device drivers. Currently, architecture initialization sets the "screen_info" object according to the system framebuffer that was detected during boot. The device driver that can map VMEM first gets access to it. There is no way to give a specific driver access to the device and no _proper_ way to revoke access again. In fact, some drivers don't even check whether they mapped the VMEM successfully, letting multiple drivers to access the system framebuffer at the same time. This series introduces a new bus in patch #1. Global system framebuffers are added as devices to this bus and drivers can register as bus drivers. Via sysfs we can now bind/unbind the drivers. This guarantees that only one driver has access to a single system-framebuffer at a time. But we can also easily control which driver gets loaded (and extend this logic at a central place if we want). If a real hardware drivers gets loaded via another bus that actually provides the system-framebuffer (like pci-bus), these drivers can use a special BUS function to claim the system framebuffer and unload all other drivers from this device. This can be used by _real_ DRM drivers that want to kill all other generic framebuffer drivers. This series adds a SYSFB_VBE (VESA/VBE) framebuffer type as example, but the bus can be used with any other system-framebuffer type. Any other architecture can add their own type like SYSFB_VBE. Patch #3 is currently a HACK to provide the VBE framebuffer on all architectures. However, the platform-device for system-framebuffers should instead be provided by architecture code. Why a new BUS type? We need a way to allow transition from a generic driver to a real hardware driver (like most DRM drivers or special fbdev drivers). We could implement this logic separately, but the BUS driver-core code is available, anyway. So lets use it and save a lot of .text space. Additionally, we get some extra features like driver binding/unbinding via sysfs for free (which is really handy for debugging). The new bus is actually implemented in <200 lines of code. I don't think we can get a smaller implementation when not using the bus-core code. Patch #4 fixes vesafb.c to be hotplug-capable. It doesn't depend on this new bus so it would be nice if it could get applied right away. It allows vesafb to be compiled as a module. Patch #5 makes vesafb.c register as new bus driver on the system-framebuffer bus. Patch #6-#9 introduce DVBE. It's a DRM driver based on VBE/VESA. It also uses the new system-framebuffer bus and provides merely the same functionality as vesafb.c but with a sane user-space API and without any fbdev dependency. What needs to be done? All drivers that use screen_info currently don't _have_ to be converted to the new bus as the request_memory() calls protect the drivers from interfering. So this new bus works even if no other driver gets converted. However, we really _should_ convert the drivers. I will do that if a maintainer agrees to take the bus code through their tree. But I hope to avoid converting all drivers if no maintainer thinks this bus is a good idea. The DVBE and vesafb drivers show how it is done. I also like to see the system-framebuffer platform-devices being registered during architecture initialization. I haven't worked much there so any comments are welcome. Otherwise, I will keep the HACK to add the devices during sysfb module-init. Regards David David Herrmann (9): video: introduce system framebuffer bus video: sysfb: new vbefb device type video: sysfb: always provide vbefb device video: vesafb: allow building as module video: vesafb: use sysfb bus drm: new sysfb DRM bus module drm: new VESA BIOS Extension DRM driver stub drm: dvbe: implement VBE/VESA blitting backend drm: dvbe: add optional fbdev frontend drivers/gpu/drm/Kconfig | 7 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/drm_sysfb.c | 145 + drivers/gpu/drm/dvbe/Kconfig | 47 + drivers/gpu/drm/dvbe/Makefile | 5 + drivers/gpu/drm/dvbe/dvbe.h | 121 +++ drivers/gpu/drm/dvbe/dvbe_drv.c | 104 + drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 + drivers/gpu/drm/dvbe/dvbe_main.c | 432 ++ drivers/gpu/drm/dvbe/dvbe_mem.c | 269 drivers/gpu/drm/dvbe/dvbe_vesa.c | 263 +++ drivers/video/Kconfig | 20 +- drivers/video/Makefile| 1 + drivers/video/sysfb.c | 315 +++ drivers/video/vesafb.c| 105 - include/drm/drmP.h| 4 + include/drm/drm_sysfb.h | 35 +++ include/linux/sysfb.h | 137 18 files changed, 2197 insertions(+), 50 deletions(-) create mode 100644 drivers/gpu/drm/drm_sysfb.c create mode 100644 drivers/gpu/drm/dvbe/Kco
[GMA500] Valid VCO frequency range on GMA500 platform?
On Mon, Feb 11, 2013 at 11:18 PM, Patrik Jakobsson wrote: > On Mon, Feb 11, 2013 at 2:15 PM, "David M?ller (ELSOFT AG)" > wrote: >> Hi Patrik >> >> Patrik Jakobsson wrote: >>> The value of VCO_MIN comes from the Intel PRM for similar GPUs. >>> >>> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and >>> M1_MAX=22? I'll test it on my own hardware tomorrow. >> >> Thanks for your suggestion. >> >> With "N_MIN=1, N_MAX=6 and M1_MAX=22", i get a refresh rate of 59.9Hz. >> >> >> Dave >> > > Those values come from the i915 driver and should work fine for us as well. > I had no problems at my end so I'll submit a patch for this. > > -Patrik I've sent in a patch for this: http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html it is slightly different to what I proposed earlier. Would be nice if you could give it a spin and report back. Thanks Patrik
Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >> >
>> >> > I think it's worth it to give them a heads-up already. So I've cc'd
>> >> > the main suspects here..
>> >>
>> >> Okay, thanks.
>> >>
>> >> >
>> >> > Daniel, Dave - any comments about a NULL fb in
>> >> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
>> >> > googling shows this:
>> >> >
>> >> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>> >>
>> >> Great, yes, I'm sure that's the same (though it says "suspend"
>> >> and I say "resume").
>> >>
>> >> >
>> >> > which sounds remarkably similar, and is also during a suspend attempt
>> >> > (but apparently Satish got a full oops out).. Some timing race with a
>> >> > worker entry?
>> >
>> > Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
>> > the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
>> > on lid open", whose force_restore case now passes down crtc->base.fb. But
>> > I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
>> > your timing race with a worker entry, perhaps.
>> >
>> > And 45e2b5f640b3 contains a fine history of going back and forth, so I
>> > wouldn't want to play further with it out of ignorance - though tempted
>> > to replace the "if (force_restore) {" by an interim safe-seeming
>> > compromise of "if (force_restore && crtc->base.fb) {".
>
> My suggestion there in the line above was stupidly wrong :(
>
>>
>> Two things to try while I try to grow a clue on what exactly is going on:
>
> Thank you.
>
> By the way, I hope you've looked back through this thread, and realize
> that Dave and I both had ThinkPad T4?0s suspend/resume display problems,
> but they've gone off in different directions: so a lot of the discussion
> comes from Dave having CONFIG_PROVE_RCU_DELAY, and has nothing to do with
> what we now know to be my oops in i915/intel_display.c.
Oh, I haven't read the earlier parts of the thread, but agree that
it's a completely different bug: Different chipset (this matters
massively for gpus usually), Dave's issue happens on -rc1 (which
doesn't contain the offending lid_notifier patch yet) and seems to die
someplace completely else than your box.
>> 1. Related to new ACPI sleep states we've recently made the lid_notifier
>> locking more sound, maybe that helps:
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
>
> Looks like it may be relevant, but I'll ignore it for now:
> preferring first to test the more minimal safety you suggest below.
>
>>
>> 2. The new i915 force restore code is indeed missing a safety check
>> compared to the old crtc helper based one:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 6eb3882..095094c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
>> *dev,
>>
>> if (force_restore) {
>> for_each_pipe(pipe) {
>> -
>> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
>> + struct drm_crtc * crtc =
>> + dev_priv->pipe_to_crtc_mapping[pipe];
>> +
>> + if (!crtc->enabled)
>> + continue;
>> +
>> + intel_crtc_restore_mode(crtc);
>> }
>>
>> i915_redisable_vga(dev);
>
> I see your followup, where you observe that intel_modeset_affected_pipes()
> should already have made this check; but you do say it would still be good
> to prove one way or the other, so I'll run from now with the patch below.
>
> Note that we haven't got to worrying about what will be in 3.9 yet
> (linux-next tells me to expect hangcheck timer problems): it's Linus's
> current git for 3.8 final that we're working on at present.
Right, patch was on top of -next, but there shouldn't be any
(functional) differences in this area compared to 3.8. The first part
of the big rework landed in 3.7 and contained the crtc->enabled check
from day one.
For the hangcheck issue in -next, that might be a new one. If you
catch it again, can you please grab the i915_error_state from debugfs
and throw it over to me? That should be enough for basic analysis.
> And since quick resumes have always worked for me, it's only occasionally
> that a long suspend (e.g. overnight) fails for me in this way, so I won't
> be able to report success for several days - but failure may come sooner.
>
> And, it being very tiresome to debug when it does fail, I have inserted
> WARN_ONs and more safety: here's what I'm running with now.
Yep, that should be interesting
[pull] tilcdc-next for 3.9
Hi Dave, Here is pull request for tilcdc drm driver.. it also includes a handful of dependent patches from me, plus a couple fixes from Daniel Vetter which haven't showed up yet in drm-next. -- The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2: Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15 10:22:01 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux tilcdc-next for you to fetch changes up to 073c917bd87a016012e03c8d98301192ae22ae34: drm/tilcdc: add support for LCD panels (v5) (2013-02-17 17:55:44 -0500) Daniel Vetter (2): drm/cma-helper: fixup compilation drm: Don't set the plane->fb to NULL on successfull set_plane Rob Clark (8): drm: small fix in drm_send_vblank_event() drm/cma: add debugfs helpers drm: i2c encoder helper wrappers drm/nouveau: use i2c encoder helper wrappers drm/tilcdc: add TI LCD Controller DRM driver (v4) drm/i2c: nxp-tda998x (v3) drm/tilcdc: add encoder slave (v2) drm/tilcdc: add support for LCD panels (v5) .../devicetree/bindings/drm/tilcdc/panel.txt | 59 ++ .../devicetree/bindings/drm/tilcdc/slave.txt | 19 + .../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 + .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 21 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_crtc.c | 2 +- drivers/gpu/drm/drm_encoder_slave.c| 63 ++ drivers/gpu/drm/drm_fb_cma_helper.c| 55 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 21 + drivers/gpu/drm/drm_irq.c | 1 + drivers/gpu/drm/i2c/Kconfig| 6 + drivers/gpu/drm/i2c/Makefile | 3 + drivers/gpu/drm/i2c/tda998x_drv.c | 906 + drivers/gpu/drm/nouveau/nv04_tv.c | 39 +- drivers/gpu/drm/tilcdc/Kconfig | 13 + drivers/gpu/drm/tilcdc/Makefile| 10 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 602 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.h| 150 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 436 ++ drivers/gpu/drm/tilcdc/tilcdc_panel.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 376 + drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 ++ drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 + include/drm/drm_encoder_slave.h| 20 + include/drm/drm_fb_cma_helper.h| 5 + include/drm/drm_gem_cma_helper.h | 4 + 30 files changed, 4070 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c create mode 100644 drivers/gpu/drm/tilcdc/Kconfig create mode 100644 drivers/gpu/drm/tilcdc/Makefile create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
[pull] omapdrm-next for 3.9
Hi Dave,
This pull moves omapdrm out of staging into drivers/gpu/drm.. since
there are a couple patches already in staging-next, I cherry-picked
these onto omapdrm-next (which is based on drm-next rather than
staging-next). I've also added a couple of Daniel's omapdrm patches,
fixed up to apply in drivers/gpu/drm.
--
The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2:
Merge branch 'drm-fb-helper' of
git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15
10:22:01 +1000)
are available in the git repository at:
git://people.freedesktop.org/~robclark/linux omapdrm-next
for you to fetch changes up to 8e44770f093c003d11784060fea4ffc82ad576eb:
drm/omap: remove fbdev debug enter/leave hooks (2013-02-16 18:14:04 -0500)
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
Cong Ding (1):
staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage
Daniel Vetter (2):
omapdrm: only take crtc->mutex in crtc callbacks
omapdrm: simplify locking in the fb debugfs file
Peter Huewe (1):
staging/omapdrm: Use kmemdup rather than duplicating its implementation
Rob Clark (2):
drm/omap: move out of staging
drm/omap: remove fbdev debug enter/leave hooks
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/{staging => gpu/drm}/omapdrm/Kconfig | 0
drivers/{staging => gpu/drm}/omapdrm/Makefile | 0
drivers/gpu/drm/omapdrm/TODO | 23 +++
.../{staging => gpu/drm}/omapdrm/omap_connector.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c | 14 +-
.../{staging => gpu/drm}/omapdrm/omap_debugfs.c| 16 +--
.../{staging => gpu/drm}/omapdrm/omap_dmm_priv.h | 5 +
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c | 159 +++--
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h | 0
drivers/{staging => gpu/drm}/omapdrm/omap_drv.c| 16 ++-
drivers/{staging => gpu/drm}/omapdrm/omap_drv.h| 8 +-
.../{staging => gpu/drm}/omapdrm/omap_encoder.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fb.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c | 5 +-
drivers/{staging => gpu/drm}/omapdrm/omap_gem.c| 34 -
.../{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c | 8 +-
.../drm}/omapdrm/omap_gem_helpers.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_irq.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_plane.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c| 0
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h| 0
drivers/{staging => gpu/drm}/omapdrm/tcm.h | 2 +
drivers/staging/Kconfig| 2 -
drivers/staging/Makefile | 1 -
drivers/staging/omapdrm/TODO | 32 -
.../omapdrm => include/uapi/drm}/omap_drm.h| 2 +-
28 files changed, 220 insertions(+), 122 deletions(-)
rename drivers/{staging => gpu/drm}/omapdrm/Kconfig (100%)
rename drivers/{staging => gpu/drm}/omapdrm/Makefile (100%)
create mode 100644 drivers/gpu/drm/omapdrm/TODO
rename drivers/{staging => gpu/drm}/omapdrm/omap_connector.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_debugfs.c (90%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_priv.h (96%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c (86%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.h (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_encoder.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fb.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_helpers.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_irq.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_plane.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm.h (99%)
delete mode 100644 drivers/staging/omapdrm/TODO
rename {drivers/staging/omapdrm => include/uapi/drm}/omap_drm.h (99%)
[Bug 60802] (bisect 8696e33f06b0c52195152cc6a0e3d52233f486c1) Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alexandre Demers changed: What|Removed |Added Summary|Kernel 3.8-rc7 breaks |(bisect |rendering on Radeon |8696e33f06b0c52195152cc6a0e |(confirmed on Cayman) |3d52233f486c1) Kernel ||3.8-rc7 breaks rendering on ||Radeon (confirmed on ||Cayman) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #4 from Alexandre Demers --- bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher Date: Thu Dec 13 18:57:07 2012 -0500 drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #2 from Chris Rankin --- Created attachment 74995 --> https://bugs.freedesktop.org/attachment.cgi?id=74995&action=edit dmesg output frpm GPU lockup/reset This dmesg log shows the GPU lockups and soft resets that occurred during my git bisect. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/aebcd018/attachment.html>
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #1 from Chris Rankin --- According to git bisect: 974b482acaf62ced1e8981761a8bda252bd51fe1 is the first bad commit commit 974b482acaf62ced1e8981761a8bda252bd51fe1 Author: Jerome Glisse Date: Fri Feb 8 16:02:32 2013 -0500 r600g: fix lockup when hyperz & alpha test are enabled together. v3 Seems that alpha test being enabled confuse the GPU on the order in which it should perform the Z testing. So force the order programmed throught db shader control. v2: Only force z order when alpha test is enabled v3: Update db shader when binding new dsa + spelling fix Signed-off-by: Jerome Glisse Reviewed-by: Marek Ol??k This results in GPU stalls, which can be reset succesfully. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/342c0e9c/attachment.html>
[Bug 60981] dri/r600: severe screen corruption with Radeon HD 6570
https://bugs.freedesktop.org/show_bug.cgi?id=60981 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 55574 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/83ca31de/attachment.html>
Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter
wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
>
> if (force_restore) {
> for_each_pipe(pipe) {
> -
> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
> + struct drm_crtc * crtc =
> + dev_priv->pipe_to_crtc_mapping[pipe];
> +
> + if (!crtc->enabled)
> + continue;
> +
> + intel_crtc_restore_mode(crtc);
> }
>
> i915_redisable_vga(dev);
>
> The issue is that we save a pointer to the fb (since those are refcounted)
> but copy the mode into the crtc struct (since modes are not refcounted).
> So on restore the mode will always be non-NULL, which is wrong if the crtc
> is off (and so also has a NULL fb).
>
> The problem I have with that patch is figuring out how this ever worked. I
> think I need more coffee ;-)
Ok, coffee seems to be working now. I think the above diff shouldn't
change anything, since we already have a crtc->enabled check in
intel_modeset_affected_pipes in intel_display.c. Still would be good
if you can prove this one way or the other.
For those wondering why this check is buried this deeply: We're in the
middle of a massive rework of our modeset code, moving from
one-crtc-at-a-time to global modeset. We need that to implement some
fancy features like fastboot or better handling of global resource
constraints (shared clocks, bw limits, ...). In the new world we set
up the desired state in staging pointers/data structures. Then the
modeset code diffs that with the current state and computes the best
way to do the transition. But since we're still converting code some
pieces pass in the new state explicitly, but lower levels then ignore
some pieces when not required to reach the desired state.
The new lid restore code relies on that by updating the tracked hw
state from the real hw one and restoring the last desired state (which
is still around from the last modeset call).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
>> I'm unsure if I like this or not, and I don't see why its greatly more >> useful than the interface we have now. > > This interface at least solves the problem with having vesafb, > uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar > drivers from accessing the system framebuffer simultaneously. And > provides a sane way of registering devices and drivers for it. But do we have the problem now? or is it more when we get dvbe/defi? Also vgacon is kinda different since fbcon kicks it off, not a driver, > It also provides a way for real drivers to unload these drivers > (sysfb_claim()) instead of using remove_conflicting_framebuffers(), > which is horribly broken and has lots of race-conditions. (I tried > fixing the fbdev refcounting/locking, but every time I tried, some > driver broke because they worked around the bug. And fixing all > drivers is just a lot of work...). > And remove_conflicting_framebuffers() also doesn't work with > vgacon/etc. which do _not_ use fbdev. but vgacon is always kicked off by fbcon, so I'm not sure what etc there is apart from it. I'd like to make fbcon a bool as well, so we don't have to deal with it appearing after the drivers. > We could simplify this approach by removing the bus and just providing > the platform-device for vbefb/etc. from the arch-code. But I thought > the bus-infrastructure allows nice rebinding of drivers if we need it > at almost no cost. I suspect a platform device is the right answer, since vesafb is that, I think we should resolve vesafb vs dvbe by just making them not config compatible, and dvbe vs defi seems like the same solution as vesafb vs efi. I'm just trying to work out what exactly you are fixing here, the problems we have now don't seem to be addressed by this, if it addresses future problems then it needs to be more upfront. >> It doesn't solve the main problem with the current interface, which is >> that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a >> real driver, things will fail either miserably or crappy from a users >> pov. >> >> The internal reference counts stop vesafb from unloading due to the >> mmaps, then i915 loads anyways and one bashes the other, or we fix so >> i915 doesn't load and the user gets fail. > > It's not the mmap that prevents vesafb from unloading, it's the > open-file instead. If a user does open(), mmap(), close(), they can > still access the mapped memory but vesafb might get unloaded (this is, > in fact, used by several user-space apps). So it's not about whether > vesafb is still loaded, but rather what to do about users which have > vesafb mmaped but don't expect it to go away. In theory we'd have to do like GEM/TTM, and unmap_mapping_range for all the open fd's mmaps and just point them to map something useless or even just return -EFAULT, because really userspace needs to be told something :-) > So what do you propose to detect this case? Keep track of every user > who mmap's vesafb? How can we detect when they unmap the memory? I > think the only way to detect this is to wait for the pages' > "mmap-count" to drop to zero and then release the memory. > > So lets compare this to other subsystems. If you unlink a file that is > still mmaped, I think the file isn't removed from memory until the > last user unmaps it. However, the memory-mapping is 'dead' in that it > doesn't have any effect on real files. > So why not copy that behavior to framebuffers? When a real DRM driver > is loaded, simply reserve the VBE framebuffer-memory in VMEM until the > last user unmaps it. But mark it 'dead' so it doesn't really belong to > a _real_ framebuffer. > So any access to the mmap'ed framebuffers will be a no-op as it just > modifies 'dead' framebuffers. > > Another idea is copying the VBE framebuffer into the DRM driver so all > old memory-maps are still valid. However, this prevents us from doing > any kind of mode-setting in the DRM driver until the last fbdev user > is gone (because there is no way to notify fbdev users of > mode-setting). > So in this case we are also stuck in a situation where we need to wait > for all users to unmap their framebuffers. It all kinda sucks, from the problems we've had previously with things like plymouth racing, (which all this will make much worse if we have kms vbe devices) really what we want the system to do is give the user the proper driver asap, stalling waiting for endless other things to let go is just going to screw users, so I think we need to be as upfront and brutal in the userspace interface if people mmaping vesafb or efifb or any generic interface then expect to load a real driver, then their old apps get killed. > Any comments? If you have a plan on how it is supposed to work (or > what the user-space semantics should be), tell me and I will try to > make it work. > I still think a central system-framebuffer registry like sysfb-bus > (which does _not_ explicitly depend on fbdev) is the way to go. > Whether it's a
webgl-conformance-tests gives errors in drm module
On Sun, Feb 17, 2013 at 11:28 AM, Toralf F?rster wrote: > While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915 > graphic. > The kernel log gives: > > > 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] > *ERROR* Timed out waiting for forcewake to ack request. > 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] > *ERROR* GT thread status wait timed out > 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] > *ERROR* Timed out waiting for forcewake to ack request. > 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] > *ERROR* GT thread status wait timed out > > A developer responded of that bug report [2] that it is a MESA thing > but b/c of the kernel msg I'm wondering whether the kernel module might be > affected too ? rc6 is an extremely fickle beast, but generally you see those messages right before the gpu dies. So I'll bet there's more than just those messages in dmesg. In any case, please try out the latest upstream driver sources first for mesa (9.1 branch) and kernel (3.8-rc series) to ensure it's not a know bug. If it still hangs you /should/ get a line about i915_error_state in debugfs in dmesg. Please file a bug report on bugs.freedesktop.org with that file attached (and citing all the git versions you've used for testing). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
Hi Dave On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote: >> >> This series tries to fix the mess with global system framebuffer access in >> device drivers. Currently, architecture initialization sets the "screen_info" >> object according to the system framebuffer that was detected during boot. The >> device driver that can map VMEM first gets access to it. There is no way to >> give >> a specific driver access to the device and no _proper_ way to revoke access >> again. In fact, some drivers don't even check whether they mapped the VMEM >> successfully, letting multiple drivers to access the system framebuffer at >> the >> same time. > > I'm unsure if I like this or not, and I don't see why its greatly more > useful than the interface we have now. This interface at least solves the problem with having vesafb, uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar drivers from accessing the system framebuffer simultaneously. And provides a sane way of registering devices and drivers for it. It also provides a way for real drivers to unload these drivers (sysfb_claim()) instead of using remove_conflicting_framebuffers(), which is horribly broken and has lots of race-conditions. (I tried fixing the fbdev refcounting/locking, but every time I tried, some driver broke because they worked around the bug. And fixing all drivers is just a lot of work...). And remove_conflicting_framebuffers() also doesn't work with vgacon/etc. which do _not_ use fbdev. We could simplify this approach by removing the bus and just providing the platform-device for vbefb/etc. from the arch-code. But I thought the bus-infrastructure allows nice rebinding of drivers if we need it at almost no cost. You could even register an oops/panic-screen as driver there and switch to it if necessary. > It doesn't solve the main problem with the current interface, which is > that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a > real driver, things will fail either miserably or crappy from a users > pov. > > The internal reference counts stop vesafb from unloading due to the > mmaps, then i915 loads anyways and one bashes the other, or we fix so > i915 doesn't load and the user gets fail. It's not the mmap that prevents vesafb from unloading, it's the open-file instead. If a user does open(), mmap(), close(), they can still access the mapped memory but vesafb might get unloaded (this is, in fact, used by several user-space apps). So it's not about whether vesafb is still loaded, but rather what to do about users which have vesafb mmaped but don't expect it to go away. So what do you propose to detect this case? Keep track of every user who mmap's vesafb? How can we detect when they unmap the memory? I think the only way to detect this is to wait for the pages' "mmap-count" to drop to zero and then release the memory. So lets compare this to other subsystems. If you unlink a file that is still mmaped, I think the file isn't removed from memory until the last user unmaps it. However, the memory-mapping is 'dead' in that it doesn't have any effect on real files. So why not copy that behavior to framebuffers? When a real DRM driver is loaded, simply reserve the VBE framebuffer-memory in VMEM until the last user unmaps it. But mark it 'dead' so it doesn't really belong to a _real_ framebuffer. So any access to the mmap'ed framebuffers will be a no-op as it just modifies 'dead' framebuffers. Another idea is copying the VBE framebuffer into the DRM driver so all old memory-maps are still valid. However, this prevents us from doing any kind of mode-setting in the DRM driver until the last fbdev user is gone (because there is no way to notify fbdev users of mode-setting). So in this case we are also stuck in a situation where we need to wait for all users to unmap their framebuffers. Any comments? If you have a plan on how it is supposed to work (or what the user-space semantics should be), tell me and I will try to make it work. I still think a central system-framebuffer registry like sysfb-bus (which does _not_ explicitly depend on fbdev) is the way to go. Whether it's a bus or not is just a matter of taste. I am willing to rework this. Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] tilcdc-next for 3.9
Hi Dave, Here is pull request for tilcdc drm driver.. it also includes a handful of dependent patches from me, plus a couple fixes from Daniel Vetter which haven't showed up yet in drm-next. -- The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2: Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15 10:22:01 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux tilcdc-next for you to fetch changes up to 073c917bd87a016012e03c8d98301192ae22ae34: drm/tilcdc: add support for LCD panels (v5) (2013-02-17 17:55:44 -0500) Daniel Vetter (2): drm/cma-helper: fixup compilation drm: Don't set the plane->fb to NULL on successfull set_plane Rob Clark (8): drm: small fix in drm_send_vblank_event() drm/cma: add debugfs helpers drm: i2c encoder helper wrappers drm/nouveau: use i2c encoder helper wrappers drm/tilcdc: add TI LCD Controller DRM driver (v4) drm/i2c: nxp-tda998x (v3) drm/tilcdc: add encoder slave (v2) drm/tilcdc: add support for LCD panels (v5) .../devicetree/bindings/drm/tilcdc/panel.txt | 59 ++ .../devicetree/bindings/drm/tilcdc/slave.txt | 19 + .../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 + .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 21 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_crtc.c | 2 +- drivers/gpu/drm/drm_encoder_slave.c| 63 ++ drivers/gpu/drm/drm_fb_cma_helper.c| 55 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 21 + drivers/gpu/drm/drm_irq.c | 1 + drivers/gpu/drm/i2c/Kconfig| 6 + drivers/gpu/drm/i2c/Makefile | 3 + drivers/gpu/drm/i2c/tda998x_drv.c | 906 + drivers/gpu/drm/nouveau/nv04_tv.c | 39 +- drivers/gpu/drm/tilcdc/Kconfig | 13 + drivers/gpu/drm/tilcdc/Makefile| 10 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 602 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.h| 150 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 436 ++ drivers/gpu/drm/tilcdc/tilcdc_panel.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 376 + drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 ++ drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 + include/drm/drm_encoder_slave.h| 20 + include/drm/drm_fb_cma_helper.h| 5 + include/drm/drm_gem_cma_helper.h | 4 + 30 files changed, 4070 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c create mode 100644 drivers/gpu/drm/tilcdc/Kconfig create mode 100644 drivers/gpu/drm/tilcdc/Makefile create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] omapdrm-next for 3.9
Hi Dave,
This pull moves omapdrm out of staging into drivers/gpu/drm.. since
there are a couple patches already in staging-next, I cherry-picked
these onto omapdrm-next (which is based on drm-next rather than
staging-next). I've also added a couple of Daniel's omapdrm patches,
fixed up to apply in drivers/gpu/drm.
--
The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2:
Merge branch 'drm-fb-helper' of
git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15
10:22:01 +1000)
are available in the git repository at:
git://people.freedesktop.org/~robclark/linux omapdrm-next
for you to fetch changes up to 8e44770f093c003d11784060fea4ffc82ad576eb:
drm/omap: remove fbdev debug enter/leave hooks (2013-02-16 18:14:04 -0500)
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
Cong Ding (1):
staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage
Daniel Vetter (2):
omapdrm: only take crtc->mutex in crtc callbacks
omapdrm: simplify locking in the fb debugfs file
Peter Huewe (1):
staging/omapdrm: Use kmemdup rather than duplicating its implementation
Rob Clark (2):
drm/omap: move out of staging
drm/omap: remove fbdev debug enter/leave hooks
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/{staging => gpu/drm}/omapdrm/Kconfig | 0
drivers/{staging => gpu/drm}/omapdrm/Makefile | 0
drivers/gpu/drm/omapdrm/TODO | 23 +++
.../{staging => gpu/drm}/omapdrm/omap_connector.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c | 14 +-
.../{staging => gpu/drm}/omapdrm/omap_debugfs.c| 16 +--
.../{staging => gpu/drm}/omapdrm/omap_dmm_priv.h | 5 +
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c | 159 +++--
.../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h | 0
drivers/{staging => gpu/drm}/omapdrm/omap_drv.c| 16 ++-
drivers/{staging => gpu/drm}/omapdrm/omap_drv.h| 8 +-
.../{staging => gpu/drm}/omapdrm/omap_encoder.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fb.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c | 5 +-
drivers/{staging => gpu/drm}/omapdrm/omap_gem.c| 34 -
.../{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c | 8 +-
.../drm}/omapdrm/omap_gem_helpers.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_irq.c| 2 +-
drivers/{staging => gpu/drm}/omapdrm/omap_plane.c | 2 +-
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c| 0
drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h| 0
drivers/{staging => gpu/drm}/omapdrm/tcm.h | 2 +
drivers/staging/Kconfig| 2 -
drivers/staging/Makefile | 1 -
drivers/staging/omapdrm/TODO | 32 -
.../omapdrm => include/uapi/drm}/omap_drm.h| 2 +-
28 files changed, 220 insertions(+), 122 deletions(-)
rename drivers/{staging => gpu/drm}/omapdrm/Kconfig (100%)
rename drivers/{staging => gpu/drm}/omapdrm/Makefile (100%)
create mode 100644 drivers/gpu/drm/omapdrm/TODO
rename drivers/{staging => gpu/drm}/omapdrm/omap_connector.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_debugfs.c (90%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_priv.h (96%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c (86%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.h (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_encoder.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fb.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem.c (97%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_helpers.c (98%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_irq.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/omap_plane.c (99%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h (100%)
rename drivers/{staging => gpu/drm}/omapdrm/tcm.h (99%)
delete mode 100644 drivers/staging/omapdrm/TODO
rename {drivers/staging/omapdrm => include/uapi/drm}/omap_drm.h (99%)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >
>> > I think it's worth it to give them a heads-up already. So I've cc'd
>> > the main suspects here..
>>
>> Okay, thanks.
>>
>> >
>> > Daniel, Dave - any comments about a NULL fb in
>> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
>> > googling shows this:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>>
>> Great, yes, I'm sure that's the same (though it says "suspend"
>> and I say "resume").
>>
>> >
>> > which sounds remarkably similar, and is also during a suspend attempt
>> > (but apparently Satish got a full oops out).. Some timing race with a
>> > worker entry?
>
> Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
> the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
> on lid open", whose force_restore case now passes down crtc->base.fb. But
> I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
> your timing race with a worker entry, perhaps.
>
> And 45e2b5f640b3 contains a fine history of going back and forth, so I
> wouldn't want to play further with it out of ignorance - though tempted
> to replace the "if (force_restore) {" by an interim safe-seeming
> compromise of "if (force_restore && crtc->base.fb) {".
Two things to try while I try to grow a clue on what exactly is going on:
1. Related to new ACPI sleep states we've recently made the lid_notifier
locking more sound, maybe that helps:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
2. The new i915 force restore code is indeed missing a safety check
compared to the old crtc helper based one:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6eb3882..095094c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
if (force_restore) {
for_each_pipe(pipe) {
-
intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct drm_crtc * crtc =
+ dev_priv->pipe_to_crtc_mapping[pipe];
+
+ if (!crtc->enabled)
+ continue;
+
+ intel_crtc_restore_mode(crtc);
}
i915_redisable_vga(dev);
The issue is that we save a pointer to the fb (since those are refcounted)
but copy the mode into the crtc struct (since modes are not refcounted).
So on restore the mode will always be non-NULL, which is wrong if the crtc
is off (and so also has a NULL fb).
The problem I have with that patch is figuring out how this ever worked. I
think I need more coffee ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH libdrm] freedreno: add freedreno DRM
From: Rob Clark The libdrm_freedreno helper layer for use by xf86-video-freedreno, fdre (freedreno r/e library and tests for driving gpu), and eventual gallium driver for the Adreno GPU. This uses the msm gpu driver from QCOM's android kernel tree. Note that current msm kernel driver is a bit strange. It provides a DRM interface for GEM, which is basically sufficient to have DRI2 working. But it does not provide KMS. And interface to 2d and 3d cores is via different other devices (/dev/kgsl-*). This is not quite how I'd write a DRM driver, but at this stage it is useful for xf86-video-freedreno and fdre (and eventual gallium driver) to be able to work on existing kernel driver from QCOM, to allow to capture cmdstream dumps from the binary blob drivers without having to reboot. So libdrm_freedreno attempts to hide most of the crazy. The intention is that when there is a proper kernel driver, it will be mostly just changes in libdrm_freedreno to adapt the gallium driver and xf86-video-freedreno (ignoring the fbdev->KMS changes). So don't look at freedreno as an example of how to write a libdrm module or a DRM driver.. it is just an attempt to paper over a non- standard kernel driver architecture. v1: original v2: hold ref's to pending bo's (because qcom's kernel driver doesn't), various bug fixes, add ringbuffer markers so we can emit IB's to portion of ringbuffer (so that gallium driver can use a single ringbuffer for both tile cmds and draw cmds. Signed-off-by: Rob Clark --- .gitignore | 1 + Makefile.am | 6 +- configure.ac | 15 +- freedreno/Makefile.am| 19 ++ freedreno/README | 16 ++ freedreno/freedreno_bo.c | 274 + freedreno/freedreno_device.c | 45 freedreno/freedreno_drmif.h | 99 freedreno/freedreno_pipe.c | 227 + freedreno/freedreno_priv.h | 117 + freedreno/freedreno_ringbuffer.c | 249 +++ freedreno/freedreno_ringbuffer.h | 87 +++ freedreno/kgsl_drm.h | 192 +++ freedreno/libdrm_freedreno.pc.in | 11 + freedreno/list.h | 137 +++ freedreno/msm_kgsl.h | 519 +++ 16 files changed, 2012 insertions(+), 2 deletions(-) create mode 100644 freedreno/Makefile.am create mode 100644 freedreno/README create mode 100644 freedreno/freedreno_bo.c create mode 100644 freedreno/freedreno_device.c create mode 100644 freedreno/freedreno_drmif.h create mode 100644 freedreno/freedreno_pipe.c create mode 100644 freedreno/freedreno_priv.h create mode 100644 freedreno/freedreno_ringbuffer.c create mode 100644 freedreno/freedreno_ringbuffer.h create mode 100644 freedreno/kgsl_drm.h create mode 100644 freedreno/libdrm_freedreno.pc.in create mode 100644 freedreno/list.h create mode 100644 freedreno/msm_kgsl.h diff --git a/.gitignore b/.gitignore index 225fd80..9f8eabb 100644 --- a/.gitignore +++ b/.gitignore @@ -48,6 +48,7 @@ libdrm_nouveau.pc libdrm_radeon.pc libdrm_omap.pc libdrm_exynos.pc +libdrm_freedreno.pc libkms.pc libtool ltmain.sh diff --git a/Makefile.am b/Makefile.am index 94572d0..f726036 100644 --- a/Makefile.am +++ b/Makefile.am @@ -47,7 +47,11 @@ if HAVE_EXYNOS EXYNOS_SUBDIR = exynos endif -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include man +if HAVE_FREEDRENO +FREEDRENO_SUBDIR = freedreno +endif + +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests include man libdrm_la_LTLIBRARIES = libdrm.la libdrm_ladir = $(libdir) diff --git a/configure.ac b/configure.ac index e2e3466..83ffe1b 100644 --- a/configure.ac +++ b/configure.ac @@ -93,6 +93,11 @@ AC_ARG_ENABLE(exynos-experimental-api, [Enable support for EXYNOS's experimental API (default: disabled)]), [EXYNOS=$enableval], [EXYNOS=no]) +AC_ARG_ENABLE(freedreno-experimental-api, + AS_HELP_STRING([--enable-freedreno-experimental-api], + [Enable support for freedreno's experimental API (default: disabled)]), + [FREEDRENO=$enableval], [FREEDRENO=no]) + dnl === dnl check compiler flags AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ @@ -201,6 +206,11 @@ if test "x$EXYNOS" = xyes; then AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support]) fi +AM_CONDITIONAL(HAVE_FREEDRENO, [test "x$FREEDRENO" = xyes]) +if test "x$FREEDRENO" = xyes; then + AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support]) +fi + AC_ARG_ENABLE([cairo-tests], [AS_HELP_STRING([--enable-cairo-tests], [Enable support for Cairo rendering in tests (default: auto)])], @@ -247,7 +257,7 @@ else fi AM_CO
Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
> > This series tries to fix the mess with global system framebuffer access in > device drivers. Currently, architecture initialization sets the "screen_info" > object according to the system framebuffer that was detected during boot. The > device driver that can map VMEM first gets access to it. There is no way to > give > a specific driver access to the device and no _proper_ way to revoke access > again. In fact, some drivers don't even check whether they mapped the VMEM > successfully, letting multiple drivers to access the system framebuffer at the > same time. I'm unsure if I like this or not, and I don't see why its greatly more useful than the interface we have now. It doesn't solve the main problem with the current interface, which is that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a real driver, things will fail either miserably or crappy from a users pov. The internal reference counts stop vesafb from unloading due to the mmaps, then i915 loads anyways and one bashes the other, or we fix so i915 doesn't load and the user gets fail. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 Beta
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #12 from Marek Olšák --- Could you please attach an apitrace file showing the issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49531] Powering down inactive GPU while running X causes NULL pointer dereference
https://bugzilla.kernel.org/show_bug.cgi?id=49531 --- Comment #7 from Matthieu Baerts 2013-02-17 13:07:48 --- Created an attachment (id=93461) --> (https://bugzilla.kernel.org/attachment.cgi?id=93461) Kernel Oops with version 3.8-rc7 Hello, I also have this crash with the version 3.8-rc7 on Ubuntu Raring 13.04. I added this line in my /etc/rc.local file: echo OFF > /sys/kernel/debug/vgaswitcheroo/switch I don't have this crash each time at startup but I guess it depends if the previous command is launched before or after that X11's launch. I'm using this card: Mobility Radeon HD 4650 I'm attaching a file with lines from /var/log/kern.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 Beta
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #11 from almos --- I just tried steam and tf2 on linux, and I didn't see any rendering error. The only abnormal thing was this line: This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer. HD6850, OpenGL version string: 3.0 Mesa 9.2-devel (git-b681ed6) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sun, 17 Feb 2013, Daniel Vetter wrote:
> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >> >
> >> > I think it's worth it to give them a heads-up already. So I've cc'd
> >> > the main suspects here..
> >>
> >> Okay, thanks.
> >>
> >> >
> >> > Daniel, Dave - any comments about a NULL fb in
> >> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> >> > googling shows this:
> >> >
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
> >>
> >> Great, yes, I'm sure that's the same (though it says "suspend"
> >> and I say "resume").
> >>
> >> >
> >> > which sounds remarkably similar, and is also during a suspend attempt
> >> > (but apparently Satish got a full oops out).. Some timing race with a
> >> > worker entry?
> >
> > Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
> > the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
> > on lid open", whose force_restore case now passes down crtc->base.fb. But
> > I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
> > your timing race with a worker entry, perhaps.
> >
> > And 45e2b5f640b3 contains a fine history of going back and forth, so I
> > wouldn't want to play further with it out of ignorance - though tempted
> > to replace the "if (force_restore) {" by an interim safe-seeming
> > compromise of "if (force_restore && crtc->base.fb) {".
My suggestion there in the line above was stupidly wrong :(
>
> Two things to try while I try to grow a clue on what exactly is going on:
Thank you.
By the way, I hope you've looked back through this thread, and realize
that Dave and I both had ThinkPad T4?0s suspend/resume display problems,
but they've gone off in different directions: so a lot of the discussion
comes from Dave having CONFIG_PROVE_RCU_DELAY, and has nothing to do with
what we now know to be my oops in i915/intel_display.c.
>
> 1. Related to new ACPI sleep states we've recently made the lid_notifier
> locking more sound, maybe that helps:
>
> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
Looks like it may be relevant, but I'll ignore it for now:
preferring first to test the more minimal safety you suggest below.
>
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
>
> if (force_restore) {
> for_each_pipe(pipe) {
> -
> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
> + struct drm_crtc * crtc =
> + dev_priv->pipe_to_crtc_mapping[pipe];
> +
> + if (!crtc->enabled)
> + continue;
> +
> + intel_crtc_restore_mode(crtc);
> }
>
> i915_redisable_vga(dev);
I see your followup, where you observe that intel_modeset_affected_pipes()
should already have made this check; but you do say it would still be good
to prove one way or the other, so I'll run from now with the patch below.
Note that we haven't got to worrying about what will be in 3.9 yet
(linux-next tells me to expect hangcheck timer problems): it's Linus's
current git for 3.8 final that we're working on at present.
And since quick resumes have always worked for me, it's only occasionally
that a long suspend (e.g. overnight) fails for me in this way, so I won't
be able to report success for several days - but failure may come sooner.
And, it being very tiresome to debug when it does fail, I have inserted
WARN_ONs and more safety: here's what I'm running with now.
--- 3.8-rc7/drivers/gpu/drm/i915/intel_display.c2013-01-17
20:06:11.384002362 -0800
+++ linux/drivers/gpu/drm/i915/intel_display.c 2013-02-17 07:50:28.012075150
-0800
@@ -4156,7 +4156,9 @@ static bool intel_choose_pipe_bpp_dither
* also stays within the max display bpc discovered above.
*/
- switch (fb->depth) {
+ if (WARN_ON(!fb))
+ bpc = 8;
+ else switch (fb->depth) {
case 8:
bpc = 8; /* since we go through a colormap */
break;
@@ -9302,6 +9304,10 @@ void intel_modeset_setup_hw_state(struct
if (force_restore) {
for_each_pipe(pipe) {
crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ if (WARN_ON(!crtc->base.enabled))
+ continue;
+ if (WARN_ON(!crtc->base.fb))
+
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >
> > I think it's worth it to give them a heads-up already. So I've cc'd
> > the main suspects here..
>
> Okay, thanks.
>
> >
> > Daniel, Dave - any comments about a NULL fb in
> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> > googling shows this:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>
> Great, yes, I'm sure that's the same (though it says "suspend"
> and I say "resume").
>
> >
> > which sounds remarkably similar, and is also during a suspend attempt
> > (but apparently Satish got a full oops out).. Some timing race with a
> > worker entry?
Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
on lid open", whose force_restore case now passes down crtc->base.fb. But
I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
your timing race with a worker entry, perhaps.
And 45e2b5f640b3 contains a fine history of going back and forth, so I
wouldn't want to play further with it out of ignorance - though tempted
to replace the "if (force_restore) {" by an interim safe-seeming
compromise of "if (force_restore && crtc->base.fb) {".
Hugh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sat, 16 Feb 2013, Linus Torvalds wrote:
> On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
> >
> > I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> > yesterday, to save an oopsing core kernel ip there, instead of hashed
> > pm trace info (it makes sense in this case to invert your sequence,
> > putting the high order into years and the low order into minutes).
>
> That sounds like a good idea in general. The PM_TRACE() thing was done
> to figure out things that locked up the PCI bus etc, but encoding the
> oopses during suspend sounds like a really good idea too.
Yes, it can and should be generalized, but needs more than I gave it.
>
> Is your patch clean enough to just be made part of the standard
> PM_TRACE infrastructure, or was it something really hacky and one-off?
Not really hacky, but three reasons why it cannot be standard without
more work (I am supposing that it should not be tied to suspend/resume,
but could be used for any oops which gets hidden by graphic screen,
and also fails to reach /var/log/messages).
1. Because I usually have a version of KDB patched into my kernels
("forked" many years ago, never time to integrate with that subset
which eventually went into 2.6.??), it was easiest to implement as
a pair of KDB commands (needing keyboard input: I already knew I
could "reboot" from KDB in this state). (Sidenote: using KDB can
prevent getting a trace into /var/log/messages: so I had tried
without it, but still failed to get one.)
2. I don't use initrd, have very little in modules, and a pared down
kernel: so for me it was not a serious restriction to limit to core
kernel addresses, which easily fitted within the limit; but we ought
to put thought into handling module addresses too.
3. Needs care on the interface: a debug config option presumably,
but perhaps also needs to tie in with panic_on_oops or something -
I don't like my date getting messed up by surprise, and there's no
point in messing it up unless there's reason to believe the machine
will very quickly be rebooted. Since I had to open the lid to resume
to hit the oops, in this case we could rely on me quickly rebooting.
But I've appended what I had below, so it's on the record, and can
be taken further if (likely) someone gets there sooner than I do.
>
> > Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is
> > 812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6
> >
> > /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159
> > * enable dithering as needed, but that costs bandwidth. So choose
> > * the minimum value that expresses the full color range of the fb
> > but
> > * also stays within the max display bpc discovered above.
> > */
> >
> > switch (fb->depth) {
> > 812d60e9: 48 8b 55 c0 mov-0x40(%rbp),%rdx
> > 812d60ed: 8b 02 mov(%rdx),%eax
> >
> > (gcc chose to pass a pointer to fb->depth down to the function,
> > instead of fb itself, since that is the only use of it there.)
> >
> > I expect that fb is NULL; but with an average of one failure to resume
> > per day, and ~26 bits of info per crash, this is not a fast procedure!
> >
> > I notice that intel_pipe_set_base() allows for NULL fb,
> > so I'm currently running with the oops-in-rtc hackery, plus
> > - switch (fb->depth) {
> > + if (WARN_ON(!fb))
> > + bpc = 8;
> > + else switch (fb->depth) {
> >
> > There's been a fair bit of change to intel_display.c since 3.7 (if
> > my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus
> > ironlake_, but I've not yet spotted anything obvious; nor yet looked
> > to see where fb would originate from anyway.
> >
> > Once I've got just a little more info out of it, I'll start another
> > thread addressed principally to the drm/gpu/i915 guys.
>
> I think it's worth it to give them a heads-up already. So I've cc'd
> the main suspects here..
Okay, thanks.
>
> Daniel, Dave - any comments about a NULL fb in
> intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> googling shows this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=895123
Great, yes, I'm sure that's the same (though it says "suspend"
and I say "resume").
>
> which sounds remarkably similar, and is also during a suspend attempt
> (but apparently Satish got a full oops out).. Some timing race with a
> worker entry?
>
> Linus
#include
#include
/*
* HughD adapted the following from drivers/base/power/trace.c:
*
* Copyright (C) 2006 Linus Torvalds
*
* Trace facility for suspend/resume problems, when none of the
* devices may be working.
*
* Horrid, horrid, horrid.
*
* It turns out that the _only_ piece of hardware that actually
* keeps its value across a hard boot (and, more importantly, the
* POST init sequence) is literally the realtime clock.
*
* Never mind that an RTC chip has
webgl-conformance-tests gives errors in drm module
While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915 graphic. The kernel log gives: 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out A developer responded of that bug report [2] that it is a MESA thing but b/c of the kernel msg I'm wondering whether the kernel module might be affected too ? [1] https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=814964 -- MfG/Sincerely Toralf F?rster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[Bug 60995] Account request for libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=60995 --- Comment #1 from David Herrmann --- Created attachment 74974 --> https://bugs.freedesktop.org/attachment.cgi?id=74974&action=edit GPG public key -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/9fbfe1cc/attachment.html>
[Bug 60995] New: Account request for libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=60995 Priority: medium Bug ID: 60995 Assignee: dri-devel at lists.freedesktop.org Summary: Account request for libdrm Severity: normal Classification: Unclassified OS: All Reporter: dh.herrmann at gmail.com Hardware: Other Status: NEW Version: unspecified Component: libdrm Product: DRI Created attachment 74973 --> https://bugs.freedesktop.org/attachment.cgi?id=74973&action=edit SSH public key Hi I'd like to get an fdo account with access to the libdrm repository so I can continue my work on the drm manpages. Name: David Herrmann Email: dh.herrmann at gmail.com Account: dvdhrm SSH and GPG public keys are attached. Thanks David -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/32868099/attachment.html>
[PATCH 9/9] drm: dvbe: add optional fbdev frontend
This adds a new fbdev frontend to the dvbe driver. It allows userspace to
access the dvbe driver via an fbdev frontend.
It is disabled by default so you can use dvbe without CONFIG_FB. It should
only be used for backwards-compatibility. Use the DRM dumb API to access
dvbe buffers properly.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 18 +++
drivers/gpu/drm/dvbe/Makefile | 1 +
drivers/gpu/drm/dvbe/dvbe.h | 23
drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 ++
drivers/gpu/drm/dvbe/dvbe_main.c | 2 +
5 files changed, 279 insertions(+)
create mode 100644 drivers/gpu/drm/dvbe/dvbe_fbdev.c
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
index e49df10..ca27455 100644
--- a/drivers/gpu/drm/dvbe/Kconfig
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -27,3 +27,21 @@ config DRM_DVBE
To compile this driver as a module, choose M here: the
module will be called dvbe.
+
+config DRM_DVBE_FBDEV
+ bool "VESA BIOS Extension DRM fbdev Compatibility Layer"
+ depends on DRM_DVBE && FB
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ This provides an fbdev frontend (via /dev/fbX) for the DVBE VESA
+ driver. Old userspace that depends on the fbdev API can access the
+ DVBE driver this way. It provides full backwards compatibility to the
+ old vesafb driver.
+
+ Newer userspace accesses graphics devices via the DRM API and the old
+ fbdev compatibility layer is not needed. Activate it only if you
+ really need to run old userspace programs.
+
+ If unsure, say N.
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
index f6fb888..e01aaa1 100644
--- a/drivers/gpu/drm/dvbe/Makefile
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -1,4 +1,5 @@
ccflags-y := -Iinclude/drm
dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o dvbe_vesa.o
+dvbe-$(CONFIG_DRM_DVBE_FBDEV) += dvbe_fbdev.o
obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
index 68fd452..dfe7c20 100644
--- a/drivers/gpu/drm/dvbe/dvbe.h
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -14,6 +14,7 @@
#define DVBE_DRV_H
#include
+#include
#include
#include
#include
@@ -47,6 +48,9 @@ struct dvbe_device {
struct drm_encoder enc;
struct drm_connector conn;
struct drm_display_mode *mode;
+
+ /* fbdev */
+ void *fbdev;
};
int dvbe_drm_load(struct drm_device *ddev, unsigned long flags);
@@ -95,4 +99,23 @@ int dvbe_vesa_damage(struct dvbe_device *dvbe, struct
dvbe_framebuffer *fb,
unsigned int flags, unsigned int color,
struct drm_clip_rect *clips, unsigned int num);
+/* fbdev helpers */
+
+#ifdef CONFIG_DRM_DVBE_FBDEV
+
+void dvbe_fbdev_init(struct dvbe_device *dvbe);
+void dvbe_fbdev_cleanup(struct dvbe_device *dvbe);
+
+#else /* CONFIG_DRM_DVBE_FBDEV */
+
+static inline void dvbe_fbdev_init(struct dvbe_device *dvbe)
+{
+}
+
+static inline void dvbe_fbdev_cleanup(struct dvbe_device *dvbe)
+{
+}
+
+#endif /* CONFIG_DRM_DVBE_FBDEV */
+
#endif /* DVBE_DRV_H */
diff --git a/drivers/gpu/drm/dvbe/dvbe_fbdev.c
b/drivers/gpu/drm/dvbe/dvbe_fbdev.c
new file mode 100644
index 000..0e22e12
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/dvbe_fbdev.c
@@ -0,0 +1,235 @@
+/*
+ * DRM VESA BIOS Extension Driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * fbdev compatibility layer
+ * This provides an fbdev framebuffer device for the DVBE driver. It is
+ * based on the old vesafb.c driver:
+ * (c) 1998 Gerd Knorr
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dvbe.h"
+
+struct dvbe_fbdev {
+ struct dvbe_device *dvbe;
+ u32 palette[256];
+};
+
+static int dvbe_fbdev_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ /*
+* Set a single color register. The values supplied are
+* already rounded down to the hardware's capabilities
+* (according to the entries in the `var' structure). Return != 0 for
+* invalid regno.
+*/
+
+ if (regno >= info->cmap.len)
+ return 1;
+ if (info->var.bits_per_pixel == 8)
+ return -EINVAL;
+ if (regno >= 16)
+ return 0;
+
+ switch (info->var.bits_per_pixel) {
+ case 16:
+ if (info->var.red.offset == 10) {
+ /* 1:5:5:5 */
+ ((u32*) (info->pseudo_palette))[re
[PATCH 8/9] drm: dvbe: implement VBE/VESA blitting backend
Extend the dvbe core driver by a VESA/VBE backend that simply blits the
data from a framebuffer into the hardware framebuffer on damage.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
On dirty-ioctls we simply vmap the framebuffer memory and copy each pixel
into the target framebuffer. Unfortunately, the VBE bpp/depth combinations
cannot easily be forwarded to the user via the DRM API as it allows a lot
more combinations. Hence, we need to convert each pixel from the user's
buffer format into the target format while blitting.
Fast-paths for xrgb32/etc. could be implemented if we want to improve
blitting performance.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/dvbe/Kconfig | 1 +
drivers/gpu/drm/dvbe/Makefile| 2 +-
drivers/gpu/drm/dvbe/dvbe.h | 25
drivers/gpu/drm/dvbe/dvbe_main.c | 39 +-
drivers/gpu/drm/dvbe/dvbe_vesa.c | 263 +++
5 files changed, 325 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/dvbe/dvbe_vesa.c
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
index bb3aa7b..e49df10 100644
--- a/drivers/gpu/drm/dvbe/Kconfig
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -3,6 +3,7 @@ config DRM_DVBE
depends on DRM
select DRM_KMS_HELPER
select DRM_SYSFB
+ select FB_BOOT_VESA_SUPPORT
help
This is a DRM/KMS driver for VESA BIOS Extension (VBE) compatible
cards. At least VBE 2.0 is needed. Older VBE 1.2 cards are not
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
index b053da3..f6fb888 100644
--- a/drivers/gpu/drm/dvbe/Makefile
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -1,4 +1,4 @@
ccflags-y := -Iinclude/drm
-dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o
+dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o dvbe_vesa.o
obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
index 0235a95..68fd452 100644
--- a/drivers/gpu/drm/dvbe/dvbe.h
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -25,6 +25,23 @@
struct dvbe_device {
struct drm_device *ddev;
+ /* vbe information */
+ unsigned long vbe_addr;
+ unsigned long vbe_vsize;
+ unsigned long vbe_size;
+ unsigned int vbe_depth;
+ unsigned int vbe_bpp;
+ unsigned int vbe_width;
+ unsigned int vbe_height;
+ unsigned int vbe_stride;
+ uint8_t vbe_red_size;
+ uint8_t vbe_red_pos;
+ uint8_t vbe_green_size;
+ uint8_t vbe_green_pos;
+ uint8_t vbe_blue_size;
+ uint8_t vbe_blue_pos;
+ uint8_t *vbe_map;
+
/* mode-setting objects */
struct drm_crtc crtc;
struct drm_encoder enc;
@@ -70,4 +87,12 @@ struct dvbe_framebuffer {
#define to_dvbe_fb(x) container_of(x, struct dvbe_framebuffer, base)
+/* vesa helpers */
+
+int dvbe_vesa_init(struct dvbe_device *dvbe);
+void dvbe_vesa_cleanup(struct dvbe_device *dvbe);
+int dvbe_vesa_damage(struct dvbe_device *dvbe, struct dvbe_framebuffer *fb,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips, unsigned int num);
+
#endif /* DVBE_DRV_H */
diff --git a/drivers/gpu/drm/dvbe/dvbe_main.c b/drivers/gpu/drm/dvbe/dvbe_main.c
index e73c77e..c418310 100644
--- a/drivers/gpu/drm/dvbe/dvbe_main.c
+++ b/drivers/gpu/drm/dvbe/dvbe_main.c
@@ -46,6 +46,15 @@ static bool dvbe_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct dvbe_device *dvbe = crtc->dev->dev_private;
+
+ if (mode->hdisplay != dvbe->vbe_width ||
+ mode->vdisplay != dvbe->vbe_height) {
+ dev_dbg(dvbe->ddev->dev, "invalid mode %ux%u\n",
+ mode->hdisplay, mode->vdisplay);
+ return false;
+ }
+
drm_mode_copy(adjusted_mode, mode);
return true;
}
@@ -66,6 +75,7 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
int x, int y,
struct drm_framebuffer *old_fb)
{
+ struct dvbe_device *dvbe = crtc->dev->dev_private;
struct dvbe_framebuffer *dfb = to_dvbe_fb(crtc->fb);
/* We can scan out any framebuffer that is given. The framebuffer
@@ -79,7 +89,7 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
if (x >= dfb->base.width || y >= dfb->base.height)
return -EINVAL;
- return 0;
+ return dvbe_vesa_damage(dvbe, dfb, 0, 0, NULL, 0);
}
/*
@@ -89,12 +99,13 @@ static int dvbe_crtc_mode_set(struct drm_crtc *crtc,
static int dvbe_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
{
+ struct dvbe_device *dvbe = crtc->
[PATCH 7/9] drm: new VESA BIOS Extension DRM driver stub
This driver uses the VESA BIOS Extensions to control the display device.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
This patch only introduces the stub DRM driver without any VESA/VBE
backend that actually touches the hardware.
The driver simply provides a single crtc+encoder+connector combination
that user-space can use to access the VBE framebuffer. No page-flips are
supported and users must explicitly mark buffers as dirty to get them
copied into the framebuffer.
All buffer objects are backed by shmem so we can later add PRIME support.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/dvbe/Kconfig | 28 +++
drivers/gpu/drm/dvbe/Makefile| 4 +
drivers/gpu/drm/dvbe/dvbe.h | 73 +++
drivers/gpu/drm/dvbe/dvbe_drv.c | 104 ++
drivers/gpu/drm/dvbe/dvbe_main.c | 399 +++
drivers/gpu/drm/dvbe/dvbe_mem.c | 269 ++
8 files changed, 880 insertions(+)
create mode 100644 drivers/gpu/drm/dvbe/Kconfig
create mode 100644 drivers/gpu/drm/dvbe/Makefile
create mode 100644 drivers/gpu/drm/dvbe/dvbe.h
create mode 100644 drivers/gpu/drm/dvbe/dvbe_drv.c
create mode 100644 drivers/gpu/drm/dvbe/dvbe_main.c
create mode 100644 drivers/gpu/drm/dvbe/dvbe_mem.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2df448e..fbbdabc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -215,3 +215,5 @@ source "drivers/gpu/drm/mgag200/Kconfig"
source "drivers/gpu/drm/cirrus/Kconfig"
source "drivers/gpu/drm/shmobile/Kconfig"
+
+source "drivers/gpu/drm/dvbe/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9249b66..ec91ae8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -49,4 +49,5 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
obj-$(CONFIG_DRM_UDL) += udl/
obj-$(CONFIG_DRM_AST) += ast/
obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
+obj-$(CONFIG_DRM_DVBE) += dvbe/
obj-y += i2c/
diff --git a/drivers/gpu/drm/dvbe/Kconfig b/drivers/gpu/drm/dvbe/Kconfig
new file mode 100644
index 000..bb3aa7b
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/Kconfig
@@ -0,0 +1,28 @@
+config DRM_DVBE
+ tristate "VESA BIOS Extension DRM Driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_SYSFB
+ help
+ This is a DRM/KMS driver for VESA BIOS Extension (VBE) compatible
+ cards. At least VBE 2.0 is needed. Older VBE 1.2 cards are not
+ supported.
+ Nearly all modern x86 graphics cards support VBE 2.0 so this driver
+ should work with all those graphics cards. However, it does not allow
+ mode-switching during runtime but requires the kernel to setup the
+ mode with the vga= kernel command line option. If you want full
+ support for your graphics card, please select a driver for your
+ specific model.
+
+ This driver can be enabled together with any other DRM graphics
+ driver. If another driver probes a device that conflicts with DVBE,
+ then DVBE will automatically drop the device and let the
+ model-specific driver take precedence.
+
+ This driver replaces the old vesafb framebuffer driver and provides
+ full backwards compatibility.
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the
+ module will be called dvbe.
diff --git a/drivers/gpu/drm/dvbe/Makefile b/drivers/gpu/drm/dvbe/Makefile
new file mode 100644
index 000..b053da3
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/Makefile
@@ -0,0 +1,4 @@
+ccflags-y := -Iinclude/drm
+
+dvbe-y := dvbe_drv.o dvbe_main.o dvbe_mem.o
+obj-$(CONFIG_DRM_DVBE) := dvbe.o
diff --git a/drivers/gpu/drm/dvbe/dvbe.h b/drivers/gpu/drm/dvbe/dvbe.h
new file mode 100644
index 000..0235a95
--- /dev/null
+++ b/drivers/gpu/drm/dvbe/dvbe.h
@@ -0,0 +1,73 @@
+/*
+ * DRM VESA BIOS Extension Driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#ifndef DVBE_DRV_H
+#define DVBE_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* dvbe devices */
+
+struct dvbe_device {
+ struct drm_device *ddev;
+
+ /* mode-setting objects */
+ struct drm_crtc crtc;
+ struct drm_encoder enc;
+ struct drm_connector conn;
+ struct drm_display_mode *mode;
+};
+
+int dvbe_drm_load(struct drm_device *ddev, unsigned long flags);
+int dvbe_drm_unload(struct drm_device *ddev);
+int dvbe_drm_mmap(struct file *filp, s
[PATCH 6/9] drm: new sysfb DRM bus module
This provides a new DRM bus helper for the system framebuffer bus. It is
very similar in its functionality to the DRM_USB helper. It allows to
write DRM drivers that register as SYSFB drivers to the system.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 5 ++
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_sysfb.c | 145
include/drm/drmP.h | 4 ++
include/drm/drm_sysfb.h | 35 +++
5 files changed, 190 insertions(+)
create mode 100644 drivers/gpu/drm/drm_sysfb.c
create mode 100644 include/drm/drm_sysfb.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 18321b68b..2df448e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -25,6 +25,11 @@ config DRM_USB
depends on USB_SUPPORT && USB_ARCH_HAS_HCD
select USB
+config DRM_SYSFB
+ tristate
+ depends on DRM
+ select SYSFB
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2ff5cef..9249b66 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -29,6 +29,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_USB) += drm_usb.o
+obj-$(CONFIG_DRM_SYSFB) += drm_sysfb.o
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
obj-$(CONFIG_DRM_R128) += r128/
diff --git a/drivers/gpu/drm/drm_sysfb.c b/drivers/gpu/drm/drm_sysfb.c
new file mode 100644
index 000..4e8a823
--- /dev/null
+++ b/drivers/gpu/drm/drm_sysfb.c
@@ -0,0 +1,145 @@
+/*
+ * DRM Bus for sysfb drivers
+ *
+ * Copyright 2013 David Herrmann
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+int drm_get_sysfb_dev(struct sysfb_device *sdev,
+ struct drm_driver *driver)
+{
+ struct drm_device *dev;
+ int ret;
+
+ DRM_DEBUG("\n");
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ dev_set_drvdata(&sdev->dev, dev);
+ dev->sysfbdev = sdev;
+ dev->dev = &sdev->dev;
+
+ mutex_lock(&drm_global_mutex);
+
+ ret = drm_fill_in_dev(dev, NULL, driver);
+ if (ret) {
+ DRM_ERROR("drm_fill_in_dev failed\n");
+ goto err_unlock;
+ }
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
+ if (ret)
+ goto err_unlock;
+ }
+
+ ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
+ if (ret)
+ goto err_ctrl;
+
+ if (dev->driver->load) {
+ ret = dev->driver->load(dev, 0);
+ if (ret)
+ goto err_primary;
+ }
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = drm_mode_group_init_legacy_group(dev,
+ &dev->primary->mode_group);
+ if (ret)
+ goto err_primary;
+ }
+
+ list_add_tail(&dev->driver_item, &driver->device_list);
+
+ mutex_unlock(&drm_global_mutex);
+
+ DRM_INFO("initialized %s %d.%d.%d %s on minor %d\n",
+driver->name, driver->major, driver->minor, driver->patchlevel,
+driver->date, dev->primary->index);
+
+ return 0;
+
+err_primary:
+ drm_put_minor(&dev->primary);
+err_ctrl:
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ drm_put_minor(&dev->control);
+err_unlock:
+ mutex_unlock(&drm_global_mutex);
+ kfree(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_get_sysfb_dev);
+
+static int drm_sysfb_get_irq(struct drm_device *dev)
+{
+ return 0;
+}
+
+static const char *drm_sysfb_get_name(struct drm_device *dev)
+{
+ return dev_name(&dev->
[PATCH 5/9] video: vesafb: use sysfb bus
Instead of using our own platform device, we now register as sysfb driver
and get notified whenever we are loaded on a system VBE device. This
allows other VBE drivers to be loaded at the same time and users can
bind/unbind drivers via sysfs. We also no longer need to fake a
platform-device because the sysfb bus provides all devices now.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 1 +
drivers/video/vesafb.c | 49 +++--
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d5723c2..5c23d32 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -776,6 +776,7 @@ config FB_VESA
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_BOOT_VESA_SUPPORT
+ select SYSFB
help
This is the frame buffer device driver for generic VESA 2.0
compliant graphic cards. The older VESA 1.2 cards are not supported.
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 4ad7b40..652858f 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -214,7 +215,7 @@ static int vesafb_setup(char *options)
return 0;
}
-static int vesafb_probe(struct platform_device *dev)
+static int vesafb_probe(struct sysfb_device *dev)
{
struct fb_info *info;
struct vesafb_par *par;
@@ -491,7 +492,7 @@ static int vesafb_probe(struct platform_device *dev)
}
printk(KERN_INFO "fb%d: %s frame buffer device\n",
info->node, info->fix.id);
- platform_set_drvdata(dev, info);
+ dev_set_drvdata(&dev->dev, info);
return 0;
err:
if (info->screen_base)
@@ -501,59 +502,39 @@ err:
return err;
}
-static int vesafb_remove(struct platform_device *dev)
+static void vesafb_remove(struct sysfb_device *dev)
{
- struct fb_info *info = platform_get_drvdata(dev);
+ struct fb_info *info = dev_get_drvdata(&dev->dev);
unregister_framebuffer(info);
- return 0;
}
-static struct platform_driver vesafb_driver = {
+static struct sysfb_driver vesafb_driver = {
+ .type_mask = SYSFB_VBE,
+ .allow_tainted = false,
+ .driver = {
+ .name = "vesafb",
+ .owner = THIS_MODULE,
+ .mod_name = KBUILD_MODNAME,
+ },
.probe = vesafb_probe,
.remove = vesafb_remove,
- .driver = {
- .name = "vesafb",
- },
};
-static struct platform_device *vesafb_device;
-
static int __init vesafb_init(void)
{
- int ret;
char *option = NULL;
/* ignore error return of fb_get_options */
fb_get_options("vesafb", &option);
vesafb_setup(option);
- vesafb_device = platform_device_alloc("vesafb", -1);
- if (!vesafb_device)
- return -ENOMEM;
-
- ret = platform_driver_register(&vesafb_driver);
- if (ret)
- goto err_dev;
-
- ret = platform_device_add(vesafb_device);
- if (ret)
- goto err_drv;
-
- return 0;
-
-err_drv:
- platform_driver_unregister(&vesafb_driver);
-err_dev:
- platform_device_put(vesafb_device);
- return ret;
+ return sysfb_register_driver(&vesafb_driver);
}
static void __exit vesafb_exit(void)
{
- platform_device_del(vesafb_device);
- platform_device_put(vesafb_device);
- platform_driver_unregister(&vesafb_driver);
+ sysfb_unregister_driver(&vesafb_driver);
}
module_init(vesafb_init);
--
1.8.1.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] video: vesafb: allow building as module
From: David Herrmann
Fix the vesafb module to no longer use any static __init data. Also add a
module_exit() function that destroys the platform device.
Note that fbdev hotplugging is broken and the self-reference actually
prevents sane module-unloading. Anyway, this at least allows delayed
module loading of vesafb and helps debugging vesafb a lot.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 2 +-
drivers/video/vesafb.c | 100 +++--
2 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index eac56ef..d5723c2 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -770,7 +770,7 @@ config FB_UVESA
If unsure, say N.
config FB_VESA
- bool "VESA VGA graphics support"
+ tristate "VESA VGA graphics support"
depends on (FB = y) && X86
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 501b340..4ad7b40 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -29,27 +29,10 @@
/* - */
-static struct fb_var_screeninfo vesafb_defined __initdata = {
- .activate = FB_ACTIVATE_NOW,
- .height = -1,
- .width = -1,
- .right_margin = 32,
- .upper_margin = 16,
- .lower_margin = 4,
- .vsync_len = 4,
- .vmode = FB_VMODE_NONINTERLACED,
-};
-
-static struct fb_fix_screeninfo vesafb_fix __initdata = {
- .id = "VESA VGA",
- .type = FB_TYPE_PACKED_PIXELS,
- .accel = FB_ACCEL_NONE,
-};
-
static int inverse__read_mostly;
static int mtrr __read_mostly; /* disable mtrr */
-static int vram_remap __initdata;/* Set amount of memory to be
used */
-static int vram_total __initdata;/* Set total amount of memory */
+static int vram_remap; /* Set amount of memory to be
used */
+static int vram_total; /* Set total amount of memory */
static int pmi_setpal __read_mostly = 1; /* pmi for palette changes ???
*/
static int ypan __read_mostly; /* 0..nothing, 1..ypan,
2..ywrap */
static void (*pmi_start)(void) __read_mostly;
@@ -58,6 +41,11 @@ static int depth __read_mostly;
static int vga_compat __read_mostly;
/* - */
+struct vesafb_par {
+ struct fb_ops ops;
+ u32 palette[256];
+};
+
static int vesafb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
@@ -182,7 +170,7 @@ static void vesafb_destroy(struct fb_info *info)
framebuffer_release(info);
}
-static struct fb_ops vesafb_ops = {
+static const struct fb_ops vesafb_ops = {
.owner = THIS_MODULE,
.fb_destroy = vesafb_destroy,
.fb_setcolreg = vesafb_setcolreg,
@@ -192,7 +180,7 @@ static struct fb_ops vesafb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int __init vesafb_setup(char *options)
+static int vesafb_setup(char *options)
{
char *this_opt;
@@ -226,13 +214,29 @@ static int __init vesafb_setup(char *options)
return 0;
}
-static int __init vesafb_probe(struct platform_device *dev)
+static int vesafb_probe(struct platform_device *dev)
{
struct fb_info *info;
+ struct vesafb_par *par;
int i, err;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
+ struct fb_var_screeninfo vesafb_defined = {
+ .activate = FB_ACTIVATE_NOW,
+ .height = -1,
+ .width = -1,
+ .right_margin = 32,
+ .upper_margin = 16,
+ .lower_margin = 4,
+ .vsync_len = 4,
+ .vmode = FB_VMODE_NONINTERLACED,
+ };
+ struct fb_fix_screeninfo vesafb_fix = {
+ .id = "VESA VGA",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .accel = FB_ACCEL_NONE,
+ };
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENODEV;
@@ -287,13 +291,14 @@ static int __init vesafb_probe(struct platform_device
*dev)
spaces our resource handlers simply don't know about */
}
- info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
+ info = framebuffer_alloc(sizeof(struct vesafb_par), &dev->dev);
if (!info) {
release_mem_region(vesafb_fix.smem_start, size_total);
return -ENOMEM;
}
- info->pseudo_palette = info->par;
- info->par = NULL;
+ par = info->par;
+ par->ops = vesafb_ops;
+ info->pseudo_palette = par->palette;
/* set vesa
[PATCH 3/9] video: sysfb: always provide vbefb device
From: David Herrmann
HACK: This should be provided by architecture setup code. But to show how it is
supposed to work, we now simply add a "vbefb" device during initialization.
The better way to do this is by moving this into arch-code. So for instance the
x86 boot initialization should create this platform-device after VBE/VESA screen
detection. Other architectures can do the same or introduce other framebuffer
types than SYSFB_VBE.
Signed-off-by: David Herrmann
---
drivers/video/sysfb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
index 5b47a9a..0c0a4e7 100644
--- a/drivers/video/sysfb.c
+++ b/drivers/video/sysfb.c
@@ -271,6 +271,8 @@ static struct platform_driver sysfb_vbe_driver = {
.remove = sysfb_vbe_remove,
};
+static struct platform_device *sysfb_vbe_device;
+
static int __init sysfb_init(void)
{
int ret;
@@ -287,6 +289,12 @@ static int __init sysfb_init(void)
goto err_bus;
}
+ sysfb_vbe_device = platform_device_register_data(NULL, "vbefb", -1,
+&screen_info,
+sizeof(screen_info));
+ if (!sysfb_vbe_device)
+ pr_warn("cannot create vbefb device\n");
+
return 0;
err_bus:
--
1.8.1.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] video: sysfb: new vbefb device type
From: David Herrmann
This adds the VESA BIOS Extension (VBE) device type. Platform code needs
to provide the "vbefb" platform-device with a screen_info structure as
platform code.
All drivers that depend on VBE can now register as bus drivers and bind
to SYSFB_VBE devices. There is no distinction between graphics
framebuffers or plain text VGA. Drivers ought to inspect the screen_info
and return -ENODEV during probe() is they cannot make use of the device.
Only one framebuffer of type SYSFB_VBE is available on a system at a time.
Signed-off-by: David Herrmann
---
drivers/video/sysfb.c | 77 +++
include/linux/sysfb.h | 5 +++-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c
index 8249006..5b47a9a 100644
--- a/drivers/video/sysfb.c
+++ b/drivers/video/sysfb.c
@@ -205,6 +205,72 @@ void sysfb_taint(struct sysfb_device *sdev, bool set)
}
EXPORT_SYMBOL(sysfb_taint);
+static void sysfb_dev_release(struct device *dev)
+{
+ struct sysfb_device *sdev = to_sysfb_device(dev);
+
+ kfree(sdev);
+}
+
+static struct sysfb_device *sysfb_dev_new(struct device *parent)
+{
+ struct sysfb_device *sdev;
+
+ sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
+ if (!sdev)
+ return NULL;
+
+ device_initialize(&sdev->dev);
+ sdev->dev.release = sysfb_dev_release;
+ sdev->dev.bus = &sysfb_bus_type;
+ sdev->dev.parent = parent;
+
+ return sdev;
+}
+
+static int sysfb_vbe_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct sysfb_device *sdev;
+
+ sdev = sysfb_dev_new(&pdev->dev);
+ if (!sdev)
+ return -ENOMEM;
+
+ dev_set_name(&sdev->dev, "vbefb");
+ sdev->type = SYSFB_VBE;
+ sdev->screen = pdev->dev.platform_data;
+
+ ret = device_add(&sdev->dev);
+ if (ret)
+ goto err_free;
+
+ platform_set_drvdata(pdev, sdev);
+ return 0;
+
+err_free:
+ put_device(&sdev->dev);
+ return ret;
+}
+
+static int sysfb_vbe_remove(struct platform_device *pdev)
+{
+ struct sysfb_device *sdev = platform_get_drvdata(pdev);
+
+ device_del(&sdev->dev);
+ put_device(&sdev->dev);
+ return 0;
+}
+
+static struct platform_driver sysfb_vbe_driver = {
+ .driver = {
+ .name = "vbefb",
+ .owner = THIS_MODULE,
+ },
+ .probe = sysfb_vbe_probe,
+ .remove = sysfb_vbe_remove,
+};
+
static int __init sysfb_init(void)
{
int ret;
@@ -215,11 +281,22 @@ static int __init sysfb_init(void)
return ret;
}
+ ret = platform_driver_register(&sysfb_vbe_driver);
+ if (ret) {
+ pr_err("cannot register VBE framebuffer driver\n");
+ goto err_bus;
+ }
+
return 0;
+
+err_bus:
+ bus_unregister(&sysfb_bus_type);
+ return ret;
}
static void __exit sysfb_exit(void)
{
+ platform_driver_unregister(&sysfb_vbe_driver);
bus_unregister(&sysfb_bus_type);
}
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index 6cd3c24..1796c1e 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -20,6 +20,7 @@
/**
* sysfb_type
+ * @SYSFB_VBE: VESA BIOS Extension compatible device (includes VGA devices)
*
* Different types of available framebuffer devices. Only one device of each
* type can be available at a time. In most systems there even is only one
@@ -29,7 +30,9 @@
* devices.
*/
enum sysfb_type {
- SYSFB_TYPES = 0,
+ SYSFB_VBE = 0x01,
+
+ SYSFB_TYPES = SYSFB_VBE,
};
/**
--
1.8.1.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] video: introduce system framebuffer bus
From: David Herrmann For a long time now we have the problem that there are multiple drivers available that try to use system framebuffers (like EFI, VESA/VBE, ...). There is no way to control which driver gets access to the devices, but instead works on a first-come-first-serve basis. Furthermore, hardware drivers (eg., gpu/drm/*) that get loaded on the real hardware bus (eg., pci-bus) of the framebuffer devices have a hard time unloading other drivers that currently use system framebuffers. This introduces a new bus-type: sysfb (system framebuffer bus) Any available system framebuffer gets registered as a device on this bus. A bus-driver can then pick up the device and use it. Standard sysfs bind/unbind interfaces can be used to change drivers on-the-fly. There are actually two types of drivers: generic and real drivers Generic drivers use the generic framebuffer interface exclusively. They are often used as a fallback interface where no real driver for the hardware is available. Generic drivers register as sysfb drivers to the sysfb bus and will get loaded dynamically. User-space can bind/unbind them via sysfs to control which driver should get access. Only one driver can be active per device. During probe the driver can retrieve additional information via a screen_info object of the device. Generic drivers include: efifb, (u)vesafb, vgacon, ... Real drivers work differently. Instead of being loaded via sysfb, they register as drivers on the real bus (eg., pci-bus). During probe they should verify whether their real device provides a system-framebuffer. If it does, they call sysfb_claim() to claim exclusive access to the device. This guarantees that any generic driver gets unloaded and the real hardware driver can gain access. This also guarantees that a real hardware driver always takes precedence over generic fallback drivers. Real drivers include: i915, radeon, nouveau, ... Signed-off-by: David Herrmann --- drivers/video/Kconfig | 17 drivers/video/Makefile | 1 + drivers/video/sysfb.c | 230 + include/linux/sysfb.h | 134 4 files changed, 382 insertions(+) create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d08d799..eac56ef 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -27,6 +27,23 @@ config VGASTATE tristate default n +config SYSFB + tristate "System Framebuffer Bus" + help + Framebuffers like VGA, VESA/VBE, EFI and others can be handled by many + different drivers. This bus provides an infrastructure for drivers to + register themselves and then get bound/unbound to these system-wide + framebuffers. + This bus prevents framebuffers from being used by multiple drivers + simultaneously and also provides a sysfs API to bind/rebind different + drivers to each device from userspace. + + Chipset-specific drivers (like real GPU drivers) will always take + precedence over generic framebuffer drivers. + + A driver should normally select this bus-option automatically. Enable + it only if you need out-of-tree builds. + config VIDEO_OUTPUT_CONTROL tristate "Lowlevel video output switch controls" help diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 23e948e..f0eb006 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -5,6 +5,7 @@ # Each configuration option enables a list of files. obj-$(CONFIG_VGASTATE)+= vgastate.o +obj-$(CONFIG_SYSFB) += sysfb.o obj-y += fb_notify.o obj-$(CONFIG_FB) += fb.o fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \ diff --git a/drivers/video/sysfb.c b/drivers/video/sysfb.c new file mode 100644 index 000..8249006 --- /dev/null +++ b/drivers/video/sysfb.c @@ -0,0 +1,230 @@ +/* + * System framebuffer bus + * Copyright (c) 2013 David Herrmann + */ + +/* + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + */ + +/* + * The system framebuffer bus (sysfb) provides a way to register global system + * framebuffers and load different drivers for it. This includes VESA/VBE and + * EFI framebuffers. + * Platform code is responsible of adding the framebuffer devices to the system + * platform bus. The sysfb bus will pick up known devices and provide them via + * the sysfb bus to system drivers. This guarantees that only one driver uses + * a single system framebuffer at a time. + * + * Drivers that can make use of the generic interfaces of system framebuffers + * should register as a sysfb driver. They will get n
[PATCH 0/9] System Framebuffer Bus (sysfb)
Hi This series tries to fix the mess with global system framebuffer access in device drivers. Currently, architecture initialization sets the "screen_info" object according to the system framebuffer that was detected during boot. The device driver that can map VMEM first gets access to it. There is no way to give a specific driver access to the device and no _proper_ way to revoke access again. In fact, some drivers don't even check whether they mapped the VMEM successfully, letting multiple drivers to access the system framebuffer at the same time. This series introduces a new bus in patch #1. Global system framebuffers are added as devices to this bus and drivers can register as bus drivers. Via sysfs we can now bind/unbind the drivers. This guarantees that only one driver has access to a single system-framebuffer at a time. But we can also easily control which driver gets loaded (and extend this logic at a central place if we want). If a real hardware drivers gets loaded via another bus that actually provides the system-framebuffer (like pci-bus), these drivers can use a special BUS function to claim the system framebuffer and unload all other drivers from this device. This can be used by _real_ DRM drivers that want to kill all other generic framebuffer drivers. This series adds a SYSFB_VBE (VESA/VBE) framebuffer type as example, but the bus can be used with any other system-framebuffer type. Any other architecture can add their own type like SYSFB_VBE. Patch #3 is currently a HACK to provide the VBE framebuffer on all architectures. However, the platform-device for system-framebuffers should instead be provided by architecture code. Why a new BUS type? We need a way to allow transition from a generic driver to a real hardware driver (like most DRM drivers or special fbdev drivers). We could implement this logic separately, but the BUS driver-core code is available, anyway. So lets use it and save a lot of .text space. Additionally, we get some extra features like driver binding/unbinding via sysfs for free (which is really handy for debugging). The new bus is actually implemented in <200 lines of code. I don't think we can get a smaller implementation when not using the bus-core code. Patch #4 fixes vesafb.c to be hotplug-capable. It doesn't depend on this new bus so it would be nice if it could get applied right away. It allows vesafb to be compiled as a module. Patch #5 makes vesafb.c register as new bus driver on the system-framebuffer bus. Patch #6-#9 introduce DVBE. It's a DRM driver based on VBE/VESA. It also uses the new system-framebuffer bus and provides merely the same functionality as vesafb.c but with a sane user-space API and without any fbdev dependency. What needs to be done? All drivers that use screen_info currently don't _have_ to be converted to the new bus as the request_memory() calls protect the drivers from interfering. So this new bus works even if no other driver gets converted. However, we really _should_ convert the drivers. I will do that if a maintainer agrees to take the bus code through their tree. But I hope to avoid converting all drivers if no maintainer thinks this bus is a good idea. The DVBE and vesafb drivers show how it is done. I also like to see the system-framebuffer platform-devices being registered during architecture initialization. I haven't worked much there so any comments are welcome. Otherwise, I will keep the HACK to add the devices during sysfb module-init. Regards David David Herrmann (9): video: introduce system framebuffer bus video: sysfb: new vbefb device type video: sysfb: always provide vbefb device video: vesafb: allow building as module video: vesafb: use sysfb bus drm: new sysfb DRM bus module drm: new VESA BIOS Extension DRM driver stub drm: dvbe: implement VBE/VESA blitting backend drm: dvbe: add optional fbdev frontend drivers/gpu/drm/Kconfig | 7 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/drm_sysfb.c | 145 + drivers/gpu/drm/dvbe/Kconfig | 47 + drivers/gpu/drm/dvbe/Makefile | 5 + drivers/gpu/drm/dvbe/dvbe.h | 121 +++ drivers/gpu/drm/dvbe/dvbe_drv.c | 104 + drivers/gpu/drm/dvbe/dvbe_fbdev.c | 235 + drivers/gpu/drm/dvbe/dvbe_main.c | 432 ++ drivers/gpu/drm/dvbe/dvbe_mem.c | 269 drivers/gpu/drm/dvbe/dvbe_vesa.c | 263 +++ drivers/video/Kconfig | 20 +- drivers/video/Makefile| 1 + drivers/video/sysfb.c | 315 +++ drivers/video/vesafb.c| 105 - include/drm/drmP.h| 4 + include/drm/drm_sysfb.h | 35 +++ include/linux/sysfb.h | 137 18 files changed, 2197 insertions(+), 50 deletions(-) create mode 100644 drivers/gpu/drm/drm_sysfb.c create mode 100644 drivers/gpu/drm/dvbe/Kco
Re: [GMA500] Valid VCO frequency range on GMA500 platform?
On Mon, Feb 11, 2013 at 11:18 PM, Patrik Jakobsson wrote: > On Mon, Feb 11, 2013 at 2:15 PM, "David Müller (ELSOFT AG)" > wrote: >> Hi Patrik >> >> Patrik Jakobsson wrote: >>> The value of VCO_MIN comes from the Intel PRM for similar GPUs. >>> >>> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and >>> M1_MAX=22? I'll test it on my own hardware tomorrow. >> >> Thanks for your suggestion. >> >> With "N_MIN=1, N_MAX=6 and M1_MAX=22", i get a refresh rate of 59.9Hz. >> >> >> Dave >> > > Those values come from the i915 driver and should work fine for us as well. > I had no problems at my end so I'll submit a patch for this. > > -Patrik I've sent in a patch for this: http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html it is slightly different to what I proposed earlier. Would be nice if you could give it a spin and report back. Thanks Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #2 from Chris Rankin --- Created attachment 74995 --> https://bugs.freedesktop.org/attachment.cgi?id=74995&action=edit dmesg output frpm GPU lockup/reset This dmesg log shows the GPU lockups and soft resets that occurred during my git bisect. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #1 from Chris Rankin --- According to git bisect: 974b482acaf62ced1e8981761a8bda252bd51fe1 is the first bad commit commit 974b482acaf62ced1e8981761a8bda252bd51fe1 Author: Jerome Glisse Date: Fri Feb 8 16:02:32 2013 -0500 r600g: fix lockup when hyperz & alpha test are enabled together. v3 Seems that alpha test being enabled confuse the GPU on the order in which it should perform the Z testing. So force the order programmed throught db shader control. v2: Only force z order when alpha test is enabled v3: Update db shader when binding new dsa + spelling fix Signed-off-by: Jerome Glisse Reviewed-by: Marek Olšák This results in GPU stalls, which can be reset succesfully. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >> >
>> >> > I think it's worth it to give them a heads-up already. So I've cc'd
>> >> > the main suspects here..
>> >>
>> >> Okay, thanks.
>> >>
>> >> >
>> >> > Daniel, Dave - any comments about a NULL fb in
>> >> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
>> >> > googling shows this:
>> >> >
>> >> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>> >>
>> >> Great, yes, I'm sure that's the same (though it says "suspend"
>> >> and I say "resume").
>> >>
>> >> >
>> >> > which sounds remarkably similar, and is also during a suspend attempt
>> >> > (but apparently Satish got a full oops out).. Some timing race with a
>> >> > worker entry?
>> >
>> > Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
>> > the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
>> > on lid open", whose force_restore case now passes down crtc->base.fb. But
>> > I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
>> > your timing race with a worker entry, perhaps.
>> >
>> > And 45e2b5f640b3 contains a fine history of going back and forth, so I
>> > wouldn't want to play further with it out of ignorance - though tempted
>> > to replace the "if (force_restore) {" by an interim safe-seeming
>> > compromise of "if (force_restore && crtc->base.fb) {".
>
> My suggestion there in the line above was stupidly wrong :(
>
>>
>> Two things to try while I try to grow a clue on what exactly is going on:
>
> Thank you.
>
> By the way, I hope you've looked back through this thread, and realize
> that Dave and I both had ThinkPad T4?0s suspend/resume display problems,
> but they've gone off in different directions: so a lot of the discussion
> comes from Dave having CONFIG_PROVE_RCU_DELAY, and has nothing to do with
> what we now know to be my oops in i915/intel_display.c.
Oh, I haven't read the earlier parts of the thread, but agree that
it's a completely different bug: Different chipset (this matters
massively for gpus usually), Dave's issue happens on -rc1 (which
doesn't contain the offending lid_notifier patch yet) and seems to die
someplace completely else than your box.
>> 1. Related to new ACPI sleep states we've recently made the lid_notifier
>> locking more sound, maybe that helps:
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
>
> Looks like it may be relevant, but I'll ignore it for now:
> preferring first to test the more minimal safety you suggest below.
>
>>
>> 2. The new i915 force restore code is indeed missing a safety check
>> compared to the old crtc helper based one:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 6eb3882..095094c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
>> *dev,
>>
>> if (force_restore) {
>> for_each_pipe(pipe) {
>> -
>> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
>> + struct drm_crtc * crtc =
>> + dev_priv->pipe_to_crtc_mapping[pipe];
>> +
>> + if (!crtc->enabled)
>> + continue;
>> +
>> + intel_crtc_restore_mode(crtc);
>> }
>>
>> i915_redisable_vga(dev);
>
> I see your followup, where you observe that intel_modeset_affected_pipes()
> should already have made this check; but you do say it would still be good
> to prove one way or the other, so I'll run from now with the patch below.
>
> Note that we haven't got to worrying about what will be in 3.9 yet
> (linux-next tells me to expect hangcheck timer problems): it's Linus's
> current git for 3.8 final that we're working on at present.
Right, patch was on top of -next, but there shouldn't be any
(functional) differences in this area compared to 3.8. The first part
of the big rework landed in 3.7 and contained the crtc->enabled check
from day one.
For the hangcheck issue in -next, that might be a new one. If you
catch it again, can you please grab the i915_error_state from debugfs
and throw it over to me? That should be enough for basic analysis.
> And since quick resumes have always worked for me, it's only occasionally
> that a long suspend (e.g. overnight) fails for me in this way, so I won't
> be able to report success for several days - but failure may come sooner.
>
> And, it being very tiresome to debug when it does fail, I have inserted
> WARN_ONs and more safety: here's what I'm running with now.
Yep, that should be interesting
Debugging Thinkpad T430s occasional suspend failure.
On Sun, 17 Feb 2013, Daniel Vetter wrote:
> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >> >
> >> > I think it's worth it to give them a heads-up already. So I've cc'd
> >> > the main suspects here..
> >>
> >> Okay, thanks.
> >>
> >> >
> >> > Daniel, Dave - any comments about a NULL fb in
> >> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
> >> > googling shows this:
> >> >
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
> >>
> >> Great, yes, I'm sure that's the same (though it says "suspend"
> >> and I say "resume").
> >>
> >> >
> >> > which sounds remarkably similar, and is also during a suspend attempt
> >> > (but apparently Satish got a full oops out).. Some timing race with a
> >> > worker entry?
> >
> > Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
> > the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
> > on lid open", whose force_restore case now passes down crtc->base.fb. But
> > I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
> > your timing race with a worker entry, perhaps.
> >
> > And 45e2b5f640b3 contains a fine history of going back and forth, so I
> > wouldn't want to play further with it out of ignorance - though tempted
> > to replace the "if (force_restore) {" by an interim safe-seeming
> > compromise of "if (force_restore && crtc->base.fb) {".
My suggestion there in the line above was stupidly wrong :(
>
> Two things to try while I try to grow a clue on what exactly is going on:
Thank you.
By the way, I hope you've looked back through this thread, and realize
that Dave and I both had ThinkPad T4?0s suspend/resume display problems,
but they've gone off in different directions: so a lot of the discussion
comes from Dave having CONFIG_PROVE_RCU_DELAY, and has nothing to do with
what we now know to be my oops in i915/intel_display.c.
>
> 1. Related to new ACPI sleep states we've recently made the lid_notifier
> locking more sound, maybe that helps:
>
> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
Looks like it may be relevant, but I'll ignore it for now:
preferring first to test the more minimal safety you suggest below.
>
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
>
> if (force_restore) {
> for_each_pipe(pipe) {
> -
> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
> + struct drm_crtc * crtc =
> + dev_priv->pipe_to_crtc_mapping[pipe];
> +
> + if (!crtc->enabled)
> + continue;
> +
> + intel_crtc_restore_mode(crtc);
> }
>
> i915_redisable_vga(dev);
I see your followup, where you observe that intel_modeset_affected_pipes()
should already have made this check; but you do say it would still be good
to prove one way or the other, so I'll run from now with the patch below.
Note that we haven't got to worrying about what will be in 3.9 yet
(linux-next tells me to expect hangcheck timer problems): it's Linus's
current git for 3.8 final that we're working on at present.
And since quick resumes have always worked for me, it's only occasionally
that a long suspend (e.g. overnight) fails for me in this way, so I won't
be able to report success for several days - but failure may come sooner.
And, it being very tiresome to debug when it does fail, I have inserted
WARN_ONs and more safety: here's what I'm running with now.
--- 3.8-rc7/drivers/gpu/drm/i915/intel_display.c2013-01-17
20:06:11.384002362 -0800
+++ linux/drivers/gpu/drm/i915/intel_display.c 2013-02-17 07:50:28.012075150
-0800
@@ -4156,7 +4156,9 @@ static bool intel_choose_pipe_bpp_dither
* also stays within the max display bpc discovered above.
*/
- switch (fb->depth) {
+ if (WARN_ON(!fb))
+ bpc = 8;
+ else switch (fb->depth) {
case 8:
bpc = 8; /* since we go through a colormap */
break;
@@ -9302,6 +9304,10 @@ void intel_modeset_setup_hw_state(struct
if (force_restore) {
for_each_pipe(pipe) {
crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ if (WARN_ON(!crtc->base.enabled))
+ continue;
+ if (WARN_ON(!crtc->base.fb))
+
[Bug 60981] dri/r600: severe screen corruption with Radeon HD 6570
https://bugs.freedesktop.org/show_bug.cgi?id=60981 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 55574 *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
>
> if (force_restore) {
> for_each_pipe(pipe) {
> -
> intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
> + struct drm_crtc * crtc =
> + dev_priv->pipe_to_crtc_mapping[pipe];
> +
> + if (!crtc->enabled)
> + continue;
> +
> + intel_crtc_restore_mode(crtc);
> }
>
> i915_redisable_vga(dev);
>
> The issue is that we save a pointer to the fb (since those are refcounted)
> but copy the mode into the crtc struct (since modes are not refcounted).
> So on restore the mode will always be non-NULL, which is wrong if the crtc
> is off (and so also has a NULL fb).
>
> The problem I have with that patch is figuring out how this ever worked. I
> think I need more coffee ;-)
Ok, coffee seems to be working now. I think the above diff shouldn't
change anything, since we already have a crtc->enabled check in
intel_modeset_affected_pipes in intel_display.c. Still would be good
if you can prove this one way or the other.
For those wondering why this check is buried this deeply: We're in the
middle of a massive rework of our modeset code, moving from
one-crtc-at-a-time to global modeset. We need that to implement some
fancy features like fastboot or better handling of global resource
constraints (shared clocks, bw limits, ...). In the new world we set
up the desired state in staging pointers/data structures. Then the
modeset code diffs that with the current state and computes the best
way to do the transition. But since we're still converting code some
pieces pass in the new state explicitly, but lower levels then ignore
some pieces when not required to reach the desired state.
The new lid restore code relies on that by updating the tracked hw
state from the real hw one and restoring the last desired state (which
is still around from the last modeset call).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: webgl-conformance-tests gives errors in drm module
On Sun, Feb 17, 2013 at 11:28 AM, Toralf Förster wrote: > While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915 > graphic. > The kernel log gives: > > > 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] > *ERROR* Timed out waiting for forcewake to ack request. > 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] > *ERROR* GT thread status wait timed out > 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] > *ERROR* Timed out waiting for forcewake to ack request. > 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] > *ERROR* GT thread status wait timed out > > A developer responded of that bug report [2] that it is a MESA thing > but b/c of the kernel msg I'm wondering whether the kernel module might be > affected too ? rc6 is an extremely fickle beast, but generally you see those messages right before the gpu dies. So I'll bet there's more than just those messages in dmesg. In any case, please try out the latest upstream driver sources first for mesa (9.1 branch) and kernel (3.8-rc series) to ensure it's not a know bug. If it still hangs you /should/ get a line about i915_error_state in debugfs in dmesg. Please file a bug report on bugs.freedesktop.org with that file attached (and citing all the git versions you've used for testing). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Debugging Thinkpad T430s occasional suspend failure.
On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >
>> > I think it's worth it to give them a heads-up already. So I've cc'd
>> > the main suspects here..
>>
>> Okay, thanks.
>>
>> >
>> > Daniel, Dave - any comments about a NULL fb in
>> > intel_choose_pipe_bpp_dither() during either suspend or resume? Some
>> > googling shows this:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=895123
>>
>> Great, yes, I'm sure that's the same (though it says "suspend"
>> and I say "resume").
>>
>> >
>> > which sounds remarkably similar, and is also during a suspend attempt
>> > (but apparently Satish got a full oops out).. Some timing race with a
>> > worker entry?
>
> Comparing Satish's backtrace and drivers/gpu/drm history, it's clear that
> the oops comes from Daniel's 3.8-rc2 45e2b5f640b3 "drm/i915: force restore
> on lid open", whose force_restore case now passes down crtc->base.fb. But
> I wouldn't have a clue why that's usually non-NULL but occasionally NULL:
> your timing race with a worker entry, perhaps.
>
> And 45e2b5f640b3 contains a fine history of going back and forth, so I
> wouldn't want to play further with it out of ignorance - though tempted
> to replace the "if (force_restore) {" by an interim safe-seeming
> compromise of "if (force_restore && crtc->base.fb) {".
Two things to try while I try to grow a clue on what exactly is going on:
1. Related to new ACPI sleep states we've recently made the lid_notifier
locking more sound, maybe that helps:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=b8efb17b3d687695b81485f606fc4e6c35a50f9a
2. The new i915 force restore code is indeed missing a safety check
compared to the old crtc helper based one:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6eb3882..095094c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9153,7 +9153,13 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
if (force_restore) {
for_each_pipe(pipe) {
-
intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct drm_crtc * crtc =
+ dev_priv->pipe_to_crtc_mapping[pipe];
+
+ if (!crtc->enabled)
+ continue;
+
+ intel_crtc_restore_mode(crtc);
}
i915_redisable_vga(dev);
The issue is that we save a pointer to the fb (since those are refcounted)
but copy the mode into the crtc struct (since modes are not refcounted).
So on restore the mode will always be non-NULL, which is wrong if the crtc
is off (and so also has a NULL fb).
The problem I have with that patch is figuring out how this ever worked. I
think I need more coffee ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49531] Powering down inactive GPU while running X causes NULL pointer dereference
https://bugzilla.kernel.org/show_bug.cgi?id=49531 --- Comment #7 from Matthieu Baerts 2013-02-17 13:07:48 --- Created an attachment (id=93461) --> (https://bugzilla.kernel.org/attachment.cgi?id=93461) Kernel Oops with version 3.8-rc7 Hello, I also have this crash with the version 3.8-rc7 on Ubuntu Raring 13.04. I added this line in my /etc/rc.local file: echo OFF > /sys/kernel/debug/vgaswitcheroo/switch I don't have this crash each time at startup but I guess it depends if the previous command is launched before or after that X11's launch. I'm using this card: Mobility Radeon HD 4650 I'm attaching a file with lines from /var/log/kern.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60995] Account request for libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=60995 --- Comment #1 from David Herrmann --- Created attachment 74974 --> https://bugs.freedesktop.org/attachment.cgi?id=74974&action=edit GPG public key -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60995] New: Account request for libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=60995 Priority: medium Bug ID: 60995 Assignee: dri-devel@lists.freedesktop.org Summary: Account request for libdrm Severity: normal Classification: Unclassified OS: All Reporter: dh.herrm...@gmail.com Hardware: Other Status: NEW Version: unspecified Component: libdrm Product: DRI Created attachment 74973 --> https://bugs.freedesktop.org/attachment.cgi?id=74973&action=edit SSH public key Hi I'd like to get an fdo account with access to the libdrm repository so I can continue my work on the drm manpages. Name: David Herrmann Email: dh.herrm...@gmail.com Account: dvdhrm SSH and GPG public keys are attached. Thanks David -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
webgl-conformance-tests gives errors in drm module
While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915 graphic. The kernel log gives: 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out A developer responded of that bug report [2] that it is a MESA thing but b/c of the kernel msg I'm wondering whether the kernel module might be affected too ? [1] https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=814964 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60981] New: dri/r600: severe screen corruption with Radeon HD 6570
https://bugs.freedesktop.org/show_bug.cgi?id=60981 Priority: medium Bug ID: 60981 Assignee: dri-devel at lists.freedesktop.org Summary: dri/r600: severe screen corruption with Radeon HD 6570 Severity: major Classification: Unclassified OS: Linux (All) Reporter: steve at steve-m.de Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 74957 --> https://bugs.freedesktop.org/attachment.cgi?id=74957&action=edit lspci, xorg log and glxinfo With my VTX3D Radeon HD 6570 card the entire screen content is corrupted, see the images and video. The proprietary AMD driver works fine. This problem is nothing new, I've seen it since I got the card with Ubuntu 12.04, 12.10 and now 13.04 (+xorg-edgers-ppa). http://steve-m.de/pics/radeon_artifacts.png http://steve-m.de/pics/radeon_corruption.ogv Also see the attached logfiles. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/b14da821/attachment.html>
