[Intel-gfx] Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Wed, Sep 25, 2013 at 05:48:06PM +0200, Daniel Vetter wrote: > On Wed, Sep 25, 2013 at 06:34:38PM +0300, Michael S. Tsirkin wrote: > > On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote: > > > On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote: > > > > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin > > > redhat.com> wrote: > > > > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > > > > >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > > > > >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > > > > >> > > > > > >> > Hi, > > > > >> > > > > > >> > saw your posting in [1]... can you try the patches below? > > > > >> > Not sure if they apply. > > > > >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? > > > > >> > > > > > >> > Regards, > > > > >> > - Sedat - > > > > >> > > > > > >> > [1] > > > > >> > http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > > > > >> > > > > >> Same thing observed with v3.11-rc7. > > > > > > > > > > I still see this with 3.11. > > > > > Following this message, my VGA monitor goes blank and > > > > > shows an error suggesting a wrong resolution or frequency are set. > > > > > Anyone? > > > > > > > > Daniel, Jesse? > > > > > > > > still ongoing I think. > > > > > > Yeah, I've dismissed it since the original issue in this thread is > > > resolved. But it's something else. > > > > > > Note to bug reporters: Please don't me-too, but start a new thread/report > > > - almost every gfx bug is different, even if it superficially looks the > > > same. > > > > > > Michael, can you please boot with drm.debug=0xe, reproduce the problem and > > > then attach the complete dmesg? Please make sure dmesg contains everything > > > since boot-up, if not please increase the dmesg buffer size with > > > log_buf_len=4M. > > > > Complete dmesg attached. > > > > > Also please test the latest drm-intel-fixes release to check that we > > > haven't just forgotten to send the patch to stable (there's at least one > > > flags mismatch fix already in-flight to 3.11 stable kernels). > > > > > > Thanks, Daniel > > > > Is it included in latest -rc2? It's easier for me to test that. > > -rc2 should be good enough for testing - the additional patches in > -fixes won't affect your issue. > -Daniel Either it's gone in -rc2 or it's masked with drm.debug=0xe. I will keep running with drm.debug=0xe some more, if it does not trigger anymore, I'll go back to -rc2 without drm.debug=0xe. > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > [0.00] Initializing cgroup subsys cpuset > > [0.00] Initializing cgroup subsys cpu > > [0.00] Initializing cgroup subsys cpuacct > > [0.00] Linux version 3.11.0-mst (mst at robin.redhat.com) (gcc > > version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #258 SMP Sun Sep 22 02:49:15 IDT > > 2013 > > [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-mst > > root=UUID=75d505b0-6e76-4f40-9cbc-0d6e700effd1 ro rd.md=0 rd.lvm=0 rd.dm=0 > > SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet drm.debug=0xe > > [0.00] Disabled fast string operations > > [0.00] e820: BIOS-provided physical RAM map: > > [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable > > [0.00] BIOS-e820: [mem 0x0009d800-0x0009] > > reserved > > [0.00] BIOS-e820: [mem 0x000e-0x000f] > > reserved > > [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable > > [0.00] BIOS-e820: [mem 0x2000-0x201f] > > reserved > > [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable > > [0.00] BIOS-e820: [mem 0x4000-0x401f] > > reserved > > [0.00] BIOS-e820: [mem 0x4020-0xda99efff] usable > > [0.00] BIOS-e820: [mem 0xda99f000-0xdae9efff] > > reserved > > [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI > > NVS > > [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI > > data > > [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable > > [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] > > reserved > > [0.00] BIOS-e820: [mem 0xf800-0xfbff] > > reserved > > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] > > reserved > > [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] > > reserved > > [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] > > reserved > > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] > > reserved > > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] > > reserved > > [0.00] BIOS-e820: [mem
[PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
Hi, This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client-dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Nevertheless there are a still a few users of the field around. This series first updates all users to use an alternative method of accessing the same data and then the last patch removes the driver field from the i2c_client struct. Note that due to this changes on most architectures neither the code size nor the type of generated instructions will change. This is due to the fact that we aren't really interested in the pointer value itself, but rather want to dereference it to access one of the fields of the struct. offset_of() (and hence to_i2c_driver) works by subtracting a offset from the pointer, so the compiler can internally create the sum of these two offsets and use that to access the field. E.g. on ARM the expression client-driver-command(...) generates ... ldr r3, [r0, #28] ldr r3, [r3, #32] blx r3 ... and the expression to_i2c_driver(client-dev.driver)-command(...) generates ... ldr r3, [r0, #160] ldr r3, [r3, #-4] blx r3 ... Other architectures will generate similar code. The most common pattern is to use the i2c_driver to get to the device_driver struct embedded in it. The same struct can easily be accessed through the device struct embedded in the i2c_client struct. E.g. client-driver-driver.field can be replaced by client-dev.driver-field. Here again the generated code is almost identical and only the offsets differ. E.g. on ARM the expression 'client-driver-driver.owner' generates ldr r3, [r0, #28] ldr r0, [r3, #44] and 'client-dev.driver-owner' generates ldr r3, [r0, #160] ldr r0, [r3, #8] The kernel overall code size is slightly reduced since the code that manages the driver field is removed and of course also the runtime memory footprint of the i2c_client struct is reduced. - Lars Lars-Peter Clausen (8): [media] s5c73m3: Don't use i2c_client-driver [media] exynos4-is: Don't use i2c_client-driver [media] core: Don't use i2c_client-driver drm: encoder_slave: Don't use i2c_client-driver drm: nouveau: Don't use i2c_client-driver ALSA: ppc: keywest: Don't use i2c_client-driver ASoC: imx-wm8962: Don't use i2c_client-driver i2c: Remove redundant 'driver' field from the i2c_client struct drivers/gpu/drm/drm_encoder_slave.c| 8 drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 3 ++- drivers/i2c/i2c-core.c | 21 - drivers/i2c/i2c-smbus.c| 10 ++ drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/platform/exynos4-is/media-dev.c | 6 +++--- drivers/media/v4l2-core/tuner-core.c | 6 +++--- drivers/media/v4l2-core/v4l2-common.c | 10 +- include/linux/i2c.h| 2 -- include/media/v4l2-common.h| 2 +- sound/ppc/keywest.c| 4 ++-- sound/soc/fsl/imx-wm8962.c | 2 +- 12 files changed, 40 insertions(+), 36 deletions(-) -- 1.8.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] [media] s5c73m3: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be removed. The results of the expressions 'client-driver.driver-field' and 'client-dev.driver-field' are identical, so replace all occurrences of the former with the later. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Andrzej Hajda a.ha...@samsung.com --- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c b/drivers/media/i2c/s5c73m3/s5c73m3-core.c index b76ec0e..1083890 100644 --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c @@ -1581,7 +1581,7 @@ static int s5c73m3_probe(struct i2c_client *client, oif_sd = state-oif_sd; v4l2_subdev_init(sd, s5c73m3_subdev_ops); - sd-owner = client-driver-driver.owner; + sd-owner = client-dev.driver-owner; v4l2_set_subdevdata(sd, state); strlcpy(sd-name, S5C73M3, sizeof(sd-name)); -- 1.8.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] [media] exynos4-is: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client-driver.driver-field' and
'client-dev.driver-field' are identical, so replace all occurrences of the
former with the later.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos4-is/media-dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index a835112..7a4ee4c 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -411,8 +411,8 @@ static int fimc_md_of_add_sensor(struct fimc_md *fmd,
device_lock(client-dev);
- if (!client-driver ||
- !try_module_get(client-driver-driver.owner)) {
+ if (!client-dev.driver ||
+ !try_module_get(client-dev.driver-owner)) {
ret = -EPROBE_DEFER;
v4l2_info(fmd-v4l2_dev, No driver found for %s\n,
node-full_name);
@@ -442,7 +442,7 @@ static int fimc_md_of_add_sensor(struct fimc_md *fmd,
fmd-num_sensors++;
mod_put:
- module_put(client-driver-driver.owner);
+ module_put(client-dev.driver-owner);
dev_put:
device_unlock(client-dev);
put_device(client-dev);
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm: encoder_slave: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client-driver.driver-field' and
'client-dev.driver-field' are identical, so replace all occurrences of the
former with the later. To get direct access to the i2c_driver struct use
'to_i2c_driver(client-dev.driver)'.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/gpu/drm/drm_encoder_slave.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index 0cfb60f..d18b88b 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -67,12 +67,12 @@ int drm_i2c_encoder_init(struct drm_device *dev,
goto fail;
}
- if (!client-driver) {
+ if (!client-dev.driver) {
err = -ENODEV;
goto fail_unregister;
}
- module = client-driver-driver.owner;
+ module = client-dev.driver-owner;
if (!try_module_get(module)) {
err = -ENODEV;
goto fail_unregister;
@@ -80,7 +80,7 @@ int drm_i2c_encoder_init(struct drm_device *dev,
encoder-bus_priv = client;
- encoder_drv = to_drm_i2c_encoder_driver(client-driver);
+ encoder_drv =
to_drm_i2c_encoder_driver(to_i2c_driver(client-dev.driver));
err = encoder_drv-encoder_init(client, dev, encoder);
if (err)
@@ -111,7 +111,7 @@ void drm_i2c_encoder_destroy(struct drm_encoder
*drm_encoder)
{
struct drm_encoder_slave *encoder = to_encoder_slave(drm_encoder);
struct i2c_client *client = drm_i2c_encoder_get_client(drm_encoder);
- struct module *module = client-driver-driver.owner;
+ struct module *module = client-dev.driver-owner;
i2c_unregister_device(client);
encoder-bus_priv = NULL;
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm: nouveau: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client-dev.driver)' instead to get direct access to
the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Cc: Martin Peres martin.pe...@labri.fr
---
drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/ic.c
b/drivers/gpu/drm/nouveau/core/subdev/therm/ic.c
index 8b3adec..eae939d 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/therm/ic.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/therm/ic.c
@@ -41,7 +41,8 @@ probe_monitoring_device(struct nouveau_i2c_port *i2c,
if (!client)
return false;
- if (!client-driver || client-driver-detect(client, info)) {
+ if (!client-dev.driver ||
+ to_i2c_driver(client-dev.driver)-detect(client, info)) {
i2c_unregister_device(client);
return false;
}
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] ALSA: ppc: keywest: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Use 'to_i2c_driver(client-dev.driver)' instead to get direct
access to the i2c_driver struct.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
sound/ppc/keywest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 01aecc2..0d1c27e 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -65,7 +65,7 @@ static int keywest_attach_adapter(struct i2c_adapter *adapter)
* already bound. If not it means binding failed, and then there
* is no point in keeping the device instantiated.
*/
- if (!keywest_ctx-client-driver) {
+ if (!keywest_ctx-client-dev.driver) {
i2c_unregister_device(keywest_ctx-client);
keywest_ctx-client = NULL;
return -ENODEV;
@@ -76,7 +76,7 @@ static int keywest_attach_adapter(struct i2c_adapter *adapter)
* This is safe because i2c-core holds the core_lock mutex for us.
*/
list_add_tail(keywest_ctx-client-detected,
- keywest_ctx-client-driver-clients);
+ to_i2c_driver(keywest_ctx-client-dev.driver)-clients);
return 0;
}
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] [media] core: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be removed. The results of the expressions 'client-driver.driver-field' and 'client-dev.driver-field' are identical, so replace all occurrences of the former with the later. Signed-off-by: Lars-Peter Clausen l...@metafoo.de --- drivers/media/v4l2-core/tuner-core.c | 6 +++--- drivers/media/v4l2-core/v4l2-common.c | 10 +- include/media/v4l2-common.h | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c index ddc9379..4133af0 100644 --- a/drivers/media/v4l2-core/tuner-core.c +++ b/drivers/media/v4l2-core/tuner-core.c @@ -43,7 +43,7 @@ #define UNSET (-1U) -#define PREFIX (t-i2c-driver-driver.name) +#define PREFIX (t-i2c-dev.driver-name) /* * Driver modprobe parameters @@ -452,7 +452,7 @@ static void set_type(struct i2c_client *c, unsigned int type, } tuner_dbg(%s %s I2C addr 0x%02x with type %d used for 0x%02x\n, - c-adapter-name, c-driver-driver.name, c-addr 1, type, + c-adapter-name, c-dev.driver-name, c-addr 1, type, t-mode_mask); return; @@ -556,7 +556,7 @@ static void tuner_lookup(struct i2c_adapter *adap, int mode_mask; if (pos-i2c-adapter != adap || - strcmp(pos-i2c-driver-driver.name, tuner)) + strcmp(pos-i2c-dev.driver-name, tuner)) continue; mode_mask = pos-mode_mask; diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c index 037d7a5..433d6d7 100644 --- a/drivers/media/v4l2-core/v4l2-common.c +++ b/drivers/media/v4l2-core/v4l2-common.c @@ -236,14 +236,14 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client, v4l2_subdev_init(sd, ops); sd-flags |= V4L2_SUBDEV_FL_IS_I2C; /* the owner is the same as the i2c_client's driver owner */ - sd-owner = client-driver-driver.owner; + sd-owner = client-dev.driver-owner; sd-dev = client-dev; /* i2c_client and v4l2_subdev point to one another */ v4l2_set_subdevdata(sd, client); i2c_set_clientdata(client, sd); /* initialize name */ snprintf(sd-name, sizeof(sd-name), %s %d-%04x, - client-driver-driver.name, i2c_adapter_id(client-adapter), + client-dev.driver-name, i2c_adapter_id(client-adapter), client-addr); } EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init); @@ -274,11 +274,11 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, loaded. This delay-load mechanism doesn't work if other drivers want to use the i2c device, so explicitly loading the module is the best alternative. */ - if (client == NULL || client-driver == NULL) + if (client == NULL || client-dev.driver == NULL) goto error; /* Lock the module so we can safely get the v4l2_subdev pointer */ - if (!try_module_get(client-driver-driver.owner)) + if (!try_module_get(client-dev.driver-owner)) goto error; sd = i2c_get_clientdata(client); @@ -287,7 +287,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, if (v4l2_device_register_subdev(v4l2_dev, sd)) sd = NULL; /* Decrease the module use count to match the first try_module_get. */ - module_put(client-driver-driver.owner); + module_put(client-dev.driver-owner); error: /* If we have a client but no subdev, then something went wrong and diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index 16550c4..a707529 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -35,7 +35,7 @@ printk(level %s %d-%04x: fmt, name, i2c_adapter_id(adapter), addr , ## arg) #define v4l_client_printk(level, client, fmt, arg...) \ - v4l_printk(level, (client)-driver-driver.name, (client)-adapter, \ + v4l_printk(level, (client)-dev.driver-name, (client)-adapter, \ (client)-addr, fmt , ## arg) #define v4l_err(client, fmt, arg...) \ -- 1.8.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] ASoC: imx-wm8962: Don't use i2c_client-driver
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Check i2c_client-dev.driver instead to see if a driver is bound to the
device.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
sound/soc/fsl/imx-wm8962.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-wm8962.c b/sound/soc/fsl/imx-wm8962.c
index 6c60666..f84ecbf 100644
--- a/sound/soc/fsl/imx-wm8962.c
+++ b/sound/soc/fsl/imx-wm8962.c
@@ -215,7 +215,7 @@ static int imx_wm8962_probe(struct platform_device *pdev)
goto fail;
}
codec_dev = of_find_i2c_device_by_node(codec_np);
- if (!codec_dev || !codec_dev-driver) {
+ if (!codec_dev || !codec_dev-dev.driver) {
dev_err(pdev-dev, failed to find codec platform device\n);
ret = -EINVAL;
goto fail;
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] i2c: Remove redundant 'driver' field from the i2c_client struct
The 'driver' field of the i2c_client struct is redundant. The same data can be
accessed through to_i2c_driver(client-dev.driver). The generated code for both
approaches in more or less the same.
E.g. on ARM the expression client-driver-command(...) generates
...
ldr r3, [r0, #28]
ldr r3, [r3, #32]
blx r3
...
and the expression to_i2c_driver(client-dev.driver)-command(...) generates
...
ldr r3, [r0, #160]
ldr r3, [r3, #-4]
blx r3
...
Other architectures will generate similar code.
All users of the 'driver' field outside of the I2C core have already been
converted. So this only leaves the core itself. This patch converts the
remaining few users in the I2C core and then removes the 'driver' field from the
i2c_client struct.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/i2c/i2c-core.c | 21 -
drivers/i2c/i2c-smbus.c | 10 ++
include/linux/i2c.h | 2 --
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 29d3f04..430c001 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -248,17 +248,16 @@ static int i2c_device_probe(struct device *dev)
driver = to_i2c_driver(dev-driver);
if (!driver-probe || !driver-id_table)
return -ENODEV;
- client-driver = driver;
+
if (!device_can_wakeup(client-dev))
device_init_wakeup(client-dev,
client-flags I2C_CLIENT_WAKE);
dev_dbg(dev, probe\n);
status = driver-probe(client, i2c_match_id(driver-id_table, client));
- if (status) {
- client-driver = NULL;
+ if (status)
i2c_set_clientdata(client, NULL);
- }
+
return status;
}
@@ -279,10 +278,9 @@ static int i2c_device_remove(struct device *dev)
dev-driver = NULL;
status = 0;
}
- if (status == 0) {
- client-driver = NULL;
+ if (status == 0)
i2c_set_clientdata(client, NULL);
- }
+
return status;
}
@@ -1606,9 +1604,14 @@ static int i2c_cmd(struct device *dev, void *_arg)
{
struct i2c_client *client = i2c_verify_client(dev);
struct i2c_cmd_arg *arg = _arg;
+ struct i2c_driver *driver;
+
+ if (!client || !client-dev.driver)
+ return 0;
- if (client client-driver client-driver-command)
- client-driver-command(client, arg-cmd, arg-arg);
+ driver = to_i2c_driver(client-dev.driver);
+ if (driver-command)
+ driver-command(client, arg-cmd, arg-arg);
return 0;
}
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index 44d4c60..c99b229 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -46,6 +46,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
{
struct i2c_client *client = i2c_verify_client(dev);
struct alert_data *data = addrp;
+ struct i2c_driver *driver;
if (!client || client-addr != data-addr)
return 0;
@@ -54,12 +55,13 @@ static int smbus_do_alert(struct device *dev, void *addrp)
/*
* Drivers should either disable alerts, or provide at least
-* a minimal handler. Lock so client-driver won't change.
+* a minimal handler. Lock so the driver won't change.
*/
device_lock(dev);
- if (client-driver) {
- if (client-driver-alert)
- client-driver-alert(client, data-flag);
+ if (client-dev.driver) {
+ driver = to_i2c_driver(client-dev.driver);
+ if (driver-alert)
+ driver-alert(client, data-flag);
else
dev_warn(client-dev, no driver alert()!\n);
} else
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 2ab11dc..eff50e0 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -205,7 +205,6 @@ struct i2c_driver {
* @name: Indicates the type of the device, usually a chip name that's
* generic enough to hide second-sourcing and compatible revisions.
* @adapter: manages the bus segment hosting this I2C device
- * @driver: device's driver, hence pointer to access routines
* @dev: Driver model device node for the slave.
* @irq: indicates the IRQ generated by this device (if any)
* @detected: member of an i2c_driver.clients list or i2c-core's
@@ -222,7 +221,6 @@ struct i2c_client {
/* _LOWER_ 7 bits */
char name[I2C_NAME_SIZE];
struct i2c_adapter *adapter;/* the adapter we sit on*/
- struct i2c_driver *driver; /* and our access routines */
[Bug 69922] New: Juniper (HD 5770): Hibernate partially broken since LInux kernel 3.10
https://bugs.freedesktop.org/show_bug.cgi?id=69922 Priority: medium Bug ID: 69922 Assignee: dri-devel@lists.freedesktop.org Summary: Juniper (HD 5770): Hibernate partially broken since LInux kernel 3.10 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: haeus...@fastmail.fm Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 86790 -- https://bugs.freedesktop.org/attachment.cgi?id=86790action=edit Log for failing (hybrid) suspend to disk I built and installed the final version of 3.11 especially for testing the improvements of the radeon driver for my system. However, I was no longer able to hibernate (suspend to disk) my system: the screen went blank, but fans were on full speed and power was not switched off. I have to reset the system and on reboot, there was no session to resume and the BIOS logged A Hyper Transport sync flood error occurred on last boot. Press F1 to resume. After that, I tried older kernel versions and figured out that suspend to disk works for me with 3.9.11, but no longer for kernel versions 3.10 and newer (tested with 3.11.1/3.12-rc2). When I start the kernel with parameter 'nomodeset', suspend to disk works though (with DRM_RADEON_UMS activated). Some details of my computer: # uname -a Linux odysseus 3.11.1-1.16-desktop #2 SMP PREEMPT Wed Sep 18 22:54:08 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/SuSE-release openSUSE 12.3 (x86_64) VERSION = 12.3 CODENAME = Dartmouth # smbios-sys-info Libsmbios version: 2.2.28 Product Name: MS-7596 Vendor: MICRO-STAR INTERNATIONAL CO.,LTD BIOS Version: V2.12 System ID: Could not determine System ID. Service Tag:To Be Filled By O.E.M. Express Service Code: 0 Asset Tag: To Be Filled By O.E.M. Property Ownership Tag: # lspci 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS880 Host Bridge 00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0) 00:05.0 PCI bridge: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 1) 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 3c) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Juniper [Radeon HD 5700 Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03) -- 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 69670] KWin crashes when switching to OpenGL 3.1 + Raster
https://bugs.freedesktop.org/show_bug.cgi?id=69670 --- Comment #5 from Eugene omegat...@gmail.com --- I am not sure how to confirm it. I tried launching: LIBGL_ALWAYS_SOFTWARE=1 kwin --replace kwin_stdout_LIBGL_ALWAYS_SOFTWARE.txt 2 kwin_stderr_LIBGL_ALWAYS_SOFTWARE.txt and it disabled desktop effects; then I tried to switch to OpenGL 3.1 + Raster and Kwin crashed displaying 'report bug assignment' window and then was restarted automatically without effects. I could not enable effect anyhow. kwin_stdout_LIBGL_ALWAYS_SOFTWARE.txt was empty. -- 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 69670] KWin crashes when switching to OpenGL 3.1 + Raster
https://bugs.freedesktop.org/show_bug.cgi?id=69670 --- Comment #6 from Eugene omegat...@gmail.com --- Created attachment 86794 -- https://bugs.freedesktop.org/attachment.cgi?id=86794action=edit kwin stderr with LIBGL_ALWAYS_SOFTWARE=1 -- 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 69897] OpenCL kernel fails to compile with R600 LLVM backend
https://bugs.freedesktop.org/show_bug.cgi?id=69897 --- Comment #6 from Grigori Goronzy g...@chown.ath.cx --- Now it compiles fine, but locks up the GPU. This might be an issue with this particular kernel, though. -- 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: Intel Haswell kernel warning (3.11.2)
Let's CC some more people. On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote: Wakko Warner wrote: Please keep me in CC. I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This happens when I'm on a console, the screen has gone into power save and I press a key to wake it up. This doesn't happen when I'm in X. Kernel is Vanilla 3.11.2. Tested 3.12-rc2. Same result. Here's the kernel log from 3.12-rc2. [ 813.921516] [ cut here ] [ 813.921531] WARNING: CPU: 0 PID: 492 at /usr/src/linux/dist/3.12-rc2/drivers/gpu/drm/i915/intel_display.c:3920 /intel_modeset_check_state+0x764/0x770 [i915]() [ 813.921531] wrong connector dpms state [ 813.921547] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_intel crc32_pclmul snd_hda_codec i915 snd_hwdep snd_pcm_oss crc32c_intel snd_mixer_oss ghash_clmulni_intel aesni_intel intel_agp aes_x86_64 intel_gtt lrw drm_kms_helper gf128mul snd_pcm 8250_pci glue_helper drm ablk_helper e1000e snd_page_alloc agpgart snd_timer video thermal processor fan snd 8250 thermal_sys serial_core soundcore cryptd button hwmon evdev i2c_i801 [ 813.921549] CPU: 0 PID: 492 Comm: kworker/0:1 Not tainted 3.12.0-rc2 #3 [ 813.921549] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 813.921553] Workqueue: events console_callback [ 813.921554] 0009 8802360b1b48 8143608e 8802360b1b90 [ 813.921555] 8802360b1b80 8103df53 8800b24ec000 8800b24eb000 [ 813.921555] 8800b24e8800 8800b24e8bd8 8800379f3c00 8802360b1be0 [ 813.921556] Call Trace: [ 813.921560] [8143608e] dump_stack+0x54/0x8d [ 813.921563] [8103df53] warn_slowpath_common+0x73/0x90 [ 813.921564] [8103dfb7] warn_slowpath_fmt+0x47/0x50 [ 813.921569] [a056d0a3] ? intel_ddi_connector_get_hw_state+0x63/0x120 [i915] [ 813.921575] [a0564014] intel_modeset_check_state+0x764/0x770 [i915] [ 813.921578] [a0564065] intel_connector_dpms+0x45/0x80 [i915] [ 813.921581] [a03a31c0] drm_fb_helper_dpms.isra.11+0x110/0x150 [drm_kms_helper] [ 813.921582] [a03a323e] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 813.921584] [81217b52] fb_blank+0x52/0xc0 [ 813.921585] [812244bb] fbcon_blank+0x21b/0x2d0 [ 813.921588] [810481e6] ? lock_timer_base.isra.29+0x26/0x50 [ 813.921589] [81047d22] ? internal_add_timer+0x12/0x40 [ 813.921590] [810489b8] ? mod_timer+0xf8/0x1c0 [ 813.921591] [8126f871] do_unblank_screen+0xa1/0x1c0 [ 813.921593] [81270ba7] poke_blanked_console+0xc7/0xd0 [ 813.921594] [81270cef] console_callback+0x13f/0x160 [ 813.921596] [81053d08] process_one_work+0x148/0x3d0 [ 813.921597] [810549c9] worker_thread+0x119/0x3a0 [ 813.921599] [810548b0] ? manage_workers.isra.30+0x2a0/0x2a0 [ 813.921600] [8105a42b] kthread+0xbb/0xc0 [ 813.921601] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921603] [8143cc3c] ret_from_fork+0x7c/0xb0 [ 813.921605] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921605] ---[ end trace b0a29ba4948c3d5b ]--- # lspci -vns2 00:02.0 0300: 8086:041a (rev 06) (prog-if 00 [VGA controller]) Subsystem: 8086:2010 Flags: bus master, fast devsel, latency 0, IRQ 57 Memory at f000 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 # gcc version 4.8.1 (Debian 4.8.1-10) This is from dmesg: [ 354.803050] [ cut here ] [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm
Re: Intel Haswell kernel warning (3.11.2)
On Sun, Sep 29, 2013 at 04:58:39PM +0200, Borislav Petkov wrote: Let's CC some more people. Please boot with drm.debug=0xe, reproduce the WARN and then attach the full dmesg. Thanks, Daniel On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote: Wakko Warner wrote: Please keep me in CC. I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This happens when I'm on a console, the screen has gone into power save and I press a key to wake it up. This doesn't happen when I'm in X. Kernel is Vanilla 3.11.2. Tested 3.12-rc2. Same result. Here's the kernel log from 3.12-rc2. [ 813.921516] [ cut here ] [ 813.921531] WARNING: CPU: 0 PID: 492 at /usr/src/linux/dist/3.12-rc2/drivers/gpu/drm/i915/intel_display.c:3920 /intel_modeset_check_state+0x764/0x770 [i915]() [ 813.921531] wrong connector dpms state [ 813.921547] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_intel crc32_pclmul snd_hda_codec i915 snd_hwdep snd_pcm_oss crc32c_intel snd_mixer_oss ghash_clmulni_intel aesni_intel intel_agp aes_x86_64 intel_gtt lrw drm_kms_helper gf128mul snd_pcm 8250_pci glue_helper drm ablk_helper e1000e snd_page_alloc agpgart snd_timer video thermal processor fan snd 8250 thermal_sys serial_core soundcore cryptd button hwmon evdev i2c_i801 [ 813.921549] CPU: 0 PID: 492 Comm: kworker/0:1 Not tainted 3.12.0-rc2 #3 [ 813.921549] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 813.921553] Workqueue: events console_callback [ 813.921554] 0009 8802360b1b48 8143608e 8802360b1b90 [ 813.921555] 8802360b1b80 8103df53 8800b24ec000 8800b24eb000 [ 813.921555] 8800b24e8800 8800b24e8bd8 8800379f3c00 8802360b1be0 [ 813.921556] Call Trace: [ 813.921560] [8143608e] dump_stack+0x54/0x8d [ 813.921563] [8103df53] warn_slowpath_common+0x73/0x90 [ 813.921564] [8103dfb7] warn_slowpath_fmt+0x47/0x50 [ 813.921569] [a056d0a3] ? intel_ddi_connector_get_hw_state+0x63/0x120 [i915] [ 813.921575] [a0564014] intel_modeset_check_state+0x764/0x770 [i915] [ 813.921578] [a0564065] intel_connector_dpms+0x45/0x80 [i915] [ 813.921581] [a03a31c0] drm_fb_helper_dpms.isra.11+0x110/0x150 [drm_kms_helper] [ 813.921582] [a03a323e] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 813.921584] [81217b52] fb_blank+0x52/0xc0 [ 813.921585] [812244bb] fbcon_blank+0x21b/0x2d0 [ 813.921588] [810481e6] ? lock_timer_base.isra.29+0x26/0x50 [ 813.921589] [81047d22] ? internal_add_timer+0x12/0x40 [ 813.921590] [810489b8] ? mod_timer+0xf8/0x1c0 [ 813.921591] [8126f871] do_unblank_screen+0xa1/0x1c0 [ 813.921593] [81270ba7] poke_blanked_console+0xc7/0xd0 [ 813.921594] [81270cef] console_callback+0x13f/0x160 [ 813.921596] [81053d08] process_one_work+0x148/0x3d0 [ 813.921597] [810549c9] worker_thread+0x119/0x3a0 [ 813.921599] [810548b0] ? manage_workers.isra.30+0x2a0/0x2a0 [ 813.921600] [8105a42b] kthread+0xbb/0xc0 [ 813.921601] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921603] [8143cc3c] ret_from_fork+0x7c/0xb0 [ 813.921605] [8105a370] ? kthread_create_on_node+0x120/0x120 [ 813.921605] ---[ end trace b0a29ba4948c3d5b ]--- # lspci -vns2 00:02.0 0300: 8086:041a (rev 06) (prog-if 00 [VGA controller]) Subsystem: 8086:2010 Flags: bus master, fast devsel, latency 0, IRQ 57 Memory at f000 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 # gcc version 4.8.1 (Debian 4.8.1-10) This is from dmesg: [ 354.803050] [ cut here ] [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT
[Bug 55951] [regression] Torchlight exits with BadDrawable (invalid Pixmap or Window parameter)
https://bugs.freedesktop.org/show_bug.cgi?id=55951 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Summary|[regression] Torchlight |[regression] Torchlight |segfault at start with Mesa |exits with BadDrawable |9.0/git |(invalid Pixmap or Window ||parameter) Component|Drivers/Gallium/r600|Mesa core --- Comment #2 from Sven Arvidsson s...@whiz.se --- Reassigning to mesa core as this has also been reported on i965. -- 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 v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote: Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: I can test on T61, would that help? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
An approach to GPU memory management(especially for radeon GPUs)
Hello i've an idea how to simplify DRI, and I think this idea will be very useful for Wayland because it allows wayland clients to partially update their windows. I suggest to provide an interface for user-mode applications to semi-directly control GPU memory map tables. Instead of working with buffers, textures via hacky GEM interface, an application should be able to 1)ask the GPU driver to reserve a specified amount of memory of each available type in case of radeon, for example, there will be 2 memory pools: system memory, gpu memory which can be accessed by UVD and other GPU memory. 2)Create one or more memory maps, or update existing memory maps, by associating reserved pages with PTE entries. 3)Make a memory map active and tell GPU to perform some operation with it. Radeon GPUs have multiple VMs so multiple applications can utilize all of them. Upon completion of operation, driver can notify usermode application by polling interface. 4)VBO and PBO emulation is provided by usermode driver 5)Memory maps are invalidated when gpu memory is released back to system. This approach can be used to accelerate partial texture updates by tile-based flipping of buffers. Instead of flipping whole render buffer, and application can 0)allocate back pages from pool controlled by application(no need to call kernel here) 1)for each updated tile, copy all memory contents from front page to back page 2)update tiles 3)notify window manager about updated tiles. 4)release front upon window manager notification. Regards, Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma500: define do_gma_backlight_set only when used
Make sure static function do_gma_backlight_set() is only defined when
CONFIG_BACKLIGHT_CLASS_DEVICE is defined, as it is never called otherwise.
This fixes the following warning:
drivers/gpu/drm/gma500/backlight.c:29:13: warning: ‘do_gma_backlight_set’
defined but not used [-Wunused-function]
While at it, remove some end of line spaces.
Signed-off-by: Vincent Stehlé vincent.ste...@laposte.net
Cc: David Airlie airl...@linux.ie
---
Hi,
This can be seen with mainline or linux-next with e.g. allmodconfig on x86.
Best regards,
V.
drivers/gpu/drm/gma500/backlight.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/backlight.c
b/drivers/gpu/drm/gma500/backlight.c
index 143eba3..399731e 100644
--- a/drivers/gpu/drm/gma500/backlight.c
+++ b/drivers/gpu/drm/gma500/backlight.c
@@ -26,13 +26,13 @@
#include intel_bios.h
#include power.h
+#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
static void do_gma_backlight_set(struct drm_device *dev)
{
-#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
struct drm_psb_private *dev_priv = dev-dev_private;
backlight_update_status(dev_priv-backlight_device);
-#endif
}
+#endif
void gma_backlight_enable(struct drm_device *dev)
{
@@ -43,7 +43,7 @@ void gma_backlight_enable(struct drm_device *dev)
dev_priv-backlight_device-props.brightness =
dev_priv-backlight_level;
do_gma_backlight_set(dev);
}
-#endif
+#endif
}
void gma_backlight_disable(struct drm_device *dev)
@@ -55,7 +55,7 @@ void gma_backlight_disable(struct drm_device *dev)
dev_priv-backlight_device-props.brightness = 0;
do_gma_backlight_set(dev);
}
-#endif
+#endif
}
void gma_backlight_set(struct drm_device *dev, int v)
@@ -67,7 +67,7 @@ void gma_backlight_set(struct drm_device *dev, int v)
dev_priv-backlight_device-props.brightness = v;
do_gma_backlight_set(dev);
}
-#endif
+#endif
}
int gma_backlight_init(struct drm_device *dev)
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/51] DMA mask changes
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. If I did that, then the mailing lists would not get the first patch, because almost none of the lists would be referred to by patch 1. Moreover, people complain when they don't have access to the full patch series - they assume patches are missing for some reason, and they ask for the rest of the series. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
On Tue, Sep 24, 2013 at 05:47:28PM +0800, Aaron Lu wrote: v3: 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; 2 Remove unnecessary function acpi_video_unregister introduced in patch 2/3 as pointed out by Jani Nikula. v2: v1 has the subject of Rework ACPI video driver and is posted here: http://lkml.org/lkml/2013/9/9/74 Since the objective is really to fix Win8 backlight issues, I changed the subject in this version, sorry about that. This patchset has three patches, the first introduced a new API named backlight_device_registered in backlight layer that can be used for backlight interface provider module to check if a specific type backlight interface has been registered, see changelog for patch 1/3 for details. Then patch 2/3 does the cleanup to sepeate the backlight control and event delivery functionality in the ACPI video module and patch 3/3 solves some Win8 backlight control problems by avoiding register ACPI video's backlight interface if: 1 Kernel cmdline option acpi_backlight=video is not given; 2 This is a Win8 system; 3 Native backlight control interface exists. Technically, patch 2/3 is not required to fix the issue here. So if you think it is not necessary, I can remove it from the series. Aaron Lu (4): backlight: introduce backlight_device_registered ACPI / video: seperate backlight control and event interface ACPI / video: Do not register backlight if win8 and native interface exists thinkpad-acpi: fix handle locate for video and query of _BCL drivers/acpi/internal.h | 5 +- drivers/acpi/video.c | 442 --- drivers/acpi/video_detect.c | 14 +- drivers/platform/x86/thinkpad_acpi.c | 31 ++- drivers/video/backlight/backlight.c | 31 +++ include/acpi/video.h | 2 + include/linux/backlight.h| 4 + 7 files changed, 324 insertions(+), 205 deletions(-) Just tested this series on my HP revolve 810 and this fixes the backlight issue it had :) Feel free to add my, Tested-by: Mika Westerberg mika.westerb...@linux.intel.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.11-rc4] [HD2400] - radeon.dpm
Hi Alex, could you just point me to the right location in the driver code to play with? I am less afraid to play with the driver than to flash my vbios... Even though, I promise I won't bother you or complain if I break something :-) NB: Daniel, although I won't modify my vbios, I still like your solution: it reminds me of good old time where you just had to edit your game files with an hex editor to cheat... Regards Sam On 09/26/2013 08:19 PM, Alex Deucher wrote: On Thu, Sep 26, 2013 at 1:49 PM, dan...@motaleite.net wrote: Hi As I suspected, on your system all the performance levels are the same: (...) [8.961704]power level 0sclk: 45000 mclk: 5 vddc: 950 [8.961706]power level 1sclk: 45000 mclk: 5 vddc: 950 [8.961708]power level 2sclk: 45000 mclk: 5 vddc: 950 (...) So there is no dynamic switching supported on your system. I also had this problem and manage to fix it (on a HD2600) :) Please be warnned that this is dangerous, requires editing the bios and may brick your card. Also, will not work on recent cards (but a HD2400 should be ok). Also, this is a hack and no one will support you if things go wrong! You need a windows machine, for some steps, but other can use a linux equivalent... but editing the GPU bios i know no alternative to using the windows program. I also don't know is there is any way in linux to load a GPU bios (and avoid the flashing)... we have the firmware, but i think that the firmware is just a subset of the bios. So here is the HOWTO: Make a usb pendrive bootable to DOS: Get this files: http://files.extremeoverclocking.com/file.php?f=196 http://pt.kioskea.net/download/baixaki-433-hp-usb-disk-storage-format-tool Unzip the windows98 DOS support to a directory and run the HP usb storage app and format the pendrive. Chek the flag Create a DOS startup disk and choose the extracted windows98 files. After formating, download and extract the ATI flash to the pen: http://www.techpowerup.com/downloads/1731/ATIFlash_3.79.html Now lets edit the bios. Ddownload this two apps: http://www.techpowerup.com/gpuz/ - Dump the GPU Bios http://www.techpowerup.com/rbe/ - ATI/AMD Bios editor use the gpu-z to dump the current bios, backup it up on a pendrive, to revert to the original bios if needed. use the rbe to edit the power levels. be conservative, DO NOT TOUCH the boot power profiles (this way you can always boot the machine), avoid changing the voltage, as it's more dangerous (but it can also save more power). Edit the lower leves to reduce the GPU frequencies and keep the level 2 high. please note that too low or too high frequencies may cause the card to be unstable. DRAM frequencies usually save little power, but may help reducing the heat. For evey change, test it and check if the card is stable, the picture is not corrupted in different resolutions and loads. Again, if something goes wrong, power off the machine and startup again, the boot profile should be the one that always work (don't forget to have a boot entry in grub that disables the dynamic powermanagement, to avoid jumping to a unstable profile). After doing the changes, save the bios and save it to the pendrive. Now shutdown the machine, make sure you have the full charge and have the power connected. If power faills during the flashing of the bios, you may brick the card/laptop. Startup the computer with the pendriver, enter the DOS and run the flash command: atiflash -p 0 .rom where the .rom is the new tuned bios. After some seconds and the command line returned, you can reboot and test it. If something fails, flash back the original bios. Test the card, increase the load, let screen/card enter the sleep mode (screensaver/suspend), change resolutions and look at the temperature. If all OK, you can try to tune even more. So this is a possible (and dangerous) solution for this problem, but may help some people. You can edit the power states in the driver as well if you don't want to flash your vbios. However the same caveats apply. It's not recommended that you flash your vbios, or edit your power states. It may break your card, void your warranty, etc. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On ven., 2013-09-27 at 15:05 -0300, Henrique de Moraes Holschuh wrote: On Fri, 27 Sep 2013, Yves-Alexis Perez wrote: On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote: Some testing on a *60 (T60,X60...) would also be best, I cannot test this on my T43. Anyway, the code itself looks fine, so: I can test on T61, would that help? I think so. Ok, just tested on my T61 with Intel graphics. I've checked that on Linux 3.12 (6cac446bd37d9381815fe4c2b0e7b1fd1085000c), brightness keys work fine like they do in 3.2. Then I've applied the patchset. The brightness keys still work, I still have 16 levels. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
2013/9/27 Rafael J. Wysocki r...@sisk.pl: On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote: 2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Jörg Otte jrg.o...@gmail.com wrote: 2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote: On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? In v3.11-rc1 it didn't work. Since a later rc (I don't remember exactly which) it did work. In v3.12-rc1/2 it does work. In v3.12-rc2 + Aaron's patch set it again doesn't work. Thanks for the test. Please check /sys/class/backlight, is there only one link file intel_backlight? Indeed, are there others? fujitsu-laptop perhaps? If yes, try CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? There is only one intel_backlight link. Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y Embarrassingly there was a bug in i915 fixed just recently where the backlight device wasn't registered for CONFIG_BACKLIGHT_CLASS_DEVICE=m... If so, please cd inside and try modify the brightness file using echo with some values in the range of 0 - max_brightness, does the backlight level change when you echo a new value? I guess it doesn't, or you wouldn't notice problem. If indeed so, perhaps file a bug at http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani and Daniel can help fix your problem. Yup, please check the above, and report back. - echo 0..max_brightness brightness does not work. Thanks for the info. How about v3.12-rc2 without Aaron's patches? Does intel_backlight also not work there? How about the acpi_video0 (which I presume is present) sysfs interface? Without Aaron's patches intel_backlight also does not work. But acpi_video0 does (and takes precedence I think). So can you please open a bug entry at bugzilla.kernel.org against i915? The fact that ACPI video works for you doesn't mean that intel_backlight shouldn't, I suppose? Rafael done. Bug-Id:62281 Jörg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Intel Haswell kernel warning (3.11.2)
Please keep me in CC.
CCing Borislav Petkov b...@alien8.de, intel-...@lists.freedesktop.org,
dri-devel@lists.freedesktop.org as they were on another part of this thread.
Chris Wilson wrote:
I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
happens when I'm on a console, the screen has gone into power save and I
press a key to wake it up.
Kernel is Vanilla 3.11.2.
Try,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bd3e115..dacde4e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4043,8 +4043,6 @@ static void intel_connector_check_state(struct
intel_connector *connector)
* consider. */
void intel_connector_dpms(struct drm_connector *connector, int mode)
{
- struct intel_encoder *encoder = intel_attached_encoder(connector);
-
/* All the simple cases only support two dpms states. */
if (mode != DRM_MODE_DPMS_ON)
mode = DRM_MODE_DPMS_OFF;
@@ -4055,10 +4053,8 @@ void intel_connector_dpms(struct drm_connector
*connector, int mode)
connector-dpms = mode;
/* Only need to change hw state when actually enabled */
- if (encoder-base.crtc)
- intel_encoder_dpms(encoder, mode);
- else
- WARN_ON(encoder-connectors_active != false);
+ if (connector-encoder)
+ intel_encoder_dpms(to_intel_encoder(connector-encoder),
mode);
intel_modeset_check_state(connector-dev);
}
Manually appied to 3.11.2. It doesn't give me a warning now and I can go
back to the VT where X is running (I forgot to mention that detail in the
original message I think).
--
Microsoft has beaten Volkswagen's world record. Volkswagen only created 22
million bugs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote: This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client-dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Great! Looks proper from a first glimpse. I'd think it makes sense to take all patches via I2C. So, I am looking for ACKs for other subsystems touched. Thanks, Wolfram signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
Hello Christian, after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with my RV730 (AGP). All nice videos didn't play any longer. -Dieter BTW I'm not on Mesa Devel, so please CC me. /opt/mesa vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 420 8192 8192 NV12 YV12 422 8192 8192 UYVY YUYV 444 8192 8192 Y8U8V8A8 V8U8Y8A8 Decoder capabilities: name level macbs width height --- MPEG1 0 262144 8192 8192 MPEG2_SIMPLE 3 262144 8192 8192 MPEG2_MAIN3 262144 8192 8192 Output surface: name width height nat types B8G8R8A8 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R8G8B8A8 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R10G10B10A2 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 B10G10R10A2 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 Bitmap surface: name width height -- B8G8R8A8 8192 8192 R8G8B8A8 8192 8192 R10G10B10A2 8192 8192 B10G10R10A2 8192 8192 A88192 8192 Video mixer: feature namesup DEINTERLACE_TEMPORAL - DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESSy LUMA_KEY - HIGH QUALITY SCALING - L1- HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3- HIGH QUALITY SCALING - L4- HIGH QUALITY SCALING - L5- HIGH QUALITY SCALING - L6- HIGH QUALITY SCALING - L7- HIGH QUALITY SCALING - L8- HIGH QUALITY SCALING - L9- parameter name sup min max - VIDEO_SURFACE_WIDTH y48 8192 VIDEO_SURFACE_HEIGHT y48 8192 CHROMA_TYPE y LAYERS y 04 attribute name sup min max - BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVELy 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMAy LUMA_KEY_MAX_LUMAy Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map-l_init_called' failed! (I've only have libvdpau1-0.6 not 0.7 on openSUSE 12.3.) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Monday 30 of September 2013 00:08:46 Sylwester Nawrocki wrote:
On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before
proceeding.
Rahul, it seems that DT people have no interest in this issue. So
let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
It often helps to Cc a DT binding maintainer directly.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
I'd like to only add that patches introducing or modifying a device tree
binding need to be acked by at least one DT binding maintainer to be
merged.
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?
The configuration data is 64 bytes of the register values IIUC. Would it
be possible to figure out exact meaning of each byte ?
This is definitely something that I would go for. Then for board specific
data appropriate device tree properties could be defined, not just a
binary blob.
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #20 from Shawn Starr shawn.st...@rogers.com --- Created attachment 86821 -- https://bugs.freedesktop.org/attachment.cgi?id=86821action=edit Radeon crash with dynclks enabled Radeon crash with dynclks enabled -- 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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #21 from Shawn Starr shawn.st...@rogers.com --- Attached crash is without DPM enabled, dynclks enabled and caused GPU reset. -- 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 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 Bruno Wolff III br...@wolff.to changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #21 from Bruno Wolff III br...@wolff.to --- This is fixed by commit 3a126f85e015701e56240884f27f97543580d5f7 which is in Linus' tree. It is also in Fedora kernel-PAE-3.12.0-0.rc2.git4.1.fc21.i686 which I tested and confirmed the fix again. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69245] Opencl random lockups whilst running tstellar's opencl-examples
https://bugs.freedesktop.org/show_bug.cgi?id=69245 --- Comment #3 from klondike klond...@klondike.es --- Created attachment 86824 -- https://bugs.freedesktop.org/attachment.cgi?id=86824action=edit Backported commit fixing the lockups Hi Tom, after manually checking the differences between the 9.2.0 and my working version of the git sources* I have tracked it down to these lines which are present on 9.2.0 but not on git The file is src/gallium/drivers/r600/evergreen_compute.c The relevant commit with the fix is this: http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/r600/evergreen_compute.c?id=f0435ebb07d01a77ca0d98967a002898811a5206 Keep in mind that ctx-b.flags = 0; should be changed by ctx-flags = 0; (and similar changes where be needed too). Anyways, patch for 9.2.0 attached :) * Yeah, I know bisect may have been faster, but for random appearing problems I prefer to do stuff the good old way. -- 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: New radeon ucode
On Wed, 2013-09-18 at 16:33 -0400, Alex Deucher wrote: On Wed, Sep 18, 2013 at 4:32 PM, Alex Deucher alexdeuc...@gmail.com wrote: Hi Ben, The attached patches add new firmware for radeon GPUs. Please apply to the firmware tree. Attached this time... Applied, thanks. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #135 from Bryan Quigley gquigs+b...@gmail.com --- Created attachment 86825 -- https://bugs.freedesktop.org/attachment.cgi?id=86825action=edit dmesg when under works due to setting .debug=1 I tried again with the latest rc3 build and it still doesn't work; I had left changes from comment 94 intact. Trying to get more information I tried booting with radeon.modeset=0 radeon.debug=1. Once I re-loaded the module with dpm, now it works! So it works correctly if you set it to debug mode, otherwise I can't get any logs of the event. This is the dmesg from when it worked (with debug on). I noticed there are some HDMI errors; I only have DVI actually hooked up. -- 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 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #22 from Alex Deucher ag...@yahoo.com --- FWIW, the dynclks parameter doesn't actually do anything on r6xx+ asics. -- 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 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #8 from Alex Deucher ag...@yahoo.com --- (In reply to comment #7) Alex, using debugfs, should I see the maxed values (sclk and mclk) or the theorical value from the table? For now, even if I have confirmation in dmesg the values were maxed out, looking in debugfs gives me: uvdvclk: 0 dclk: 0 power level 2sclk: 83000 mclk: 13 vddc: 1060 vddci: 1150 (it should be sclk: 8 mclk: 125000...) IIRC, it references the unpatched power state so you'll see the unpatched state. The hw just returns an index which is used to look up the state attributes. -- 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/edid: catch kmalloc failure in drm_edid_to_speaker_allocation
On Sat, 28 Sep 2013, Alex Deucher alexdeuc...@gmail.com wrote:
Return -ENOMEM if the allocation fails.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1688ff5..830f750 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2925,6 +2925,8 @@ int drm_edid_to_speaker_allocation(struct edid *edid,
u8 **sadb)
/* Speaker Allocation Data Block */
if (dbl == 3) {
*sadb = kmalloc(dbl, GFP_KERNEL);
+ if (!*sadb)
+ return -ENOMEM;
memcpy(*sadb, db[1], dbl);
count = dbl;
break;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #136 from Alex Deucher ag...@yahoo.com --- (In reply to comment #135) Created attachment 86825 [details] dmesg when under works due to setting .debug=1 I tried again with the latest rc3 build and it still doesn't work; I had left changes from comment 94 intact. Trying to get more information I tried booting with radeon.modeset=0 radeon.debug=1. Once I re-loaded the module with dpm, now it works! So it works correctly if you set it to debug mode, otherwise I can't get any logs of the event. There is no radeon.debug parameter: [ 34.991462] radeon: unknown parameter 'debug' ignored Seems like you just got lucky this time. Does it work reliably if you disable radeon and boot into a non-X runlevel, then manually load radeon? E.g., boot with: radeon.modeset=0 1 on the kernel command line in grub to boot into single user mode. then at the command prompt: modprobe -r radeon modprobe radeon modeset=1 dpm=1 This is the dmesg from when it worked (with debug on). I noticed there are some HDMI errors; I only have DVI actually hooked up. You can ignore those. -- 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
