On 11 November 2014 06:33, Rian Quinn wrote:
> I did another test using the following that David put up on github:
>
> https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c
>
> This test also fails on everything except Intel. What's really strange is
> this test actually does a test to ve
>> How does amdkfd interfact with runtime pm on the radeon driver? I'd expect
>> some calls to the runtime get/put functions in some places.
>>
>> Dave.
>>
> Hi Dave,
> Per Jerome's request from the first time he saw the driver, we removed all
> the "register bashing" code from amdkfd and moved the
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(&create_arg, 0, sizeof(create_arg));
> me
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 th
On Tue, Oct 28, 2014 at 04:20:48PM +0200, Jani Nikula wrote:
> The Baseline_ELD_Len field does not include ELD Header Block size.
>
> From High Definition Audio Specification, Revision 1.0a:
>
> The header block is a fixed size of 4 bytes. The baseline block
> is variable size in mult
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 locked.
Signed-off-by
On Mon, Nov 10, 2014 at 10:59:23AM -0500, Rob Clark wrote:
> Signed-off-by: Rob Clark
> ---
> I'll need this helper for msm async commit, and I suspect other
> drivers will as well.
Yeah, makes sense. Some nits to clarify the kerneldoc below, with that
addressed this is
Reviewed-by: Daniel Vette
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/53077a15/attachment.html>
but I see no special wine error on the console.
--
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/6353d246/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/07114456/attachment-0001.html>
vel/attachments/20141111/2bfd6762/attachment.html>
stem has completely woken up.
--
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/42a6adc0/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/8d501be3/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/0c0edb60/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/2014/942505dc/attachment.html>
ed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/ab1fd9b5/attachment.html>
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
Au
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 i
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
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/e21bec1c/attachment.html>
ug 85647.
--
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>
rver 1.16.1
--
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/45c00199/attachment.html>
l 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>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/95e8f62f/attachment.html>
> if ((mVaddr = (svuint32 *)mmap(0, mSize, PROT_READ | PROT_WRITE,
>> > MAP_SHARED, gpu->fd(), map_arg.offset)) == MAP_FAILED)
>> > {
>> > // Need to clear out the address so that we don't try to use it.
>> > mVaddr = NULL;
>> >
>> > // Error out.
>> > svWarning(0) << "Failed: Dumb Buffer mmap - " <<
>> strerror(errno);
>> > return;
>> > }
>> >
>>
>> mmap is probably truncating the offset,
>>
>> look into,
>> #define _FILE_OFFSET_BITS 64
>>
>> AC_SYS_LARGEFILE
>>
>> Dave.
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/14cfd0d7/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/fc544fcd/attachment.html>
fer(4096, 4096);
allocate_buffer(4096, 4096);
allocate_buffer(4096, 4096);
allocate_buffer(4096, 4096);
close(fd);
}
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/e14bd5b1/attachment-0001.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/e19237ea/attachment.html>
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>
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 f
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/d50a2b06/attachment.html>
vel/attachments/20141111/0599ebcb/attachment.html>
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
>> +++ b/drivers/gp
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 do
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 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
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
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 for
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/0c8607f1/attachment.html>
itself 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>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/8ab020f0/attachment.html>
ves/dri-devel/attachments/2014/eb262e9f/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/37eae9ba/attachment.html>
vel/attachments/20141111/56f64455/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>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/10ba74e7/attachment.html>
ceiving 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/cbb52a51/attachment.html>
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>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/b2f61799/attachment.html>
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.
>
> https://software.intel.com/sites
--
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/05080cfa/attachment-0001.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>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/de5b224c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85491
Marek changed:
What|Removed |Added
CC||kordikmarek at gmail.com
--- Comment #10 from Mar
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #11 from Marek ---
Created attachment 157331
--> https://bugzilla.kernel.org/attachment.cgi?id=157331&action=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
--- Comment #12 from Marek ---
Created attachment 157341
--> https://bugzilla.kernel.org/attachment.cgi?id=157341&action=edit
logs for first not working kernel
--
You are receiving this mail because:
You are watching the assignee of the bug.
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 " __stringify(NOP_DS_PREFIX)
||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
=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>
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 NO
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/d07f5e0c/attachment.html>
n bug 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/2014/768359ea/attachment.html>
I've 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>
ards
Marcus
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/c76b08bf/attachment.html>
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 v3: None
Changes in v2
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 by
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 reg_
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 by
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 {
[...]
Sign
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
drivers/staging/imx-d
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
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 reg_
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 v3: None
Changes in v2
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 Documentation/
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
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.
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 rk3288
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 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 dr
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 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?
Ye
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 files
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.
https://software.intel.com/sites/default/files/manage
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: dri-devel
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 not
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
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
Cc
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 Airl
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: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 vo
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 i
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 Y
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 Zwis
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. Could
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
>>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/4a8d320c/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/88f7a4e3/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
(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
1 - 100 of 114 matches
Mail list logo
