Dear Chen,
thanks for your patch.
Firstly, is Chen your first or last name? If it is your first name, your
From address should be switched.
Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails.
Secondly, coul
On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel
wrote:
> Dear Chen,
>
>
> thanks for your patch.
>
> Firstly, is Chen your first or last name? If it is your first name, your
> From address should be switched.
Chen is may last name.
>
> Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen:
>> W
Dear Huacai,
Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen:
> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote:
> > thanks for your patch.
> >
> > Firstly, is Chen your first or last name? If it is your first name, your
> > From address should be switched.
> Chen is may last name.
On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel
wrote:
> Dear Huacai,
>
>
> Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen:
>> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote:
>
>> > thanks for your patch.
>> >
>> > Firstly, is Chen your first or last name? If it is your first name, yo
Am Montag, den 13.08.2012, 16:04 +0800 schrieb Huacai Chen:
> On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel wrote:
> > Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen:
> >> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote:
[…]
> >> > Am Montag, den 13.08.2012, 10:09 +0800 schrieb Hua
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:
x
eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.
However, timings
Hi,
While looking at the kernel DRM code, I've noticed that in many places
we kmalloc() memory to store the raw EDID information, whether it be
from a DDC adapter, or loaded from firmware.
Nowhere can I find where this memory is freed. It seems in several
places that we assign it into connector-
On Mon, Aug 06, 2012 at 07:44:16AM +1000, Dave Airlie wrote:
> >> The "correct" approach is clearly to just have the drm core change the
> >> i2c mux before requesting edid, but that's made difficult because of the
> >> absence of ordering guarantees in initialisation. I don't like quirking
> >> th
We use __fls() to find the most significant bit. Using that, the
loop can be avoided. A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.
The routine is now exact up to 2^24. Above
We use __fls() to find the most significant bit. Using that, the
loop can be avoided. A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.
The routine is now exact up to 2^24. Above
Remove the copy of i2f() in r600_blit_kms.c
We rename the function to something longer now that it is a global
symbol. This reduces the likelyhood of unintended clashes later.
This might be a candidate for inclusion inside general drm infrastructure.
However, at the moment only the radeon driver
This allows gcc to fold duplicate calls into a single call. Since
the current users do actually call it multiple times with the
same arguments, this is an obvious win.
---
drivers/gpu/drm/radeon/r600_blit.c |2 +-
drivers/gpu/drm/radeon/r600_blit_shaders.h |2 +-
2 files changed,
Hi,
I've been carrying this fix privately for far too long; without it, I
cannot enable the hardware I2C for either of my Radeons RV280 or RV350.
It does not fix the I2C for my rv100, which remains broken.
The nature of the failure is that the display fails completely:
[ 35.067825] [drm:dr
While reading through the Intel driver code, I spotted this in
I830SetPortAttributeOverlay:
} else if (attribute == xvPipe) {
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
if ((value < -1) || (value > xf86_config->num_crtc))
Hi,
guilty driver is probably udl_fb.c
any ideas?
[ 42.890551] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 42.890585] released /dev/fb1 user=1 count=0
[ 42.890702] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 43.053034] type=1400 audit(1344698343.496:9): avc: denie
Hi Daniel.
The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the
i915 driver initializes itself. I bisected this down to commit
24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the
blc controller on the right pipe), and when I revert that, and also
a4f32fc3a37
On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote:
> On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote:
> > Hi Daniel.
> >
> > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the
> > i915 driver initializes itself. I bisected this down to commit
> > 24ded2044
On Sun, Aug 12, 2012 at 11:33:05AM -0700, Greg KH wrote:
> On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote:
> > > Hi Daniel.
> > >
> > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the
> > > i915 dri
(Bringing this back to the mailing lists after a bit of uninteresting private
conversation.)
> Honestly, I think we need a way to force disable gmbus with a module
> parameter or something anyway. It's not the first time gmbus has been
> implicated with an issue. Maybe it even exists already, bu
Yeah, I know I'm on vacation, but without coding I die of boringness in less
than a week.
This patchset is currently based on Jeromes VA fencing patch, but in the end
makes it superfluous. It just moves the whole VM handling into the CP ring,
removing the need to wait for anything directly in the
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbindi
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c |5 +++--
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
So it looks more like the rest of the driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 35 +---
drivers/gpu/drm/radeon/radeon_asic.c | 50 ++
drivers/gpu/drm/radeon/radeon_gart.c | 16 +--
3 files
It actually isn't very useful.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |2 --
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_gart.c |1 -
drivers/gpu/drm/radeon/si.c
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/rad
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 31 ---
drivers/gpu/drm/radeon/radeon.h |6 --
drivers/gpu/drm/radeon/radeon_asic.c | 1
Move binding onto the ring, simplifying handling a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c| 20 ++---
drivers/gpu/drm/radeon/radeon.h| 30 +++-
drivers/gpu/drm/radeon/radeon_asic.c |9 +--
drivers/gpu/drm/radeon/radeon_asic.h |4
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 28 +
drivers/gpu/drm/radeon/radeon_gart.c | 107 +++--
Makes it easier to move it into the rings.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 22 +++---
drivers/gpu/drm/radeon/radeon.h | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_asic.h |7
Currently doing the update with the CP.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 20 ++
drivers/gpu/drm/radeon/nid.h |1 +
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |3 ++
drivers/gpu/drm/radeon/
On Mon August 13 2012 13:48:28 Soby Mathew wrote:
> Hi Hans,
>The patch seems to cover most of the requirement. I find 2 gaps:
>
> > +/* DV-class control IDs defined by V4L2 */
> > +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> > +#define V4L2_CID_DV_CLASS
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
> +
> + if (!ret) {
> + cb->base.flags = 0;
> + cb->base.func = __dma_fence_wake_func;
> + cb->base.private = priv;
> + cb->fence = fence;
> + cb->func = func;
> It's not 100% complete cause page table updates should be made with the DMA
> ring, but we haven't released documentation for that yet, so I currently
> use CP memory writes instead.
Sad. Any release time hint? (the DMA ring will cleanup a lot of code).
BTW, maybe at the same time the HDP_NONSU
Alex, Maciej, please test the following to see if it fixes the issue
[1], thanks.
BR,
Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
Jani Nikula (2):
drm/i915: extract connector update from intel_ddc_get_modes() for
reuse
drm/i915: fall back to bit-banging if GMBUS fails in
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_modes.c | 31 ++-
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6d235bd465309e12f4c56ea16e7
Author: Daniel Vetter
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
Author: Daniel Vetter
Date
Hi Hans,
The patch seems to cover most of the requirement. I find 2 gaps:
> +/* DV-class control IDs defined by V4L2 */
> +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> +
> +#define
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implici
On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
> (Bringing this back to the mailing lists after a bit of uninteresting private
> conversation.)
>
> > Honestly, I think we need a way to force disable gmbus with a module
> > parameter or something anyway. It's not the first time gm
On Sat, Aug 11, 2012 at 6:51 PM, Russell King - ARM Linux
wrote:
> Hi,
>
> While looking at the kernel DRM code, I've noticed that in many places
> we kmalloc() memory to store the raw EDID information, whether it be
> from a DDC adapter, or loaded from firmware.
>
> Nowhere can I find where this
On Mon, 13 Aug 2012, Daniel Vetter wrote:
> On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
>> (Bringing this back to the mailing lists after a bit of uninteresting private
>> conversation.)
>>
>> > Honestly, I think we need a way to force disable gmbus with a module
>> > paramet
On 08/12/2012 04:31 PM, Paul Menzel wrote:
> So I vote for getting this into stable and hopefully the maintainers
> agree.
Paul -
We obviously disagree on whether this makes sense for -stable. If you
feel strongly that it should go in, I suggest that you go ahead and
submit it for inclusion.
Th
On Fri, Aug 10, 2012 at 6:52 PM, Russell King - ARM Linux
wrote:
> At the moment, there is an inconsistency in the way modes are named.
> Modes with timings parsed from the EDID information will call
> drm_mode_set_name(), which will name the mode using this form:
>
> x
>
> eg, 1920x1080i
From: Forest Bond
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index bfb0565..24
From: Forest Bond
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |1 -
2 files changed, 3 d
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug]
From: Forest Bond
This causes the pipe to be forced off prior to initial mode set, which
roughly mirrors the behavior of the i915 driver. It fixes initial mode
setting on my Intel DN2800MT (Cedarview) board. Witho
https://bugzilla.kernel.org/show_bug.cgi?id=16560
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=16581
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=17241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Other
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
> Currently doing the update with the CP.
>
> Signed-off-by: Christian König
NAK until point below are addressed
> ---
> drivers/gpu/drm/radeon/ni.c | 20 ++
> drivers/gpu/drm/radeon/nid.h |1 +
> drivers/gp
On Mon, Aug 13, 2012 at 6:25 AM, Christian König
wrote:
> Yeah, I know I'm on vacation, but without coding I die of boringness in less
> than a week.
>
> This patchset is currently based on Jeromes VA fencing patch, but in the end
> makes it superfluous. It just moves the whole VM handling into th
On 2012-08-08 08:18 +0200, Sven Joachim wrote:
> On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>
>> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>>> once, subsequent attempts fail:
>>>
>>> ,
>>> | Aug 8
https://bugzilla.kernel.org/show_bug.cgi?id=17692
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=17782
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 13.08.2012 18:19, Jerome Glisse wrote:
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
Currently doing the update with the CP.
Signed-off-by: Christian König
NAK until point below are addressed
[SNIP]
For this to work properly you will need patch :
http://people.freedesktop.org/
On 13.08.2012 14:53, Sylvain BERTRAND wrote:
It's not 100% complete cause page table updates should be made with the DMA
ring, but we haven't released documentation for that yet, so I currently
use CP memory writes instead.
Sad. Any release time hint? (the DMA ring will cleanup a lot of code).
On Mon, Aug 13, 2012 at 12:53 PM, Christian König
wrote:
> On 13.08.2012 18:19, Jerome Glisse wrote:
>>
>> On Mon, Aug 13, 2012 at 6:26 AM, Christian König
>> wrote:
>>>
>>> Currently doing the update with the CP.
>>>
>>> Signed-off-by: Christian König
>>
>> NAK until point below are addressed
>
On Mon, Aug 13, 2012 at 05:26:03PM +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: i
On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen 陈俊杰 wrote:
>
> Since there is no response for the last mail. Maybe it didn't sent
> successfully. So I send it again. Here is the initial patch for siliconmotion
> kernel driver.
What's with the #ifdef 0 or #ifdef 1?
Why is there a bunch of
On Sun, 12 Aug 2012 10:01:44 +0100, Russell King - ARM Linux
wrote:
> While reading through the Intel driver code, I spotted this in
> I830SetPortAttributeOverlay:
>
> } else if (attribute == xvPipe) {
> xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
>
On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>
> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
> >
> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more
Hi Linus,
radeon and intel fixes mostly, one fix to the mgag200 driver to not hang
on certain server variants.
Dave.
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://peopl
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith Packar
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a bit
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a/driv
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i91
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807..952
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b099a17..754
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
di
https://bugs.freedesktop.org/show_bug.cgi?id=43477
--- Comment #5 from maximlevit...@gmail.com 2012-08-14 04:51:48 UTC ---
This still happens on nouveau, despite OpenGL 3.0 advertised.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=43477
Andreas Boll changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
When SWIOTLB is configured, if without this patch kernel compilation
fails.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_ttm.c |4
1 files changed, 4 insertions(+), 0 deletions(-
Dear Chen,
thanks for your patch.
Firstly, is Chen your first or last name? If it is your first name, your
On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel
wrote:
> Dear Chen,
>
>
> thanks for your patch.
>
> Firstly, is Chen your first or last name? If it is your first name, your
> From address should be switched.
Chen is may last name.
>
> Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen:
>> W
es from the
beginning as for example Alex Deucher is doing [1].
[?]
Thanks,
Paul
[1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/112079d5/attachment.pgp>
On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel
wrote:
> Dear Huacai,
>
>
> Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen:
>> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote:
>
>> > thanks for your patch.
>> >
>> > Firstly, is Chen your first or last name? If it is your first name, yo
m line and paste it after the Subject line?
wereHamster on #git suggested to use
git send-email --from 'Huacai Chen '
and it should do the right thing.
Thanks,
Paul
> > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html
-- next part
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
river-initial-patch.patch
Type: application/octet-stream
Size: 369305 bytes
Desc: 0001-Siliconmotion-new-kernel-driver-initial-patch.patch
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/9fc4abf7/attachment-0001.obj>
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbindi
Yeah, I know I'm on vacation, but without coding I die of boringness in less
than a week.
This patchset is currently based on Jeromes VA fencing patch, but in the end
makes it superfluous. It just moves the whole VM handling into the CP ring,
removing the need to wait for anything directly in the
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c |5 +++--
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
So it looks more like the rest of the driver.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 35 +---
drivers/gpu/drm/radeon/radeon_asic.c | 50 ++
drivers/gpu/drm/radeon/radeon_gart.c | 16 +--
3 files
It actually isn't very useful.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |2 --
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_gart.c |1 -
drivers/gpu/drm/radeon/si.c
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/rad
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 31 ---
drivers/gpu/drm/radeon/radeon.h |6 --
drivers/gpu/drm/radeon/radeon_asic.c | 1
Move binding onto the ring, simplifying handling a bit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c| 20 ++---
drivers/gpu/drm/radeon/radeon.h| 30 +++-
drivers/gpu/drm/radeon/radeon_asic.c |9 +--
drivers/gpu/drm/radeon/radeon_asic.h |4
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 28 +
drivers/gpu/drm/radeon/radeon_gart.c | 107 +++--
Makes it easier to move it into the rings.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 22 +++---
drivers/gpu/drm/radeon/radeon.h | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_asic.h |7
Currently doing the update with the CP.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 20 ++
drivers/gpu/drm/radeon/nid.h |1 +
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |3 ++
drivers/gpu/drm/radeon/
On Mon August 13 2012 13:48:28 Soby Mathew wrote:
> Hi Hans,
>The patch seems to cover most of the requirement. I find 2 gaps:
>
> > +/* DV-class control IDs defined by V4L2 */
> > +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> > +#define V4L2_CID_DV_CLASS
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
> +
> + if (!ret) {
> + cb->base.flags = 0;
> + cb->base.func = __dma_fence_wake_func;
> + cb->base.private = priv;
> + cb->fence = fence;
> + cb->func = func;
> It's not 100% complete cause page table updates should be made with the DMA
> ring, but we haven't released documentation for that yet, so I currently
> use CP memory writes instead.
Sad. Any release time hint? (the DMA ring will cleanup a lot of code).
BTW, maybe at the same time the HDP_NONSU
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implici
1 - 100 of 138 matches
Mail list logo
