On 13 June 2016 at 19:44, Philipp Zabel wrote:
> Hi Dave,
>
> please consider merging this tag, which contains the v16 MT8173 HDMI
> patches I sent on 2016-05-26, rebased onto v4.7-rc2. There have been no
> further comments.
arm32 build
DTC drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dtb
/hom
Hi Sergey,
On Wed, Jun 15, 2016 at 04:59:09PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> -next 4.7.0-rc3-next-20160614
>
>
> [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled
> [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory
> access
> [ 315.146546] gener
es
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/05102da0/attachment-0001.obj>
Hi Liviu,
On Wed, 15 Jun 2016 16:03:04 +0100 Liviu Dudau wrote:
>
> I would like to add the Mali DP DRM driver tree to linux-next. I'm planning
> to send a pull request for inclusion into v4.8 and I hope that getting a
> wider exposure for a few weeks is beneficial.
>
> Please add the following
On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> > Hi,
> >
> > On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> >> > On 05/31/2016 05:31 AM, Minchan Kim wrote:
> >>> > > @@ -791,6 +921,7 @@ static int __unmap_and_
, reassigning to core for now.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/8ab47e62/attachment-0001.html>
On 15.06.2016 18:23, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 05:03:41PM +0900, Michel Dänzer wrote:
>> On 14.06.2016 17:06, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote:
On 14.06.2016 14:53, Daniel Vetter wrote:
>
> I didn't know that
Tomasz,
On 06/15/2016 05:27 PM, Tomasz Figa wrote:
> Hi Yakir,
>
> Yakir Yang rock-chips.com> writes:
>> RK3399 and RK3288 shared the same eDP IP controller, only some light
>> difference with VOP configure and GRF configure.
>>
>> Also same misc fix to analogix_dp driver:
>> - Hotplug invalid wh
Tomasz,
On 06/15/2016 05:25 PM, Tomasz Figa wrote:
> Hi Yakir,
>
> Yakir Yang rock-chips.com> writes:
Required properties:
-- compatible: "rockchip,rk3288-edp";
+- compatible: "rockchip,rk3288-edp",
+ "rockchip,rk3399-edp";
>>> As commented by Tomasz on gerrit,
chment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 54172 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/e2db6c0d/attachment-0001.obj>
On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (06/16/16 08:12), Minchan Kim wrote:
> > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled
> > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user
> > > memory access
> > > [ 315.146546] general
Hi, Daniel,
Thank you for your suggestion, I will modify that to use the atomic
color management.
Bibby
On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies ar
Hi Linus,
Main drm fixes pull for rc4, one regression fix in the connector
refcounting, and an MST fix.
There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes,
mostly regression or black screen fixes.
Dave.
The following changes since commit 7ff6977be8e3c7e6f5ae1ee56bc1535c5ca65
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/542cc81d/attachment.html>
nel.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/a7a8cc02/attachment-0001.html>
On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:58), Minchan Kim wrote:
> [..]
> > RAX: 2065676162726166 so rax is totally garbage, I think.
> > It means obj_to_head returns garbage because get_first_obj_offset is
> > utter crab because (page_idx / class->pages
On 06/14/2016 12:33 AM, Rob Herring wrote:
> On Fri, Jun 10, 2016 at 04:16:33PM +0530, Archit Taneja wrote:
>> MDP5:
>> - Don't ask for source clock
>>
>> MDP4:
>> - Give a better name for MDP_TV_CLK
>> - Remove TV_SRC
>> - Add MDP_AXI_CLK
>
> This could use the explanation in the commit msg why
On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> >> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Ansh
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 54174 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/c4b92587/attachment-0001.obj>
There is no limit on high "idx" can go. It should be less than
ARRAY_SIZE(data.states) which is 16.
The "data" variable wasn't declared in that scope so I shifted the code
around a bit to make it work.
Fixes: f3898ea12fc1 ('drm/amd/powerplay: add some sysfs interfaces for
powerplay.')
Signed-of
On Thu, Jun 16, 2016 at 02:22:09PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 13:47), Minchan Kim wrote:
> [..]
> > > this is what I'm getting with the [zsmalloc: keep first object offset in
> > > struct page]
> > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc
> >
Am 16.06.2016 08:41, schrieb Dan Carpenter:
> There is no limit on high "idx" can go. It should be less than
> ARRAY_SIZE(data.states) which is 16.
>
> The "data" variable wasn't declared in that scope so I shifted the code
> around a bit to make it work.
>
> Fixes: f3898ea12fc1 ('drm/amd/powe
https://bugzilla.kernel.org/show_bug.cgi?id=107381
benoit.sarels at gmail.com changed:
What|Removed |Added
CC||benoit.sarels at gmail.com
-
On Thu, Jun 16, 2016 at 09:26:03AM +0200, walter harms wrote:
>
>
> Am 16.06.2016 08:41, schrieb Dan Carpenter:
> > There is no limit on high "idx" can go. It should be less than
> > ARRAY_SIZE(data.states) which is 16.
> >
> > The "data" variable wasn't declared in that scope so I shifted the
Hi Russell,
On Wed, Jun 15, 2016 at 09:11:16PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote:
> > Could be the tda998x_drv fault, but I'm getting this splat:
> >
> > [1.347687] kobject_add_internal failed for card0-HDMI-A-1 (error: -2
>
Am 16.06.2016 um 09:54 schrieb Dan Carpenter:
> On Thu, Jun 16, 2016 at 09:26:03AM +0200, walter harms wrote:
>>
>> Am 16.06.2016 08:41, schrieb Dan Carpenter:
>>> There is no limit on high "idx" can go. It should be less than
>>> ARRAY_SIZE(data.states) which is 16.
>>>
>>> The "data" variable wa
Sure, I'll resend. Unsigned is a little cleaner. There is no new error
code/message or change in behavior though either way.
regards,
dan carpenter
Provide a small convenience wrapper that set/get the
display brightness value
Cc: John Stultz
Cc: Sumit Semwal
Cc: Archit Taneja
Cc: Rob Clark
Cc: Jani Nikula
Cc: Thierry Reding
Signed-off-by: Vinay Simha BN
---
v1:
*tested in nexus7 2nd gen.
v2:
* implemented jani review comments
-f
Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.
Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git
And video mode setting is from dsi-panel-jdi-d
On Thu, Jun 16, 2016 at 11:15:14AM +0900, Michel Dänzer wrote:
> On 15.06.2016 18:23, Daniel Vetter wrote:
> > On Wed, Jun 15, 2016 at 05:03:41PM +0900, Michel Dänzer wrote:
> >> On 14.06.2016 17:06, Daniel Vetter wrote:
> > Yeah I think there's a bit of confusion going on here ;-) Of course I'm
On Wed, Jun 15, 2016 at 12:43:11PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:01PM +0200, Daniel Vetter wrote:
> > Like with drm_master_open protect it with a check for primary_client
> > to make it clear that this can't happen on render/control nodes.
> >
> > Signed-off-by: Daniel
There is no limit on high "idx" can go. It should be less than
ARRAY_SIZE(data.states) which is 16.
The "data" variable wasn't declared in that scope so I shifted the code
around a bit to make it work. Also I made "idx" unsigned.
Fixes: f3898ea12fc1 ('drm/amd/powerplay: add some sysfs interface
Am 16.06.2016 um 10:30 schrieb Dan Carpenter:
> There is no limit on high "idx" can go. It should be less than
> ARRAY_SIZE(data.states) which is 16.
>
> The "data" variable wasn't declared in that scope so I shifted the code
> around a bit to make it work. Also I made "idx" unsigned.
>
> Fixes:
t attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/b3c1135e/attachment.sig>
ion/octet-stream
Size: 54177 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/f3686af8/attachment-0001.obj>
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/a533814a/attachment.sig>
, which shouldn't be too difficult either...
Anyway, as I said, not part of this patch.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/053eb097/attachment.sig>
On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
> From: Christian König
>
> When we pipeline evictions the page directory could already be
> moving somewhere else when grab_id is called.
Isn't PD bo protected by job fence?
I think before job fence is signalled, the PD bo is safe, there
sho
ttachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/6519bb24/attachment-0001.sig>
Am 16.06.2016 um 10:33 schrieb zhoucm1:
>
>
> On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
>> From: Christian König
>>
>> When we pipeline evictions the page directory could already be
>> moving somewhere else when grab_id is called.
> Isn't PD bo protected by job fence?
> I think before j
On 2016å¹´06æ16æ¥ 17:52, Christian König wrote:
> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>
>>
>> On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
>>> From: Christian König
>>>
>>> When we pipeline evictions the page directory could already be
>>> moving somewhere else when grab_id is c
On Thu, Jun 16, 2016 at 05:42:11PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 15:47), Minchan Kim wrote:
> > > [..]
> > > > > this is what I'm getting with the [zsmalloc: keep first object offset
> > > > > in struct page]
> > > > > applied: "count:0 mapcount:-127". which may be not related t
Am 16.06.2016 um 11:54 schrieb zhoucm1:
>
>
> On 2016å¹´06æ16æ¥ 17:52, Christian König wrote:
>> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>>
>>>
>>> On 2016å¹´06æ15æ¥ 19:44, Christian König wrote:
From: Christian König
When we pipeline evictions the page directory could alr
On Mon, May 30, 2016 at 3:13 PM, Ulf Hansson wrote:
> If the PM domain is powered off when the first device starts its system PM
> prepare phase, genpd prevents any further attempts to power on the PM
> domain during the following system PM phases. Not until the system PM
> complete phase is final
This patchset adds the last bits needed for getting the MSM display
bindings in correct shape, and as an example, adds display support for
MSM8916.
One problem with the MDP5 driver was that device hierarchy didn't match
with the hardware. All MDP5 based display blocks contain a top-level
MDSS wrap
This isn't needed as we only support OF.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9788989..aada291 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/d
These aren't used. Probably left overs when driver was refactored to
support both MDP4 and MDP5.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_kms.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index e3c..009
The driver gets the irq number using platform_get_irq on the main kms
platform device. This works fine since both MDP4 and MDP5 currently
have a flat device hierarchy. The platform device tied with the
drm_device points to the MDP DT node in both cases.
This won't work when MDP5 supports a tree-li
In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_devic
Since MDSS registers were stuffed within the the MDP5 register
space, we had an __offset_MDP() macro to identify the offset
between the start of MDSS and MDP5 address spaces. This offset
macro expected a MDP index argument, which didn't make much
sense since we don't have multiple MDPs.
The offset
SoCs that contain MDP5 have a top level wrapper called MDSS that manages
clocks, power and irq for the sub-blocks within it.
Currently, the MDSS portions are stuffed into the MDP5 driver. This makes
it hard to represent the DT bindings in the correct way. We create a top
level MDSS helper that han
With MDP5 as a new device, we need to do less for MDP when initializing
modeset after all the components are bound.
Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will
eventually replace the older kms_init/destroy funcs.
In the new kms_init2, the platform_device used is the one co
Call msm_mdss_init in msm_drv to set up top level registers/irq line.
Start using the new kms_init2/destroy2 funcs to inititalize MDP5 KMS.
With the MDSS interrupt and irqdomain set up, the old MDP5 irq code
can be dropped.
The mdp5_hw_init kms func now uses the platform device tied to MDP5
inste
With the new kms_init/destroy funcs in place for MDP5, we can get rid of
the old kms funcs. Some members of the mdp5_kms struct also become
redundant, so we remove those too.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 228 +---
drivers/
The MDP5 sub-block register offsets are relative to the top level
MDSS register address.
Now that we have the start of MDP5 register address space, provide
the offsets relative to that. This involves subtracting the offsets
with 0x1000 or 0x100 depending on the MDP5 version.
Signed-off-by: Archit
With the new device hierarchy for MDP5, we need to enable runtime PM
for both the toplevel MDSS device and the MDP5 device itself. Enable
runtime PM for the new devices.
Since MDP4 and MDP5 now have different places where runtime PM is
enabled, remove the previous pm_runtime_enable/disable calls,
Since runtime PM isn't implemented yet, we need to call
mdp5_enable/disable in a few more places. These would later be
replaced by runtime PM get/put calls.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 2 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 2 ++
2 files ch
Simplifies some of the code that we'll add later.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bc2c371..e623dc5 100644
Introduce new compatible strings for the top level MDSS wrapper device,
and the MDP5 device.
Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
were used to match the top level platform_device (which was also tied
to the top level drm_device struct). Now, these strings are used
to
MDP4 and MDP5 vary a bit in terms of device hierarchy and the properties
they require. Rename the binding doc to mdp4.txt and remove MDP5 specific
pieces. A separate document will be created for MDP5
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Signed-off-by: Archit Taneja
---
.../devicet
Add a new doc for DT bindings for platforms that contain MDP5 display
controller hardware. The doc describes bindings for the top level
MDSS wrapper hardware and MDP5 itself.
Add an example for the bindings as found in MSM8916.
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
Signed-off-by: Ar
The MDP4/5 DT node now contains a list of ports that describe how it
connects to external encoder interfaces like DSI and HDMI. These follow
the standard of_graph bindings, and allow us to get rid of the 'connectors'
phandle that contained a list of all the external encoders connected to
MDP.
The
The APQ8016-sbc provides a HDMI output. The APQ8016 display block only
provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI
encoder chip that sits between the DSI PHY output and the HDMI
connector.
Add the ADV7533 DT node under its I2C control bus, and tie the DSI
output port to the
The kms driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.
Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI.
For MDP5 based platforms, the master device isn't the MDP5 platform
device, but the top level MDSS device, which is a parent to MDP5 and
interface (DSI, HDMI, eDP etc) devices.
In order to add components on MDP5 platforms, we first need to populate
the MDSS children, locate the MDP5 child, and the
The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.
This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.
Once we know how to link the
The MSM8916 SoC contains a MDP5 based display block, and one DSI output.
Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children
sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's
input port.
Cc: Andy Gross
Cc: Rob Herring
Cc: devicetree at vger.kernel.org
The rockchip drm driver started using drm_gem_cma_vm_ops, but that might
not be part of the kernel, causing the link to fail:
drivers/gpu/built-in.o:(.data+0xb234): undefined reference to
`drm_gem_cma_vm_ops'
This adds a Kconfig 'select' statement to enable it like the other
user do.
Signed-off
On Thu, Jun 16, 2016 at 01:09:34PM +0100, Jose Abreu wrote:
> Hi Daniel,
>
> Sorry to bother you again. I promise this is the last time :)
>
> On 15-06-2016 11:15, Daniel Vetter wrote:
> > On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu
> > wrote:
> >> On 15-06-2016 09:52, Daniel Vetter wrote:
> >
On Thu, Jun 16, 2016 at 02:27:57PM +0200, Arnd Bergmann wrote:
> The rockchip drm driver started using drm_gem_cma_vm_ops, but that might
> not be part of the kernel, causing the link to fail:
>
> drivers/gpu/built-in.o:(.data+0xb234): undefined reference to
> `drm_gem_cma_vm_ops'
>
> This adds
On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu wrote:
> Hi Daniel,
>
> Sorry to bother you again. I promise this is the last time :)
>
> On 15-06-2016 11:15, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu
>> wrote:
>>> On 15-06-2016 09:52, Daniel Vetter wrote:
On Tue, Jun
Signed-off-by: Meng Yi
---
Change in V2:
-add prefix "drm/fsl-dcu" to subject
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
index c564ec6.
Hi Daniel,
Sorry to bother you again. I promise this is the last time :)
On 15-06-2016 11:15, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu
> wrote:
>> On 15-06-2016 09:52, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu
>>> wrote:
> I assume tha
n alternate
> solution for EGL ready. Hence why I want to know whether there's
> anyone who's using this outside of EGL.
>
> Really this was just drive-by that I spotted while looking around at
> stuff for our other discussion around vblanks.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/85b087df/attachment.html>
Some fixes and cleanups that should get merged to tilcdc even if my
atomic changes are still a work in progress.
Changes since v2:
- "drm/tilcdc: Restore old dpms state in pm_resume()"
- Improve description
- "drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ
- Handle LCDC_FIFO_UN
Reorder the IRQ function so that the write to LCDC_END_OF_INT_IND_REG
is done last. The write to LCDC_END_OF_INT_IND_REG indicates to LCDC
that the interrupt service routine has completed (see section
13.3.6.1.6 in AM335x TRM). This is needed if LCDC's ipgvmodirq module
is configured for pulse inte
Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
into stop() function. This is just a cleanup and enables independent
use of stop() function.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
1 file changed, 16 insertio
Increase time out for waiting frame done interrupt. 50ms is long
enough for the usual display modes (50 Hz or higher refresh rate), but
it may be a bit tight for some unusual mode.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Add drm_crtc_vblank_on() and *_off() calls to start() and stop()
functions, to make sure any vblank waits etc. gets properly cleaned
up.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
The legacy panel.txt and tfp410.txt bindings are still the only supported
way to connect lcd panel and tfp410 DVI encoder to tilcdc.
Signed-off-by: Jyri Sarha
---
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/dev
Avoid error print by of_graph_get_next_endpoint() if there is no ports
present.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/ti
Restore old dpms state in pm_resume(). The dpms is turned off in
pm_suspend() and it should be restored to its original state in
pm_resume(). Without this patch the display is left blanked after a
suspend/resume cycle.
Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
engine w
So, if we wanted to extend this to support the fourcc-modifiers that
we have on the kernel side for compressed/tiled/etc formats, what
would be the right approach?
A new version of the existing extension or a new
EGL_EXT_image_dma_buf_import2 extension, or ??
BR,
-R
On Mon, Feb 25, 2013 at 6:54
Am Donnerstag, den 16.06.2016, 06:19 +1000 schrieb Dave Airlie:
> On 13 June 2016 at 19:44, Philipp Zabel wrote:
> > Hi Dave,
> >
> > please consider merging this tag, which contains the v16 MT8173 HDMI
> > patches I sent on 2016-05-26, rebased onto v4.7-rc2. There have been no
> > further comment
On Wed, Jun 15, 2016 at 1:08 PM, Daniel Vetter
wrote:
> It's not obvious at first sight that this is a fastpath, make that
> clearer with a goto. Fallout from a discussion with Liviu on irc.
>
> Cc: Liviu.Dudau at arm.com
> Acked-by: Liviu.Dudau at arm.com
> Signed-off-by: Daniel Vetter
> ---
>
> -Original Message-
> From: Alex Deucher [mailto:alexdeucher at gmail.com]
> Sent: June-15-16 1:00 PM
> To: Alex Williamson
> Cc: Maling list - DRI developers; Deucher, Alexander; Rodriguez, Andres; for
> 3.8
> Subject: Re: [PATCH] drm/radeon: fix asic initialization for virtualized
> en
On Thu, Jun 16, 2016 at 5:30 PM, Oded Gabbay wrote:
> On Wed, Jun 15, 2016 at 1:08 PM, Daniel Vetter
> wrote:
>> It's not obvious at first sight that this is a fastpath, make that
>> clearer with a goto. Fallout from a discussion with Liviu on irc.
>>
>> Cc: Liviu.Dudau at arm.com
>> Acked-by: L
On Thu, Jun 16, 2016 at 3:02 PM, Rainer Hochecker
wrote:
> Daniel,
>
> Peter posted me some snippets about your discussion around vblank that
> confused me. Our use case is as follows:
> We synchronise our video player clock to the pace of the display. Assume we
> play some 23.976 content and the
performance options does
changing any of them help?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/ceaa13f2/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/fdf9467c/attachment.html>
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/ca55dfcf/attachment.html>
output still be interested on resolving this issue, or some more
information?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments
Hi Vinay,
I belive I've spotted a few issues. If my understanding is correct,
then I'll defer to Thierry if he'd like them fixed here, or as
follow-ups.
On 16 June 2016 at 04:00, Vinay Simha BN wrote:
> +#define PANEL_NUM_REGULATORS 3
> +
Nit: #define PANEL_NUM_REGULATORS ARRAY_SIZE(regulato
Hi Jitao Shi,
A few comments/suggestions which I hope you'll find useful. Note that
I'm not an expert in the area so take them with a pinch of salt.
On 2 June 2016 at 10:57, Jitao Shi wrote:
> +#define WRITE_STATUS_REG_CMD 0x01
> +#define READ_STATUS_REG_CMD0x05
> +#define BUSY
On 15 June 2016 at 16:45, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
>> On 14 June 2016 at 19:50, Daniel Vetter wrote:
>> > Master-based auth only exists for the legacy/primary drm_minor, hence
>> > there can only be one per device. The goal here is to un
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/54c8aa64/attachment.html>
On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> On Tue, 31 May 2016, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > On Mon, 30 May 2016, James Bottomley <
> > > James.Bottomley at HansenPartnership.com> wr
Also working on fence-fd support for submit ioctl, but that is
depending on some other patches from Gustavo, and not so much
actually tested yet, so unlikely to be 4.8 material. But I'll
send an RFC at least in near future.
Main interesting thing here is, I think, shrinker. Currently
it is limit
Be kinder to things that do lots of signal handling (ie. Xorg)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index eb
Doesn't do anything too interesting until we wire up shrinker. Pretty
much lifted from i915.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 39 +++
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_gem.c | 35
1 - 100 of 119 matches
Mail list logo
