https://bugzilla.kernel.org/show_bug.cgi?id=42876
--- Comment #7 from Artyom Kunyov 2012-03-27 06:57:00
---
(In reply to comment #6)
> I have tried booting with both nouveau and nvidia blacklisted in console mode
> and still get the same behaviour.
>
> As mention in comment #4, acpi=off no
Hi Scott,
Please don't top-post.
On Mon, 26 Mar 2012 15:59:56 -0400, Scott Ondercin wrote:
> -I've been running the computer for over an hour currently and it feels
> perfectly fine. Even the hard drive feels only mildly warm. Nonetheless,
> I'm getting 96C readings for my PCI Adapter.
>
> I
-I've been running the computer for over an hour currently and it feels
perfectly fine. Even the hard drive feels only mildly warm. Nonetheless, I'm
getting 96C readings for my PCI Adapter.
Is there a way to modify my /etc/sensors.conf file to change the input levels
or high/crit temps for t
On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
>> Instead of rolling our own custom quirk_xfer function, use the bit_algo
>> pre_xfer and post_xfer functions to setup and teardown bit-banged
>> i2c transactions.
>>
>> gmbus_xf
On Mon, Mar 26, 2012 at 11:08 PM, Daniel Vetter wrote:
>
> On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote:
> > On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote:
> > > According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> > > actually gmbus pin pair 6 (gmbus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Also, can you check whether disabling vt-d does work around the
> issue?
Yes, that does appear to stay operational for longer on:
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21
BST 2012
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Ok, this is ugly. Do you have any special module options for i915
> set (like i915_enable_rc6)?
None set:
adrastea ~ # cat /proc/cmdline
BOOT_IMAGE=3.3.0-04074-g53 rw root=0
> Also, can you check whether disa
The GMBUS controller can report a NAK condition while a transaction is
still active. If the driver is fast enough, and the bus is slow enough,
the driver may clear the NAK condition while the controller is still
busy, resulting in a confused GMBUS controller. This will leave the
controller in a ba
Instead of letting other modules directly access the ->gmbus array,
introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
for a given gmbus pin pair identifier. This API enables later refactoring
of the gmbus pin pair list.
Note: The gmbus pin must be checked for validity befor
The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
transaction) during a DATA or WAIT phase. In other words, the
controller rejects a STOP requested as part of the first transaction in a
sequence.
Thus, for the first transaction we must always use a WAIT cycle, detect
when the d
Save the GMBUS2 value read while polling for state changes, and then
reuse this value when determining for which reason the loops were exited.
This is a small optimization which saves a couple of bus accesses for
memory mapped IO registers.
Signed-off-by: Daniel Kurtz
Reviewed-by: Chris Wilson
-
This memory is always allocated, and it is always a fixed size, so just
allocate it along with the rest of the driver state.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/intel_i2c.c | 10 --
2 files changed, 1 insertions(+), 11 deleti
A common method of probing an i2c bus is trying to do a zero-length write.
Handle this case by checking the length first before decrementing it.
This is actually important, since attempting a zero-length write is one
of the ways that i2cdetect and i2c_new_probed_device detect whether
there is devi
Instead of rolling our own custom quirk_xfer function, use the bit_algo
pre_xfer and post_xfer functions to setup and teardown bit-banged
i2c transactions.
gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
either i2c_bit_algo.master_xfer or its own. So, Similarly, let gmbus_func
It is very common for an i2c device to require a small 1 or 2 byte write
followed by a read. For example, when reading from an i2c EEPROM it is
common to write and address, offset or index followed by a reading some
values.
The i915 gmbus controller provides a special "INDEX" cycle for performing
80 col, spaces around operators and other basic cleanup.
Some info message cleanup.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c | 32 +---
1 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/driver
This patchset addresses a couple of issues with the i915 gmbus implementation:
* fixes misassigned pin port pair for HDMI-D
* fixes write transactions when they are the only transaction requested
(including large >4-byte writes) by terminating every transaction with a
WAIT cycle.
* returns
There is no GMBUS "disabled" port 0, nor "reserved" port 7.
For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
gmbus ports, which means every real gmbus port has a gpio pin.
Given these realizations, clean up gmbus initialization.
Tested on Sandybridge (gen 6, PCH == CougarP
According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.
[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org
Note: the "reserved" and "disabled" pairs do
Hi Linus,
Could you please pull the dma-buf updates for 3.4? This includes the
following key items:
- kernel cpu access support,
- flag-passing to dma_buf_fd,
- relevant Documentation updates, and
- some minor cleanups and fixes.
These changes are needed for the drm prime/dma-buf interface code
Save the GMBUS2 value read while polling for state changes, and then
reuse this value when determining for which reason the loops were exited.
This is a small optimization which saves a couple of bus accesses for
memory mapped IO registers.
Signed-off-by: Daniel Kurtz
Reviewed-by: Chris Wilson
-
It is very common for an i2c device to require a small 1 or 2 byte write
followed by a read. For example, when reading from an i2c EEPROM it is
common to write and address, offset or index followed by a reading some
values.
The i915 gmbus controller provides a special "INDEX" cycle for performing
The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
transaction) during a DATA or WAIT phase. In other words, the
controller rejects a STOP requested as part of the first transaction in a
sequence.
Thus, for the first transaction we must always use a WAIT cycle, detect
when the d
The GMBUS controller can report a NAK condition while a transaction is
still active. If the driver is fast enough, and the bus is slow enough,
the driver may clear the NAK condition while the controller is still
busy, resulting in a confused GMBUS controller. This will leave the
controller in a ba
A common method of probing an i2c bus is trying to do a zero-length write.
Handle this case by checking the length first before decrementing it.
This is actually important, since attempting a zero-length write is one
of the ways that i2cdetect and i2c_new_probed_device detect whether
there is devi
Instead of letting other modules directly access the ->gmbus array,
introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
for a given gmbus pin pair identifier. This API enables later refactoring
of the gmbus pin pair list.
Note: The gmbus pin must be checked for validity befor
This memory is always allocated, and it is always a fixed size, so just
allocate it along with the rest of the driver state.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/intel_i2c.c | 10 --
2 files changed, 1 insertions(+), 11 deleti
There is no GMBUS "disabled" port 0, nor "reserved" port 7.
For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
gmbus ports, which means every real gmbus port has a gpio pin.
Given these realizations, clean up gmbus initialization.
Tested on Sandybridge (gen 6, PCH == CougarP
Instead of rolling our own custom quirk_xfer function, use the bit_algo
pre_xfer and post_xfer functions to setup and teardown bit-banged
i2c transactions.
gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
either i2c_bit_algo.master_xfer or its own. So, Similarly, let gmbus_func
According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.
[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org
Note: the "reserved" and "disabled" pairs do
80 col, spaces around operators and other basic cleanup.
Some info message cleanup.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c | 32 +---
1 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/driver
This patchset addresses a couple of issues with the i915 gmbus implementation:
* fixes misassigned pin port pair for HDMI-D
* fixes write transactions when they are the only transaction requested
(including large >4-byte writes) by terminating every transaction with a
WAIT cycle.
* returns
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these use
On Tue, Mar 27, 2012 at 01:58:47AM +0800, Daniel Kurtz wrote:
> On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter wrote:
> > On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> >> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> >> pre_xfer and post_xfer function
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #15 from Daniel Vetter 2012-03-26 13:40:43 PDT
---
> --- Comment #14 from stefan 2012-03-26 13:17:45
> PDT ---
> Hi Daniel,
> I believe I'm also bitten by this bug and I'd like to test your patch.
> Unfortunately, MI_WRITE_NOPID_RE
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #14 from stefan 2012-03-26 13:17:45 PDT
---
Hi Daniel,
I believe I'm also bitten by this bug and I'd like to test your patch.
Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
and I couldn't find any reference. I
On Mon, Mar 26, 2012 at 04:02:55PM +0100, Dave Airlie wrote:
> +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> + struct drm_file *file_priv, uint32_t handle, uint32_t flags,
> + int *prime_fd)
> +{
> + struct drm_gem_object *obj;
> +
> + obj = drm_gem_obje
https://bugzilla.kernel.org/show_bug.cgi?id=42941
Len Brown changed:
What|Removed |Added
CC||l...@kernel.org
Component|Hibernati
Hi Laurent,
Please refer to the comments below.
On 03/22/2012 12:04 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function impl
On Mon, Mar 26, 2012 at 10:26:39PM +0800, Daniel Kurtz wrote:
> This patchset addresses a couple of issues with the i915 gmbus implementation:
> * fixes misassigned pin port pair for HDMI-D
> * fixes write transactions when they are the only transaction requested
>(including large >4-byte wri
https://bugzilla.kernel.org/show_bug.cgi?id=42876
ArTourter changed:
What|Removed |Added
CC||artour...@gmail.com
--- Comment #6 from A
On Mon, Mar 26, 2012 at 10:26:40PM +0800, Daniel Kurtz wrote:
> 80 col, spaces around operators and other basic cleanup.
> Some info message cleanup.
>
> Signed-off-by: Daniel Kurtz
On reconsideration, nacked. You desperately try to squeeze a function with
already 5 indent levels (not counting i
On Mon, Mar 26, 2012 at 10:26:45PM +0800, Daniel Kurtz wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
> for a given gmbus pin pair identifier. This API enables later refactoring
> of the gmbus
On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
>
> Signed-off-by: Daniel Kurtz
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mob
On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
>
> Given these realizations, clea
On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
>
> Signed-off-by: Daniel Kurtz
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mob
On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
>
> Given these realizations, clea
On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote:
> > According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> > actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
> > Pin pair 7 is a reserved p
https://bugs.freedesktop.org/show_bug.cgi?id=46724
Jerome Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> pre_xfer and post_xfer functions to setup and teardown bit-banged
> i2c transactions.
>
> gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
>
On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote:
> According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
> Pin pair 7 is a reserved pair.
>
> [1] Documentation for [DevSNB+] and [DevIBX], as found on
> h
On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
> On 21/03/12 10:47, Dave Airlie wrote:
> > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> > knows), missed irq fixes, stencil tiling fixes, interlaced support,
> > aliasesd PPGTT support for SNB/IVB, swizzling f
Hi Linus,
Could you please pull the dma-buf updates for 3.4? This includes the
following key items:
- kernel cpu access support,
- flag-passing to dma_buf_fd,
- relevant Documentation updates, and
- some minor cleanups and fixes.
These changes are needed for the drm prime/dma-buf interface code
From: Dave Airlie
This adds the basic drm dma-buf interface layer, called PRIME,
The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.
The flags value is currently limited to O_CLOEXEC.
Acknowledgement
s 0x50
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... Yes
> > (confidence 8, not a hardware monitoring chip)
> > Probing for `EDID EEPROM'...No
> > Client found at address 0x52
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... Yes
> > (confidence 8, not a hardware monitoring chip)
> >
> > Now follows a summary of the probes I have just done.
> > Just press ENTER to continue:
> >
> > Driver `coretemp':
> > * Chip `Intel digital thermal sensor' (confidence: 9)
> >
> > To load everything that is needed, add this to /etc/modules:
> > #cut here
> > # Chip drivers
> > coretemp
> > #cut here
> > If you have some drivers built into your kernel, the list above will
> > contain too many modules. Skip the appropriate ones!
> >
> > Do you want to add these lines automatically to /etc/modules? (yes/NO)y
> > Successful!
> >
> > Monitoring programs won't work until the needed modules are
> > loaded. You may want to run 'service module-init-tools start'
> > to load them.
> >
> > Unloading i2c-dev... OK
> > Unloading cpuid... OK
> >
> > And when I try to run module-init-tools, I get:
> >
> > sgo542 at NostalgiaforInfinity:~$ sudo service module-init-tools start
> > module-init-tools stop/waiting
> >
> > I've heard I might be able to fix this by tweaking the /etc/sensors.conf
> > file,
> > but I'm unsure how to even start with that. I am moderately experiences
> > with
> > Linux, but by no means an expert. Any help would be appreciated, before it
> > gets hot outside and my computer becomes completely unusable.
>
> > ___
> > lm-sensors mailing list
> > lm-sensors at lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120326/58bae7cb/attachment-0001.htm>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Also, can you check whether disabling vt-d does work around the
> issue?
Yes, that does appear to stay operational for longer on:
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21
BST 2012
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Ok, this is ugly. Do you have any special module options for i915
> set (like i915_enable_rc6)?
None set:
adrastea ~ # cat /proc/cmdline
BOOT_IMAGE=3.3.0-04074-g53 rw root=0
> Also, can you check whether disa
From: Alex Deucher
Improve handling of bpc (bits per color) in radeon.
In most cases we want 8 except for HDMI, DP, LVDS, and eDP.
v2: handle DP better.
Signed-off-by: Alex Deucher
Tested-by: Lennert Buytenhek
---
drivers/gpu/drm/radeon/atombios_crtc.c |7 +--
drivers/gpu/drm/radeon/
On 21/03/12 10:47, Dave Airlie wrote:
> i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> knows), missed irq fixes, stencil tiling fixes, interlaced support,
> aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes
This causes an eventual (after barely a
https://bugs.freedesktop.org/show_bug.cgi?id=47900
Bug #: 47900
Summary: Sampler does not work with cubemaps in 16-bit
component pixel format
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
On Tue, 20 Mar 2012 11:53:21 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Same change for intel_display.c and sna_display.c.
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 20 Mar 2012 11:53:22 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Don't worry if that fails: only the KVMr feature will be affected.
This introduces a dependency on libdrm changes that are not yet upstream.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #15 from Daniel Vetter 2012-03-26 13:40:43 PDT ---
> --- Comment #14 from stefan 2012-03-26 13:17:45 PDT
> ---
> Hi Daniel,
> I believe I'm also bitten by this bug and I'd like to test your patch.
> Unfortunately, MI_WRITE_NOPID_REG
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #14 from stefan 2012-03-26 13:17:45 PDT ---
Hi Daniel,
I believe I'm also bitten by this bug and I'd like to test your patch.
Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
and I couldn't find any reference. If
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these use
https://bugs.freedesktop.org/show_bug.cgi?id=47875
--- Comment #3 from Alexandre Demers
2012-03-26 05:29:57 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > After testing, I can confirm the problem comes from "export
> > LIBDRM_LIBS=/usr/lib/i386-linux-gnu/".
>
> LIBDRM_LIBS mus
From: Alex Deucher
Improve handling of bpc (bits per color) in radeon.
In most cases we want 8 except for HDMI, DP, LVDS, and eDP.
v2: handle DP better.
Signed-off-by: Alex Deucher
Tested-by: Lennert Buytenhek
---
drivers/gpu/drm/radeon/atombios_crtc.c |7 +--
drivers/gpu/drm/radeon/
On Tue, Mar 27, 2012 at 01:58:47AM +0800, Daniel Kurtz wrote:
> On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter wrote:
> > On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> >> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> >> pre_xfer and post_xfer function
https://bugs.freedesktop.org/show_bug.cgi?id=46724
Jerome Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Mar 26, 2012 at 04:02:55PM +0100, Dave Airlie wrote:
> +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> + struct drm_file *file_priv, uint32_t handle, uint32_t flags,
> + int *prime_fd)
> +{
> + struct drm_gem_object *obj;
> +
> + obj = drm_gem_obje
Reviewed-by: Inki Dae
2012. 3. 27. 오전 12:02 Dave Airlie 작성:
> From: Dave Airlie
>
> This adds the basic drm dma-buf interface layer, called PRIME,
>
> The main APIs exposed to userspace allow translating a 32-bit object handle
> to a file descriptor, and a file descriptor to a 32-bit object
Hi Laurent,
Please refer to the comments below.
On 03/22/2012 12:04 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function impl
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #20 from Rolf 2012-03-26 01:46:54 PDT ---
On 21.03.2012 18:49, bugzilla-daemon at freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=43278
>
> --- Comment #19 from Jonathan Nieder 2012-03-21
> 10:49:34 PDT ---
> (
On Mon, Mar 26, 2012 at 10:26:39PM +0800, Daniel Kurtz wrote:
> This patchset addresses a couple of issues with the i915 gmbus implementation:
> * fixes misassigned pin port pair for HDMI-D
> * fixes write transactions when they are the only transaction requested
>(including large >4-byte wri
On Mon, Mar 26, 2012 at 10:26:40PM +0800, Daniel Kurtz wrote:
> 80 col, spaces around operators and other basic cleanup.
> Some info message cleanup.
>
> Signed-off-by: Daniel Kurtz
On reconsideration, nacked. You desperately try to squeeze a function with
already 5 indent levels (not counting i
On Mon, Mar 26, 2012 at 10:26:45PM +0800, Daniel Kurtz wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
> for a given gmbus pin pair identifier. This API enables later refactoring
> of the gmbus
On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
>
> Signed-off-by: Daniel Kurtz
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile
On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
>
> Given these realizations, clea
On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
>
> Signed-off-by: Daniel Kurtz
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile
On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
>
> Given these realizations, clea
On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote:
> > According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> > actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
> > Pin pair 7 is a reserved p
From: Dave Airlie
This adds the basic drm dma-buf interface layer, called PRIME,
The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.
The flags value is currently limited to O_CLOEXEC.
Acknowledgement
https://bugzilla.kernel.org/show_bug.cgi?id=21652
Daniel Vetter changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Video(DRI - Intel)
AssignedTo|dr
https://bugzilla.kernel.org/show_bug.cgi?id=21652
Daniel Vetter changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #15 from Daniel Ve
https://bugzilla.kernel.org/show_bug.cgi?id=21652
--- Comment #14 from Michel D?nzer 2012-03-26 07:58:40
---
(In reply to comment #13)
> Also, it's a radeon issue afaict.
AFAICT Norbert's original report was for Intel, Mark's problem was unrelated.
--
Configure bugmail: https://bugzilla.
On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> pre_xfer and post_xfer functions to setup and teardown bit-banged
> i2c transactions.
>
> gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
>
https://bugs.freedesktop.org/show_bug.cgi?id=47881
Michel D?nzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote:
> According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
> Pin pair 7 is a reserved pair.
>
> [1] Documentation for [DevSNB+] and [DevIBX], as found on
> h
https://bugs.freedesktop.org/show_bug.cgi?id=47881
Bug #: 47881
Summary: r600_asm.c:780:12: internal compiler error with
gcc-4.7.0
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=45760
--- Comment #9 from Andrew 2012-03-26 00:45:40 PDT ---
I use World of warcraft 4.3 Cataclysm with all updates on official server
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail beca
On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
> On 21/03/12 10:47, Dave Airlie wrote:
> > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> > knows), missed irq fixes, stencil tiling fixes, interlaced support,
> > aliasesd PPGTT support for SNB/IVB, swizzling f
https://bugs.freedesktop.org/show_bug.cgi?id=47900
Bug #: 47900
Summary: Sampler does not work with cubemaps in 16-bit
component pixel format
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
https://bugs.freedesktop.org/show_bug.cgi?id=47875
Michel D?nzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, 20 Mar 2012 11:53:21 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Same change for intel_display.c and sna_display.c.
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lis
On Tue, 20 Mar 2012 11:53:22 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Don't worry if that fails: only the KVMr feature will be affected.
This introduces a dependency on libdrm changes that are not yet upstream.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
https://bugs.freedesktop.org/show_bug.cgi?id=47875
Alexandre Demers changed:
What|Removed |Added
Summary|Making r600_dri.so fails|Making r600_dri.so fails
https://bugs.freedesktop.org/show_bug.cgi?id=47875
--- Comment #1 from Alexandre Demers
2012-03-25 22:32:19 PDT ---
After testing, I can confirm the problem comes from "export
LIBDRM_LIBS=/usr/lib/i386-linux-gnu/". When it is not set, the build goes all
the way to the end.
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=47875
--- Comment #3 from Alexandre Demers 2012-03-26
05:29:57 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > After testing, I can confirm the problem comes from "export
> > LIBDRM_LIBS=/usr/lib/i386-linux-gnu/".
>
> LIBDRM_LIBS mus
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #20 from Rolf 2012-03-26 01:46:54 PDT ---
On 21.03.2012 18:49, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=43278
>
> --- Comment #19 from Jonathan Nieder 2012-03-21 10:49:34
> PDT ---
> (In
https://bugzilla.kernel.org/show_bug.cgi?id=21652
Daniel Vetter changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Video(DRI - Intel)
AssignedTo|dr
1 - 100 of 107 matches
Mail list logo
