https://bugzilla.kernel.org/show_bug.cgi?id=102401
--- Comment #9 from Maxqia ---
Created attachment 185391
--> https://bugzilla.kernel.org/attachment.cgi?id=185391&action=edit
Possible Patch
--
You are receiving this mail because:
You are watching the assignee of the bug.
Excellent. Thanks a lot.
Regards,
Jammy
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Friday, August 21, 2015 12:28 AM
To: Zhou, Jammy
Cc: ML dri-devel
Subject: Re: [PATCH 1/4] drm: add interface to get drm devices on the system v3
On 20 August 2015 at 04
e you using?
--
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/20150821/4c10c476/attachment.html>
Hi Emil,
On Thu, 20 Aug 2015 17:17:27 +0100
Emil Velikov wrote:
> Hi Hyungwon,
>
> On 19 August 2015 at 01:58, Hyungwon Hwang
> wrote:
> > This patch seprates the code, which sorts proprty sets and
> > eliminates duplicate properties, from drmModeAtomicCommit(). Now
> > drmModeAtomicCleanup()
On 08/20/2015 10:34 PM, Jerome Glisse wrote:
> On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
>> On 08/20/2015 04:53 PM, Jerome Glisse wrote:
>>> On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom wrote:
Hi, Tiago!
On 08/20/2015 12:33 AM, Tiago Vignatti wro
Hi Emil,
On Thu, 20 Aug 2015 17:23:09 +0100
Emil Velikov wrote:
> On 19 August 2015 at 01:58, Hyungwon Hwang
> wrote:
> > This patch makes 'struct _drmModeAtomicReqItem' and 'struct
> > _drmModeAtomicReq' visible from outside. This is needed for
> > userspace applications to use those structure
On 08/20/2015 05:18 PM, Thierry Reding wrote:
> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
>> Hi Thierry, Lucas,
>>
>>
>> On 08/19/2015 08:32 PM, Thierry Reding wrote:
>>> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
Am Mittwoch, den 19.08.2015, 16:34 +020
u need that, exactly?
Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/c81c7b8f/attachment.sig>
you. I think I should drop this patch, and find
> another way for modetest.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/f3c89b23/attachment.sig>
Hi Pekka,
On Fri, 21 Aug 2015 09:42:26 +0300
Pekka Paalanen wrote:
> On Fri, 21 Aug 2015 13:54:49 +0900
> Hyungwon Hwang wrote:
>
> > Hi Emil,
> >
> > On Thu, 20 Aug 2015 17:17:27 +0100
> > Emil Velikov wrote:
> >
> > > Hi Hyungwon,
> > >
> > > On 19 August 2015 at 01:58, Hyungwon Hwang
>
Dear,
On Fri, 21 Aug 2015 09:44:42 +0300
Pekka Paalanen wrote:
> On Fri, 21 Aug 2015 15:06:58 +0900
> Hyungwon Hwang wrote:
>
> > Hi Emil,
> >
> > On Thu, 20 Aug 2015 17:23:09 +0100
> > Emil Velikov wrote:
> >
> > > On 19 August 2015 at 01:58, Hyungwon Hwang
> > > wrote:
> > > > This patch
> > Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
> > chipset and old Radeon graphics. The machine crashes during boot and
> > starts spamming dmesg as fast as it scrolls. Netconsole caught the
> > dmesg. 4.1.0 worked fine.
> >
> > The first crash seems to be related to radeo
On 20.08.2015 22:51, Bas Nieuwenhuizen wrote:
> Signed-off-by: Bas Nieuwenhuizen
Thanks for the help, but I've addressed both bugs internally already and
they are just waiting for public release.
Not sure which patches Alex are going to pick now.
In general it looks like we should probably mov
When a user-space process writes directly to the fbdev framebuffer,
we hit a circular locking dependency. Fix this by introducing a local
delayed work callback so that the defio lock can be released before
calling into the modesetting code for a dirty update.
Signed-off-by: Thomas Hellstrom
Revie
No need to try to call ttm_bo_device_release twice during module unload.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.
Dave,
The third pull request for 4.3. Contains two fixes for regressions introduced
with previous pull requests.
The following changes since commit 294947a5c7f6d228b70fcc51a89527e74a38a2c5:
Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux
into drm-next (2015-08-17 16:
Hi Linus,
a bunch of i915 fixes, one revert a VBT fix that was a bit premature, and
some braswell feature removal that the hw actually didn't support.
One radeon race fix at boot, and one hlcdc build fix, one fix from
Russell that fixes build as well with new audio features.
This is hopefully
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/6fd85e33/attachment.html>
somewhere else too in any case,
exactly because it wants to allocate buffers of the same size. So very
likely those values were already stored *before* the atomic request was
even created.
IMHO, it is the responsibility of the application to track what it
itself is doing. If you have to write some data structures to do that,
then that's what you should do. Libdrm is not a replacement for that.
Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/39996f11/attachment.sig>
Am Freitag, den 21.08.2015, 07:25 +0200 schrieb Thomas Hellstrom:
> On 08/20/2015 10:34 PM, Jerome Glisse wrote:
> > On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
> >> On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> >>> On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom w
On 08/21/2015 12:28 PM, Lucas Stach wrote:
> Am Freitag, den 21.08.2015, 07:25 +0200 schrieb Thomas Hellstrom:
>> On 08/20/2015 10:34 PM, Jerome Glisse wrote:
>>> On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> On Thu, Aug 20
drivers/gpu/drm/bridge/parade-ps8622.c:671:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu
---
parade-ps8622.c |1 -
1 file
drivers/gpu/drm/bridge/nxp-ptn3460.c:403:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu
---
nxp-ptn3460.c |1 -
1 file cha
On Fri, Aug 21, 2015 at 4:48 AM, Mark Brown wrote:
>
> On Thu, Aug 20, 2015 at 05:36:34PM -0400, Alex Deucher wrote:
> > From: Maruthi Srinivas Bayyavarapu
> >
> > ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> > provides the DMA and CPU DAI components to ALSA core.
>
> T
-
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/20150821/73ffc3c2/attachment-0001.html>
Hi Thomas,
On 13 August 2015 at 06:49, Thomas Hellstrom wrote:
[snip]
> --- a/include/uapi/drm/vmwgfx_drm.h
> +++ b/include/uapi/drm/vmwgfx_drm.h
> @@ -826,7 +830,6 @@ struct drm_vmw_update_layout_arg {
> enum drm_vmw_shader_type {
> drm_vmw_shader_type_vs = 0,
> drm_vmw_shader_
On 08/21/2015 02:19 PM, Emil Velikov wrote:
> Hi Thomas,
>
> On 13 August 2015 at 06:49, Thomas Hellstrom wrote:
> [snip]
>> --- a/include/uapi/drm/vmwgfx_drm.h
>> +++ b/include/uapi/drm/vmwgfx_drm.h
>> @@ -826,7 +830,6 @@ struct drm_vmw_update_layout_arg {
>> enum drm_vmw_shader_type {
>>
Hi Thomas,
On 14 August 2015 at 12:29, Thomas Hellstrom wrote:
> On 08/13/2015 08:38 AM, Daniel Vetter wrote:
>> On Thu, Aug 13, 2015 at 7:04 AM, Thomas Hellstrom
>> wrote:
Out of curiosity I did take a (very) quick look and also tried to find the
corresponding userspace parts. On a q
Hi, Emil
On 08/21/2015 02:31 PM, Emil Velikov wrote:
> Hi Thomas,
>
> On 14 August 2015 at 12:29, Thomas Hellstrom wrote:
>> On 08/13/2015 08:38 AM, Daniel Vetter wrote:
>>> On Thu, Aug 13, 2015 at 7:04 AM, Thomas Hellstrom >> vmware.com> wrote:
> Out of curiosity I did take a (very) quick lo
On Fri, Aug 21, 2015 at 07:25:07AM +0200, Thomas Hellstrom wrote:
> On 08/20/2015 10:34 PM, Jerome Glisse wrote:
> > On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
> >> On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> >>> On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom w
I've now dropped this into linux-next so that it can get some time there,
and still be merged during the 4.3 merge window should it open this Sunday.
On Wed, Aug 19, 2015 at 09:11:06AM +0100, Russell King wrote:
> David,
>
> Please incorporate the latest Synopsis DesignWare HDMI driver developmen
On 08/21/2015 03:32 PM, Jerome Glisse wrote:
> On Fri, Aug 21, 2015 at 07:25:07AM +0200, Thomas Hellstrom wrote:
>> On 08/20/2015 10:34 PM, Jerome Glisse wrote:
>>> On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> On Thu, Aug
On 21/08/15 13:42, Thomas Hellstrom wrote:
> Hi, Emil
>
> On 08/21/2015 02:31 PM, Emil Velikov wrote:
>> Hi Thomas,
>>
>> On 14 August 2015 at 12:29, Thomas Hellstrom
>> wrote:
>>> On 08/13/2015 08:38 AM, Daniel Vetter wrote:
On Thu, Aug 13, 2015 at 7:04 AM, Thomas Hellstrom >>> vmware.com>
Hi
On 08/21/2015 04:39 PM, Emil Velikov wrote:
> On 21/08/15 13:42, Thomas Hellstrom wrote:
>> Unfortunately I wasn't aware that the mesa 11.0
>> branchpoint was immediately upcoming.
> It was mentioned on the mailing list (search for "release schedule")
> with a few reminders, plus a note in the
On Fri, Aug 21, 2015 at 10:39 AM, Emil Velikov
wrote:
> On 21/08/15 13:42, Thomas Hellstrom wrote:
>> I guess there's not much we can do
>> about it at this point? Even if I post the patches now we can't just
>> expect them to be reviewed within a couple of hours...
>>
> Unfortunately it seems li
ves/dri-devel/attachments/20150821/8a1e35fb/attachment.html>
On Fri, Aug 21, 2015 at 04:15:53PM +0200, Thomas Hellstrom wrote:
> On 08/21/2015 03:32 PM, Jerome Glisse wrote:
> > On Fri, Aug 21, 2015 at 07:25:07AM +0200, Thomas Hellstrom wrote:
> >> On 08/20/2015 10:34 PM, Jerome Glisse wrote:
> >>> On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom w
Hello Chunming Zhou,
The patch 57ff96cf471a: "drm/amdgpu: implement cgs gpu memory
callbacks" from Apr 24, 2015, leads to the following static checker
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:274 amdgpu_cgs_gmap_gpu_mem()
warn: should 'obj->placements[0]->fpfn << 12' be a
On Thu, Aug 20, 2015 at 3:27 PM, Thomas Hellstrom
wrote:
> On 08/20/2015 04:33 PM, Rob Clark wrote:
>> On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom
>> wrote:
>>> Hi, Tiago!
>>>
>>> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
Hey Thomas, you haven't answered my email about making SYN
Hi,
In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number"
writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero
period per lane). This causes some problems with certain panel timings when
timing->hs_zero plus an "unknown integer" becomes evenly di
Hi,
I'm having issues with non-functional DSI output driving a 2-lane panel
connected to DSI0 on MSM8x74 MDP5 v1.2 hardware. The code in
drivers/gpu/drm/msm/dsi/dsi_host.c around line 703 enables lane 1 and 2 instead
of lane 0 and 1 for performance reasons (and then enables lane swapping in the
Using pandoc as the Markdown engine cause some minor side effects as
pandoc includes main tags for almost everything.
Original Markdown support approach removes those main tags, but it caused
some inconsistencies when that tag is not the main one, like:
..
...
As kernel-doc was already including
"/**" should be used for kernel-doc documentation only.
It causes a warning with the new "in struct body" format.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: l
From: Mathieu Larouche
Added the deviceId, PLL algorithm and initialization code for two new
chipset in the G200 Server family.
Mathieu Larouche (2):
drm/mgag200: Add support for a new G200eW3 chipset
drm/mgag200: Add support for a new rev of G200e
drivers/gpu/drm/mgag200/mgag200_drv.c |
area being remapped was lock
on fault so it will be locked and prefaulted by remap. How can we avoid
this without tracking per vma if it was locked with lock or lock on
fault?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/34a7e3fe/attachment-0001.sig>
Hi,
I'm having issues with non-functional DSI output driving a 2-lane panel
connected to DSI0 on MSM8x74 MDP5 v1.2 hardware. The code in
drivers/gpu/drm/msm/dsi/dsi_host.c around line 703 enables lane 1 and 2 instead
of lane 0 and 1 for performance reasons (and then enables lane swapping in the
Hi,
In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number"
writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero
period per lane). This causes some problems with certain panel timings when
timing->hs_zero plus an "unknown integer" becomes evenly di
On Thu 20-08-15 13:03:09, Eric B Munson wrote:
> On Thu, 20 Aug 2015, Michal Hocko wrote:
>
> > On Wed 19-08-15 17:33:45, Eric B Munson wrote:
> > [...]
> > > The group which asked for this feature here
> > > wants the ability to distinguish between LOCKED and LOCKONFAULT regions
> > > and without
e mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>> create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> create mode 100644 drivers/phy/phy-rockchip-dp.c
>> create mode 100644 include/drm/bridge/analogix_dp.h
>>
>> --
>> 1.9.1
>>
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/de8938c2/attachment-0001.html>
x_dp_reg.h}
>>> (62%)
>>> create mode 100644 drivers/gpu/drm/exynos/analogix_dp-exynos.c
>>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
>>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>>> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>>> create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> create mode 100644 drivers/phy/phy-rockchip-dp.c
>>> create mode 100644 include/drm/bridge/analogix_dp.h
>>>
>>> --
>>> 1.9.1
>>>
>>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/6453075e/attachment-0001.html>
From: Mathieu Larouche
- Added support for the new deviceID for G200eW3
- Added PLL algorithm for the G200eW3
- Added some initialization code for G200eW3
Signed-off-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 +
drivers
From: Mathieu Larouche
- Added PLL algorithm for a new rev of G200e
- Removed the bandwidth limitation for the new G200e
Signed-off-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 119 +
1 file changed, 90 insertions(+), 29 deletions(-)
diff -
s was declared and handled.
> The board for which driver is developed, doesn't support more than 2 channels.
This is a driver for the IP, not for the board - you may not be able to
test everything but code should try to be as general as it can be.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/3cca5b89/attachment.sig>
From: Stephen Chandler Paul
Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a mo
On 2015. 8. 19., at PM 11:48, Yakir Yang wrote:
>
>
.
> .../bindings/video/analogix_dp-rockchip.txt| 83 ++
> .../devicetree/bindings/video/exynos_dp.txt| 51 +-
> arch/arm/boot/dts/exynos5250-arndale.dts | 10 +-
> arch/arm/boot/dts/exynos5250-smdk5250.dts
>
> drivers/gpu/drm/exynos/
> exynos_drm_buf.c
> exynos_drm_core.c
>
>
> However, "analogix_dp-exynos.c" looks very inconsistent.
>
> If there is no strict naming rule, please use "exynos_dp.c"
> or "exynos_drm_dp.c".
Exynos DRM maintainers get to pick their filenames, so Yakir, please
rename as Jingoo suggested.
Even if you didn't the first thing that would go into the Exynos DRM
driver tree after this is merged is a rename patch anyway.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/542c4e0f/attachment-0001.sig>
is skew is implemented? If it is indeed
needed in some cases would a move to DT instead of leaving it hard-coded
make sense?
Thanks for any input!
/wj
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150821/eb1be46a/attachment.html>
Hi Werner,
When I made DSI changes, I tried to limit the information in DT (like our
downstream driver), until there is a case driver really cannot figure it out by
the existing information.
I think this is the requirement of upstream kernel.
If we see a panel requires different value in PHY_LN
Hi Werner,
I will prepare a change to make the lane swap configurable.
Thanks,
Hai
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Johansson, Werner
Sent: Thursday, August 20, 2015 8:54 PM
To: dri-devel at lists.freedesktop.org
Subject: d
> From: Hai Li [mailto:hali at codeaurora.org]
> Sent: den 21 augusti 2015 13:14
> Hi Werner,
>
> I will prepare a change to make the lane swap configurable.
>
> Thanks,
> Hai
That sounds really great Hai!
Any idea as to why this lane swap would misbehave? In theory the swap should be
complete
> From: Hai Li [mailto:hali at codeaurora.org]
> Sent: den 21 augusti 2015 12:56
>
> When I made DSI changes, I tried to limit the information in DT (like
> our downstream driver), until there is a case driver really cannot
> figure it out by the existing information.
> I think this is the require
We discussed a bit with the folks on the Cc: list below what to do
with ION. Two big take-aways:
- High-performance drivers (like gpus) always want to play tricks with
coherency and will lie to the dma api (radeon, nouveau, i915 gpu
drivers all do so in upstream). What needs to be done here is
sgtm. Thanks for keeping me in the loop.
Tiago
On 08/21/2015 06:02 PM, Daniel Vetter wrote:
> We discussed a bit with the folks on the Cc: list below what to do
> with ION. Two big take-aways:
>
> - High-performance drivers (like gpus) always want to play tricks with
>coherency and will lie t
On Fri, Aug 21, 2015 at 2:16 PM, wrote:
> From: Stephen Chandler Paul
>
> Most of the time this isn't an issue since hotplugging an adaptor will
> trigger a crtc mode change which in turn, causes the driver to probe
> every DisplayPort for a dpcd. However, in cases where hotplugging
> doesn't ca
On Thu, Aug 06, 2015 at 10:08:12PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> This patch adds atomic get property interface for Intel CRTC. This
> interface will be used for get operation on any non-core DRM properties.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Ma
On Thu, Aug 06, 2015 at 10:08:14PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> As per Color Manager design, each driver is responsible to load its
> palette color correction and enhancement capabilities in the form of
> a DRM blob property, so that user space can query and read.
>
>
On Thu, Aug 06, 2015 at 10:08:15PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> This patch adds new variables in CRTC state, to hold respective color
> correction blobs. These blobs will be required during the atomic commit
> for writing the color correction values in correction regis
On Thu, Aug 06, 2015 at 10:08:17PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> I915 driver registers gamma correction as palette correction
> property with DRM layer. This patch adds set_property() and get_property()
> handlers for pipe level gamma correction.
>
> The set function a
On Thu, Aug 06, 2015 at 10:08:18PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> CHV/BSW platform supports two different pipe level gamma
> correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Attaches G
On Thu, Aug 06, 2015 at 10:08:24PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> This patch initializes gamma color correction proeprty
typo
> for Gen8 and higher platforms.
I'd sp
Hi back!
On 08/20/2015 03:48 AM, Thomas Hellstrom wrote:
> Hi, Tiago!
Something that the Chrome OS folks told me today is whether we could
change the sync API to use a syscall for that instead. Reason for that
is to eventually fit this in nicely in their sandbox architecture
requirements, so y
https://bugzilla.kernel.org/show_bug.cgi?id=102401
Maxqia changed:
What|Removed |Added
Attachment #185391|0 |1
is obsolete|
72 matches
Mail list logo
