Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
2013/1/10 Laurent Pinchart :
> Hi Vikas,
>
> Thank you for the patch.
>
> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>> On 3 January 2013 16:29, Tomasz Figa wrote:
>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> >> From: Vikas Sajjan
>> >>
>> >> Signed-off-by: Vikas Sajjan
>> >> ---
>> >>
>> >> include/video/display.h |6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/include/video/display.h b/include/video/display.h
>> >> index b639fd0..fb2f437 100644
>> >> --- a/include/video/display.h
>> >> +++ b/include/video/display.h
>> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>> >>
>> >> void (*enable_hs)(struct video_source *src, bool enable);
>> >>
>> >> + /* frame related */
>> >> + int (*get_frame_done)(struct video_source *src);
>> >> + int (*clear_frame_done)(struct video_source *src);
>> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
>> >> + int (*set_blank_mode)(struct video_source *src, int power);
>> >> +
>> >
>> > I'm not sure if all those extra ops are needed in any way.
>> >
>> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
>> > FB_BLANK_UNBLANK status, which basically equals to the already existing
>> > enable operation, while set_early_blank mode handles only
>> > FB_BLANK_POWERDOWN, being equal to disable callback.
>>
>> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
>> of now, but FB_BLANK_NORMAL will be supported in future.
>> If not for Exynos, i think it will be need for other SoCs which
>> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
>
> Could you please explain in a bit more details what the set_early_blank_mode
> and set_blank_mode operations do ?
>
>> > Both get_frame_done and clear_frame_done do not look at anything used at
>> > the moment and if frame done status monitoring will be ever needed, I
>> > think a better way should be implemented.
>>
>> You are right, as of now Exynos MIPI DSI Panels are NOT using these
>> callbacks, but as you mentioned we will need frame done status monitoring
>> anyways, so i included these callbacks here. Will check, if we can implement
>> any better method.
>
> Do you expect the entity drivers (and in particular the panel drivers) to
> require frame done notification ? If so, could you explain your use case(s) ?
>
Hi Laurent,
As you know, there are two types of MIPI-DSI based lcd panels, RGB and
CPU mode. In case of CPU mode lcd panel, it has its own framebuffer
internally and the image in the framebuffer is transferred on lcd
panel in 60Hz itself. But for this, there is something we should
consider. The display controller with CPU mode doens't transfer image
data to MIPI-DSI controller itself. So we should set trigger bit of
the display controller to 1 to do it and also check whether the data
transmission in the framebuffer is done on lcd panel to avoid tearing
issue and some confliction issue(A) between read and write operations
like below,
lcd_panel_frame_done_interrrupt_handler()
{
...
if (mipi-dsi frame done)
trigger display controller;
...
}
A. the issue that LCD panel can access its own framebuffer while some
new data from MIPI-DSI controller is being written in the framebuffer.
But I think there might be better way to avoid such thing.
Thanks,
Inki Dae
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/exynos: let drm handle edid allocations
Applied.
Thanks,
Inki Dae
2013/1/4 Rahul Sharma :
> There's no need to allocate edid twice and do a memcpy when drm helpers
> exist to do just that. This patch cleans that interaction up, and
> doesn't keep the edid hanging around in the connector.
>
> v4:
> - removed error check for drm_mode_connector_update_edid_property
> which is expected to fail for Virtual Connectors like VIDI.
> Thanks to Seung-Woo Kim.
>
> v3:
> - removed MAX_EDID as it is not used anymore.
>
> v2:
> - changed vidi_get_edid callback inside vidi driver.
>
> Signed-off-by: Sean Paul
> Signed-off-by: Rahul Sharma
> Signed-off-by: Seung-Woo Kim
> ---
> This patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 33
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 19 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 25
> 6 files changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index ab37437..4c5b685 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -18,7 +18,6 @@
> #include "exynos_drm_drv.h"
> #include "exynos_drm_encoder.h"
>
> -#define MAX_EDID 256
> #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
> drm_connector)
>
> @@ -96,7 +95,9 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> to_exynos_connector(connector);
> struct exynos_drm_manager *manager = exynos_connector->manager;
> struct exynos_drm_display_ops *display_ops = manager->display_ops;
> - unsigned int count;
> + struct edid *edid = NULL;
> + unsigned int count = 0;
> + int ret;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> @@ -114,27 +115,21 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> * because lcd panel has only one mode.
> */
> if (display_ops->get_edid) {
> - int ret;
> - void *edid;
> -
> - edid = kzalloc(MAX_EDID, GFP_KERNEL);
> - if (!edid) {
> - DRM_ERROR("failed to allocate edid\n");
> - return 0;
> + edid = display_ops->get_edid(manager->dev, connector);
> + if (IS_ERR_OR_NULL(edid)) {
> + ret = PTR_ERR(edid);
> + edid = NULL;
> + DRM_ERROR("Panel operation get_edid failed %d\n",
> ret);
> + goto out;
> }
>
> - ret = display_ops->get_edid(manager->dev, connector,
> - edid, MAX_EDID);
> - if (ret < 0) {
> - DRM_ERROR("failed to get edid data.\n");
> - kfree(edid);
> - edid = NULL;
> - return 0;
> + count = drm_add_edid_modes(connector, edid);
> + if (count < 0) {
> + DRM_ERROR("Add edid modes failed %d\n", count);
> + goto out;
> }
>
> drm_mode_connector_update_edid_property(connector, edid);
> - count = drm_add_edid_modes(connector, edid);
> - kfree(edid);
> } else {
> struct exynos_drm_panel_info *panel;
> struct drm_display_mode *mode =
> drm_mode_create(connector->dev);
> @@ -161,6 +156,8 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
> count = 1;
> }
>
> +out:
> + kfree(edid);
> return count;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index b9e51bc..4606fac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -148,8 +148,8 @@ struct exynos_drm_overlay {
> struct exynos_drm_display_ops {
> enum exynos_drm_output_type type;
> bool (*is_connected)(struct device *dev);
> - int (*get_edid)(struct device *dev, struct drm_connector *connector,
> - u8 *edid, int len);
> + struct edid *(*get_edid)(struct device *dev,
> + struct drm_connector *connector);
> void *(*get_panel)(struct device *dev);
> int (*check_timing)(struct device *dev, void *timing);
> int (*power_on)(struct device *dev, int mode);
> diff --git a/drivers/gpu/drm/exynos/exyno
Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Laurent,
On 10 January 2013 05:05, Laurent Pinchart
wrote:
> Hi Vikas,
>
> Thank you for the patch.
>
> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>> On 3 January 2013 16:29, Tomasz Figa wrote:
>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> >> From: Vikas Sajjan
>> >>
>> >> Signed-off-by: Vikas Sajjan
>> >> ---
>> >>
>> >> include/video/display.h |6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/include/video/display.h b/include/video/display.h
>> >> index b639fd0..fb2f437 100644
>> >> --- a/include/video/display.h
>> >> +++ b/include/video/display.h
>> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>> >>
>> >> void (*enable_hs)(struct video_source *src, bool enable);
>> >>
>> >> + /* frame related */
>> >> + int (*get_frame_done)(struct video_source *src);
>> >> + int (*clear_frame_done)(struct video_source *src);
>> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
>> >> + int (*set_blank_mode)(struct video_source *src, int power);
>> >> +
>> >
>> > I'm not sure if all those extra ops are needed in any way.
>> >
>> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
>> > FB_BLANK_UNBLANK status, which basically equals to the already existing
>> > enable operation, while set_early_blank mode handles only
>> > FB_BLANK_POWERDOWN, being equal to disable callback.
>>
>> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
>> of now, but FB_BLANK_NORMAL will be supported in future.
>> If not for Exynos, i think it will be need for other SoCs which
>> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
>
> Could you please explain in a bit more details what the set_early_blank_mode
> and set_blank_mode operations do ?
>
with reference to Mr. Inki Dae's patch and discussion
http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/00413.html
http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/02247.html
set_early_blank_mode:
- sets the framebuffer blank mode.
- this callback should be called prior to fb_blank() by a client
driver only if needed
set_blank_mode:
- sets framebuffer blank mode
- this callback should be called after fb_blank() by a client
driver only if needed.
In case of MIPI-DSI based video mode LCD Panel, for lcd power off, the
power off commands should be transferred to lcd panel with display and
mipi-dsi controller enabled, because the commands is set to lcd panel
at vsync porch period, hence set_early_blank_mode() was introduced and
should be called prior to fb_blank() as mentioned in the above 2
links.
I think Mr. Inki Dae can throw more light on this.
>> > Both get_frame_done and clear_frame_done do not look at anything used at
>> > the moment and if frame done status monitoring will be ever needed, I
>> > think a better way should be implemented.
>>
>> You are right, as of now Exynos MIPI DSI Panels are NOT using these
>> callbacks, but as you mentioned we will need frame done status monitoring
>> anyways, so i included these callbacks here. Will check, if we can implement
>> any better method.
>
> Do you expect the entity drivers (and in particular the panel drivers) to
> require frame done notification ? If so, could you explain your use case(s) ?
>
In our Exynos MIPI DSIM H/W, once MIPI DSIM transfers whole image
frame, interrupt will raised to indicate the same.
as part of the mipi_dsim_master_ops() we have get_dsim_frame_done()
and clear_dsim_frame_done() ops. But as of now we are also _NOT_ using
these ops in any particular use case. So i guess as of now we can park
it, later if we find any need for the same we can add it.
> --
> Regards,
>
> Laurent Pinchart
>
--
Thanks and Regards
Vikas Sajjan
SAMSUNG Research India - Banglore.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCHv16 0/7] of: add display helper
Hi Steffen, On Thu, Jan 10, 2013 at 01:45:41, Steffen Trumtrar wrote: > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK To clarify, This series was tested with DT boot (making use of the functionalities provided by this series) on AM335X EVM & AM335X EVM-SK. DA850 EVM was tested with non DT boot along with this series (to make sure that non-DT boot on DA850 EVM is not broken, and it needed the additional change that was mentioned earlier) Sorry that my initial reply did not express what I wanted to. Regards Afzal ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar, > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. MX53QSB and another custom MX53 board. > Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. > > Thanks, > Steffen Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> > Dear Steffen Trumtrar,
> >
> > I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> > adding the following piece of code (quick hack), this works just fine.
> > Thanks!
> >
> > diff --git a/drivers/staging/imx-drm/parallel-display.c
> > b/drivers/staging/imx- drm/parallel-display.c
> > index a8064fc..e45002a 100644
> > --- a/drivers/staging/imx-drm/parallel-display.c
> > +++ b/drivers/staging/imx-drm/parallel-display.c
> > @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct
> > drm_connector *connector)
> >
> > static int imx_pd_connector_get_modes(struct drm_connector *connector)
> > {
> >
> > struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> >
> > + struct device_node *np = imxpd->dev->of_node;
> >
> > int num_modes = 0;
> >
> > if (imxpd->edid) {
> >
> > @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct
> > drm_connector *connector)
> >
> > num_modes++;
> >
> > }
> >
> > + if (np) {
> > + struct drm_display_mode *mode =
> > drm_mode_create(connector->dev); +
> > of_get_drm_display_mode(np, &imxpd->mode, 0);
> > + drm_mode_copy(mode, &imxpd->mode);
> > + mode->type |= DRM_MODE_TYPE_DRIVER |
> > DRM_MODE_TYPE_PREFERRED, + drm_mode_probed_add(connector,
> > mode);
> > + num_modes++;
> > + }
> > +
> >
> > return num_modes;
> >
> > }
>
> Nice! I haven't tried the parallel display, but I think Philipp Zabel might
> already have a patch for it. If not, I will definitly keep your patch in my
> topic branch.
Works like charm here.
Make sure to adjust the patch and check for the return value of
of_get_drm_display_mode(np, &imxpd->mode, 0); call, that's probably the only
issue that needs fixing in that hack. Checking if np != NULL might not hurt
either. I can roll you a real patch if it helps.
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After adding
the following piece of code (quick hack), this works just fine. Thanks!
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
drm/parallel-display.c
index a8064fc..e45002a 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
*connector)
static int imx_pd_connector_get_modes(struct drm_connector *connector)
{
struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+ struct device_node *np = imxpd->dev->of_node;
int num_modes = 0;
if (imxpd->edid) {
@@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
num_modes++;
}
+ if (np) {
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ of_get_drm_display_mode(np, &imxpd->mode, 0);
+ drm_mode_copy(mode, &imxpd->mode);
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ drm_mode_probed_add(connector, mode);
+ num_modes++;
+ }
+
return num_modes;
}
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Wed, Jan 09, 2013 at 12:27:22PM +0100, Daniel Vetter wrote: > On Tue, Jan 8, 2013 at 3:37 PM, J. Bruce Fields wrote: > >> please grab the i915_error_state file from debugfs > > > > As I said in the original mail, I've already done that: > > > > http://fieldses.org/~bfields/3.8-hang/ > > Sorry, missed that the first time around. > > >> and file a bug on > >> bugs.freedesktop.org against DRM - DRI (Intel). > > > > Would it still be useful for me to file a bug? (Just going through the > > new-account confirmation dance now.) > > Looks like the ilk bug tracked at > https://bugs.freedesktop.org/show_bug.cgi?id=55984 OK, I'll add something there if I'm available to find a reproducer. Thanks! --b. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.8-rc2: lockdep warning in nouveau driver
Maybe this one is already known, but I did not find a post about it. So
here it is.
Regards,
Arend
==
[9.422018] usb 1-1.2: new high-speed USB device number 4 using ehci-pci
[9.436177] [TTM] Zone kernel: Available graphics memory: 433698 kiB
[9.442676] [TTM] Zone highmem: Available graphics memory: 1678052 kiB
[9.449256] [TTM] Initializing pool allocator
[9.455462] nouveau [ DRM] VRAM: 512 MiB
[9.459851] nouveau [ DRM] GART: 512 MiB
[9.464227] nouveau [ DRM] BIT BIOS found
[9.468709] nouveau [ DRM] Bios version 70.18.53.00
[9.474040] nouveau [ DRM] TMDS table version 2.0
[9.479196] nouveau [ DRM] DCB version 4.0
[9.483746] nouveau [ DRM] DCB outp 00: 048003b6 0f200014
[9.489580] nouveau [ DRM] DCB outp 01: 02033300
[9.495431] nouveau [ DRM] DCB outp 02: 088223a6 0f220010
[9.501278] nouveau [ DRM] DCB outp 03: 08022362 00020010
[9.507124] nouveau [ DRM] DCB outp 04: 028113c6 0f220010
[9.512970] nouveau [ DRM] DCB outp 05: 02011382 00020010
[9.518804] nouveau [ DRM] DCB conn 00: 2047
[9.523059] hub 1-1.2:1.0: USB hub found
[9.523201] hub 1-1.2:1.0: 3 ports detected
[9.532105] nouveau [ DRM] DCB conn 01: 00101146
[9.537360] nouveau [ DRM] DCB conn 02: 00410246
[9.542450] nouveau [ DRM] DCB conn 03: 0300
[9.588499]
[9.589986] =
[9.595365] [ INFO: possible recursive locking detected ]
[9.600745] 3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1 Not tainted
[9.607248] -
[9.612626] modprobe/163 is trying to acquire lock:
[9.617486] (&subdev->mutex){+.+.+.}, at: []
nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.626052]
[9.626052] but task is already holding lock:
[9.631865] (&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x55/0xc0 [nouveau]
[9.640593]
[9.640593] other info that might help us debug this:
[9.647096] Possible unsafe locking scenario:
[9.647096]
[9.652995]CPU0
[9.655430]
[9.657867] lock(&subdev->mutex);
[9.661365] lock(&subdev->mutex);
[9.664863]
[9.664863] *** DEADLOCK ***
[9.664863]
[9.670762] May be due to missing lock nesting notation
[9.670762]
[9.677526] 4 locks held by modprobe/163:
[9.681520] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x50/0xa0
[9.690341] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x5c/0xa0
[9.699156] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xa8/0x260 [drm]
[9.707899] #3: (&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x55/0xc0 [nouveau]
[9.717075]
[9.717075] stack backtrace:
[9.721417] Pid: 163, comm: modprobe Not tainted
3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1
[9.730085] Call Trace:
[9.732524] [] __lock_acquire+0x12f3/0x1780
[9.737644] [] ? noop_count+0x10/0x10
[9.742246] [] ? check_usage+0x6b/0x410
[9.747021] [] lock_acquire+0x84/0x120
[9.751721] [] ? nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.757797] [] mutex_lock_nested+0x64/0x2e0
[9.762929] [] ? nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.769012] [] ? nv50_fb_vram_new+0x5e/0x230 [nouveau]
[9.775096] [] nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.781008] [] nv50_instobj_ctor+0xae/0xf0 [nouveau]
[9.786918] [] nouveau_object_ctor+0x3b/0xe0 [nouveau]
[9.793001] [] nv50_instmem_alloc+0x2d/0x40 [nouveau]
[9.798996] [] nouveau_gpuobj_create_+0x232/0x2b0 [nouveau]
[9.805501] [] ? _raw_spin_unlock_irqrestore+0x36/0x70
[9.811574] [] ? trace_hardirqs_on_caller+0xf4/0x180
[9.817483] [] nouveau_engctx_create_+0x220/0x260 [nouveau]
[9.824002] [] nv50_disp_data_ctor+0xaf/0xc0 [nouveau]
[9.830086] [] nouveau_object_ctor+0x3b/0xe0 [nouveau]
[9.836168] [] nouveau_object_new+0xe9/0x220 [nouveau]
[9.842258] [] nv50_display_create+0x18c/0x850 [nouveau]
[9.848505] [] ? __cancel_work_timer+0x5a/0xb0
[9.853884] [] ? trace_hardirqs_on_caller+0xf4/0x180
[9.859783] [] ? __cancel_work_timer+0x6a/0xb0
[9.865181] [] nouveau_display_create+0x415/0x6a0 [nouveau]
[9.871700] [] nouveau_drm_load+0x28b/0x5d0 [nouveau]
[9.877688] [] ? device_register+0x17/0x20
[9.882727] [] ? drm_sysfs_device_add+0x7a/0xa0 [drm]
[9.888719] [] ? drm_get_minor+0x220/0x2b0 [drm]
[9.894279] [] drm_get_pci_dev+0x14b/0x260 [drm]
[9.899833] [] ? __pci_set_master+0x27/0x80
[9.904969] [] nouveau_drm_probe+0x20e/0x250 [nouveau]
[9.911042] [] pci_device_probe+0x83/0xc0
[9.915989] [] driver_probe_device+0x64/0x1f0
[9.921282] [] __driver_attach+0x99/0xa0
[9.926143] [] ? driver_probe_device+0x1f0/0x1f0
[9.931696] [] bus_for_each_dev+0x42/0x70
[9.936
[PATCH] [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
it also removes the dependency on backlight and lcd framework.
Signed-off-by: Vikas Sajjan
---
drivers/video/exynos/s6e8ax0.c | 602 ++--
1 file changed, 328 insertions(+), 274 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 05d080b..5d9be51 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -38,8 +38,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a->dsim_dev->master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +46,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct panel_platform_data *plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
@@ -70,39 +83,42 @@ static struct regulator_bulk_data supplies[] = {
{ .supply = "vci", },
};
-static void s6e8ax0_regulator_enable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_enable(struct s6e8ax0 *panel)
{
int ret = 0;
- struct lcd_platform_data *pd = NULL;
+ struct panel_platform_data *plat_data = NULL;
+
+ plat_data = panel->plat_data;
- pd = lcd->ddi_pd;
- mutex_lock(&lcd->lock);
- if (!lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (!panel->enabled) {
ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = true;
+ panel->enabled = true;
}
- msleep(pd->power_on_delay);
+ msleep(plat_data->power_on_delay);
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
-static void s6e8ax0_regulator_disable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_disable(struct s6e8ax0 *panel)
{
int ret = 0;
- mutex_lock(&lcd->lock);
- if (lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (panel->enabled) {
ret = regulator_bulk_disable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = false;
+ panel->enabled = false;
}
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
static const unsigned char s6e8ax0_22_gamma_30[] = {
@@ -283,10 +299,8 @@ static const unsigned char *s6e8ax0_22_gamma_table[] = {
s6e8ax0_22_gamma_300,
};
-static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
+static void s6e8ax0_panel_cond(struct s6e8ax0 *panel)
{
- struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
-
static const unsigned char data_to_send[] = {
0xf8, 0x3d, 0x35, 0x00, 0x00, 0x00, 0x93, 0x00, 0x3c, 0x7d,
0x08, 0x27, 0x7d, 0x3f, 0x00, 0x00, 0x00, 0x20, 0x04, 0x08,
@@ -300,239 +314,218 @@ static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
0xc1, 0x01, 0x41, 0xc1, 0x00, 0xc1, 0xf6, 0xf6, 0xc1
};
- if (lcd->dsim_dev->panel_reverse)
- ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
+ if (panel->panel_reverse)
+ panel->src->ops.dsi->dcs_write(panel->src,
MIPI_DSI_DCS_LONG_WRITE,
data_to_send_panel_reverse,
ARRAY_SIZE(data_to_send_panel_reverse));
else
[PATCH] Make s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan Have made necessary chanages in s6e8ax0 panel driver, made an effort to remove dependency on backlight and lcd framework, but its NOT fully done. s6e8ax0_get_brightness() and s6e8ax0_set_brightness() functionalities have NOT been modified. as backlight support in CDF are _NOT_ implemented yet. Thought of adding these "get and set" as part of display_entity_control_ops(), but didn't modify as of now. Any thoughts on the same will be helpful. removed the lcd_ops "set_power and get_power" and added as part of panel_set_state. I _SHALL_ test these modificaions once i get the s6e8ax0 panel. Vikas Sajjan (1): [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF drivers/video/exynos/s6e8ax0.c | 582 ++-- 1 file changed, 314 insertions(+), 268 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar, > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. MX53QSB and another custom MX53 board. > Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. > > Thanks, > Steffen Best regards, Marek Vasut
[PATCHv16 0/7] of: add display helper
On Wednesday 09 January 2013 21:15:41 Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. I've used the sh-mobile-lcdcfb driver. > Those are the people I know from the top of my head, that use or at least > did use the patches in one of its iterations. If I forgot anyone, please > speak up and possibly add your new HW to the list of tested devices. -- Regards, Laurent Pinchart
[PATCHv16 0/7] of: add display helper
On Wed, Jan 09, 2013 at 09:15:41PM +0100, Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. I tested earlier versions on Tegra. The latest one was v15 I think. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130109/f25191c3/attachment.pgp>
[PATCHv16 0/7] of: add display helper
On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > Hi! > > Finally, right in time before the end of the world on friday, v16 of the > display helpers. > So, any more criticism on the series? Any takers for the series as is? I guess it could be merged via the fbdev-tree if David Airlie can agree to the DRM patches ?! Does that sound about right? I think the series was tested at least with - imx6q: sabrelite, sabresd - imx53: tqma53/mba53 - omap: DA850 EVM, AM335x EVM, EVM-SK I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala are using. Those are the people I know from the top of my head, that use or at least did use the patches in one of its iterations. If I forgot anyone, please speak up and possibly add your new HW to the list of tested devices. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> > Dear Steffen Trumtrar,
> >
> > I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> > adding the following piece of code (quick hack), this works just fine.
> > Thanks!
> >
> > diff --git a/drivers/staging/imx-drm/parallel-display.c
> > b/drivers/staging/imx- drm/parallel-display.c
> > index a8064fc..e45002a 100644
> > --- a/drivers/staging/imx-drm/parallel-display.c
> > +++ b/drivers/staging/imx-drm/parallel-display.c
> > @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct
> > drm_connector *connector)
> >
> > static int imx_pd_connector_get_modes(struct drm_connector *connector)
> > {
> >
> > struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> >
> > + struct device_node *np = imxpd->dev->of_node;
> >
> > int num_modes = 0;
> >
> > if (imxpd->edid) {
> >
> > @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct
> > drm_connector *connector)
> >
> > num_modes++;
> >
> > }
> >
> > + if (np) {
> > + struct drm_display_mode *mode =
> > drm_mode_create(connector->dev); +
> > of_get_drm_display_mode(np, &imxpd->mode, 0);
> > + drm_mode_copy(mode, &imxpd->mode);
> > + mode->type |= DRM_MODE_TYPE_DRIVER |
> > DRM_MODE_TYPE_PREFERRED, + drm_mode_probed_add(connector,
> > mode);
> > + num_modes++;
> > + }
> > +
> >
> > return num_modes;
> >
> > }
>
> Nice! I haven't tried the parallel display, but I think Philipp Zabel might
> already have a patch for it. If not, I will definitly keep your patch in my
> topic branch.
Works like charm here.
Make sure to adjust the patch and check for the return value of
of_get_drm_display_mode(np, &imxpd->mode, 0); call, that's probably the only
issue that needs fixing in that hack. Checking if np != NULL might not hurt
either. I can roll you a real patch if it helps.
Best regards,
Marek Vasut
[PATCHv16 0/7] of: add display helper
Hi!
On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> Dear Steffen Trumtrar,
>
> I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> adding
> the following piece of code (quick hack), this works just fine. Thanks!
>
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
> drm/parallel-display.c
> index a8064fc..e45002a 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
> *connector)
> static int imx_pd_connector_get_modes(struct drm_connector *connector)
> {
> struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> + struct device_node *np = imxpd->dev->of_node;
> int num_modes = 0;
>
> if (imxpd->edid) {
> @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
> *connector)
> num_modes++;
> }
>
> + if (np) {
> + struct drm_display_mode *mode =
> drm_mode_create(connector->dev);
> + of_get_drm_display_mode(np, &imxpd->mode, 0);
> + drm_mode_copy(mode, &imxpd->mode);
> + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + drm_mode_probed_add(connector, mode);
> + num_modes++;
> + }
> +
> return num_modes;
> }
>
Nice! I haven't tried the parallel display, but I think Philipp Zabel might
already have a patch for it. If not, I will definitly keep your patch in my
topic branch.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After adding
the following piece of code (quick hack), this works just fine. Thanks!
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
drm/parallel-display.c
index a8064fc..e45002a 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
*connector)
static int imx_pd_connector_get_modes(struct drm_connector *connector)
{
struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+ struct device_node *np = imxpd->dev->of_node;
int num_modes = 0;
if (imxpd->edid) {
@@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
num_modes++;
}
+ if (np) {
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ of_get_drm_display_mode(np, &imxpd->mode, 0);
+ drm_mode_copy(mode, &imxpd->mode);
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ drm_mode_probed_add(connector, mode);
+ num_modes++;
+ }
+
return num_modes;
}
Best regards,
Marek Vasut
[PATCH] build: Add --disable-manpages configure option
It's not enough to check for xsltproc - the system may not have the docbook stylesheets installed. This patch also allows builders to override the generation/installation of manpages entirely; for example, manpages are of no use for embedded systems, so it's better to not even waste the power building them. --- configure.ac| 10 -- man/Makefile.am |4 ++-- 2 files changed, 10 insertions(+), 4 deletions(-) -- next part -- A non-text attachment was scrubbed... Name: 0001-build-Add-disable-manpages-configure-option.patch Type: text/x-patch Size: 2070 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130109/656948d8/attachment.bin>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #17 from Alexandre Demers --- (In reply to comment #16) > Does a 3.8 kernel it work ok if you revert mesa back to > cf5632094ba0c19d570ea47025cf6da75ef8457a? > > I think > r600g: rework flusing and synchronization pattern v7 > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a > may be problematic on cayman. If it is, not for this bug. Went back to cf563, applied a fix for glcpp, reloaded libraries and still locks at the same point, even after rebooting. -- 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: [PATCHv16 0/7] of: add display helper
Hi Steffen, On Thu, Jan 10, 2013 at 1:45 AM, Steffen Trumtrar wrote: > > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. I tested V16 patches with Exynos: smdk5250 board and it works fine for me. > Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. > > Thanks, > Steffen > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59172] [r300g] flashing and corruption with MSAA 6x and 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=59172 --- Comment #1 from Alex Deucher --- This is probably related to memory bandwidth since MSAA compression is not currently implemented. -- 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/20130109/0cda9d42/attachment.html>
[PATCH 1/2] radeon/kms: fix dma relocation checking
On Wed, Jan 9, 2013 at 4:40 PM, wrote: > From: Jerome Glisse > > We were checking the index against the size of the relocation buffer > instead of against the last index. This fix kernel segfault when > userspace submit ill formated command stream/relocation buffer pair. > > Signed-off-by: Jerome Glisse Added to my -fixes queue. thanks! Alex
Re: [PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39
On Tue, Jan 8, 2013 at 12:10 AM, Philippe De Swert wrote: > Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b > ). As such the comment > is incorrect. drm_put_dev() is now called from drm_platform_exit() or when > the pci device is "unplugged". > > Signed-off-by: Philippe De Swert > --- > drivers/gpu/drm/drm_stub.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c > index 200e104..b39f591 100644 > --- a/drivers/gpu/drm/drm_stub.c > +++ b/drivers/gpu/drm/drm_stub.c > @@ -445,7 +445,7 @@ static void drm_unplug_minor(struct drm_minor *minor) > } > > /** > - * Called via drm_exit() at module unload time or when pci device is > + * Called via drm_platform_exit() at module unload time or when pci device is > * unplugged. Not really correct, its called from drm_pci_exit, drm_usb_exit and drm_platform_exit now. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] build: Add --disable-manpages configure option
It's not enough to check for xsltproc - the system may not have the docbook stylesheets installed. This patch also allows builders to override the generation/installation of manpages entirely; for example, manpages are of no use for embedded systems, so it's better to not even waste the power building them. --- configure.ac| 10 -- man/Makefile.am |4 ++-- 2 files changed, 10 insertions(+), 4 deletions(-) >From eb0f352dc35e5b4a75abd27f1877b37bd1d536c6 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Wed, 9 Jan 2013 19:35:05 -0500 Subject: [PATCH] build: Add --disable-manpages configure option It's not enough to check for xsltproc - the system may not have the docbook stylesheets installed. This patch also allows builders to override the generation/installation of manpages entirely; for example, manpages are of no use for embedded systems, so it's better to not even waste the power building them. This is equivalent to the code in systemd and kmod's configure.ac. --- configure.ac| 10 -- man/Makefile.am |4 ++-- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 0e6db86..273b9b8 100644 --- a/configure.ac +++ b/configure.ac @@ -226,8 +226,14 @@ if test "x$HAVE_LIBUDEV" = xyes; then fi AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes]) -AC_PATH_PROG(XSLTPROC, xsltproc) -AM_CONDITIONAL([HAVE_XSLTPROC], [test "x$XSLTPROC" != "x"]) +AC_ARG_ENABLE([manpages], +AS_HELP_STRING([--disable-manpages], [disable manpages @<:@default=enabled@:>@]), + [], enable_manpages=yes) +AM_CONDITIONAL([BUILD_MANPAGES], [test "x$enable_manpages" = "xyes"]) +AC_PATH_PROG([XSLTPROC], [xsltproc], [no]) +AS_IF([test "x$XSLTPROC" = "xno" && test "x$enable_manpages" = "xyes"], [ + AC_MSG_ERROR([xsltproc command not found, try ./configure --disable-manpages]) +]) if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o "x$OMAP" != "xno"; then # Check for atomic intrinsics diff --git a/man/Makefile.am b/man/Makefile.am index 32acd07..42c3616 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -22,7 +22,7 @@ CLEANFILES = EXTRA_DIST = man_MANS = -if HAVE_XSLTPROC +if BUILD_MANPAGES CLEANFILES += $(MANPAGES) $(MANPAGES_ALIASES) EXTRA_DIST += $(MANPAGES) $(MANPAGES_ALIASES) $(XML_FILES) @@ -51,4 +51,4 @@ XSLTPROC_PROCESS_MAN = \ %.7: %.xml $(XSLTPROC_PROCESS_MAN) -endif # HAVE_XSLTPROC +endif # BUILD_MANPAGES -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59172] New: [r300g] flashing and corruption with MSAA 6x and 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=59172 Priority: medium Bug ID: 59172 Assignee: dri-devel at lists.freedesktop.org Summary: [r300g] flashing and corruption with MSAA 6x and 1920x1080 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio.ped at libero.it Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa When running some applications such as supertuxkart 0.8 with a high resolution (1920x1080) and MSAA 6x the screen flashes, shows massive corruptions and gets very slow. Just changing MSAA to 4x the problem is no longer reproducible. Tested on current git with: r300: DRM version: 2.18.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES -- 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/20130109/34949d2b/attachment-0001.html>
[PATCH 2/2] radeon/kms: cleanup async dma packet checking
From: Jerome Glisse
This simplify and cleanup the async dma checking.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c| 16 +-
drivers/gpu/drm/radeon/evergreen_cs.c | 807 +-
drivers/gpu/drm/radeon/evergreend.h | 29 +-
3 files changed, 417 insertions(+), 435 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f92f6bb..28f8d4f 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3223,14 +3223,14 @@ void evergreen_dma_fence_ring_emit(struct radeon_device
*rdev,
struct radeon_ring *ring = &rdev->ring[fence->ring];
u64 addr = rdev->fence_drv[fence->ring].gpu_addr;
/* write the fence */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_FENCE, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_FENCE, 0, 0));
radeon_ring_write(ring, addr & 0xfffc);
radeon_ring_write(ring, (upper_32_bits(addr) & 0xff));
radeon_ring_write(ring, fence->seq);
/* generate an interrupt */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_TRAP, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_TRAP, 0, 0));
/* flush HDP */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0));
radeon_ring_write(ring, (0xf << 16) | HDP_MEM_COHERENCY_FLUSH_CNTL);
radeon_ring_write(ring, 1);
}
@@ -3253,7 +3253,7 @@ void evergreen_dma_ring_ib_execute(struct radeon_device
*rdev,
while ((next_rptr & 7) != 5)
next_rptr++;
next_rptr += 3;
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_WRITE, 0, 0, 1));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_WRITE, 0, 1));
radeon_ring_write(ring, ring->next_rptr_gpu_addr & 0xfffc);
radeon_ring_write(ring, upper_32_bits(ring->next_rptr_gpu_addr)
& 0xff);
radeon_ring_write(ring, next_rptr);
@@ -3263,8 +3263,8 @@ void evergreen_dma_ring_ib_execute(struct radeon_device
*rdev,
* Pad as necessary with NOPs.
*/
while ((ring->wptr & 7) != 5)
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_INDIRECT_BUFFER, 0, 0,
0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_INDIRECT_BUFFER, 0, 0));
radeon_ring_write(ring, (ib->gpu_addr & 0xFFE0));
radeon_ring_write(ring, (ib->length_dw << 12) |
(upper_32_bits(ib->gpu_addr) & 0xFF));
@@ -3323,7 +3323,7 @@ int evergreen_copy_dma(struct radeon_device *rdev,
if (cur_size_in_dw > 0xF)
cur_size_in_dw = 0xF;
size_in_dw -= cur_size_in_dw;
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
radeon_ring_write(ring, src_offset & 0xfffc);
radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
@@ -3431,7 +3431,7 @@ static int evergreen_startup(struct radeon_device *rdev)
ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size,
R600_WB_DMA_RPTR_OFFSET,
DMA_RB_RPTR, DMA_RB_WPTR,
-2, 0x3fffc, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
+2, 0x3fffc, DMA_PACKET(DMA_PACKET_NOP, 0, 0));
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 7a44566..32c07bb 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2858,16 +2858,6 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
return 0;
}
-/*
- * DMA
- */
-
-#define GET_DMA_CMD(h) (((h) & 0xf000) >> 28)
-#define GET_DMA_COUNT(h) ((h) & 0x000f)
-#define GET_DMA_T(h) (((h) & 0x0080) >> 23)
-#define GET_DMA_NEW(h) (((h) & 0x0400) >> 26)
-#define GET_DMA_MISC(h) (((h) & 0x070) >> 20)
-
/**
* evergreen_dma_cs_parse() - parse the DMA IB
* @p: parser structure holding parsing context.
@@ -2881,9 +2871,9 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
{
struct radeon_cs_chunk *ib_chunk = &p->chunks[p->chunk_ib_idx];
struct radeon_cs_reloc *src_reloc, *dst_reloc, *dst2_reloc;
- u32 header, cmd, count, tiled, new_cmd, misc;
+ u32 header, cmd, count, sub_cmd;
volatile u32 *ib = p->ib.ptr;
- u32 idx, idx_value;
+ u32 idx;
u64 src_offset, dst_offset, dst2_offset;
int r;
@@ -2897
[PATCH 1/2] radeon/kms: fix dma relocation checking
From: Jerome Glisse
We were checking the index against the size of the relocation buffer
instead of against the last index. This fix kernel segfault when
userspace submit ill formated command stream/relocation buffer pair.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r600_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..f91919e 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2561,16 +2561,16 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
struct radeon_cs_chunk *relocs_chunk;
unsigned idx;
+ *cs_reloc = NULL;
if (p->chunk_relocs_idx == -1) {
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- *cs_reloc = NULL;
relocs_chunk = &p->chunks[p->chunk_relocs_idx];
idx = p->dma_reloc_idx;
- if (idx >= relocs_chunk->length_dw) {
+ if (idx >= p->nrelocs) {
DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
- idx, relocs_chunk->length_dw);
+ idx, p->nrelocs);
return -EINVAL;
}
*cs_reloc = p->relocs_ptr[idx];
--
1.7.11.7
Re: [PATCH libdrm 0/4] Manpages for libdrm
On Fri, 28 Sep 2012 23:44:18 +0200 David Herrmann wrote: > Hi > > This is revision 2 of the manpages for libdrm. I converted everything to > docbook > XML. This makes it easier to write them (troff is really hard to read) and > allows us to integrate it into other documentation. > > Other than that I only fixed typos and the small corrections you guys > mentioned. > Thanks for reviewing! I went ahead and pushed these finally. Can you just apply for an fdo account though so we can let you push things in the future? :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/4] Manpages for libdrm
On Fri, 28 Sep 2012 23:44:18 +0200 David Herrmann wrote: > Hi > > This is revision 2 of the manpages for libdrm. I converted everything to > docbook > XML. This makes it easier to write them (troff is really hard to read) and > allows us to integrate it into other documentation. > > Other than that I only fixed typos and the small corrections you guys > mentioned. > Thanks for reviewing! I went ahead and pushed these finally. Can you just apply for an fdo account though so we can let you push things in the future? :) -- Jesse Barnes, Intel Open Source Technology Center
Re: [RFC 0/4] TI LCDC DRM driver
On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote: > Updated version of DRM driver for TI LCD Controller. Since the initial > version of the patch, which only supported TFP410 DVI output, I've added > an output driver for LCD panels (for example, LCD3 or LCD7 cape for the > beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI > encoder (via i2c encoder-slave output driver). > > At this point, I think the basic lcdc drm driver plus TFP410 DVI output > (first patch) is in reasonable shape (barring potential rename, if lcdc > is too generic of a name... but I was not feeling creative enough yet to > pick a new name). I'd like at least tilcdc :-) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59169] [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Ol??k --- This should be fixed by 1385c353cf06c6156d574cffba6164f2b59739e6. Closing. -- 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/20130109/c7b8ad3e/attachment.html>
Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Vikas,
Thank you for the patch.
On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
> On 3 January 2013 16:29, Tomasz Figa wrote:
> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
> >> From: Vikas Sajjan
> >>
> >> Signed-off-by: Vikas Sajjan
> >> ---
> >>
> >> include/video/display.h |6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/include/video/display.h b/include/video/display.h
> >> index b639fd0..fb2f437 100644
> >> --- a/include/video/display.h
> >> +++ b/include/video/display.h
> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
> >>
> >> void (*enable_hs)(struct video_source *src, bool enable);
> >>
> >> + /* frame related */
> >> + int (*get_frame_done)(struct video_source *src);
> >> + int (*clear_frame_done)(struct video_source *src);
> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
> >> + int (*set_blank_mode)(struct video_source *src, int power);
> >> +
> >
> > I'm not sure if all those extra ops are needed in any way.
> >
> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
> > FB_BLANK_UNBLANK status, which basically equals to the already existing
> > enable operation, while set_early_blank mode handles only
> > FB_BLANK_POWERDOWN, being equal to disable callback.
>
> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
> of now, but FB_BLANK_NORMAL will be supported in future.
> If not for Exynos, i think it will be need for other SoCs which
> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
Could you please explain in a bit more details what the set_early_blank_mode
and set_blank_mode operations do ?
> > Both get_frame_done and clear_frame_done do not look at anything used at
> > the moment and if frame done status monitoring will be ever needed, I
> > think a better way should be implemented.
>
> You are right, as of now Exynos MIPI DSI Panels are NOT using these
> callbacks, but as you mentioned we will need frame done status monitoring
> anyways, so i included these callbacks here. Will check, if we can implement
> any better method.
Do you expect the entity drivers (and in particular the panel drivers) to
require frame done notification ? If so, could you explain your use case(s) ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59169] [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 --- Comment #1 from Tomasz P. --- Confirm. My rv350 is detected as rv370. -- 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/20130109/9a70847a/attachment.html>
[Bug 59169] New: [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 Priority: medium Bug ID: 59169 Assignee: dri-devel at lists.freedesktop.org Summary: [radeons] wrong chip detection Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio.ped at libero.it Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa I noticed my RV530 get "upgraded" by mesa to a R580: GL_RENDERER = Gallium 0.4 on ATI R580 Up to some days ago it was correctly reported as a RV530. Possible regression of http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca474f98f2cda5cb333e9f851c7e0e31c9a6f823 -- 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/20130109/0af01545/attachment.html>
Re: [PATCH 2/2] radeon: add support for forcing off lvds when mux switched away
On Thu, Jan 10, 2013 at 12:16 AM, Alex Deucher wrote: > On Mon, Jan 7, 2013 at 11:53 PM, Dave Airlie wrote: >> From: Dave Airlie >> >> otherwise userspace can get very confused > > > Thinking about this more, we probably want to check whether we have a > muxed to mux-less system otherwise we'll be disconnecting the display > when we switch. Looks like the first patch is cognizant of that, but > this one is not unless I'm missing something. vga switcheroo is only for muxed systems, for muxless there is no "switching". Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
it also removes the dependency on backlight and lcd framework.
Signed-off-by: Vikas Sajjan
---
drivers/video/exynos/s6e8ax0.c | 602 ++--
1 file changed, 328 insertions(+), 274 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 05d080b..5d9be51 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -38,8 +38,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a->dsim_dev->master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +46,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct panel_platform_data *plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
@@ -70,39 +83,42 @@ static struct regulator_bulk_data supplies[] = {
{ .supply = "vci", },
};
-static void s6e8ax0_regulator_enable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_enable(struct s6e8ax0 *panel)
{
int ret = 0;
- struct lcd_platform_data *pd = NULL;
+ struct panel_platform_data *plat_data = NULL;
+
+ plat_data = panel->plat_data;
- pd = lcd->ddi_pd;
- mutex_lock(&lcd->lock);
- if (!lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (!panel->enabled) {
ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = true;
+ panel->enabled = true;
}
- msleep(pd->power_on_delay);
+ msleep(plat_data->power_on_delay);
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
-static void s6e8ax0_regulator_disable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_disable(struct s6e8ax0 *panel)
{
int ret = 0;
- mutex_lock(&lcd->lock);
- if (lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (panel->enabled) {
ret = regulator_bulk_disable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = false;
+ panel->enabled = false;
}
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
static const unsigned char s6e8ax0_22_gamma_30[] = {
@@ -283,10 +299,8 @@ static const unsigned char *s6e8ax0_22_gamma_table[] = {
s6e8ax0_22_gamma_300,
};
-static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
+static void s6e8ax0_panel_cond(struct s6e8ax0 *panel)
{
- struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
-
static const unsigned char data_to_send[] = {
0xf8, 0x3d, 0x35, 0x00, 0x00, 0x00, 0x93, 0x00, 0x3c, 0x7d,
0x08, 0x27, 0x7d, 0x3f, 0x00, 0x00, 0x00, 0x20, 0x04, 0x08,
@@ -300,239 +314,218 @@ static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
0xc1, 0x01, 0x41, 0xc1, 0x00, 0xc1, 0xf6, 0xf6, 0xc1
};
- if (lcd->dsim_dev->panel_reverse)
- ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
+ if (panel->panel_reverse)
+ panel->src->ops.dsi->dcs_write(panel->src,
MIPI_DSI_DCS_LONG_WRITE,
data_to_send_panel_reverse,
ARRAY_SIZE(data_to_send_panel_reverse));
else
-
[PATCH] Make s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan Have made necessary chanages in s6e8ax0 panel driver, made an effort to remove dependency on backlight and lcd framework, but its NOT fully done. s6e8ax0_get_brightness() and s6e8ax0_set_brightness() functionalities have NOT been modified. as backlight support in CDF are _NOT_ implemented yet. Thought of adding these "get and set" as part of display_entity_control_ops(), but didn't modify as of now. Any thoughts on the same will be helpful. removed the lcd_ops "set_power and get_power" and added as part of panel_set_state. I _SHALL_ test these modificaions once i get the s6e8ax0 panel. Vikas Sajjan (1): [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF drivers/video/exynos/s6e8ax0.c | 582 ++-- 1 file changed, 314 insertions(+), 268 deletions(-) -- 1.7.9.5
Re: [PATCH 1/2] radeon/kms: fix dma relocation checking
On Wed, Jan 9, 2013 at 4:40 PM, wrote: > From: Jerome Glisse > > We were checking the index against the size of the relocation buffer > instead of against the last index. This fix kernel segfault when > userspace submit ill formated command stream/relocation buffer pair. > > Signed-off-by: Jerome Glisse Added to my -fixes queue. thanks! Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #33 from Alex Deucher --- Does a 3.8 kernel it work ok if you revert mesa back to cf5632094ba0c19d570ea47025cf6da75ef8457a? I think r600g: rework flusing and synchronization pattern v7 http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a may be problematic on cayman. -- 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/20130109/c9154701/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #16 from Alex Deucher --- Does a 3.8 kernel it work ok if you revert mesa back to cf5632094ba0c19d570ea47025cf6da75ef8457a? I think r600g: rework flusing and synchronization pattern v7 http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a may be problematic on cayman. -- 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/20130109/f45450f0/attachment-0001.html>
[RFC v2 0/5] Common Display Framework
Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] radeon/kms: cleanup async dma packet checking
From: Jerome Glisse
This simplify and cleanup the async dma checking.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c| 16 +-
drivers/gpu/drm/radeon/evergreen_cs.c | 807 +-
drivers/gpu/drm/radeon/evergreend.h | 29 +-
3 files changed, 417 insertions(+), 435 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index f92f6bb..28f8d4f 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3223,14 +3223,14 @@ void evergreen_dma_fence_ring_emit(struct radeon_device
*rdev,
struct radeon_ring *ring = &rdev->ring[fence->ring];
u64 addr = rdev->fence_drv[fence->ring].gpu_addr;
/* write the fence */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_FENCE, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_FENCE, 0, 0));
radeon_ring_write(ring, addr & 0xfffc);
radeon_ring_write(ring, (upper_32_bits(addr) & 0xff));
radeon_ring_write(ring, fence->seq);
/* generate an interrupt */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_TRAP, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_TRAP, 0, 0));
/* flush HDP */
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0));
radeon_ring_write(ring, (0xf << 16) | HDP_MEM_COHERENCY_FLUSH_CNTL);
radeon_ring_write(ring, 1);
}
@@ -3253,7 +3253,7 @@ void evergreen_dma_ring_ib_execute(struct radeon_device
*rdev,
while ((next_rptr & 7) != 5)
next_rptr++;
next_rptr += 3;
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_WRITE, 0, 0, 1));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_WRITE, 0, 1));
radeon_ring_write(ring, ring->next_rptr_gpu_addr & 0xfffc);
radeon_ring_write(ring, upper_32_bits(ring->next_rptr_gpu_addr)
& 0xff);
radeon_ring_write(ring, next_rptr);
@@ -3263,8 +3263,8 @@ void evergreen_dma_ring_ib_execute(struct radeon_device
*rdev,
* Pad as necessary with NOPs.
*/
while ((ring->wptr & 7) != 5)
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_INDIRECT_BUFFER, 0, 0,
0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_INDIRECT_BUFFER, 0, 0));
radeon_ring_write(ring, (ib->gpu_addr & 0xFFE0));
radeon_ring_write(ring, (ib->length_dw << 12) |
(upper_32_bits(ib->gpu_addr) & 0xFF));
@@ -3323,7 +3323,7 @@ int evergreen_copy_dma(struct radeon_device *rdev,
if (cur_size_in_dw > 0xF)
cur_size_in_dw = 0xF;
size_in_dw -= cur_size_in_dw;
- radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
+ radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
radeon_ring_write(ring, src_offset & 0xfffc);
radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
@@ -3431,7 +3431,7 @@ static int evergreen_startup(struct radeon_device *rdev)
ring = &rdev->ring[R600_RING_TYPE_DMA_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size,
R600_WB_DMA_RPTR_OFFSET,
DMA_RB_RPTR, DMA_RB_WPTR,
-2, 0x3fffc, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
+2, 0x3fffc, DMA_PACKET(DMA_PACKET_NOP, 0, 0));
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 7a44566..32c07bb 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -2858,16 +2858,6 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
return 0;
}
-/*
- * DMA
- */
-
-#define GET_DMA_CMD(h) (((h) & 0xf000) >> 28)
-#define GET_DMA_COUNT(h) ((h) & 0x000f)
-#define GET_DMA_T(h) (((h) & 0x0080) >> 23)
-#define GET_DMA_NEW(h) (((h) & 0x0400) >> 26)
-#define GET_DMA_MISC(h) (((h) & 0x070) >> 20)
-
/**
* evergreen_dma_cs_parse() - parse the DMA IB
* @p: parser structure holding parsing context.
@@ -2881,9 +2871,9 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
{
struct radeon_cs_chunk *ib_chunk = &p->chunks[p->chunk_ib_idx];
struct radeon_cs_reloc *src_reloc, *dst_reloc, *dst2_reloc;
- u32 header, cmd, count, tiled, new_cmd, misc;
+ u32 header, cmd, count, sub_cmd;
volatile u32 *ib = p->ib.ptr;
- u32 idx, idx_value;
+ u32 idx;
u64 src_offset, dst_offset, dst2_offset;
int r;
@@ -
[PATCH 1/2] radeon/kms: fix dma relocation checking
From: Jerome Glisse
We were checking the index against the size of the relocation buffer
instead of against the last index. This fix kernel segfault when
userspace submit ill formated command stream/relocation buffer pair.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r600_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..f91919e 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2561,16 +2561,16 @@ int r600_dma_cs_next_reloc(struct radeon_cs_parser *p,
struct radeon_cs_chunk *relocs_chunk;
unsigned idx;
+ *cs_reloc = NULL;
if (p->chunk_relocs_idx == -1) {
DRM_ERROR("No relocation chunk !\n");
return -EINVAL;
}
- *cs_reloc = NULL;
relocs_chunk = &p->chunks[p->chunk_relocs_idx];
idx = p->dma_reloc_idx;
- if (idx >= relocs_chunk->length_dw) {
+ if (idx >= p->nrelocs) {
DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
- idx, relocs_chunk->length_dw);
+ idx, p->nrelocs);
return -EINVAL;
}
*cs_reloc = p->relocs_ptr[idx];
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.8-rc2: lockdep warning in nouveau driver
Maybe this one is already known, but I did not find a post about it. So
here it is.
Regards,
Arend
==
[9.422018] usb 1-1.2: new high-speed USB device number 4 using ehci-pci
[9.436177] [TTM] Zone kernel: Available graphics memory: 433698 kiB
[9.442676] [TTM] Zone highmem: Available graphics memory: 1678052 kiB
[9.449256] [TTM] Initializing pool allocator
[9.455462] nouveau [ DRM] VRAM: 512 MiB
[9.459851] nouveau [ DRM] GART: 512 MiB
[9.464227] nouveau [ DRM] BIT BIOS found
[9.468709] nouveau [ DRM] Bios version 70.18.53.00
[9.474040] nouveau [ DRM] TMDS table version 2.0
[9.479196] nouveau [ DRM] DCB version 4.0
[9.483746] nouveau [ DRM] DCB outp 00: 048003b6 0f200014
[9.489580] nouveau [ DRM] DCB outp 01: 02033300
[9.495431] nouveau [ DRM] DCB outp 02: 088223a6 0f220010
[9.501278] nouveau [ DRM] DCB outp 03: 08022362 00020010
[9.507124] nouveau [ DRM] DCB outp 04: 028113c6 0f220010
[9.512970] nouveau [ DRM] DCB outp 05: 02011382 00020010
[9.518804] nouveau [ DRM] DCB conn 00: 2047
[9.523059] hub 1-1.2:1.0: USB hub found
[9.523201] hub 1-1.2:1.0: 3 ports detected
[9.532105] nouveau [ DRM] DCB conn 01: 00101146
[9.537360] nouveau [ DRM] DCB conn 02: 00410246
[9.542450] nouveau [ DRM] DCB conn 03: 0300
[9.588499]
[9.589986] =
[9.595365] [ INFO: possible recursive locking detected ]
[9.600745] 3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1 Not tainted
[9.607248] -
[9.612626] modprobe/163 is trying to acquire lock:
[9.617486] (&subdev->mutex){+.+.+.}, at: []
nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.626052]
[9.626052] but task is already holding lock:
[9.631865] (&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x55/0xc0 [nouveau]
[9.640593]
[9.640593] other info that might help us debug this:
[9.647096] Possible unsafe locking scenario:
[9.647096]
[9.652995]CPU0
[9.655430]
[9.657867] lock(&subdev->mutex);
[9.661365] lock(&subdev->mutex);
[9.664863]
[9.664863] *** DEADLOCK ***
[9.664863]
[9.670762] May be due to missing lock nesting notation
[9.670762]
[9.677526] 4 locks held by modprobe/163:
[9.681520] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x50/0xa0
[9.690341] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x5c/0xa0
[9.699156] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xa8/0x260 [drm]
[9.707899] #3: (&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x55/0xc0 [nouveau]
[9.717075]
[9.717075] stack backtrace:
[9.721417] Pid: 163, comm: modprobe Not tainted
3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1
[9.730085] Call Trace:
[9.732524] [] __lock_acquire+0x12f3/0x1780
[9.737644] [] ? noop_count+0x10/0x10
[9.742246] [] ? check_usage+0x6b/0x410
[9.747021] [] lock_acquire+0x84/0x120
[9.751721] [] ? nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.757797] [] mutex_lock_nested+0x64/0x2e0
[9.762929] [] ? nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.769012] [] ? nv50_fb_vram_new+0x5e/0x230 [nouveau]
[9.775096] [] nv50_fb_vram_new+0x92/0x230 [nouveau]
[9.781008] [] nv50_instobj_ctor+0xae/0xf0 [nouveau]
[9.786918] [] nouveau_object_ctor+0x3b/0xe0 [nouveau]
[9.793001] [] nv50_instmem_alloc+0x2d/0x40 [nouveau]
[9.798996] [] nouveau_gpuobj_create_+0x232/0x2b0 [nouveau]
[9.805501] [] ? _raw_spin_unlock_irqrestore+0x36/0x70
[9.811574] [] ? trace_hardirqs_on_caller+0xf4/0x180
[9.817483] [] nouveau_engctx_create_+0x220/0x260 [nouveau]
[9.824002] [] nv50_disp_data_ctor+0xaf/0xc0 [nouveau]
[9.830086] [] nouveau_object_ctor+0x3b/0xe0 [nouveau]
[9.836168] [] nouveau_object_new+0xe9/0x220 [nouveau]
[9.842258] [] nv50_display_create+0x18c/0x850 [nouveau]
[9.848505] [] ? __cancel_work_timer+0x5a/0xb0
[9.853884] [] ? trace_hardirqs_on_caller+0xf4/0x180
[9.859783] [] ? __cancel_work_timer+0x6a/0xb0
[9.865181] [] nouveau_display_create+0x415/0x6a0 [nouveau]
[9.871700] [] nouveau_drm_load+0x28b/0x5d0 [nouveau]
[9.877688] [] ? device_register+0x17/0x20
[9.882727] [] ? drm_sysfs_device_add+0x7a/0xa0 [drm]
[9.888719] [] ? drm_get_minor+0x220/0x2b0 [drm]
[9.894279] [] drm_get_pci_dev+0x14b/0x260 [drm]
[9.899833] [] ? __pci_set_master+0x27/0x80
[9.904969] [] nouveau_drm_probe+0x20e/0x250 [nouveau]
[9.911042] [] pci_device_probe+0x83/0xc0
[9.915989] [] driver_probe_device+0x64/0x1f0
[9.921282] [] __driver_attach+0x99/0xa0
[9.926143] [] ? driver_probe_device+0x1f0/0x1f0
[9.931696] [] bus_for_each_dev+0x42/0x70
[9.936
Re: [PATCHv16 0/7] of: add display helper
On Wednesday 09 January 2013 21:15:41 Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. I've used the sh-mobile-lcdcfb driver. > Those are the people I know from the top of my head, that use or at least > did use the patches in one of its iterations. If I forgot anyone, please > speak up and possibly add your new HW to the list of tested devices. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv16 0/7] of: add display helper
On Wed, Jan 09, 2013 at 09:15:41PM +0100, Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. I tested earlier versions on Tegra. The latest one was v15 I think. Thierry pgp4jWZ22YeJI.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Tue, Jan 8, 2013 at 3:37 PM, J. Bruce Fields wrote: >> please grab the i915_error_state file from debugfs > > As I said in the original mail, I've already done that: > > http://fieldses.org/~bfields/3.8-hang/ Sorry, missed that the first time around. >> and file a bug on >> bugs.freedesktop.org against DRM - DRI (Intel). > > Would it still be useful for me to file a bug? (Just going through the > new-account confirmation dance now.) Looks like the ilk bug tracked at https://bugs.freedesktop.org/show_bug.cgi?id=55984 -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCHv16 0/7] of: add display helper
On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > Hi! > > Finally, right in time before the end of the world on friday, v16 of the > display helpers. > So, any more criticism on the series? Any takers for the series as is? I guess it could be merged via the fbdev-tree if David Airlie can agree to the DRM patches ?! Does that sound about right? I think the series was tested at least with - imx6q: sabrelite, sabresd - imx53: tqma53/mba53 - omap: DA850 EVM, AM335x EVM, EVM-SK I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala are using. Those are the people I know from the top of my head, that use or at least did use the patches in one of its iterations. If I forgot anyone, please speak up and possibly add your new HW to the list of tested devices. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36596] Major 2D performance bottleneck (most noticeable with compiz)
https://bugs.freedesktop.org/show_bug.cgi?id=36596 --- Comment #14 from Tomasz P. --- is it still an issue with current mesa? -- 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/20130109/6fc572b3/attachment.html>
[Bug 47244] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
https://bugs.freedesktop.org/show_bug.cgi?id=47244 --- Comment #3 from Tomasz P. --- Is it still an 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/20130109/94cf2a9e/attachment.html>
Re: [PATCHv16 0/7] of: add display helper
Hi!
On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> Dear Steffen Trumtrar,
>
> I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> adding
> the following piece of code (quick hack), this works just fine. Thanks!
>
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
> drm/parallel-display.c
> index a8064fc..e45002a 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
> *connector)
> static int imx_pd_connector_get_modes(struct drm_connector *connector)
> {
> struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> + struct device_node *np = imxpd->dev->of_node;
> int num_modes = 0;
>
> if (imxpd->edid) {
> @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
> *connector)
> num_modes++;
> }
>
> + if (np) {
> + struct drm_display_mode *mode =
> drm_mode_create(connector->dev);
> + of_get_drm_display_mode(np, &imxpd->mode, 0);
> + drm_mode_copy(mode, &imxpd->mode);
> + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + drm_mode_probed_add(connector, mode);
> + num_modes++;
> + }
> +
> return num_modes;
> }
>
Nice! I haven't tried the parallel display, but I think Philipp Zabel might
already have a patch for it. If not, I will definitly keep your patch in my
topic branch.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Tue, Jan 8, 2013 at 4:18 AM, Mandeep Singh Baines wrote:
> On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K
> wrote:
> > The wait_for_vblank interface is modified to the complete_scanout
> > function in fimd. This patch adds the fimd_complete_scanout function
> >
>
> With this series, you have a race if the rmfb happens before the flip
> has completed.
>
> How will there be a race? Can you explain the scenario in more detail?
If the current fb (fb1) is being removed, (i.e the shadow register has fb1),
then we wait for vblank before returning. This ensures that the flip has
been handled
before remove fb is complete.
> Why not just use reference counts as is done in the i915 driver: see
> unpin_work.
> The reference counts also allow you to avoid blocking in rmfb.
>
> Will look into it. Thanks.
Regards,
Prathyush
> Regards,
> Mandeep
>
> > Inside fimd_complete_scanout, we read the shadow register for each
> > window and compare it with the dma address of the framebuffer. If
> > the dma_address is in the shadow register, then the function waits
> > for the next vblank and returns.
> >
> > Signed-off-by: Prathyush K
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
> +++-
> > include/video/samsung_fimd.h | 1 +
> > 2 files changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 3aeedf5..190ffde9 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -46,6 +46,7 @@
> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
> >
> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
> 8)
> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
> (win) * 8)
> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
> >
> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
> *dev)
> > fimd_disable_vblank(dev);
> > }
> >
> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
> dma_addr,
> > + unsigned long size)
> > +{
> > + struct fimd_context *ctx = get_fimd_context(dev);
> > + int win;
> > + bool in_use = false;
> > +
> > + if (ctx->suspended)
> > + return;
> > +
> > + for (win = 0; win < WINDOWS_NR; win++) {
> > + dma_addr_t dma_addr_in_use;
> > +
> > + if (!ctx->win_data[win].enabled)
> > + continue;
> > +
> > + dma_addr_in_use = readl(ctx->regs +
> VIDWx_BUF_START_S(win, 0));
> > + if (dma_addr_in_use >= dma_addr &&
> > + dma_addr_in_use < (dma_addr + size)) {
> > + in_use = true;
> > + break;
> > + }
> > + }
> > +
> > + if (in_use)
> > + fimd_wait_for_vblank(dev);
> > + return;
> > +}
> > +
> > static struct exynos_drm_manager_ops fimd_manager_ops = {
> > .dpms = fimd_dpms,
> > .apply = fimd_apply,
> > .commit = fimd_commit,
> > .enable_vblank = fimd_enable_vblank,
> > .disable_vblank = fimd_disable_vblank,
> > - .wait_for_vblank = fimd_wait_for_vblank,
> > + .complete_scanout = fimd_complete_scanout,
> > };
> >
> > static void fimd_win_mode_set(struct device *dev,
> > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> > index 7ae6c07..382eaec 100644
> > --- a/include/video/samsung_fimd.h
> > +++ b/include/video/samsung_fimd.h
> > @@ -274,6 +274,7 @@
> >
> > /* Video buffer addresses */
> > #define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
> > +#define VIDW_BUF_START_S(_buff)(0x40A0 +
> ((_buff) * 8))
> > #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
> > #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
> > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
> > --
> > 1.8.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130109/4451a17d/attachment-0001.html>
Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Tue, Jan 8, 2013 at 9:43 PM, Prathyush K wrote:
>
>
>
> On Tue, Jan 8, 2013 at 4:18 AM, Mandeep Singh Baines
> wrote:
>>
>> On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in fimd. This patch adds the fimd_complete_scanout function
>> >
>>
>> With this series, you have a race if the rmfb happens before the flip
>> has completed.
>>
> How will there be a race? Can you explain the scenario in more detail?
>
I'm sorry. There's no race. I had misunderstood something.
Reference counting might still be preferable to avoid blocking the
Xserver till vblank.
You can implement it by grabbing a reference on page_flip and release
the reference
on finish_page_flip (when flipping to a new fb).
Regards,
Mandeep
> If the current fb (fb1) is being removed, (i.e the shadow register has fb1),
> then we wait for vblank before returning. This ensures that the flip has
> been handled
> before remove fb is complete.
>
>>
>> Why not just use reference counts as is done in the i915 driver: see
>> unpin_work.
>> The reference counts also allow you to avoid blocking in rmfb.
>>
> Will look into it. Thanks.
>
> Regards,
> Prathyush
>
>
>>
>> Regards,
>> Mandeep
>>
>> > Inside fimd_complete_scanout, we read the shadow register for each
>> > window and compare it with the dma address of the framebuffer. If
>> > the dma_address is in the shadow register, then the function waits
>> > for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
>> > +++-
>> > include/video/samsung_fimd.h | 1 +
>> > 2 files changed, 32 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 3aeedf5..190ffde9 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -46,6 +46,7 @@
>> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
>> >
>> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) *
>> > 8)
>> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
>> > 8)
>> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
>> > (win) * 8)
>> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
>> >
>> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
>> > *dev)
>> > fimd_disable_vblank(dev);
>> > }
>> >
>> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
>> > dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct fimd_context *ctx = get_fimd_context(dev);
>> > + int win;
>> > + bool in_use = false;
>> > +
>> > + if (ctx->suspended)
>> > + return;
>> > +
>> > + for (win = 0; win < WINDOWS_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = readl(ctx->regs +
>> > VIDWx_BUF_START_S(win, 0));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > + in_use = true;
>> > + break;
>> > + }
>> > + }
>> > +
>> > + if (in_use)
>> > + fimd_wait_for_vblank(dev);
>> > + return;
>> > +}
>> > +
>> > static struct exynos_drm_manager_ops fimd_manager_ops = {
>> > .dpms = fimd_dpms,
>> > .apply = fimd_apply,
>> > .commit = fimd_commit,
>> > .enable_vblank = fimd_enable_vblank,
>> > .disable_vblank = fimd_disable_vblank,
>> > - .wait_for_vblank = fimd_wait_for_vblank,
>> > + .complete_scanout = fimd_complete_scanout,
>> > };
>> >
>> > static void fimd_win_mode_set(struct device *dev,
>> > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> > index 7ae6c07..382eaec 100644
>> > --- a/include/video/samsung_fimd.h
>> > +++ b/include/video/samsung_fimd.h
>> > @@ -274,6 +274,7 @@
>> >
>> > /* Video buffer addresses */
>> > #define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
>> > +#define VIDW_BUF_START_S(_buff)(0x40A0 +
>> > ((_buff) * 8))
>> > #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
>> > #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
>> > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
>> > --
>> > 1.8.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing
[PATCH 8/8] drm/exynos: fimd: add complete_scanout function
On Tue, Jan 8, 2013 at 9:43 PM, Prathyush K wrote:
>
>
>
> On Tue, Jan 8, 2013 at 4:18 AM, Mandeep Singh Baines
> wrote:
>>
>> On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K
>> wrote:
>> > The wait_for_vblank interface is modified to the complete_scanout
>> > function in fimd. This patch adds the fimd_complete_scanout function
>> >
>>
>> With this series, you have a race if the rmfb happens before the flip
>> has completed.
>>
> How will there be a race? Can you explain the scenario in more detail?
>
I'm sorry. There's no race. I had misunderstood something.
Reference counting might still be preferable to avoid blocking the
Xserver till vblank.
You can implement it by grabbing a reference on page_flip and release
the reference
on finish_page_flip (when flipping to a new fb).
Regards,
Mandeep
> If the current fb (fb1) is being removed, (i.e the shadow register has fb1),
> then we wait for vblank before returning. This ensures that the flip has
> been handled
> before remove fb is complete.
>
>>
>> Why not just use reference counts as is done in the i915 driver: see
>> unpin_work.
>> The reference counts also allow you to avoid blocking in rmfb.
>>
> Will look into it. Thanks.
>
> Regards,
> Prathyush
>
>
>>
>> Regards,
>> Mandeep
>>
>> > Inside fimd_complete_scanout, we read the shadow register for each
>> > window and compare it with the dma address of the framebuffer. If
>> > the dma_address is in the shadow register, then the function waits
>> > for the next vblank and returns.
>> >
>> > Signed-off-by: Prathyush K
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32
>> > +++-
>> > include/video/samsung_fimd.h | 1 +
>> > 2 files changed, 32 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 3aeedf5..190ffde9 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -46,6 +46,7 @@
>> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
>> >
>> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) *
>> > 8)
>> > +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) *
>> > 8)
>> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) +
>> > (win) * 8)
>> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
>> >
>> > @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device
>> > *dev)
>> > fimd_disable_vblank(dev);
>> > }
>> >
>> > +static void fimd_complete_scanout(struct device *dev, dma_addr_t
>> > dma_addr,
>> > + unsigned long size)
>> > +{
>> > + struct fimd_context *ctx = get_fimd_context(dev);
>> > + int win;
>> > + bool in_use = false;
>> > +
>> > + if (ctx->suspended)
>> > + return;
>> > +
>> > + for (win = 0; win < WINDOWS_NR; win++) {
>> > + dma_addr_t dma_addr_in_use;
>> > +
>> > + if (!ctx->win_data[win].enabled)
>> > + continue;
>> > +
>> > + dma_addr_in_use = readl(ctx->regs +
>> > VIDWx_BUF_START_S(win, 0));
>> > + if (dma_addr_in_use >= dma_addr &&
>> > + dma_addr_in_use < (dma_addr + size)) {
>> > + in_use = true;
>> > + break;
>> > + }
>> > + }
>> > +
>> > + if (in_use)
>> > + fimd_wait_for_vblank(dev);
>> > + return;
>> > +}
>> > +
>> > static struct exynos_drm_manager_ops fimd_manager_ops = {
>> > .dpms = fimd_dpms,
>> > .apply = fimd_apply,
>> > .commit = fimd_commit,
>> > .enable_vblank = fimd_enable_vblank,
>> > .disable_vblank = fimd_disable_vblank,
>> > - .wait_for_vblank = fimd_wait_for_vblank,
>> > + .complete_scanout = fimd_complete_scanout,
>> > };
>> >
>> > static void fimd_win_mode_set(struct device *dev,
>> > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
>> > index 7ae6c07..382eaec 100644
>> > --- a/include/video/samsung_fimd.h
>> > +++ b/include/video/samsung_fimd.h
>> > @@ -274,6 +274,7 @@
>> >
>> > /* Video buffer addresses */
>> > #define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
>> > +#define VIDW_BUF_START_S(_buff)(0x40A0 +
>> > ((_buff) * 8))
>> > #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
>> > #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
>> > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
>> > --
>> > 1.8.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mail
[PATCH 1/4] drm: small fix in drm_send_vblank_event()
On Tue, Jan 8, 2013 at 11:08 PM, Rob Clark wrote: > Initialize e->pipe.. some drivers set this themselves, others do not. > Setting it in drm_send_vblank_event() should help ensure more consistent > behavior with the different drivers. > > Signed-off-by: Rob Clark Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_irq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 19c01ca..9bb83a5 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -863,6 +863,7 @@ void drm_send_vblank_event(struct drm_device *dev, int > crtc, > > now = get_drm_timestamp(); > } > + e->pipe = crtc; > send_vblank_event(dev, e, seq, &now); > } > EXPORT_SYMBOL(drm_send_vblank_event); > -- > 1.8.0.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Wed, Jan 09, 2013 at 12:27:22PM +0100, Daniel Vetter wrote: > On Tue, Jan 8, 2013 at 3:37 PM, J. Bruce Fields > wrote: > >> please grab the i915_error_state file from debugfs > > > > As I said in the original mail, I've already done that: > > > > http://fieldses.org/~bfields/3.8-hang/ > > Sorry, missed that the first time around. > > >> and file a bug on > >> bugs.freedesktop.org against DRM - DRI (Intel). > > > > Would it still be useful for me to file a bug? (Just going through the > > new-account confirmation dance now.) > > Looks like the ilk bug tracked at > https://bugs.freedesktop.org/show_bug.cgi?id=55984 OK, I'll add something there if I'm available to find a reproducer. Thanks! --b.
[PATCH 2/2] radeon: add support for forcing off lvds when mux switched away
On Mon, Jan 7, 2013 at 11:53 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> otherwise userspace can get very confused
Thinking about this more, we probably want to check whether we have a
muxed to mux-less system otherwise we'll be disconnecting the display
when we switch. Looks like the first patch is cognizant of that, but
this one is not unless I'm missing something.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 4
> drivers/gpu/drm/radeon/radeon_device.c | 14 ++
> drivers/gpu/drm/radeon/radeon_mode.h | 2 ++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 2399f25..e5a4a10 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -611,6 +611,10 @@ radeon_lvds_detect(struct drm_connector *connector, bool
> force)
> struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> struct drm_encoder *encoder = radeon_best_single_encoder(connector);
> enum drm_connector_status ret = connector_status_disconnected;
> + struct radeon_device *rdev = connector->dev->dev_private;
> +
> + if (rdev->mode_info.mux_force_disconnected)
> + return connector_status_disconnected;
>
> if (encoder) {
> struct radeon_encoder *radeon_encoder =
> to_radeon_encoder(encoder);
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index cd75626..bf66f09 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -945,10 +945,24 @@ static bool radeon_switcheroo_can_switch(struct pci_dev
> *pdev)
> return can_switch;
> }
>
> +static void radeon_switcheroo_mux_switched(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> +{
> + struct drm_device *dev = pci_get_drvdata(pdev);
> + struct radeon_device *rdev = dev->dev_private;
> +
> + if (state == VGA_SWITCHEROO_OFF)
> + rdev->mode_info.mux_force_disconnected = true;
> + else
> + rdev->mode_info.mux_force_disconnected = false;
> +
> + drm_kms_helper_hotplug_event(dev);
> +}
> +
> static const struct vga_switcheroo_client_ops radeon_switcheroo_ops = {
> .set_gpu_state = radeon_switcheroo_set_state,
> .reprobe = NULL,
> .can_switch = radeon_switcheroo_can_switch,
> + .mux_switched = radeon_switcheroo_mux_switched,
> };
>
> /**
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 4003f5a..172eed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -256,6 +256,8 @@ struct radeon_mode_info {
> u16 firmware_flags;
> /* pointer to backlight encoder */
> struct radeon_encoder *bl_encoder;
> +
> + bool mux_force_disconnected;
> };
>
> #define RADEON_MAX_BL_LEVEL 0xFF
> --
> 1.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59172] [r300g] flashing and corruption with MSAA 6x and 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=59172 --- Comment #1 from Alex Deucher --- This is probably related to memory bandwidth since MSAA compression is not currently implemented. -- 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 59172] New: [r300g] flashing and corruption with MSAA 6x and 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=59172 Priority: medium Bug ID: 59172 Assignee: dri-devel@lists.freedesktop.org Summary: [r300g] flashing and corruption with MSAA 6x and 1920x1080 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio@libero.it Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa When running some applications such as supertuxkart 0.8 with a high resolution (1920x1080) and MSAA 6x the screen flashes, shows massive corruptions and gets very slow. Just changing MSAA to 4x the problem is no longer reproducible. Tested on current git with: r300: DRM version: 2.18.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES -- 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 59169] [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Olšák --- This should be fixed by 1385c353cf06c6156d574cffba6164f2b59739e6. Closing. -- 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 59169] [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 --- Comment #1 from Tomasz P. --- Confirm. My rv350 is detected as rv370. -- 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 59169] New: [radeons] wrong chip detection
https://bugs.freedesktop.org/show_bug.cgi?id=59169 Priority: medium Bug ID: 59169 Assignee: dri-devel@lists.freedesktop.org Summary: [radeons] wrong chip detection Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fabio@libero.it Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa I noticed my RV530 get "upgraded" by mesa to a R580: GL_RENDERER = Gallium 0.4 on ATI R580 Up to some days ago it was correctly reported as a RV530. Possible regression of http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca474f98f2cda5cb333e9f851c7e0e31c9a6f823 -- 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: [PATCH 1/4] drm: small fix in drm_send_vblank_event()
On Tue, Jan 8, 2013 at 11:08 PM, Rob Clark wrote: > Initialize e->pipe.. some drivers set this themselves, others do not. > Setting it in drm_send_vblank_event() should help ensure more consistent > behavior with the different drivers. > > Signed-off-by: Rob Clark Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_irq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 19c01ca..9bb83a5 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -863,6 +863,7 @@ void drm_send_vblank_event(struct drm_device *dev, int > crtc, > > now = get_drm_timestamp(); > } > + e->pipe = crtc; > send_vblank_event(dev, e, seq, &now); > } > EXPORT_SYMBOL(drm_send_vblank_event); > -- > 1.8.0.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] radeon: add support for forcing off lvds when mux switched away
On Mon, Jan 7, 2013 at 11:53 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> otherwise userspace can get very confused
Thinking about this more, we probably want to check whether we have a
muxed to mux-less system otherwise we'll be disconnecting the display
when we switch. Looks like the first patch is cognizant of that, but
this one is not unless I'm missing something.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 4
> drivers/gpu/drm/radeon/radeon_device.c | 14 ++
> drivers/gpu/drm/radeon/radeon_mode.h | 2 ++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 2399f25..e5a4a10 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -611,6 +611,10 @@ radeon_lvds_detect(struct drm_connector *connector, bool
> force)
> struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> struct drm_encoder *encoder = radeon_best_single_encoder(connector);
> enum drm_connector_status ret = connector_status_disconnected;
> + struct radeon_device *rdev = connector->dev->dev_private;
> +
> + if (rdev->mode_info.mux_force_disconnected)
> + return connector_status_disconnected;
>
> if (encoder) {
> struct radeon_encoder *radeon_encoder =
> to_radeon_encoder(encoder);
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index cd75626..bf66f09 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -945,10 +945,24 @@ static bool radeon_switcheroo_can_switch(struct pci_dev
> *pdev)
> return can_switch;
> }
>
> +static void radeon_switcheroo_mux_switched(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> +{
> + struct drm_device *dev = pci_get_drvdata(pdev);
> + struct radeon_device *rdev = dev->dev_private;
> +
> + if (state == VGA_SWITCHEROO_OFF)
> + rdev->mode_info.mux_force_disconnected = true;
> + else
> + rdev->mode_info.mux_force_disconnected = false;
> +
> + drm_kms_helper_hotplug_event(dev);
> +}
> +
> static const struct vga_switcheroo_client_ops radeon_switcheroo_ops = {
> .set_gpu_state = radeon_switcheroo_set_state,
> .reprobe = NULL,
> .can_switch = radeon_switcheroo_can_switch,
> + .mux_switched = radeon_switcheroo_mux_switched,
> };
>
> /**
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 4003f5a..172eed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -256,6 +256,8 @@ struct radeon_mode_info {
> u16 firmware_flags;
> /* pointer to backlight encoder */
> struct radeon_encoder *bl_encoder;
> +
> + bool mux_force_disconnected;
> };
>
> #define RADEON_MAX_BL_LEVEL 0xFF
> --
> 1.8.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #33 from Alex Deucher --- Does a 3.8 kernel it work ok if you revert mesa back to cf5632094ba0c19d570ea47025cf6da75ef8457a? I think r600g: rework flusing and synchronization pattern v7 http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a may be problematic 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 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #16 from Alex Deucher --- Does a 3.8 kernel it work ok if you revert mesa back to cf5632094ba0c19d570ea47025cf6da75ef8457a? I think r600g: rework flusing and synchronization pattern v7 http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a may be problematic 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 36596] Major 2D performance bottleneck (most noticeable with compiz)
https://bugs.freedesktop.org/show_bug.cgi?id=36596 --- Comment #14 from Tomasz P. --- is it still an issue with current mesa? -- 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 47244] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
https://bugs.freedesktop.org/show_bug.cgi?id=47244 --- Comment #3 from Tomasz P. --- Is it still an 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
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Tue, Jan 8, 2013 at 3:37 PM, J. Bruce Fields wrote: >> please grab the i915_error_state file from debugfs > > As I said in the original mail, I've already done that: > > http://fieldses.org/~bfields/3.8-hang/ Sorry, missed that the first time around. >> and file a bug on >> bugs.freedesktop.org against DRM - DRI (Intel). > > Would it still be useful for me to file a bug? (Just going through the > new-account confirmation dance now.) Looks like the ilk bug tracked at https://bugs.freedesktop.org/show_bug.cgi?id=55984 -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 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #32 from Alexandre Demers --- You're using a Cayman card, but which model exactly? -- 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/20130109/46e71c48/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #15 from Alexandre Demers --- Created attachment 72694 --> https://bugs.freedesktop.org/attachment.cgi?id=72694&action=edit dmesg from killing Xorg remotely when frozen with patch 72013 applied This is with patch 72013 applied. -- 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/20130109/ef192263/attachment-0001.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #14 from Alexandre Demers --- (In reply to comment #13) > Is there anything in the kernel log when this happens now that the mesa fix > is applied? Also does the patch in attachment 72013 [details] [review] help > now that the mesa side is fixed? With or without the patch, it still ends saying the kernel rejected the CS and to check in dmesg. Then, it freezes. However, accessed through ssh, there is nothing I could get from it. I killed Xorg remotely, the screen blinked for a moment and only garbage was displayed. I was able to retrieve something from dmesg. I killed it a second time to only get some different garbage. I'll attach the file right away. -- 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/20130109/f3aac4a9/attachment.html>
Re: [RFC v2 0/5] Common Display Framework
Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Get HDMI version from device tree
On 1/8/2013 6:48 AM, Sean Paul wrote: > On Tue, Jan 8, 2013 at 11:45 AM, Lucas Stach wrote: >> Am Montag, den 07.01.2013, 16:12 -0500 schrieb Sean Paul: >>> On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley wrote: On 1/7/2013 10:43 AM, Sean Paul wrote: > Add a property to the hdmi node so we can specify the HDMI version in > the device tree instead of just defaulting to v1.4 with the existence of > the dt node. > > Signed-off-by: Sean Paul > --- > .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 19 > ++- > 2 files changed, 13 insertions(+), 9 deletions(-) > > diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt > b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt > index 589edee..d1c7d91 100644 > --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt > +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt > @@ -11,6 +11,8 @@ Required properties: > c) pin function mode. > d) optional flags and pull up/down. > e) drive strength. > +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4 > +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3 a) This seems pretty generic, not at all samsung-specific, as the HDMI version numbering space is well-defined by the HDMI spec. b) It would be better to make it an integer property whose value encodes the version number, thus eliminating the need to add new properties as new HDMI versions appear. >>> >>> Thanks for the quick review, Mitch. >>> >>> How about: >>> >>> - hdmi-version: 0=v1.3, 1=v1.4 >> Why bother obfuscating the real version number? Why not just 13=v1.3, >> 14=v1.4? It's hard to predict how the HDMI committee will assign version numbers in the future, but... In the EDID structure that HDMI devices use for identification, the major.minor version number is encoded as two bytes, one for major and one for minor, thus it is conceivable that the minor could exceed 9. (reference CEA-861-D section A.2.5 or http://en.wikipedia.org/wiki/Extended_display_identification_data#EDID_1.3_data_format The EDID version number is not the same as the HDMI version number, but I expect that the committees share people and thus ways of doing things. I think it would be safer to encode the version number as (major<<8) | minor. >> > > Sure, that sounds good to me. > > Sean > >> Regards, >> Lucas >> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/5] Common Display Framework
On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart wrote: > Hi Rob, > > On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >> What I've done to avoid that so far is that the master device registers the >> drivers for it's output sub-devices before registering it's own device. > > I'm not sure to follow you here. The master device doesn't register anything, > do you mean the master device driver ? If so, how does the master device > driver register its own device ? Devices are not registered by their driver. sorry, that should have read "master driver registers drivers for it's sub-devices.." BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: "Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2
On Sun, Jan 06, 2013 at 07:06:52PM +0100, Daniel Vetter wrote: > On Thu, Jan 03, 2013 at 06:11:23PM -0500, J. Bruce Fields wrote: > > On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote: > > > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields > > > wrote: > > > > I got a crash after a few minutes of running 3.8.0-rc2, was able to > > > > switch to a vt and look at dmesg: > > > > > > > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > > > elapsed... GPU hung > > > > [ 490.963019] [drm] capturing error event; look for more information > > > > in /debug/dri/0/i915_error_state > > > > [ 492.961446] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > > > elapsed... GPU hung > > > > [ 492.965613] [drm:i915_reset] *ERROR* GPU hanging too fast, > > > > declaring wedged! > > > > [ 492.965621] [drm:i915_reset] *ERROR* Failed to reset chip. > > > > > > > > Previously I was on 3.6.10-2.fc17.x86_64, which didn't have any such > > > > problem. > > > > > > I'm not questioning that you haven't seen that error in F17, but we have > > > had quite a few bug reports with similar error messages for a while now. > > > Apparently there are lots of ways GPUs can get hung, so they might be > > > different from what you're seeing. Just wanted to point out that it > > > might not be a new 3.8 change that caused it. > > > > OK, sure. It reproduced very quickly after the upgrade, so I assumed it > > was a regression. > > > > I'm running 3.7.0 now which hasn't shown any problem. > > > > I'll try a newer kernel again to see if it's really that easy for me to > > reproduce. > > If you hit this again (even better if you have a way to reproduce) Unfortunately I wasn't able to reproduce after working a couple more hours on 3.8 again. However: > please grab the i915_error_state file from debugfs As I said in the original mail, I've already done that: http://fieldses.org/~bfields/3.8-hang/ > and file a bug on > bugs.freedesktop.org against DRM - DRI (Intel). Would it still be useful for me to file a bug? (Just going through the new-account confirmation dance now.) --b. > We do know of a few recent > issues introduced around 3.7 kernels, preliminary patches are floating > around. The error state should be good enough to decide whether you're > hitting the same issues. > > Thanks, 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
