On 04/09/2012 15.56, Adam Jackson wrote:
On 9/4/12 9:41 AM, Luca Ellero wrote:
I've read this page:
http://intellinuxgraphics.org/documentation.html
and found a lot of interesting docs on various chipsets. But I'm
interested on GMA3150 (found for example on Atom processor D450
LunaPier) and I
Xingchao,
We have the drm_i915_display_funcs.write_eld() for such
functionalities.
Thanks,
Fengguang
On Wed, Sep 05, 2012 at 01:06:16PM +0800, Wang Xingchao wrote:
> ELD infomation should update immediately when detected HDMI hot plug event.
> The related ELD_VALID bit should be set/clear to gen
ELD infomation should update immediately when detected HDMI hot plug event.
The related ELD_VALID bit should be set/clear to generate unsolicited event
to notify Alsa driver this change.
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/intel_hdmi.c | 28
1 fil
On Sun, 19 Aug 2012 21:12:25 +0200
Daniel Vetter wrote:
> CRT is the first output which can be cloned, hence we cannot (yet)
> move the dpms handling over to disable/enable. This requires some more
> smarts in intel_crtc_dpms first to set the display pipe status
> depening upon encoder->connector
On Sun, 19 Aug 2012 21:12:37 +0200
Daniel Vetter wrote:
> Instead of going through the crtc helper function tables.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/g
On Sun, 19 Aug 2012 21:12:29 +0200
Daniel Vetter wrote:
> All encoders are now converted so there's no need for these checks any
> more.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 24
> 1 file changed, 8 insertions(+), 16 deletions(
Passing in the old fb, having overwritten the current fb, leads to
some neatly convoluted code. It's much simpler if we defer the
crtc->fb update to the place that updates the hw, in pipe_set_base.
This way we also don't need to restore anything in case something
fails - we only update crtc->fb onc
With this change we can (finally!) rip out a few of the temporary hacks
and clean up a few other things:
- Kill intel_crtc_prepare_encoders, now unused.
- Kill the hacks in the crtc_disable/enable functions to always call the
encoder callbacks, we now always call the crtc functions with the right
On Sun, 19 Aug 2012 21:12:46 +0200
Daniel Vetter wrote:
> Similar to the sdvo code we poke the dvo encoder whether the output is
> active. Safe that dvo encoders are not standardized, so this requires
> a new callback into the dvo chip driver.
>
> Hence implement that for all 6 dvo drivers.
>
>
On Sun, 19 Aug 2012 21:12:45 +0200
Daniel Vetter wrote:
> SDVO is the first real special case - we support multiple outputs on
> the same encoder and the encoder dpms state isn't the same as when
> just disabling the outputs when the encoder is cloned.
>
> Hence we need a real connector get_hw_s
On Sun, 19 Aug 2012 21:12:44 +0200
Daniel Vetter wrote:
> Note that even though this connector is cloneable we still can use the
> exact same test to check whether the connector is on or whether the
> encoder is enabled - both the dpms code and the encoder disable/enable
> frob the exact same hw
On Sun, 19 Aug 2012 21:12:43 +0200
Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> ind
On Sun, 19 Aug 2012 21:12:42 +0200
Daniel Vetter wrote:
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_tv.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 5dc08b9..98ad7fd
On Sun, 19 Aug 2012 21:12:41 +0200
Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 29 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 24
> 3 files changed,
On Sun, 19 Aug 2012 21:12:40 +0200
Daniel Vetter wrote:
> Also add some macros to make the pipe computation a bit easier.
>
> v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/
On Sun, 19 Aug 2012 21:12:39 +0200
Daniel Vetter wrote:
> It is all glorious if we try really hard to only enable/disable an
> entire display pipe to ensure that everyting happens in the right
> order. But if we don't know the output configuration when the driver
> takes over, this will all be fo
On Sun, 19 Aug 2012 21:12:38 +0200
Daniel Vetter wrote:
> This is the first tiny step towards cross-checking the entire modeset
> state machine with WARNs. A crtc can only be enabled when it's
> actually in use, i.e. crtc->active imlies crtc->enabled.
>
> Unfortunately we can't (yet) check this
On Sun, 19 Aug 2012 21:12:31 +0200
Daniel Vetter wrote:
> And the following static functions required by it:
> drm_encoder_crtc_ok, drm_crtc_helper_disable
>
> No changes safe for the s/drm/intel prefix change.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 31
On Sun, 19 Aug 2012 21:12:36 +0200
Daniel Vetter wrote:
> With the new infrastructure we're doing this when enabling/disabling
> the entire display pipe.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_crt.c | 2 --
> drivers/gpu/drm/i915/intel_display.c | 24 -
On Sun, 19 Aug 2012 21:12:35 +0200
Daniel Vetter wrote:
> - We don't have the ->get_crtc callback.
> - Call intel_encoder->disable directly.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 25 -
> 1 file changed, 4 insertions(+), 21 delet
On Sun, 19 Aug 2012 21:12:34 +0200
Daniel Vetter wrote:
> Together with the static helper functions drm_crtc_prepare_encoders
> and drm_encoder_disable (which will be simplified in the next patch,
> but for now are 1:1 copies). Again, no changes beside new names for
> these functions.
>
> Also c
On Sun, 19 Aug 2012 21:12:33 +0200
Daniel Vetter wrote:
> Also kill the error-path, we have a fixed connector-encoder mapping.
>
> Unfortunately we can't rip out all the ->best_encoder callbacks, these
> are all still used by the fb_helper. Neat helper layering violation there.
>
> Signed-off-b
On Sun, 19 Aug 2012 21:12:32 +0200
Daniel Vetter wrote:
> And drop the check, we always have it.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_displa
On Sun, 19 Aug 2012 21:12:30 +0200
Daniel Vetter wrote:
> We no longer need them. And now that all encoders are converted, we
> can finally move the cpt modeset check to the right place - at the end
> of the crtc_enable function.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/in
On Wed, 29 Aug 2012 09:12:23 +0200
Daniel Vetter wrote:
> Yeah, big patch but I couldn't come up with a neat idea of how to
> split it up further, that wouldn't break dpms on cloned configs
> somehow. But the changes in dvo/sdvo/crt are all pretty much
> orthonogal, so it's not too bad a patch.
>
In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.
For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinnin
Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.
One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be
We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.
Signed-
A few of the earlier registers where enlarged and so the Base Data of
Stolem Memory Register (BDSM) was pushed to 0xb0.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 97f6735..9de9cd9 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i91
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 984a0c5..577a96a 100644
--- a/drivers/gpu/drm/i915/intel_rin
As we may wish to wrap regions preallocated by the BIOS, we need to do
that before carving out contiguous chunks of stolen space for FBC.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_stolen.c | 110 ---
As FBC is commonly disabled due to limitations of the chipset upon
output configurations, on many systems FBC is never enabled. For those
systems, it is advantageous to make use of the stolen memory for other
objects and so we defer allocation of the FBC chunk until we actually
require it. This inc
The primary purpose of this was to debug some use-after-free memory
corruption that was causing an OOPS inside drm/i915. As it turned out
the corruption was being caused elsewhere and i915.ko as a major user of
many objects was being hit hardest.
Indeed as we do frequent the generic kmalloc caches
In order to accommodate objects that are not backed by struct pages, but
instead point into a contiguous region of stolen space, we need to make
various changes to avoid dereferencing obj->pages or obj->base.filp.
First introduce a marker for the stolen object, that specifies its
offset into the s
To be used later by i915 to preallocate exact blocks of space from the
range manager.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_mm.c | 49 ++
include/drm/drm_mm.h |4
2 files changed, 53 insertions(+)
diff --g
This will be used i915 in forthcoming patches in order to measure the
largest contiguous chunk of memory available for enabling chipset
features.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_mm.c | 55 +++---
include/drm/drm_mm.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 175 ++-
1 file changed, 116 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7946d73..070ddf2 100644
--- a/drivers/gpu/drm/i9
Allow for the creation of GEM objects backed by stolen memory. As these
are not backed by ordinary pages, we create a fake dma mapping and store
the address in the scatterlist rather than obj->pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|3 +
drivers/gpu/drm
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_overlay.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index afd0f30..2fa20a4 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dd49046..fe3f60c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 159 ---
1 file changed, 100 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f1cef1f..7946d73 100644
--- a/drivers/gpu/drm/i9
Stolen objects also share the property that they have no backing shmemfs
filp, but they can be used with pwrite/pread/gtt-mapping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_gem.c |4 ++--
2 files changed, 7 insertions(+), 2 deleti
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ---
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f6
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then
By providing a callback for when we need to bind the pages, and then
release them again later, we can shorten the amount of time we hold the
foreign pages mapped and pinned, and importantly the dmabuf objects then
behave as any other normal object with respect to the shrinker and
memory management.
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 36
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 37
This addresses all the comments I've received so far, except for the
handling of pwrite/pread through additional obj->ops as I think the cure
was worse than the disease in that case (due to the fiddling around
required for sg iterator and tracking individual struct page operations).
-Chris
___
Just a spark of an idea to see if this is valid.
Given extreme memory pressure where we must zap our own caches and bound
buffers or else we fail to allocate a structure, we have a choice of
propagating that interrupt back to userspace or to quietly suppress it
in the hope of making the allocation
On Sun, 19 Aug 2012 21:12:27 +0200
Daniel Vetter wrote:
> Similar to the sdvo conversion.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dvo.c | 32 ++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i
On Sun, 19 Aug 2012 21:12:26 +0200
Daniel Vetter wrote:
> Similar to crt, this doesn't convert the dpms functions.
> Also similar to crt, we don't switch of the display pipe
> for the intermediate modes, only DPMS_OFF is truely off.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915
On Tue, Sep 4, 2012 at 9:33 PM, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:24 +0200
> Daniel Vetter wrote:
>
>> -static void intel_dp_prepare(struct drm_encoder *encoder)
>> +static void intel_disable_dp(struct intel_encoder *encoder)
>> {
>> - struct intel_dp *intel_dp = enc_to_intel_d
On Sun, 19 Aug 2012 21:12:24 +0200
Daniel Vetter wrote:
> -static void intel_dp_prepare(struct drm_encoder *encoder)
> +static void intel_disable_dp(struct intel_encoder *encoder)
> {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> + struct intel_dp *intel_dp = enc_to_int
On Sun, 19 Aug 2012 21:12:23 +0200
Daniel Vetter wrote:
> With the previous patch LVDS is also a simple case. Treat it
> accordingly.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 52
> +++
> 1 file changed, 14 insertions(+),
On Sun, 19 Aug 2012 21:12:22 +0200
Daniel Vetter wrote:
> Like hdmi tv outputs are simple: They only have 2 states and can't be
> cloned. Hence give it the same treatment.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_tv.c | 35 +++
> 1 fil
On Sun, 19 Aug 2012 21:12:21 +0200
Daniel Vetter wrote:
> +/* Even simpler default implementation, if there's really no special case to
> + * consider. */
> +void intel_connector_dpms(struct drm_connector *connector, int mode)
> +{
> + struct intel_encoder *encoder = intel_attached_encoder(con
On Tue, 04 Sep 2012 09:52:10 -0400, Adam Jackson wrote:
> On 9/2/12 5:40 AM, Chris Wilson wrote:
>
> > * Incoherent concurrent access with the CPU and GPU
> > https://bugs.freedesktop.org/show_bug.cgi
> > https://bugs.freedesktop.org/show_bug.cgi
References: https://bugs.freedesktop.or
On 9/4/12 9:41 AM, Luca Ellero wrote:
I've read this page:
http://intellinuxgraphics.org/documentation.html
and found a lot of interesting docs on various chipsets. But I'm
interested on GMA3150 (found for example on Atom processor D450
LunaPier) and I cannot find datasheets about it.
Can some
On 9/2/12 5:40 AM, Chris Wilson wrote:
* Incoherent concurrent access with the CPU and GPU
https://bugs.freedesktop.org/show_bug.cgi
https://bugs.freedesktop.org/show_bug.cgi
Which bugs were these meant to be?
- ajax
___
Intel-gfx mailing
Hi everybody,
I've read this page:
http://intellinuxgraphics.org/documentation.html
and found a lot of interesting docs on various chipsets. But I'm
interested on GMA3150 (found for example on Atom processor D450
LunaPier) and I cannot find datasheets about it.
Can someone please tell me where
On Tue, Sep 04, 2012 at 11:11:13AM +0300, Jani Nikula wrote:
> On Mon, 03 Sep 2012, Damien Lespiau wrote:
> > From: Damien Lespiau
> >
> > From time to time, one would like to decode a register value that have
> > been captured at a certain point in time (and say printed out with a
> > printk). i
On Mon, 03 Sep 2012, Damien Lespiau wrote:
> From: Damien Lespiau
>
> From time to time, one would like to decode a register value that have
> been captured at a certain point in time (and say printed out with a
> printk). intel_reg_dumper has all the knowledge to do that and this
> patch adds a
On Mon, 03 Sep 2012, "Woodhouse, David" wrote:
> There was a Tested-by: David Woodhouse in
> there somewhere too, but the broken list config ate it.
Thanks again for testing. Your Tested-by was not lost:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=28dcc2d60cb570d9f549c329b2f5140055
65 matches
Mail list logo
