On 2014å¹´11æ11æ¥ 22:40, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> Some minor comments inline.
>
> On 11/11/14 12:54, Andy Yan wrote:
>> Signed-off-by: Andy Yan
>> ---
>>
>> Changes in v7: None
>> Changes in v6: None
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3: None
Hi ZubairLK:
On 2014å¹´11æ11æ¥ 22:36, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> On 11/11/14 12:54, Andy Yan wrote:
>> From: Yakir Yang
>>
>> keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c
> Is there a reason for this separation? Keeping encoder in platform
On 2014å¹´11æ11æ¥ 22:20, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> This patch adds the reg-io-width binding.
>
> Hence the binding patch should come before it.
>
do you mean that I should put dts binding patch
before this patch?
> On 11/11/14 12:53, Andy Yan wrote:
>> On rockchip
On 2014å¹´11æ11æ¥ 22:16, Zubair Lutfullah Kakakhel wrote:
> Hi Andy,
>
> On 11/11/14 12:53, Andy Yan wrote:
>> the original imx hdmi driver is under staging/imx-drm,
>> which depends on imx-drm, so move the imx hdmi drvier out
> Spelling mistake. ^'driver'
>
>> to
Hi Inki,
On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote:
>
> Hi,
>
> Fortunately, I could get the user manual for Exynos7420. Below are my
> comments.
>
> Thanks,
> Inki Dae
>
> On 2014ë
10ì 23ì¼ 01:34, Ajay kumar wrote:
>> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote:
>>>
>>> Thanks
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/88f7a4e3/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/4a8d320c/attachment.html>
Signed-off-by: Andy Yan
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/drm/bridge/dw-hdmi.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644
On Tue, Nov 11, 2014 at 12:48:52PM -0700, Ross Zwisler wrote:
> Essentially we need one additional byte at the beginning of the clflush so
> that we can flip it into a clflushopt by changing that byte into a 0x66
> prefix. Two options are to either insert a 1 byte ASM_NOP1, or to add a 1
> byte
From: Yakir Yang
keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c
Signed-off-by: Andy Yan
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- move some modification from patch#5
Changes in v5: None
Changes in v4: None
Changes in
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width accesses (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
Changes in v7: None
Changes in v6:
- move some modification to patch#6
- refactor register access without
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi
Signed-off-by: Andy Yan
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes
imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.
To reuse the imx
drm driver may probe before the i2c bus, so the driver should
defer probing until it is available
Signed-off-by: Andy Yan
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter
Changes in v3: None
Changes in v2: None
CHECK: Alignment should match open parenthesis
+ if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+ (hdmi->vic == 12) || (hdmi->vic == 13) ||
CHECK: braces {} should be used on all arms of this statement
+ if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+ else {
[...]
On Tue, Nov 11, 2014 at 8:40 PM, Rian Quinn wrote:
> Right now I need to support Intel and AMD, and nVidia would be a great plus
> with VMWare being my sudo dev/test environment on travel. I have control of
> the kernel so itâs whatever I need.
>
> Can you point me to the âatomic-helpersâ
We found freescale imx5 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access
On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote:
> Yep, it's weird, I know. :)
But sure, saving opcode space, makes sense to me.
Btw, I'd still be interested about this:
> +static inline void clwb(volatile void *__p)
> +{
> + alternative_io_2(".byte "
Right now I need to support Intel and AMD, and nVidia would be a great plus
with VMWare being my sudo dev/test environment on travel. I have control of the
kernel so itâs whatever I need.
Can you point me to the âatomic-helpersâ stuff. I have never heard of that.
Is that exposed via
On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa wrote:
> Andrew Morton wrote:
> > Poor ttm guys - this is a bit of a trap we set for them.
>
> Commit a91576d7916f6cce (\"drm/ttm: Pass GFP flags in order to avoid
> deadlock.\")
> changed to use sc->gfp_mask rather than GFP_KERNEL.
>
> -
answered both your questions by private e-mail.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/651a2ddf/attachment.html>
77288...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/768359ea/attachment.html>
On Tue, Nov 11, 2014 at 8:25 PM, Rian Quinn wrote:
> Yeah, I had issues trying to get the first method to work across the board on
> all of the hardware that we need to support. One example that I saw was to
> use the second method, and then to use planes when you had to scale. So
> basically,
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/d07f5e0c/attachment.html>
Yeah, I had issues trying to get the first method to work across the board on
all of the hardware that we need to support. One example that I saw was to use
the second method, and then to use planes when you had to scale. So basically,
if you could not find a match, you would select the lowest
On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote:
> > +".byte 0x66; xsaveopt %P0",
>
> Huh, XSAVEOPT?!? Shouldn't that be CLWB??
Bah, the same opcodes, only 0x66 prefix makes it into CLWB. Could use a
comment I guess.
--
Regards/Gruss,
Boris.
Sent from a
On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> Add support for the new clwb instruction. This instruction was
> announced in the document "Intel Architecture Instruction Set Extensions
> Programming Reference" with reference number 319433-022.
>
>
From: Yakir Yang
keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c
Signed-off-by: Andy Yan
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- move some modification from patch#5
Changes in v5: None
Changes in v4: None
Changes in
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width accesses (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
Changes in v7: None
Changes in v6:
- move some modification to patch#6
- refactor register access without
We found freescale imx5 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access
On Tue, Nov 11, 2014 at 12:19 PM, Rian Quinn wrote:
> What exactly is the correct way to support cloned monitors using LibDRM. As
> I see it, there are two methods:
>
> - Use the connector array in drmModeSetCrtc
> - Use one crtc per connector, but share the same framebuffer.
>
> Right now I am
=86169 |
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/8446bd0f/attachment-0001.html>
||g/show_bug.cgi?id=86169
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/559af
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #12 from Marek ---
Created attachment 157341
--> https://bugzilla.kernel.org/attachment.cgi?id=157341=edit
logs for first not working kernel
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #11 from Marek ---
Created attachment 157331
--> https://bugzilla.kernel.org/attachment.cgi?id=157331=edit
logs for last working kernel
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=85491
Marek changed:
What|Removed |Added
CC||kordikmarek at gmail.com
--- Comment #10 from
v1: original
v2: danvet's kerneldoc nitpicks
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 17 ++---
include/drm/drm_atomic_helper.h | 3 +++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/de5b224c/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/c83597ff/attachment.html>
ing this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/05080cfa/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/b2f61799/attachment.html>
On Tue, 11 Nov 2014, Andrew Morton wrote:
> Well, attempting to fix it up and continue is nice, but we can live
> with the BUG.
>
> Not knowing which bit was set is bad.
Could we change BUG_ON to diplay the value? This keeps on coming up.
If you want to add this to the slab allocators then
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/0a3e8103/attachment.html>
Marcus
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/c76b08bf/attachment.html>
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/cbb52a51/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/10ba74e7/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/91a9cc7d/attachment-0001.html>
vel/attachments/20141111/56f64455/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/37eae9ba/attachment.html>
On Tue, 11 Nov 2014, Andrew Morton wrote:
> There's no point in doing
>
> #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
>
> because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
__GFP_DMA32 is bit
ves/dri-devel/attachments/2014/eb262e9f/attachment.html>
On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov" wrote:
> On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > > linux.com> wrote:
> > >
>
On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim
wrote:
> On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
> > On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote:
> >
> > > On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > > > But anyway - Luke, please attach
Motivated by the per-plane locking I've gone through all the get*
ioctls and reduced the locking to the bare minimum required.
v2: Rebase and make it compile ...
v3: Review from Sean:
- Simplify return handling in getplane_res.
- Add a comment to getplane_res that the plane list is invariant and
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/8ab020f0/attachment.html>
On Mon, Nov 10, 2014 at 6:16 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> While developing MST support I noticed I often got the wrong data
> back from a transaction, in a racy fashion. I noticed the scratch
> space wasn't locked against concurrent users.
>
> Based on a patch by Alex, but I've
On Wed, 12 Nov 2014 00:54:01 + Luke Dashjr wrote:
> On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
> > But anyway - Luke, please attach your .config to
> > https://bugzilla.kernel.org/show_bug.cgi?id=87891?
>
> Done: https://bugzilla.kernel.org/attachment.cgi?id=157381
>
On Wed, 12 Nov 2014 09:44:19 +0900 Joonsoo Kim
wrote:
> >
> > And it's quite infuriating to go BUG when the code could easily warn
> > and fix it up.
>
> If user wants memory on HIGHMEM, it can be easily fixed by following
> change because all memory is compatible for HIGHMEM. But, if user
On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter
wrote:
> On Tue, 11 Nov 2014, Andrew Morton wrote:
>
> > There's no point in doing
> >
> > #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
> >
> > because __GFP_DMA32|__GFP_HIGHMEM are already part of
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/0c8607f1/attachment.html>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=87891
>
> Bug ID: 87891
>Summary: kernel BUG
Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah
Kakakhel:
> Hi Andy,
>
> This patch adds the reg-io-width binding.
>
> Hence the binding patch should come before it.
>
>
> On 11/11/14 12:53, Andy Yan wrote:
> > On rockchip rk3288, only word(32-bit) accesses are
> > permitted
On 11/11/14 14:46, Andy Yan wrote:
>
> On 2014å¹´11æ11æ¥ 22:20, Zubair Lutfullah Kakakhel wrote:
>> Hi Andy,
>>
>> This patch adds the reg-io-width binding.
>>
>> Hence the binding patch should come before it.
>>
>do you mean that I should put dts binding patch
>before this patch?
Hi Andy,
Some minor comments inline.
On 11/11/14 12:54, Andy Yan wrote:
> Signed-off-by: Andy Yan
> ---
>
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/drm/bridge/dw-hdmi.txt
On 11/11/14 14:23, Lucas Stach wrote:
> Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah
> Kakakhel:
>> Hi Andy,
>>
>> This patch adds the reg-io-width binding.
>>
>> Hence the binding patch should come before it.
>>
>>
>> On 11/11/14 12:53, Andy Yan wrote:
>>> On rockchip
Hi Andy,
On 11/11/14 12:54, Andy Yan wrote:
> From: Yakir Yang
>
> keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c
Is there a reason for this separation? Keeping encoder in platform files?
If yes, then the commit message should explain that.
>
> Signed-off-by: Andy
On 10/11/14 17:36, Rob Clark wrote:
> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson
> wrote:
>> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c
>> b/drivers/gpu/drm/msm/msm_gem_prime.c
>> index ad772fe36115..4e4fa5828d5d 100644
>> --- a/drivers/gpu/drm/msm/msm_gem_prime.c
>> +++
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/d50a2b06/attachment.html>
vel/attachments/20141111/0599ebcb/attachment.html>
Hi Andy,
This patch adds the reg-io-width binding.
Hence the binding patch should come before it.
On 11/11/14 12:53, Andy Yan wrote:
> On rockchip rk3288, only word(32-bit) accesses are
> permitted for hdmi registers. Byte width accesses (writeb,
> readb) generate an imprecise external abort.
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/85f3baad/attachment.html>
Hi Andy,
On 11/11/14 12:53, Andy Yan wrote:
> the original imx hdmi driver is under staging/imx-drm,
> which depends on imx-drm, so move the imx hdmi drvier out
Spelling mistake. ^'driver'
> to drm/bridge and rename imx-hdmi to dw-hdmi
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/e19237ea/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/fc544fcd/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/95e8f62f/attachment.html>
On Tue, 2014-11-11 at 20:46 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote:
> > Yep, it's weird, I know. :)
>
> But sure, saving opcode space, makes sense to me.
>
> Btw, I'd still be interested about this:
>
> > +static inline void clwb(volatile
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/a71ee986/attachment-0001.html>
On Tue, 2014-11-11 at 20:12 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote:
> > Add support for the new clwb instruction. This instruction was
> > announced in the document "Intel Architecture Instruction Set Extensions
> > Programming Reference" with
On Tue, 2014-11-11 at 20:19 +0100, Borislav Petkov wrote:
> On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote:
> > > + ".byte 0x66; xsaveopt %P0",
> >
> > Huh, XSAVEOPT?!? Shouldn't that be CLWB??
>
> Bah, the same opcodes, only 0x66 prefix makes it into CLWB.
f to some more basic resolutions (like 800x600).
- Rian
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/5cf1c594/attachment.html>
If clwb is available on the system, use it in drm_clflush_virt_range.
If clwb is not available, fall back to clflushopt if you can.
If clflushopt is not supported, fall all the way back to clflush.
Signed-off-by: Ross Zwisler
Cc: H Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: David
If clwb is available on the system, use it in drm_clflush_page.
If clwb is not available, fall back to clflushopt if you can.
If clflushopt is not supported, fall all the way back to clflush.
Signed-off-by: Ross Zwisler
Cc: H Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: David Airlie
If clwb is available on the system, use it in clflush_cache_range.
If clwb is not available, fall back to clflushopt if you can.
If clflushopt is not supported, fall all the way back to clflush.
Signed-off-by: Ross Zwisler
Cc: H Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: David Airlie
Add support for the new clwb instruction. This instruction was
announced in the document "Intel Architecture Instruction Set Extensions
Programming Reference" with reference number 319433-022.
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
Here are some things of
Add alternative_io_2 in the spirit of alternative_input_2 and
alternative_io. This will allow us to have instructions with an output
parameter that vary based on two CPU features.
Signed-off-by: Ross Zwisler
Cc: H Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: David Airlie
Cc:
Add support for the new pcommit instruction. This instruction was
announced in the document "Intel Architecture Instruction Set Extensions
Programming Reference" with reference number 319433-022.
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
Signed-off-by: Ross
This patch set adds support for two new persistent memory instructions, pcommit
and clwb. These instructions were announced in the document "Intel
Architecture Instruction Set Extensions Programming Reference" with reference
number 319433-022.
On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson
wrote:
> On 10/11/14 17:36, Rob Clark wrote:
>> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson
>> wrote:
>>> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c
>>> b/drivers/gpu/drm/msm/msm_gem_prime.c
>>> index ad772fe36115..4e4fa5828d5d 100644
On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> As a side note if someone is looking for stuff to do, then the pin/unpin
> logic might be good thing to look at. We're currently a bit inconsistent
> whether we have the buffer pinned when the plane is disabled, or just
> otherwise
Motivated by the per-plane locking I've gone through all the get*
ioctls and reduced the locking to the bare minimum required.
v2: Rebase and make it compile ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 46 ++
1 file changed, 18
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/45c00199/attachment.html>
On Tue, Nov 11, 2014 at 10:12:01AM +0100, Daniel Vetter wrote:
> Motivated by the per-plane locking I've gone through all the get*
> ioctls and reduced the locking to the bare minimum required.
>
> v2: Rebase and make it compile ...
>
> Signed-off-by: Daniel Vetter
Just a couple nits.
> ---
>
On Tue, Nov 11, 2014 at 10:12:00AM +0100, Daniel Vetter wrote:
> Turned out to be much simpler on top of my latest atomic stuff than
> what I've feared. Some details:
>
> - Drop the modeset_lock_all snakeoil in drm_plane_init. Same
> justification as for the equivalent change in drm_crtc_init
647.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/184e52cc/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/e21bec1c/attachment.html>
From: Dave Airlie
While developing MST support I noticed I often got the wrong data
back from a transaction, in a racy fashion. I noticed the scratch
space wasn't locked against concurrent users.
Based on a patch by Alex, but I've made it a bit more obvious when
things are
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/ab1fd9b5/attachment.html>
On Mon, Nov 10, 2014 at 11:39 PM, Daniel Vetter wrote:
> Hi Ben,
>
> The below patch from Jani also touches nouveau, can you please take a
> look at it an ack? The core part + nouveau apply on top of drm-next,
> the i915 part needs stuff from my next queue. So I'd prefer if we can
> get this in
On 11 November 2014 07:33, Rian Quinn wrote:
> I would be surprised if the size argument was the issue. That comes right
> out out of the create IOCTL unmodified. Here is the full source that I am
> using.
>
> // Clear the arg buffers.
> memset(_arg, 0, sizeof(create_arg));
>
1 - 100 of 114 matches
Mail list logo