[PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki wrote: > Hi, > > On 09/06/2012 09:21 AM, InKi Dae wrote: +Required properties: + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for >>> Doesn't better to use single word? fimd or fb?. I think 'fb' is used >>> for framebuffer historically. >>> but now it's used both fb and drm, so fimd is neutral and architecture >>> specific. >>> >>> To do this, Modify arch-exynos first and update it at each drivers it >>> properly. >>> >>> Thank you, >>> Kyungmin Park >>> >> >> I agree with Kyungmin but I'd like to use as is. the reason we used >> 'exynos4-fb' as device name, is for that it uses fimd driver's >> platform device commonly and gets fimd clock. so I think that dts file >> should be defined with hardware specific name but not driver name such >> as 'exynos4-fb'. but with this, we can't get fimd clock with device's >> name because 'exynos4-fb' is used as device name of fimd clock. so to >> use 'exynos4-fimd', we should modify the device name of fimd clock >> from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of >> s3c-fb and drm fimd driver. so my conclusion is that it merges this > > I think it's good moment to put those things in order, i.e. use uniform > 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". > Platform device names are separate issue, but could perhaps be unified > at this time as well. Yes, Platform device name is independent of compatible string. Will change the compatible string to "samsung,exynos4-fimd" and will keep the device name as exynos4-fb for now. Will change the platform device names to exynosX-fimd later. > >> patch set as is and then let's modify related things later. >> any opinions, welcome~ anytime. >> >> Thanks. >> Inki Dae > > -- > > Regards, > Sylwester > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Applied. Thanks, Inki Dae 2012/9/7 Mandeep Singh Baines : > The double invocations are incorrect but seem to be safe so I don't > think this will fix any bugs. > > Before: > > [7.639366] drm_prime_init_file ee3675d0 > [7.639377] drm_prime_init_file ee3675d0 > [7.639507] drm_prime_destroy_file ee3675d0 > [7.639518] drm_prime_destroy_file ee3675d0 > [7.639802] drm_prime_init_file ee372390 > [7.639810] drm_prime_init_file ee372390 > [8.473316] drm_prime_init_file ee356390 > [8.473331] drm_prime_init_file ee356390 > > After: > > [6.363842] drm_prime_init_file edc2e5d0 > [6.363994] drm_prime_destroy_file edc2e5d0 > [6.364260] drm_prime_init_file edc2e750 > [8.004837] drm_prime_init_file ee36ded0 > > Signed-off-by: Mandeep Singh Baines > Acked-by: Seung-Woo Kim > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index ebacec6..a27b8ff 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct > drm_file *file) > if (!file_priv) > return -ENOMEM; > > - drm_prime_init_file_private(&file->prime); > file->driver_priv = file_priv; > > return exynos_drm_subdrv_open(dev, file); > @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, > e->base.destroy(&e->base); > } > } > - drm_prime_destroy_file_private(&file->prime); > spin_unlock_irqrestore(&dev->event_lock, flags); > > exynos_drm_subdrv_close(dev, file); > -- > 1.7.7.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi 2012/9/7 Leela Krishna Amudala : > Hi, > > On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki > wrote: >> Hi, >> >> On 09/06/2012 09:21 AM, InKi Dae wrote: > +Required properties: > + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" > for Doesn't better to use single word? fimd or fb?. I think 'fb' is used for framebuffer historically. but now it's used both fb and drm, so fimd is neutral and architecture specific. To do this, Modify arch-exynos first and update it at each drivers it properly. Thank you, Kyungmin Park >>> >>> I agree with Kyungmin but I'd like to use as is. the reason we used >>> 'exynos4-fb' as device name, is for that it uses fimd driver's >>> platform device commonly and gets fimd clock. so I think that dts file >>> should be defined with hardware specific name but not driver name such >>> as 'exynos4-fb'. but with this, we can't get fimd clock with device's >>> name because 'exynos4-fb' is used as device name of fimd clock. so to >>> use 'exynos4-fimd', we should modify the device name of fimd clock >>> from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of >>> s3c-fb and drm fimd driver. so my conclusion is that it merges this >> >> I think it's good moment to put those things in order, i.e. use uniform >> 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". >> Platform device names are separate issue, but could perhaps be unified >> at this time as well. > > Yes, Platform device name is independent of compatible string. > Will change the compatible string to "samsung,exynos4-fimd" and will keep the > device name as exynos4-fb for now. Will change the platform device > names to exynosX-fimd > later. > I'm not sure that clk_get is worked well with this change. I think, when driver called clk_get(), first of all, it tries to get a clk from the registered list of clock providers in the dts file and next in legacy way. but now legacy way(needing clock name and device' name) would be failed if the dts file has no the list because platform device's name differs from device name of clock. so I think we should change device name of clock and also ids of related drivers for compatibility with non-dt. for this, we need some patch sets, changing arch/arm/mach-exynos/common.c and changing arch/arm/mach-exynos/clock-exynos4/5.c and changing s3c-fb.c and last this patch. if there are no other opinions, I'd like to merge this patch set(v5) and next we can update others(maybe common.c, clock-exynos4/5.c and s3c-fb.c) later. Thanks. Inki Dae >> >>> patch set as is and then let's modify related things later. >>> any opinions, welcome~ anytime. >>> >>> Thanks. >>> Inki Dae >> >> -- >> >> Regards, >> Sylwester >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 0/2] video: drm: Add Device tree support to DRM-FIMD
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. It includes parsing platform data from dts file. Also, adds the driver data for exynos4 and exynos5 devices. This patchset is based and tested on top of v3.6-rc4 on smdk5250 board Also depends on below patchset http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html Changes since V4: - Changed the compatible string from "samsung,exynos4-fb" to "samsung,exynos4-fimd". Changes since V3: - Removed the fimd version from driver data and using timing base address instead - Removed the drm_ prefixes to the structures and fucntions Changes since V2: - Added driver data to exynos5-drm-fimd as per Marek Szyprowski suggestion Changes since V1: - Corrected typo errors and changed compatibility string Leela Krishna Amudala (2): drm/exynos: add platform_device_id table and driver data for drm fimd video: drm: exynos: Add device tree support Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 138 - 2 files changed, 212 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
[PATCH V5 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd
Two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 43 +++---
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..65e927b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@
#define get_fimd_context(dev) platform_get_drvdata(to_platform_device(dev))
+struct fimd_driver_data {
+ unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+ .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+ .timing_base = 0x2,
+};
+
struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+ struct platform_device *pdev)
+{
+ return (struct fimd_driver_data *)
+ platform_get_device_id(pdev)->driver_data;
+}
+
static bool fimd_display_is_connected(struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
struct fb_videomode *timing = &panel->timing;
+ struct fimd_driver_data *driver_data;
+ struct platform_device *pdev = to_platform_device(dev);
u32 val;
+ driver_data = drm_fimd_get_driver_data(pdev);
if (ctx->suspended)
return;
DRM_DEBUG_KMS("%s\n", __FILE__);
/* setup polarity values from machine code. */
- writel(ctx->vidcon1, ctx->regs + VIDCON1);
+ writel(ctx->vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing->upper_margin - 1) |
VIDTCON0_VFPD(timing->lower_margin - 1) |
VIDTCON0_VSPW(timing->vsync_len - 1);
- writel(val, ctx->regs + VIDTCON0);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
/* setup horizontal timing values. */
val = VIDTCON1_HBPD(timing->left_margin - 1) |
VIDTCON1_HFPD(timing->right_margin - 1) |
VIDTCON1_HSPW(timing->hsync_len - 1);
- writel(val, ctx->regs + VIDTCON1);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
VIDTCON2_HOZVAL(timing->xres - 1);
- writel(val, ctx->regs + VIDTCON2);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);
/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -982,6 +1004,18 @@ static int fimd_runtime_resume(struct device *dev)
}
#endif
+static struct platform_device_id fimd_driver_ids[] = {
+ {
+ .name = "exynos4-fb",
+ .driver_data= (unsigned long)&exynos4_fimd_driver_data,
+ }, {
+ .name = "exynos5-fb",
+ .driver_data= (unsigned long)&exynos5_fimd_driver_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,6 +1024,7 @@ static const struct dev_pm_ops fimd_pm_ops = {
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = __devexit_p(fimd_remove),
+ .id_table = fimd_driver_ids,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
--
1.7.0.4
[PATCH V5 2/2] video: drm: exynos: Add device tree support
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..bf94cd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fimd" for
+ fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+ specified in the following order.
+ - VSYNC interrupt
+ - FIFO level interrupt
+ - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+ display device node which holds the video interface timing with the
+ below mentioned properties.
+
+ - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+ - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+ The following is an example for the fimd controller is split into
+ two portions. The SoC specific portion can be specified in the SoC
+ specific dts file. The board specific portion can be specified in the
+ board specific dts file.
+
+ - SoC Specific portion
+
+ fimd {
+ compatible = "samsung,exynos5-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x1440 0x4>;
+ interrupts = <18 5>, <18 4>, <18 6>;
+ };
+
+ - Board Specific portion
+
+ lcd_fimd0: lcd_panel0 {
+ lcd-htiming = <4 4 4 480>;
+ lcd-vtiming = <4 4 4 320>;
+ supports-mipi-panel;
+ };
+
+ fimd {
+ samsung,fimd-display = <&lcd_fimd0>;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = <60>;
+ samsung,default-window = <0>;
+ samsung,fimd-win-bpp = <32>;
+ };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 65e927b..cd1b841 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static const struct of_device_id fimd_dt_match[];
+
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
+#ifdef CONFIG_OF
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_ptr(fimd_dt_match);
+ return (struct fimd_driver_data *)match->data;
+ }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
}
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
return 0;
}
+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device
*dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *disp_np;
+ struct exynos_drm_fimd_pdata *pd;
+ u32 data[4];
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "memory allocation for pdata failed\n");
+ return ERR_PTR(-ENOMEM);
+
[PATCH V4 2/2] video: drm: exynos: Add device tree support
2012/9/7 Inki Dae : > Hi > > 2012/9/7 Leela Krishna Amudala : >> Hi, >> >> On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki >> wrote: >>> Hi, >>> >>> On 09/06/2012 09:21 AM, InKi Dae wrote: >> +Required properties: >> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" >> for > Doesn't better to use single word? fimd or fb?. I think 'fb' is used > for framebuffer historically. > but now it's used both fb and drm, so fimd is neutral and architecture > specific. > > To do this, Modify arch-exynos first and update it at each drivers it > properly. > > Thank you, > Kyungmin Park > I agree with Kyungmin but I'd like to use as is. the reason we used 'exynos4-fb' as device name, is for that it uses fimd driver's platform device commonly and gets fimd clock. so I think that dts file should be defined with hardware specific name but not driver name such as 'exynos4-fb'. but with this, we can't get fimd clock with device's name because 'exynos4-fb' is used as device name of fimd clock. so to use 'exynos4-fimd', we should modify the device name of fimd clock from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of s3c-fb and drm fimd driver. so my conclusion is that it merges this >>> >>> I think it's good moment to put those things in order, i.e. use uniform >>> 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". >>> Platform device names are separate issue, but could perhaps be unified >>> at this time as well. >> >> Yes, Platform device name is independent of compatible string. >> Will change the compatible string to "samsung,exynos4-fimd" and will keep the >> device name as exynos4-fb for now. Will change the platform device >> names to exynosX-fimd >> later. >> > > I'm not sure that clk_get is worked well with this change. I think, > when driver called clk_get(), first of all, it tries to get a clk from > the registered list of clock providers in the dts file and next in > legacy way. but now legacy way(needing clock name and device' name) > would be failed if the dts file has no the list because platform > device's name differs from device name of clock. so I think we should > change device name of clock and also ids of related drivers for > compatibility with non-dt. for this, we need some patch sets, changing > arch/arm/mach-exynos/common.c and changing > arch/arm/mach-exynos/clock-exynos4/5.c and changing s3c-fb.c and last > this patch. if there are no other opinions, I'd like to merge this > patch set(v5) and next we can update others(maybe common.c, > clock-exynos4/5.c and s3c-fb.c) later. > there is my missing point. with dt, platform device's name is set by OF_DEV_AUXDATA's name so it doesn't need to modify things related to exynos4 anymore. we just need to update things related to exynos5. Thanks. Inki Dae > Thanks. > Inki Dae > >>> patch set as is and then let's modify related things later. any opinions, welcome~ anytime. Thanks. Inki Dae >>> >>> -- >>> >>> Regards, >>> Sylwester >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-samsung-soc" in >>> the body of a message to majordomo at vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 0/2] video: drm: Add Device tree support to DRM-FIMD
Applied. Thanks. Inki Dae 2012/9/7 Leela Krishna Amudala : > This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. > It includes parsing platform data from dts file. Also, adds the driver data > for exynos4 and exynos5 devices. > > This patchset is based and tested on top of v3.6-rc4 on smdk5250 board > Also depends on below patchset > http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html > > Changes since V4: > - Changed the compatible string from "samsung,exynos4-fb" to > "samsung,exynos4-fimd". > > Changes since V3: > - Removed the fimd version from driver data and using timing base > address instead > - Removed the drm_ prefixes to the structures and fucntions > > Changes since V2: > - Added driver data to exynos5-drm-fimd as per Marek Szyprowski > suggestion > > Changes since V1: > - Corrected typo errors and changed compatibility string > > Leela Krishna Amudala (2): > drm/exynos: add platform_device_id table and driver data for drm fimd > video: drm: exynos: Add device tree support > > Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 138 > - > 2 files changed, 212 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt > > > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PCI Radeon RV100 detection hang on sparc64
On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote: > From: Michel D?nzer > Date: Thu, 06 Sep 2012 18:55:51 +0200 > >> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: >>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in >>> Ultra 10 (clean, without my "Video RAM" hack that I talked in other >>> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the >>> kernel, I compiled radeon drm driver with modesetting enabled and tried >>> it: >>> >>> [drm] radeon defaulting to kernel modesetting. >>> [drm] radeon kernel modesetting enabled. >>> PCI: Enabling device: (:02:02.0), cmd 82 >>> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). >>> [drm] register mmio base: 0x1000 >>> [drm] register mmio size: 32768 >>> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR >>> >>> And here the machine hangs. Debugging printk-s reveal that it does not >>> find any active I/O port resources and then continues into initializing >>> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >>> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >>> 2 bytes from there and hangs on reading bios[0]. >> >> Is the card initialized by OpenFirmware? E.g., does it display anything >> before the kernel boots? > > I think Meelis gave you every single detail you need to know to > analyze and fix this bug. > > He says it crashes on reading bios[0]. > > If you look at the function he tells you the crash occurs in, you'll > see clearly that bios is an ioremap()'d pointer. > > You cannot dereference ioremap()'d pointers, you must use the proper > accessors such as readl(). we should just skip the igp reading function on not-x86, since IGP on not x86 makes no sense. the other option is to readl out the whole bios from vram instead. Dave.
[PATCH] drm/exynos: remove DRM_FORMAT_NV12M from plane module
this patch removes DRM_FORMAT_NV12M from plane module because this format
is same as DRM_FORMAT_NV12. DRM_FORMAT_NV12M will be identified by
mode_cmd->handles and mode_cmd->offsets fields internally.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin.park
---
drivers/gpu/drm/exynos/exynos_drm_plane.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index b89829e..e1f94b7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -29,7 +29,6 @@ static const uint32_t formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_NV12,
- DRM_FORMAT_NV12M,
DRM_FORMAT_NV12MT,
};
--
1.7.4.1
[PATCH] drm/fb helper: don't call drm_helper_connector_dpms directly
Yet again a case where the fb helper is too intimate with the crtc
helper and calls a crtc helepr function directly instead of going
through the interface vtable.
This fixes console blanking in drm/i915 with the new i915-specific
modeset code.
Reported-by: Jesse Barnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index eb79515..b5d05f5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -330,7 +330,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
/* Walk the connectors & encoders on this fb turning them
on/off */
for (j = 0; j < fb_helper->connector_count; j++) {
connector = fb_helper->connector_info[j]->connector;
- drm_helper_connector_dpms(connector, dpms_mode);
+ connector->funcs->dpms(connector, dpms_mode);
drm_connector_property_set_value(connector,
dev->mode_config.dpms_property, dpms_mode);
}
--
1.7.11.2
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #51 from Zolt?n B?sz?rm?nyi 2012-09-07 10:08:21 UTC --- I saw this: commit 5ceb87286f2e1b5b8527ba18a844abf450903175 Author: Jerome Glisse Date: Wed Sep 5 15:18:24 2012 -0400 r600g: order atom emission v3 To avoid GPU lockup registers must be emited in a specific order (no kidding ...). This patch rework atom emission so order in which atom are emited in respect to each other is always the same. We don't have any informations on what is the correct order so order will need to be infered from fglrx command stream. v2: add comment warning that atom order should not be taken lightly v3: rebase on top of alphatest atom fix Signed-off-by: Jerome Glisse Does this mean the htile patch may also be committed without causing lockups? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53490] [bisected] bump map corruption from kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=53490 Joeri Capens changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #14 from Joeri Capens 2012-09-07 12:10:45 UTC --- I re-compiled mesa again (the "8.1_rc1_pre20120724" git snapshot provided by Gentoo, to be exact) and this time the bump map corruption does not occur anymore, with or without my kernel patch. I tried some recent mesa versions before, but I must have made mistakes while copying the mesa libraries from a 32-bit chroot to the /usr/lib32/ directory on my 64-bit system. Somewhere between mesa 8.0.4 and the snapshot of 2012-07-24, the bug has already been fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 54649] New: Image in Quake 3 is dark
https://bugs.freedesktop.org/show_bug.cgi?id=54649 Bug #: 54649 Summary: Image in Quake 3 is dark Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: js314592 at gmail.com Image in Quake 3 is dark. Changing of brightness has no effect. name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on i915 (chipset: G33) OpenGL version string: 2.1 Mesa 9.0-devel OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_fog_distance, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_primitive_restart, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, GL_EXT_pixel_buffer_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_ARB_framebuffer_object, GL_EX
[Bug 54649] Image in Quake 3 is dark
https://bugs.freedesktop.org/show_bug.cgi?id=54649 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #1 from Sven Arvidsson 2012-09-07 17:54:42 UTC --- Are you sure this is a driver bug? Sounds like: http://bugzilla.libsdl.org/show_bug.cgi?id=971 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/omap: add more new timings fields
From: Rob Clark Without these, DVI is broken. Signed-off-by: Rob Clark --- Greg, it looks like the omapdss changes which added these fields, as well as the interlaced field, where merged in Linux 3.5-rc5. So I think both this and the 'update for interlaced' patch are needed for both 3.6 and 3.5. drivers/staging/omapdrm/omap_connector.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 5f4a89b..55e9c86 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -52,6 +52,16 @@ static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode, if (timings->interlace) mode->flags |= DRM_MODE_FLAG_INTERLACE; + + if (timings->hsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PHSYNC; + else + mode->flags |= DRM_MODE_FLAG_NHSYNC; + + if (timings->vsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PVSYNC; + else + mode->flags |= DRM_MODE_FLAG_NVSYNC; } static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, @@ -70,6 +80,20 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, timings->vbp = mode->vtotal - mode->vsync_end; timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE); + + if (mode->flags & DRM_MODE_FLAG_PHSYNC) + timings->hsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->hsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + if (mode->flags & DRM_MODE_FLAG_PVSYNC) + timings->vsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->vsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE; + timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH; + timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES; } static void omap_connector_dpms(struct drm_connector *connector, int mode) -- 1.7.9.5
[Bug 53511] r600g llvm backend doesn't support indirect addressing
https://bugs.freedesktop.org/show_bug.cgi?id=53511 --- Comment #1 from almos 2012-09-07 18:05:39 UTC --- I see that testing is the first item on the r600todo list, and to see if there are any differences between the two shader compilers. Maybe this should be a prerequisite of that, because most of the shader-heavy applications hit this fallback. BTW I don't see any performance difference between the two compilers on my hd6850 apart from what I reported in bug 51787 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #32 from diego.abelenda at gmail.com 2012-09-07 19:19:10 UTC --- Created attachment 66808 --> https://bugs.freedesktop.org/attachment.cgi?id=66808 dmesg booting with 2 monitors plugged drm.debug=4 This drm-fixes-3.6 branch just gives me two black screens when I have them both plugged during the boot. And when X starts I get a 100% processor usage from the X process and nothing displayed. The Xorg.0.log shows nothing out of the ordinary. But I think there is something really wrong because my X server never starts accepting connection from my login manager. When I boot with only the DVI screen plugged, no problem it boots fine. After having booted with only the DVI plugging the VGA one works just like before. When X puts my screens into DPMS off and I try to wake them up, the VGA goes back on correctly with this branch whereas it didn't with vanilla kernel. So there are some good points and some bad points. Attached is dmesg | grep -e drm -e radeon when both screens are connected, after X is "started". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #33 from Alex Deucher 2012-09-07 19:35:20 UTC --- You might try this patch on top of my 3.6 fixees tree: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=46b417b3eee694451b5bca8a7863e9174611a2e9 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #34 from diego.abelenda at gmail.com 2012-09-07 21:07:16 UTC --- Created attachment 66817 --> https://bugs.freedesktop.org/attachment.cgi?id=66817 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 With the additional patch, I get the DVI screen displaying things when both a plugged-in but the VGA one now says there is no signal (instead of staying black). So the behavior is somewhat similar to the vanilla kernel in that regard. Booting with the VGA unplugged and plugging it later gives the same behavior as without that patch (i.e. better than the vanilla kernel). Attached is the dmesg | grep -e drm -e radeon when the 2 screens are plugged and the VGA says no signal. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abelenda at gmail.com changed: What|Removed |Added Attachment #66817|application/octet-stream|text/plain mime type|| --- Comment #35 from diego.abelenda at gmail.com 2012-09-07 21:08:26 UTC --- Comment on attachment 66817 --> https://bugs.freedesktop.org/attachment.cgi?id=66817 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Sorry wrong auto-detect of the type... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abelenda at gmail.com changed: What|Removed |Added Attachment #66817|0 |1 is obsolete|| --- Comment #36 from diego.abelenda at gmail.com 2012-09-07 21:11:53 UTC --- Created attachment 66819 --> https://bugs.freedesktop.org/attachment.cgi?id=66819 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Sorry... I appended the new log to the last one instead of overwriting it... Now there is only the new dmesg information. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abelenda at gmail.com changed: What|Removed |Added Attachment #66819|0 |1 is obsolete|| --- Comment #37 from diego.abelenda at gmail.com 2012-09-07 21:28:26 UTC --- Created attachment 66822 --> https://bugs.freedesktop.org/attachment.cgi?id=66822 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Ok I need sleep... This time is the right dmesg. With both screens plugged during the boot and the patch, but mysteriously this time the DVI screen stayed black and the VGA had no link. And X started to take 100% CPU. So exactly the same behavior as without the patch. I tried rebooting and then both screens lit up and were black. X using 100% CPU. the new attachment shows dmesg | grep -e drm -e radeon after both attempts. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/fb helper: don't call drm_helper_connector_dpms directly
On Fri, 7 Sep 2012 10:14:52 +0200
Daniel Vetter wrote:
> Yet again a case where the fb helper is too intimate with the crtc
> helper and calls a crtc helepr function directly instead of going
> through the interface vtable.
>
> This fixes console blanking in drm/i915 with the new i915-specific
> modeset code.
>
> Reported-by: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index eb79515..b5d05f5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -330,7 +330,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> /* Walk the connectors & encoders on this fb turning them
> on/off */
> for (j = 0; j < fb_helper->connector_count; j++) {
> connector = fb_helper->connector_info[j]->connector;
> - drm_helper_connector_dpms(connector, dpms_mode);
> + connector->funcs->dpms(connector, dpms_mode);
> drm_connector_property_set_value(connector,
> dev->mode_config.dpms_property, dpms_mode);
> }
Tested-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
[PATCH 0/7] Fixes for hybrid graphics Apple machines
On Fri, Sep 7, 2012 at 4:22 PM, Seth Forshee wrote: > Many hybrid graphics Apple laptops fail to set up LVDS on the secondary > GPU due to missing or incorrect mode information for the panel at init > time. The only way to get the LVDS mode on these machines is via the > DDC, but this is muxed to the active GPU at boot. However, the graphics > mux on these machines supports muxing the i2c idependently of the > display, making it possible for the secondary graphics driver to read > the EDID without a full display switch. > > In order to support this, these patches modify vga_switcheroo to allow > muxing of the DDC idependently of the display. apple-gmux is updated to > support this new functionality, and drm_get_edid() is modified to switch > the DDC mux as needed. > > For this to work we also need to ensure that sufficient switcheroo > suport is available before initializing the secondary GPU. This is done > by adding any non-active GPUs that try to initialize before switcheroo > is ready to a list and initializing these devices once switcheroo > becomes ready. This behavior is restricted to Apple laptops to prevent > causing problems on other machines. I hate this idea, no delaying stuff. We either need to have some sort of enforced ordering or make some stuff only work built-in. But sticking things on a delayed list just in case seems wrong to me. Dave.
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #38 from Alex Deucher 2012-09-07 21:52:32 UTC --- You're getting a GPU hang for some reason which may be causing the modeset failure. Can you try with acceleration disabled to take the out of the equation? Try adding: Option "NoAccel" "TRUE" to the device section of your xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH V6] drm: edid: add support for E-DDC
Hi Dave,
Gentle Reminder!
This patch is required for passing the very first test case of HDMI
Compliance test suite.
Regards,
Shirish S
On Mon, Sep 3, 2012 at 8:54 AM, Shirish S wrote:
> Hello Dave,
>
> My patch-set for adding support for 4 block EDID is now reviewed and ready.
> Please let me know if you want any further clarification
>
> Regards,
> Shirish S
>
>
> On Thu, Aug 30, 2012 at 12:04 AM, Shirish S wrote:
>
>> The current logic for probing ddc is limited to
>> 2 blocks (256 bytes), this patch adds support
>> for the 4 block (512) data.
>>
>> To do this, a single 8-bit segment index is
>> passed to the display via the I2C address 30h.
>> Data from the selected segment is then immediately
>> read via the regular DDC2 address using a repeated
>> I2C 'START' signal.
>>
>> Signed-off-by: Shirish S
>> Reviewed-by: Jean Delvare
>> Reviewed-by: Daniel Vetter
>> Reviewed-by: Ville Syrjala
>> ---
>> drivers/gpu/drm/drm_edid.c | 19 ---
>> 1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index bcc4725..7f62de5 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> int block, int len)
>> {
>> unsigned char start = block * EDID_LENGTH;
>> + unsigned char segment = block >> 1;
>> + unsigned char xfers = segment ? 3 : 2;
>> int ret, retries = 5;
>>
>> /* The core i2c driver will automatically retry the transfer if
>> the
>> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> do {
>> struct i2c_msg msgs[] = {
>> {
>> + .addr = DDC_SEGMENT_ADDR,
>> + .flags = 0,
>> + .len= 1,
>> + .buf= &segment,
>> + }, {
>> .addr = DDC_ADDR,
>> .flags = 0,
>> .len= 1,
>> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> .buf= buf,
>> }
>> };
>> - ret = i2c_transfer(adapter, msgs, 2);
>> +
>> + /*
>> +* Avoid sending the segment addr to not upset non-compliant ddc
>> +* monitors.
>> +*/
>> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>> +
>> if (ret == -ENXIO) {
>> DRM_DEBUG_KMS("drm: skipping non-existent adapter
>> %s\n",
>> adapter->name);
>> break;
>> }
>> - } while (ret != 2 && --retries);
>> + } while (ret != xfers && --retries);
>>
>> - return ret == 2 ? 0 : -1;
>> + return ret == xfers ? 0 : -1;
>> }
>>
>> static bool drm_edid_is_zero(u8 *in_edid, int length)
>> --
>> 1.7.0.4
>>
>> ___
>> 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/20120907/04e173e9/attachment.html>
[PATCH] drm: remove property_blob_list
From: Rob Clark
It isn't used anywhere.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |2 --
include/drm/drm_crtc.h |1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7552675..21a0a85 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -995,7 +995,6 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.connector_list);
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
- INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
@@ -3114,7 +3113,6 @@ static struct drm_property_blob
*drm_property_create_blob(struct drm_device *dev
memcpy(blob->data, data, length);
- list_add_tail(&blob->head, &dev->mode_config.property_blob_list);
return blob;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1422b36..a3574d0d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -794,7 +794,6 @@ struct drm_mode_config {
struct delayed_work output_poll_work;
/* pointers to standard properties */
- struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
--
1.7.9.5
[PATCH 3/7] vga_switcheroo: Add notifier call chain for switcheroo events
DRM needs to be notified of client and handler registration in order to
defer initialization of the secondary GPU until the EDID can be read
from the LVDS panel. To support this add a notifier call chain to
vga_switcheroo for subscribing to switcheroo events. Events are
generated for registration and unregistration of handlers and clients.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 34 ++
include/linux/vga_switcheroo.h | 14 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e53f67d..d5cd274 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,28 @@ static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
};
+static BLOCKING_NOTIFIER_HEAD(vga_switcheroo_notifier_list);
+
+int vga_switcheroo_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&vga_switcheroo_notifier_list,
+ nb);
+}
+EXPORT_SYMBOL(vga_switcheroo_register_notifier);
+
+int vga_switcheroo_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&vga_switcheroo_notifier_list,
+ nb);
+}
+EXPORT_SYMBOL(vga_switcheroo_unregister_notifier);
+
+static int vga_switcheroo_notifier_call_chain(enum vga_switcheroo_event event)
+{
+ return blocking_notifier_call_chain(&vga_switcheroo_notifier_list,
+ event, NULL);
+}
+
static bool vga_switcheroo_ready(void)
{
/* we're ready if we get two clients + handler */
@@ -113,10 +136,18 @@ int vga_switcheroo_register_handler(struct
vga_switcheroo_handler *handler)
vga_switcheroo_enable();
}
mutex_unlock(&vgasr_mutex);
+
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_HANDLER_REGISTERED);
return 0;
}
EXPORT_SYMBOL(vga_switcheroo_register_handler);
+bool vga_switcheroo_handler_registered(void)
+{
+ return !!vgasr_priv.handler;
+}
+EXPORT_SYMBOL(vga_switcheroo_handler_registered);
+
void vga_switcheroo_unregister_handler(void)
{
mutex_lock(&vgasr_mutex);
@@ -127,6 +158,7 @@ void vga_switcheroo_unregister_handler(void)
vgasr_priv.active = false;
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_HANDLER_UNREGISTERED);
}
EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
@@ -156,6 +188,7 @@ static int register_client(struct pci_dev *pdev,
vga_switcheroo_enable();
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_CLIENT_REGISTERED);
return 0;
}
@@ -250,6 +283,7 @@ void vga_switcheroo_unregister_client(struct pci_dev *pdev)
vgasr_priv.active = false;
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_CLIENT_UNREGISTERED);
}
EXPORT_SYMBOL(vga_switcheroo_unregister_client);
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index e361858..c3d7c6f 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -11,6 +11,7 @@
#define _LINUX_VGA_SWITCHEROO_H_
#include
+#include
struct pci_dev;
@@ -28,6 +29,13 @@ enum vga_switcheroo_client_id {
VGA_SWITCHEROO_MAX_CLIENTS,
};
+enum vga_switcheroo_event {
+ VGA_SWITCHEROO_CLIENT_REGISTERED,
+ VGA_SWITCHEROO_CLIENT_UNREGISTERED,
+ VGA_SWITCHEROO_HANDLER_REGISTERED,
+ VGA_SWITCHEROO_HANDLER_UNREGISTERED,
+};
+
struct vga_switcheroo_handler {
int (*switch_ddc)(enum vga_switcheroo_client_id id);
int (*switchto)(enum vga_switcheroo_client_id id);
@@ -44,6 +52,9 @@ struct vga_switcheroo_client_ops {
};
#if defined(CONFIG_VGA_SWITCHEROO)
+int vga_switcheroo_register_notifier(struct notifier_block *nb);
+int vga_switcheroo_unregister_notifier(struct notifier_block *nb);
+bool vga_switcheroo_handler_registered(void);
void vga_switcheroo_unregister_client(struct pci_dev *dev);
int vga_switcheroo_register_client(struct pci_dev *dev,
const struct vga_switcheroo_client_ops *ops);
@@ -66,6 +77,9 @@ int vga_switcheroo_get_client_state(struct pci_dev *dev);
#else
+static inline int vga_switcheroo_register_notifier(struct notifier_block *nb)
{ return 0; }
+static inline int vga_switcheroo_unregister_notifier(struct notifier_block
*nb) { return 0; }
+static inline bool vga_switcheroo_handler_registered(void) { return false; }
static inline void vga_switcheroo_unregister_client(struct pci_dev *dev) {}
static inline int vga_switcheroo_register_client(struct pci_dev *dev,
const struct vga_switchero
[PATCH 0/7] Fixes for hybrid graphics Apple machines
Many hybrid graphics Apple laptops fail to set up LVDS on the secondary GPU due to missing or incorrect mode information for the panel at init time. The only way to get the LVDS mode on these machines is via the DDC, but this is muxed to the active GPU at boot. However, the graphics mux on these machines supports muxing the i2c idependently of the display, making it possible for the secondary graphics driver to read the EDID without a full display switch. In order to support this, these patches modify vga_switcheroo to allow muxing of the DDC idependently of the display. apple-gmux is updated to support this new functionality, and drm_get_edid() is modified to switch the DDC mux as needed. For this to work we also need to ensure that sufficient switcheroo suport is available before initializing the secondary GPU. This is done by adding any non-active GPUs that try to initialize before switcheroo is ready to a list and initializing these devices once switcheroo becomes ready. This behavior is restricted to Apple laptops to prevent causing problems on other machines. Thanks, Seth Seth Forshee (7): vga_switcheroo: Add support for switching only the DDC vga_switcheroo: Add helper function to get the active client vga_switcheroo: Add notifier call chain for switcheroo events apple-gmux: Add switch_ddc support drm/edid: Switch DDC when reading the EDID drm/pci: Add drm_put_pci_dev() drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready drivers/gpu/drm/ast/ast_drv.c |2 +- drivers/gpu/drm/cirrus/cirrus_drv.c |2 +- drivers/gpu/drm/drm_drv.c |3 + drivers/gpu/drm/drm_edid.c| 17 drivers/gpu/drm/drm_pci.c | 172 + drivers/gpu/drm/gma500/psb_drv.c |2 +- drivers/gpu/drm/i915/i915_drv.c |2 +- drivers/gpu/drm/mgag200/mgag200_drv.c |2 +- drivers/gpu/drm/nouveau/nouveau_drv.c |2 +- drivers/gpu/drm/radeon/radeon_drv.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +- drivers/gpu/vga/vga_switcheroo.c | 87 - drivers/platform/x86/apple-gmux.c | 12 ++- include/drm/drmP.h|3 + include/linux/vga_switcheroo.h| 20 15 files changed, 302 insertions(+), 28 deletions(-)
[PATCH 1/7] vga_switcheroo: Add support for switching only the DDC
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM to mux
only the DDC.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 39 +-
include/linux/vga_switcheroo.h |4
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e25cf31..ea6bcc2 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -252,6 +252,29 @@ void vga_switcheroo_client_fb_set(struct pci_dev *pdev,
}
EXPORT_SYMBOL(vga_switcheroo_client_fb_set);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev)
+{
+ int ret = 0;
+ int id;
+
+ mutex_lock(&vgasr_mutex);
+
+ if (!vgasr_priv.handler) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (vgasr_priv.handler->switch_ddc) {
+ id = vgasr_priv.handler->get_client_id(pdev);
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+
+out:
+ mutex_unlock(&vgasr_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(vga_switcheroo_switch_ddc);
+
static int vga_switcheroo_show(struct seq_file *m, void *v)
{
struct vga_switcheroo_client *client;
@@ -342,9 +365,15 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
}
+ if (vgasr_priv.handler->switch_ddc) {
+ ret = vgasr_priv.handler->switch_ddc(new_client->id);
+ if (ret)
+ return ret;
+ }
+
ret = vgasr_priv.handler->switchto(new_client->id);
if (ret)
- return ret;
+ goto restore_ddc;
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
@@ -356,6 +385,14 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
new_client->active = true;
return 0;
+
+restore_ddc:
+ if (vgasr_priv.handler->switch_ddc) {
+ int id = (new_client->id == VGA_SWITCHEROO_IGD) ?
+ VGA_SWITCHEROO_DIS : VGA_SWITCHEROO_IGD;
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+ return ret;
}
static bool check_can_switch(void)
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index ddb419c..b0d0839 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -29,6 +29,7 @@ enum vga_switcheroo_client_id {
};
struct vga_switcheroo_handler {
+ int (*switch_ddc)(enum vga_switcheroo_client_id id);
int (*switchto)(enum vga_switcheroo_client_id id);
int (*power_state)(enum vga_switcheroo_client_id id,
enum vga_switcheroo_state state);
@@ -53,6 +54,8 @@ int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
void vga_switcheroo_client_fb_set(struct pci_dev *dev,
struct fb_info *info);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev);
+
int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler);
void vga_switcheroo_unregister_handler(void);
@@ -66,6 +69,7 @@ static inline void vga_switcheroo_unregister_client(struct
pci_dev *dev) {}
static inline int vga_switcheroo_register_client(struct pci_dev *dev,
const struct vga_switcheroo_client_ops *ops) { return 0; }
static inline void vga_switcheroo_client_fb_set(struct pci_dev *dev, struct
fb_info *info) {}
+static inline void vga_switcheroo_switch_ddc(struct pci_dev *pdev) { return
NULL; }
static inline int vga_switcheroo_register_handler(struct
vga_switcheroo_handler *handler) { return 0; }
static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
const struct vga_switcheroo_client_ops *ops,
--
1.7.9.5
[PATCH 2/7] vga_switcheroo: Add helper function to get the active client
Add vga_switcheroo_get_active_client() to allow drivers to get the
active video client. This will be used by drivers wishing to temporarily
mux only the DDC to the inactive client.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 14 ++
include/linux/vga_switcheroo.h |2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index ea6bcc2..e53f67d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -205,6 +205,20 @@ find_active_client(struct list_head *head)
return NULL;
}
+struct pci_dev *vga_switcheroo_get_active_client(void)
+{
+ struct vga_switcheroo_client *client;
+ struct pci_dev *pdev = NULL;
+
+ mutex_lock(&vgasr_mutex);
+ client = find_active_client(&vgasr_priv.clients);
+ if (client)
+ pdev = client->pdev;
+ mutex_unlock(&vgasr_mutex);
+ return pdev;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_active_client);
+
int vga_switcheroo_get_client_state(struct pci_dev *pdev)
{
struct vga_switcheroo_client *client;
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index b0d0839..e361858 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -61,6 +61,7 @@ void vga_switcheroo_unregister_handler(void);
int vga_switcheroo_process_delayed_switch(void);
+struct pci_dev *vga_switcheroo_get_active_client(void);
int vga_switcheroo_get_client_state(struct pci_dev *dev);
#else
@@ -76,6 +77,7 @@ static inline int vga_switcheroo_register_audio_client(struct
pci_dev *pdev,
int id, bool active) { return 0; }
static inline void vga_switcheroo_unregister_handler(void) {}
static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
+static inline struct pci_dev *vga_switcheroo_get_active_client(void) { return
NULL; }
static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) {
return VGA_SWITCHEROO_ON; }
--
1.7.9.5
[PATCH 4/7] apple-gmux: Add switch_ddc support
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a VBT
or have invalid mode data in the VBT.
Signed-off-by: Seth Forshee
---
drivers/platform/x86/apple-gmux.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index dfb1a92..d1e372d 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -269,14 +269,21 @@ static const struct backlight_ops gmux_bl_ops = {
.update_status = gmux_update_status,
};
+static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
+{
+ if (id == VGA_SWITCHEROO_IGD)
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+ else
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+ return 0;
+}
+
static int gmux_switchto(enum vga_switcheroo_client_id id)
{
if (id == VGA_SWITCHEROO_IGD) {
- gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
} else {
- gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
}
@@ -343,6 +350,7 @@ gmux_active_client(struct apple_gmux_data *gmux_data)
}
static struct vga_switcheroo_handler gmux_handler = {
+ .switch_ddc = gmux_switch_ddc,
.switchto = gmux_switchto,
.power_state = gmux_set_power_state,
.get_client_id = gmux_get_client_id,
--
1.7.9.5
[PATCH 5/7] drm/edid: Switch DDC when reading the EDID
Some dual graphics machines support muxing the DDC separately from the
display, so make use of this functionality when reading the EDID on the
inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races
on the DDC mux state.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_edid.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..b389269 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_edid_modes.h"
@@ -82,6 +83,8 @@ struct detailed_mode_closure {
#define LEVEL_GTF2 2
#define LEVEL_CVT 3
+static DEFINE_MUTEX(drm_edid_mutex);
+
static struct edid_quirk {
char vendor[4];
int product_id;
@@ -398,12 +401,26 @@ struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid = NULL;
+ struct pci_dev *pdev = connector->dev->pdev;
+ struct pci_dev *active_pdev = NULL;
+
+ mutex_lock(&drm_edid_mutex);
+
+ if (pdev) {
+ active_pdev = vga_switcheroo_get_active_client();
+ if (active_pdev != pdev)
+ vga_switcheroo_switch_ddc(pdev);
+ }
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (active_pdev && active_pdev != pdev)
+ vga_switcheroo_switch_ddc(active_pdev);
+
connector->display_info.raw_edid = (char *)edid;
+ mutex_unlock(&drm_edid_mutex);
return edid;
}
--
1.7.9.5
[PATCH 6/7] drm/pci: Add drm_put_pci_dev()
When deferred initialization support for pci devices is added some
additional cleanup will be needed. Add a pci-specific put function to
serve this purpose, and convert the pci drivers over to using it. For
now it just calls drm_put_dev(), so this commit has no functional
change.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/ast/ast_drv.c |2 +-
drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-
drivers/gpu/drm/drm_pci.c |8 +++-
drivers/gpu/drm/gma500/psb_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/mgag200/mgag200_drv.c |2 +-
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drmP.h|1 +
10 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index d0c4574..001298d 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -72,7 +72,7 @@ ast_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 7053140..c7ca02b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -64,7 +64,7 @@ static void cirrus_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct file_operations cirrus_driver_fops = {
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 5320364..55eb824 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -388,6 +388,12 @@ err_g1:
}
EXPORT_SYMBOL(drm_get_pci_dev);
+void drm_put_pci_dev(struct drm_device *dev)
+{
+ drm_put_dev(dev);
+}
+EXPORT_SYMBOL(drm_put_pci_dev);
+
/**
* PCI device initialization. Called direct from modules at load time.
*
@@ -460,7 +466,7 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
pci_unregister_driver(pdriver);
} else {
list_for_each_entry_safe(dev, tmp, &driver->device_list,
driver_item)
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
DRM_INFO("Module unloaded\n");
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 0c47374..d7c3c9c 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -585,7 +585,7 @@ static void psb_driver_preclose(struct drm_device *dev,
struct drm_file *priv)
static void psb_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct dev_pm_ops psb_pm_ops = {
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a24ffbe..86ae5a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -856,7 +856,7 @@ i915_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static int i915_pm_suspend(struct device *dev)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index ea1024d..a3b0a4a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -73,7 +73,7 @@ static void mga_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct file_operations mgag200_driver_fops = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 9a36f5f..b74b02a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -168,7 +168,7 @@ nouveau_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
int
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 8c593ea..05d2ebc 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -310,7 +310,7 @@ radeon_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static int
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4d9edea..cf901cc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -982,7 +982,7 @@ static void vmw_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm
[PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
Many Apple laptops with hybrid graphics require switching the i2c mux to
the integrated GPU when that device is being initialized in order to get
correct mode information for the LVDS panel. This requires that switcheroo
is ready at the time the device is initialized, which is not guaranteed.
To support this, delay calling the driver load() callback until the
vga_switcheroo handler and active client have been registered. This is
restricted to Apple notebooks via DMI data to avoid causing problems on
machines without switcheroo support.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_drv.c |3 +
drivers/gpu/drm/drm_pci.c | 164 -
include/drm/drmP.h|2 +
3 files changed, 153 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..124fd8a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -276,6 +276,8 @@ static int __init drm_core_init(void)
goto err_p3;
}
+ drm_pci_module_init();
+
DRM_INFO("Initialized %s %d.%d.%d %s\n",
CORE_NAME, CORE_MAJOR, CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
return 0;
@@ -291,6 +293,7 @@ err_p1:
static void __exit drm_core_exit(void)
{
+ drm_pci_module_exit();
remove_proc_entry("dri", NULL);
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 55eb824..a5c9068 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -40,6 +40,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include "drmP.h"
/**/
@@ -297,19 +301,8 @@ static struct drm_bus drm_pci_bus = {
.agp_init = drm_pci_agp_init,
};
-/**
- * Register.
- *
- * \param pdev - PCI device structure
- * \param ent entry from the PCI ID table with device type flags
- * \return zero on success or a negative number on failure.
- *
- * Attempt to gets inter module "drm" information. If we are first
- * then register the character device and inter module information.
- * Try and register, if we fail to register, backout previous work.
- */
-int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
- struct drm_driver *driver)
+int __drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
+ struct drm_driver *driver)
{
struct drm_device *dev;
int ret;
@@ -334,8 +327,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
dev->hose = pdev->sysdata;
#endif
- mutex_lock(&drm_global_mutex);
-
if ((ret = drm_fill_in_dev(dev, ent, driver))) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
goto err_g2;
@@ -371,7 +362,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
driver->name, driver->major, driver->minor, driver->patchlevel,
driver->date, pci_name(pdev), dev->primary->index);
- mutex_unlock(&drm_global_mutex);
return 0;
err_g4:
@@ -386,10 +376,140 @@ err_g1:
mutex_unlock(&drm_global_mutex);
return ret;
}
+
+/*
+ * List of machines that require delaying initialization of the secondary
+ * GPU until vga_switcheroo is ready.
+ */
+static struct dmi_system_id deferred_init_dmi_table[] = {
+ {
+ .ident = "Apple Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
+ },
+ },
+};
+
+struct deferred_init_data {
+ struct list_head list;
+ struct pci_dev *pdev;
+ const struct pci_device_id *ent;
+ struct drm_driver *driver;
+};
+
+static LIST_HEAD(deferred_init_list);
+
+static bool drm_pci_switcheroo_ready(void)
+{
+ if (!vga_switcheroo_handler_registered())
+ return false;
+ if (!vga_switcheroo_get_active_client())
+ return false;
+ return true;
+}
+
+static void drm_deferred_init_work_fn(struct work_struct *work)
+{
+ struct deferred_init_data *di_data, *temp;
+
+ mutex_lock(&drm_global_mutex);
+
+ if (!drm_pci_switcheroo_ready()) {
+ mutex_unlock(&drm_global_mutex);
+ return;
+ }
+
+ list_for_each_entry_safe(di_data, temp, &deferred_init_list, list) {
+ if (__drm_get_pci_dev(di_data->pdev, di_data->ent,
+ di_data->driver))
+ DRM_ERROR("pci device initialization failed\n");
+ list_del(&di_data->list);
+ kfree(di_data);
+ }
+ mutex_unlock(&drm_global_mutex);
+}
+static DECLARE_WORK(deferred_init_work, drm_deferred_init_work_fn);
+
+static int drm_
Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support
2012/9/7 Inki Dae : > Hi > > 2012/9/7 Leela Krishna Amudala : >> Hi, >> >> On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki >> wrote: >>> Hi, >>> >>> On 09/06/2012 09:21 AM, InKi Dae wrote: >> +Required properties: >> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" >> for > Doesn't better to use single word? fimd or fb?. I think 'fb' is used > for framebuffer historically. > but now it's used both fb and drm, so fimd is neutral and architecture > specific. > > To do this, Modify arch-exynos first and update it at each drivers it > properly. > > Thank you, > Kyungmin Park > I agree with Kyungmin but I'd like to use as is. the reason we used 'exynos4-fb' as device name, is for that it uses fimd driver's platform device commonly and gets fimd clock. so I think that dts file should be defined with hardware specific name but not driver name such as 'exynos4-fb'. but with this, we can't get fimd clock with device's name because 'exynos4-fb' is used as device name of fimd clock. so to use 'exynos4-fimd', we should modify the device name of fimd clock from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of s3c-fb and drm fimd driver. so my conclusion is that it merges this >>> >>> I think it's good moment to put those things in order, i.e. use uniform >>> 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". >>> Platform device names are separate issue, but could perhaps be unified >>> at this time as well. >> >> Yes, Platform device name is independent of compatible string. >> Will change the compatible string to "samsung,exynos4-fimd" and will keep the >> device name as exynos4-fb for now. Will change the platform device >> names to exynosX-fimd >> later. >> > > I'm not sure that clk_get is worked well with this change. I think, > when driver called clk_get(), first of all, it tries to get a clk from > the registered list of clock providers in the dts file and next in > legacy way. but now legacy way(needing clock name and device' name) > would be failed if the dts file has no the list because platform > device's name differs from device name of clock. so I think we should > change device name of clock and also ids of related drivers for > compatibility with non-dt. for this, we need some patch sets, changing > arch/arm/mach-exynos/common.c and changing > arch/arm/mach-exynos/clock-exynos4/5.c and changing s3c-fb.c and last > this patch. if there are no other opinions, I'd like to merge this > patch set(v5) and next we can update others(maybe common.c, > clock-exynos4/5.c and s3c-fb.c) later. > there is my missing point. with dt, platform device's name is set by OF_DEV_AUXDATA's name so it doesn't need to modify things related to exynos4 anymore. we just need to update things related to exynos5. Thanks. Inki Dae > Thanks. > Inki Dae > >>> patch set as is and then let's modify related things later. any opinions, welcome~ anytime. Thanks. Inki Dae >>> >>> -- >>> >>> Regards, >>> Sylwester >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-samsung-soc" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> ___ >> 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 V5 0/2] video: drm: Add Device tree support to DRM-FIMD
Applied. Thanks. Inki Dae 2012/9/7 Leela Krishna Amudala : > This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. > It includes parsing platform data from dts file. Also, adds the driver data > for exynos4 and exynos5 devices. > > This patchset is based and tested on top of v3.6-rc4 on smdk5250 board > Also depends on below patchset > http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html > > Changes since V4: > - Changed the compatible string from "samsung,exynos4-fb" to > "samsung,exynos4-fimd". > > Changes since V3: > - Removed the fimd version from driver data and using timing base > address instead > - Removed the drm_ prefixes to the structures and fucntions > > Changes since V2: > - Added driver data to exynos5-drm-fimd as per Marek Szyprowski > suggestion > > Changes since V1: > - Corrected typo errors and changed compatibility string > > Leela Krishna Amudala (2): > drm/exynos: add platform_device_id table and driver data for drm fimd > video: drm: exynos: Add device tree support > > Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 138 > - > 2 files changed, 212 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote: > From: Michel Dänzer > Date: Thu, 06 Sep 2012 18:55:51 +0200 > >> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: >>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in >>> Ultra 10 (clean, without my "Video RAM" hack that I talked in other >>> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the >>> kernel, I compiled radeon drm driver with modesetting enabled and tried >>> it: >>> >>> [drm] radeon defaulting to kernel modesetting. >>> [drm] radeon kernel modesetting enabled. >>> PCI: Enabling device: (:02:02.0), cmd 82 >>> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). >>> [drm] register mmio base: 0x1000 >>> [drm] register mmio size: 32768 >>> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR >>> >>> And here the machine hangs. Debugging printk-s reveal that it does not >>> find any active I/O port resources and then continues into initializing >>> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >>> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >>> 2 bytes from there and hangs on reading bios[0]. >> >> Is the card initialized by OpenFirmware? E.g., does it display anything >> before the kernel boots? > > I think Meelis gave you every single detail you need to know to > analyze and fix this bug. > > He says it crashes on reading bios[0]. > > If you look at the function he tells you the crash occurs in, you'll > see clearly that bios is an ioremap()'d pointer. > > You cannot dereference ioremap()'d pointers, you must use the proper > accessors such as readl(). we should just skip the igp reading function on not-x86, since IGP on not x86 makes no sense. the other option is to readl out the whole bios from vram instead. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: remove DRM_FORMAT_NV12M from plane module
this patch removes DRM_FORMAT_NV12M from plane module because this format
is same as DRM_FORMAT_NV12. DRM_FORMAT_NV12M will be identified by
mode_cmd->handles and mode_cmd->offsets fields internally.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin.park
---
drivers/gpu/drm/exynos/exynos_drm_plane.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index b89829e..e1f94b7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -29,7 +29,6 @@ static const uint32_t formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_NV12,
- DRM_FORMAT_NV12M,
DRM_FORMAT_NV12MT,
};
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb helper: don't call drm_helper_connector_dpms directly
Yet again a case where the fb helper is too intimate with the crtc
helper and calls a crtc helepr function directly instead of going
through the interface vtable.
This fixes console blanking in drm/i915 with the new i915-specific
modeset code.
Reported-by: Jesse Barnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index eb79515..b5d05f5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -330,7 +330,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
/* Walk the connectors & encoders on this fb turning them
on/off */
for (j = 0; j < fb_helper->connector_count; j++) {
connector = fb_helper->connector_info[j]->connector;
- drm_helper_connector_dpms(connector, dpms_mode);
+ connector->funcs->dpms(connector, dpms_mode);
drm_connector_property_set_value(connector,
dev->mode_config.dpms_property, dpms_mode);
}
--
1.7.11.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #51 from Zoltán Böszörményi 2012-09-07 10:08:21 UTC --- I saw this: commit 5ceb87286f2e1b5b8527ba18a844abf450903175 Author: Jerome Glisse Date: Wed Sep 5 15:18:24 2012 -0400 r600g: order atom emission v3 To avoid GPU lockup registers must be emited in a specific order (no kidding ...). This patch rework atom emission so order in which atom are emited in respect to each other is always the same. We don't have any informations on what is the correct order so order will need to be infered from fglrx command stream. v2: add comment warning that atom order should not be taken lightly v3: rebase on top of alphatest atom fix Signed-off-by: Jerome Glisse Does this mean the htile patch may also be committed without causing lockups? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 53490] [bisected] bump map corruption from kernel 3.5
https://bugs.freedesktop.org/show_bug.cgi?id=53490 Joeri Capens changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #14 from Joeri Capens 2012-09-07 12:10:45 UTC --- I re-compiled mesa again (the "8.1_rc1_pre20120724" git snapshot provided by Gentoo, to be exact) and this time the bump map corruption does not occur anymore, with or without my kernel patch. I tried some recent mesa versions before, but I must have made mistakes while copying the mesa libraries from a 32-bit chroot to the /usr/lib32/ directory on my 64-bit system. Somewhere between mesa 8.0.4 and the snapshot of 2012-07-24, the bug has already been fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 54649] New: Image in Quake 3 is dark
https://bugs.freedesktop.org/show_bug.cgi?id=54649 Bug #: 54649 Summary: Image in Quake 3 is dark Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: js314...@gmail.com Image in Quake 3 is dark. Changing of brightness has no effect. name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on i915 (chipset: G33) OpenGL version string: 2.1 Mesa 9.0-devel OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_fog_distance, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_primitive_restart, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, GL_EXT_pixel_buffer_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_ARB_framebuffer_object, GL_EXT_fram
[Bug 54649] Image in Quake 3 is dark
https://bugs.freedesktop.org/show_bug.cgi?id=54649 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se --- Comment #1 from Sven Arvidsson 2012-09-07 17:54:42 UTC --- Are you sure this is a driver bug? Sounds like: http://bugzilla.libsdl.org/show_bug.cgi?id=971 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
[PATCH] drm/omap: add more new timings fields
From: Rob Clark Without these, DVI is broken. Signed-off-by: Rob Clark --- Greg, it looks like the omapdss changes which added these fields, as well as the interlaced field, where merged in Linux 3.5-rc5. So I think both this and the 'update for interlaced' patch are needed for both 3.6 and 3.5. drivers/staging/omapdrm/omap_connector.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 5f4a89b..55e9c86 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -52,6 +52,16 @@ static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode, if (timings->interlace) mode->flags |= DRM_MODE_FLAG_INTERLACE; + + if (timings->hsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PHSYNC; + else + mode->flags |= DRM_MODE_FLAG_NHSYNC; + + if (timings->vsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PVSYNC; + else + mode->flags |= DRM_MODE_FLAG_NVSYNC; } static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, @@ -70,6 +80,20 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, timings->vbp = mode->vtotal - mode->vsync_end; timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE); + + if (mode->flags & DRM_MODE_FLAG_PHSYNC) + timings->hsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->hsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + if (mode->flags & DRM_MODE_FLAG_PVSYNC) + timings->vsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->vsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE; + timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH; + timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES; } static void omap_connector_dpms(struct drm_connector *connector, int mode) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53511] r600g llvm backend doesn't support indirect addressing
https://bugs.freedesktop.org/show_bug.cgi?id=53511 --- Comment #1 from almos 2012-09-07 18:05:39 UTC --- I see that testing is the first item on the r600todo list, and to see if there are any differences between the two shader compilers. Maybe this should be a prerequisite of that, because most of the shader-heavy applications hit this fallback. BTW I don't see any performance difference between the two compilers on my hd6850 apart from what I reported in bug 51787 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #32 from diego.abele...@gmail.com 2012-09-07 19:19:10 UTC --- Created attachment 66808 --> https://bugs.freedesktop.org/attachment.cgi?id=66808 dmesg booting with 2 monitors plugged drm.debug=4 This drm-fixes-3.6 branch just gives me two black screens when I have them both plugged during the boot. And when X starts I get a 100% processor usage from the X process and nothing displayed. The Xorg.0.log shows nothing out of the ordinary. But I think there is something really wrong because my X server never starts accepting connection from my login manager. When I boot with only the DVI screen plugged, no problem it boots fine. After having booted with only the DVI plugging the VGA one works just like before. When X puts my screens into DPMS off and I try to wake them up, the VGA goes back on correctly with this branch whereas it didn't with vanilla kernel. So there are some good points and some bad points. Attached is dmesg | grep -e drm -e radeon when both screens are connected, after X is "started". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #33 from Alex Deucher 2012-09-07 19:35:20 UTC --- You might try this patch on top of my 3.6 fixees tree: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=46b417b3eee694451b5bca8a7863e9174611a2e9 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #34 from diego.abele...@gmail.com 2012-09-07 21:07:16 UTC --- Created attachment 66817 --> https://bugs.freedesktop.org/attachment.cgi?id=66817 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 With the additional patch, I get the DVI screen displaying things when both a plugged-in but the VGA one now says there is no signal (instead of staying black). So the behavior is somewhat similar to the vanilla kernel in that regard. Booting with the VGA unplugged and plugging it later gives the same behavior as without that patch (i.e. better than the vanilla kernel). Attached is the dmesg | grep -e drm -e radeon when the 2 screens are plugged and the VGA says no signal. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abele...@gmail.com changed: What|Removed |Added Attachment #66817|application/octet-stream|text/plain mime type|| --- Comment #35 from diego.abele...@gmail.com 2012-09-07 21:08:26 UTC --- Comment on attachment 66817 --> https://bugs.freedesktop.org/attachment.cgi?id=66817 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Sorry wrong auto-detect of the type... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abele...@gmail.com changed: What|Removed |Added Attachment #66817|0 |1 is obsolete|| --- Comment #36 from diego.abele...@gmail.com 2012-09-07 21:11:53 UTC --- Created attachment 66819 --> https://bugs.freedesktop.org/attachment.cgi?id=66819 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Sorry... I appended the new log to the last one instead of overwriting it... Now there is only the new dmesg information. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 diego.abele...@gmail.com changed: What|Removed |Added Attachment #66819|0 |1 is obsolete|| --- Comment #37 from diego.abele...@gmail.com 2012-09-07 21:28:26 UTC --- Created attachment 66822 --> https://bugs.freedesktop.org/attachment.cgi?id=66822 dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 Ok I need sleep... This time is the right dmesg. With both screens plugged during the boot and the patch, but mysteriously this time the DVI screen stayed black and the VGA had no link. And X started to take 100% CPU. So exactly the same behavior as without the patch. I tried rebooting and then both screens lit up and were black. X using 100% CPU. the new attachment shows dmesg | grep -e drm -e radeon after both attempts. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm/fb helper: don't call drm_helper_connector_dpms directly
On Fri, 7 Sep 2012 10:14:52 +0200
Daniel Vetter wrote:
> Yet again a case where the fb helper is too intimate with the crtc
> helper and calls a crtc helepr function directly instead of going
> through the interface vtable.
>
> This fixes console blanking in drm/i915 with the new i915-specific
> modeset code.
>
> Reported-by: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index eb79515..b5d05f5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -330,7 +330,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> /* Walk the connectors & encoders on this fb turning them
> on/off */
> for (j = 0; j < fb_helper->connector_count; j++) {
> connector = fb_helper->connector_info[j]->connector;
> - drm_helper_connector_dpms(connector, dpms_mode);
> + connector->funcs->dpms(connector, dpms_mode);
> drm_connector_property_set_value(connector,
> dev->mode_config.dpms_property, dpms_mode);
> }
Tested-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] Fixes for hybrid graphics Apple machines
On Fri, Sep 7, 2012 at 4:22 PM, Seth Forshee wrote: > Many hybrid graphics Apple laptops fail to set up LVDS on the secondary > GPU due to missing or incorrect mode information for the panel at init > time. The only way to get the LVDS mode on these machines is via the > DDC, but this is muxed to the active GPU at boot. However, the graphics > mux on these machines supports muxing the i2c idependently of the > display, making it possible for the secondary graphics driver to read > the EDID without a full display switch. > > In order to support this, these patches modify vga_switcheroo to allow > muxing of the DDC idependently of the display. apple-gmux is updated to > support this new functionality, and drm_get_edid() is modified to switch > the DDC mux as needed. > > For this to work we also need to ensure that sufficient switcheroo > suport is available before initializing the secondary GPU. This is done > by adding any non-active GPUs that try to initialize before switcheroo > is ready to a list and initializing these devices once switcheroo > becomes ready. This behavior is restricted to Apple laptops to prevent > causing problems on other machines. I hate this idea, no delaying stuff. We either need to have some sort of enforced ordering or make some stuff only work built-in. But sticking things on a delayed list just in case seems wrong to me. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #38 from Alex Deucher 2012-09-07 21:52:32 UTC --- You're getting a GPU hang for some reason which may be causing the modeset failure. Can you try with acceleration disabled to take the out of the equation? Try adding: Option "NoAccel" "TRUE" to the device section of your xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm/fb helper: don't call drm_helper_connector_dpms directly
On Fri, Sep 07, 2012 at 02:28:28PM -0700, Jesse Barnes wrote:
> On Fri, 7 Sep 2012 10:14:52 +0200
> Daniel Vetter wrote:
>
> > Yet again a case where the fb helper is too intimate with the crtc
> > helper and calls a crtc helepr function directly instead of going
> > through the interface vtable.
> >
> > This fixes console blanking in drm/i915 with the new i915-specific
> > modeset code.
> >
> > Reported-by: Jesse Barnes
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index eb79515..b5d05f5 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -330,7 +330,7 @@ static void drm_fb_helper_dpms(struct fb_info *info,
> > int dpms_mode)
> > /* Walk the connectors & encoders on this fb turning them
> > on/off */
> > for (j = 0; j < fb_helper->connector_count; j++) {
> > connector = fb_helper->connector_info[j]->connector;
> > - drm_helper_connector_dpms(connector, dpms_mode);
> > + connector->funcs->dpms(connector, dpms_mode);
> > drm_connector_property_set_value(connector,
> > dev->mode_config.dpms_property, dpms_mode);
> > }
>
> Tested-by: Jesse Barnes
Applied with Dave's irc-ack, thanks for yelling&testing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libkms: link against libdrm
Signed-off-by: Marcin Slusarz --- libkms/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libkms/Makefile.am b/libkms/Makefile.am index fa379a4..215450a 100644 --- a/libkms/Makefile.am +++ b/libkms/Makefile.am @@ -6,7 +6,7 @@ AM_CFLAGS = \ libkms_la_LTLIBRARIES = libkms.la libkms_ladir = $(libdir) libkms_la_LDFLAGS = -version-number 1:0:0 -no-undefined -libkms_la_LIBADD = +libkms_la_LIBADD = ../libdrm.la #if HAVE_LIBUDEV #libkms_la_LIBADD += $(LIBUDEV_LIBS) -- 1.7.12 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6] drm: edid: add support for E-DDC
Hi Dave,
Gentle Reminder!
This patch is required for passing the very first test case of HDMI
Compliance test suite.
Regards,
Shirish S
On Mon, Sep 3, 2012 at 8:54 AM, Shirish S wrote:
> Hello Dave,
>
> My patch-set for adding support for 4 block EDID is now reviewed and ready.
> Please let me know if you want any further clarification
>
> Regards,
> Shirish S
>
>
> On Thu, Aug 30, 2012 at 12:04 AM, Shirish S wrote:
>
>> The current logic for probing ddc is limited to
>> 2 blocks (256 bytes), this patch adds support
>> for the 4 block (512) data.
>>
>> To do this, a single 8-bit segment index is
>> passed to the display via the I2C address 30h.
>> Data from the selected segment is then immediately
>> read via the regular DDC2 address using a repeated
>> I2C 'START' signal.
>>
>> Signed-off-by: Shirish S
>> Reviewed-by: Jean Delvare
>> Reviewed-by: Daniel Vetter
>> Reviewed-by: Ville Syrjala
>> ---
>> drivers/gpu/drm/drm_edid.c | 19 ---
>> 1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index bcc4725..7f62de5 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> int block, int len)
>> {
>> unsigned char start = block * EDID_LENGTH;
>> + unsigned char segment = block >> 1;
>> + unsigned char xfers = segment ? 3 : 2;
>> int ret, retries = 5;
>>
>> /* The core i2c driver will automatically retry the transfer if
>> the
>> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> do {
>> struct i2c_msg msgs[] = {
>> {
>> + .addr = DDC_SEGMENT_ADDR,
>> + .flags = 0,
>> + .len= 1,
>> + .buf= &segment,
>> + }, {
>> .addr = DDC_ADDR,
>> .flags = 0,
>> .len= 1,
>> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
>> unsigned char *buf,
>> .buf= buf,
>> }
>> };
>> - ret = i2c_transfer(adapter, msgs, 2);
>> +
>> + /*
>> +* Avoid sending the segment addr to not upset non-compliant ddc
>> +* monitors.
>> +*/
>> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>> +
>> if (ret == -ENXIO) {
>> DRM_DEBUG_KMS("drm: skipping non-existent adapter
>> %s\n",
>> adapter->name);
>> break;
>> }
>> - } while (ret != 2 && --retries);
>> + } while (ret != xfers && --retries);
>>
>> - return ret == 2 ? 0 : -1;
>> + return ret == xfers ? 0 : -1;
>> }
>>
>> static bool drm_edid_is_zero(u8 *in_edid, int length)
>> --
>> 1.7.0.4
>>
>> ___
>> 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
[PATCH] drm: remove property_blob_list
From: Rob Clark
It isn't used anywhere.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |2 --
include/drm/drm_crtc.h |1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7552675..21a0a85 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -995,7 +995,6 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.connector_list);
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
- INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
@@ -3114,7 +3113,6 @@ static struct drm_property_blob
*drm_property_create_blob(struct drm_device *dev
memcpy(blob->data, data, length);
- list_add_tail(&blob->head, &dev->mode_config.property_blob_list);
return blob;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1422b36..a3574d0d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -794,7 +794,6 @@ struct drm_mode_config {
struct delayed_work output_poll_work;
/* pointers to standard properties */
- struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54662] New: [bisected] Kernel 3.6 breaks KMS on Radeon RV530 (black screen)
https://bugs.freedesktop.org/show_bug.cgi?id=54662 Bug #: 54662 Summary: [bisected] Kernel 3.6 breaks KMS on Radeon RV530 (black screen) Classification: Unclassified Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: skitch...@apache.org Created attachment 66826 --> https://bugs.freedesktop.org/attachment.cgi?id=66826 Dmesg output from a kernel that does not show black screen problem The following commit (merged in 3.6 rc series) makes the screen go black immediately after Plymouth completes (ie just before greeter screen): 876dc9f32907e57e0298bcd0f1607cb7a2582f63 is the first bad commit commit 876dc9f32907e57e0298bcd0f1607cb7a2582f63 Author: Christian König Date: Tue May 8 14:24:01 2012 +0200 drm/radeon: remove radeon_fence_create Note that this is a different bug than https://bugs.freedesktop.org/show_bug.cgi?id=54129 (which I'm also getting) but might be related. The same kernel boots without problems using "nomodeset". System is an x86-32 laptop (about 5 years old) with Radeon mobility X1600, running Ubuntu 12.04. lspci reports: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI M56P [Radeon Mobility X1600] Attached is full dmesg output from a *different* (ie earlier, working) kernel. Some relevant bits include: [2.978637] [drm] Initialized drm 1.1.0 20060810 [3.052940] [drm] radeon defaulting to kernel modesetting. [3.052945] [drm] radeon kernel modesetting enabled. [3.053261] [drm] initializing kernel modesetting (RV530 0x1002:0x71C5 0x103C:0x30A3). .. [3.245417] [drm] Loading R500 Microcode [3.247401] [drm] radeon: ring at 0x10001000 [3.247441] [drm] ring test succeeded in 9 usecs ... [4.064745] [drm] Initialized radeon 2.17.0 20080528 for :01:00.0 on minor 0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129
Simon Kitching changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
||g/show_bug.cgi?id=54662
--- Comment #9 from Simon Kitching 2012-09-08 06:48:22
UTC ---
Sorry, have to take back that comment about 3.6-rc4+ working; I'm now getting
the "black screen" problem consistently. I was definitely running the right
kernel ("uname -a" was reporting 3.6-rc4+) and can only think that I
accidentally fat-fingered the keyboard and selected the grub "recovery" option
(ie with "nomodeset").
In short: 3.6-rc4+ just boots to a totally black screen for me, due to
something merged in the 3.6-rc series. I've bisected this, and raised a
separate bug (54662) for it. Interestingly, that commit is *also* about "radeon
fence" handling.
I presume that this bug (54129) is still also present and lurking underneath
the black screen - but obviously I can't test that.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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
