Hi Chanwoo Choi,
On 2016å¹´08æ17æ¥ 12:50, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
>> This patch adds the documentation for rockchip rk3399 dmc driver.
>>
>> Signed-off-by: Lin Huang
>> ---
>> Changes in v6:
>> -Add more detail in Documentation
>>
>> Cha
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/1929afa5/attachment.html>
ever
program has the bug and not the entire xorg session?
--
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/20160822/660f10dd/attachment-0001.html>
On Sat, Aug 20, 2016 at 2:20 PM, Emil Velikov
wrote:
>> While I understand some people want to discuss this further, these
>> patches must land first in order bring back the compatibility with
>> libdrm.
> This is where the misunderstanding lies - there _must_ _not_ be
> compatible with the libdr
On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov
wrote:
> On 20 August 2016 at 16:08, Marek Olšák wrote:
>> On Sat, Aug 20, 2016 at 2:20 PM, Emil Velikov
>> wrote:
>>> On 20 August 2016 at 12:47, Marek Olšák wrote:
On Sat, Aug 20, 2016 at 1:08 PM, Emil Velikov >>> gmail.com> wrote:
On Fri, Aug 19, 2016 at 11:50:09AM -0600, Jonathan Corbet wrote:
> On Fri, 19 Aug 2016 11:52:15 +1000
> Stephen Rothwell wrote:
>
> > Today's linux-next merge of the jc_docs tree got a conflict in:
> >
> > Documentation/gpu/index.rst
> >
> > between commit:
> >
> > b754b35b089d ("vgaarbite
On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote:
> Some display controllers need plane(s) to be disabled together with
> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
> This patch adds atomic_disable CRTC helper callback so that
> old_crtc_state(as a parameter of the c
On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote:
> We don't support configuring active plane on-the-fly for imx-drm.
> The relevant CRTC should be disabled before the plane configuration.
> Of course, the plane itself should be disabled as well.
>
> This patch adds active plane reconfigur
On Fri, Aug 19, 2016 at 04:55:34PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark
> ---
> drivers/dma-buf/reservation.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index b528edb..1461b51 100644
> ---
On Sun, Aug 21, 2016 at 07:56:19PM +0200, Heinrich Schuchardt wrote:
> The C standard does not specify the size of the integer used
> to store an enum. Hence in structure drm_stats32_t alignment
> bytes may exist.
>
> To avoid exposing bytes from the kernel stack it is
> necessary to initialize va
On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
>
> Signed-off-by: Heinrich Schuchardt
Might be a silly question, but where exactly would we expo
On Mon, Aug 22, 2016 at 3:01 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote:
>> Some display controllers need plane(s) to be disabled together with
>> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
>> This patch adds atomic_disable CRTC help
Hi Daniel,
On Mon, Aug 22, 2016 at 3:20 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote:
>> We don't support configuring active plane on-the-fly for imx-drm.
>> The relevant CRTC should be disabled before the plane configuration.
>> Of course, the plane itself
On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote:
>>> +
>>> + /*
>>> + * The relevant plane's ->atomic_check callback may set
>>> + * crtc_state->mode_changed to be true when the active
>>> + * plane needs to be reconfigured. In this case and only
>>> + * this case, active_
On Mon, Aug 22, 2016 at 9:37 AM, Ying Liu wrote:
>> kernel-doc is a bit lacking compared to the one for @disable. And I think
>> on top of that it should explain better the difference with @disable (and
>> @disable should reference @atomic_disable too).
>
> Will improve the kernel-doc in the next
Signed-off-by: Lin Huang
---
Changes in v7:
-None
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
include/dt-bindings/clock/rk3399-cru.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clo
add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.
Signed-off-by: Lin Huang
---
Changes in v7:
- change SCLK_DDRC name from clk_ddrc to sclk_ddrc
Changes in v6:
- None
Changes in v5:
- fit for the ddr type
Changes in v4:
- None
Changes in v3:
- None
Chan
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
---
Changes in v7:
-None
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
.../bindings/devfreq/event/rockchip-dfi.
Everyone knows them, except all the new folks joining from the ARM
side haven't lived through all the pain of the past years and are
entirely surprised when I raise this. Definitely time to document
this.
Last time this was a big discussion was about 6 years ago, when qcom
tried to land a kernel d
rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:
kernel
On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.
Signed-off-by: Lin Huang
---
Changes in v7:
- add rockchip_ddrclk_sip_ops so we can distinguish other
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v7:
-access need to *4 to get right DDR loading
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
This patch adds the documentation for rockchip rk3399 dmc driver.
Signed-off-by: Lin Huang
---
Changes in v7:
-None
Changes in v6:
-Add more detail in Documentation
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
.../devicetree/bind
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
Reviewed-by: Chanwoo Choi
---
Changes in v7:
- remove a blank line
Changes in v6:
- fix some nit suggest by Chanwoo Choi
Changes in v5:
- improve
when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not wo
Am 21.08.2016 um 20:06 schrieb Heinrich Schuchardt:
> In an if block for (running == 0) running cannot be non-zero.
>
> Signed-off-by: Heinrich Schuchardt
The following patches are all Reviewed-by: Christian König
:
[PATCH 1/1] drm/amdgpu/gmc7: remove dead code
[PATCH 1/1] drm/amdgpu/gmc8: rem
On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote:
+
+ /*
+ * The relevant plane's ->atomic_check callback may set
+ * crtc_state->mode_changed to be true when the active
+ * plane needs to be reconf
Op 18-08-16 om 16:05 schreef Lyude Paul:
> On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 17-08-16 om 21:55 schreef Lyude:
>>> Since the watermark calculations for Skylake are still broken, we're apt
>>> to hitting underruns very easily under multi-monitor configuratio
On Mon, 22 Aug 2016, Daniel Vetter wrote:
> On Sun, Aug 21, 2016 at 07:56:19PM +0200, Heinrich Schuchardt wrote:
>> The C standard does not specify the size of the integer used
>> to store an enum. Hence in structure drm_stats32_t alignment
>> bytes may exist.
>>
>> To avoid exposing bytes from t
On Sun, 21 Aug 2016, Heinrich Schuchardt wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
> 1 file changed, 1 inser
On Sun, 21 Aug 2016, Heinrich Schuchardt wrote:
> All components of variable clock should be initialized
> to avoid bytes from the kernel stack to be exposed.
>
> Reported-by: Joe Perches
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
> 1 file changed
On 20 August 2016 at 23:31, Rob Clark wrote:
> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli wrote:
>> Cc'ing lkml too.
>>
>> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>>> Story time:
>>> I was dreaming of a day were we can stop installing these headers,
>>> thus making deprec
Am 22.08.2016 um 10:48 schrieb Emil Velikov:
>
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.
For the re
On Mon, 22 Aug 2016 09:29:17 +0200
Daniel Vetter wrote:
> On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> > Components m1, m2, p2, dot, vco of variable clock should be
> > initialized to avoid bytes from the kernel stack to be
> > exposed.
> >
> > Signed-off-by: Heinrich S
Am Sonntag, den 21.08.2016, 19:32 -0300 schrieb Fabio Estevam:
> There is no need to initialize variable 'err' with 0 because it will
> be properly assigned later on.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
This patch extends DRM API with generic support for hardware modules, which
can be used for processing image data from the one memory buffer to
another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them. I named such hardware modules a
framebuffer pr
This is a quick conversion of Exynos DRM rotator driver from
Exynos IPP framework to generic DRM FBProc API to demonstrate how to use it
from the driver side.
Not-for-merge-yet: the code of the driver must be cleaned up first, because
its internals still depends on Exynos IPP structures.
Signed-o
This patch extends DRM API with generic support for hardware modules, which
can be used for processing image data from the one memory buffer to
another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them. I named such hardware modules a
framebuffer pr
Dear all,
This is the initial proposal for extending DRM API with generic support for
hardware modules, which can be used for processing image data from the one
memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. In this pro
This is simple example how DRM FBProc API can be used from
userspace. The code allocates 2 dumb framebuffers, fill first with
test pattern and then performs 180 degree rotation of the image data.
TODO: add code to release all allocated resources
Signed-off-by: Marek Szyprowski
---
rotate.c | 33
Hey Marek,
I had a quick look at the series and I really like the new approach.
I was wondering about the following though. If I understand this
correctly I can only perform m2m operations on buffers which are
registered as framebuffers. Is this possible to weaken that requirements
such that arbi
On Mon, Aug 22, 2016 at 09:48:10AM +0100, Emil Velikov wrote:
> On 20 August 2016 at 23:31, Rob Clark wrote:
> > On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli
> > wrote:
> >> Cc'ing lkml too.
> >>
> >> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
> >>> Story time:
> >>> I was dr
Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> Dear all,
>
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
> rotation,
On Mon, Aug 22, 2016 at 4:48 AM, Emil Velikov
wrote:
> On 20 August 2016 at 23:31, Rob Clark wrote:
>> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli wrote:
>>> Cc'ing lkml too.
>>>
>>> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
Story time:
I was dreaming of a day we
Dear Tobias
On 2016-08-22 12:07, Tobias Jakobi wrote:
> Hey Marek,
>
> I had a quick look at the series and I really like the new approach.
>
> I was wondering about the following though. If I understand this
> correctly I can only perform m2m operations on buffers which are
> registered as frame
The GPU may still keep its state when in suspend, which breaks the
assumption that the hardware is in a clean state before the init
routine runs. Make sure to reset the GPU when coming back from
suspend, so this assumption is validated.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etna
This function has external visibility and only handles the Vivant IOMMU
version 1. Rename to make this more clear and allow a clear separation
of the different IOMMU versions.
Also drop the domain parameter, as we can infer it from the GPU we are
dealing with.
Signed-off-by: Lucas Stach
---
dri
Hi all,
this series adds support for the new MMU version 2, found on newer
Vivante cores. The new MMU provides full isolation, with no way for
the GPU to bypass it. This may enable optimizations like skipping
commandstream validation later on. For now we stick with a single
address space for all c
There is no linear window on MMUv2 and the FE can access the full 4GB
address space either directly (as long as the MMU isn't configured) or
through the MMU, once it is up.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(
As the comment above the code states, the linear window is only
available on MMUv1. Don't try to use it on MMUv2.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/dr
The GPU code doesn't need to deal with the IOMMU directly, instead
it can all be hidden behind the etnaviv mmu interface. Move the
last remaining part into etnaviv mmu.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 33 +++---
drivers/gpu/drm/
So we can call the v2 restore code once it is there.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 9 +
drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drive
Split out into a new externally visible function, as the IOMMUv2
code needs this functionality, too.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 40 +++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
2 files changed, 23 insertions(+), 18
With MMUv2 the command buffers need to be mapped through the MMU.
Split out the iova search and MMU reaping logic so it can be reused
for the cmdbuf mapping, where no GEM object is involved.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 62 +--
Split out into a new externally visible function, as the IOMMUv2
code needs this functionality, too.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --
With MMUv2 all buffers need to be mapped through the MMU once it
is enabled. Align the buffer size to 4K, as the MMU is only able to
map page aligned buffers.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 2 ++
drivers/gp
Flushing works differently on MMUv2, in that it's only necessary
to set a single bit in the control register to flush all translation
units. A semaphore stall then makes sure that the flush has propagated
properly.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 31
GC2000+ on the i.MX6QP is just a re-branded GC3000, lets call it by
its real name to avoid confusion in other parts of the driver.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnavi
It is only relevant for the V1 MMU, so we should not do this in the
common code.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 9 +
drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 7 +++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/d
Both the safe/scratch address and the master TLB address are per pipe
with the CPU mapped registers not properly propagating to the
different translation units.
The only way to correctly configure all translation units is to have
a command stream snipped executed by the FE, before any other execut
This has been there from the original merge, but has never been used.
Get rid of it.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h | 25 -
1 file changed, 25 deletions(-)
delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h
diff --gi
The GPU virtual address for the command buffers differs depending on
the IOMMU version. Move the calculation of the iova into etnaviv
mmu, to enable proper dispatch.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 16 ++--
drivers/gpu/drm/etnaviv/etnaviv_gpu
Bit 30 of the interrupt status signals an MMU exception. Handle this
condition properly and dump some useful registers.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
drivers/gpu/drm/etnaviv/state_hi.xml.h | 9 +
2 files changed, 17 insertions(+
All other parts are now in place, so implement the actual translation
step and hook it up, so the driver claims support for cores with
the new MMU.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_iommu.h| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 255 +++
Op 17-08-16 om 21:55 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them
Hello Marek,
Marek Szyprowski wrote:
> Dear Tobias
>
>
> On 2016-08-22 12:07, Tobias Jakobi wrote:
>> Hey Marek,
>>
>> I had a quick look at the series and I really like the new approach.
>>
>> I was wondering about the following though. If I understand this
>> correctly I can only perform m2m o
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #32 from Kontantin Ivanov ---
Created attachment 229671
--> https://bugzilla.kernel.org/attachment.cgi?id=229671&action=edit
4.8.0-040800rc3 dmesg
yet another dmesg for 4.8.0-rc3
--
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #33 from Kontantin Ivanov ---
Created attachment 229681
--> https://bugzilla.kernel.org/attachment.cgi?id=229681&action=edit
4.8.0-040800rc3 Xorg.0.log
yet another Xorg.0.log (4.8.0-rc3)
--
You are receiving this mail because:
Yo
Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > The GPU may still keep its state when in suspend, which breaks the
> > assumption that the hardware is in a clean state before the init
> > routine runs. Make
Am Montag, den 22.08.2016, 12:22 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote:
> > There is no linear window on MMUv2 and the FE can access the full 4GB
> > address space either directly (as long as the MMU isn't configured) or
> > through th
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/2aee8c0a/attachment.html>
Am Montag, den 22.08.2016, 13:27 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> > Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > > The GPU may
Hi Heinrich,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to rec
On Sun, 21 Aug 2016, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fixes the following sparse warning:
>
> drivers/gpu/drm/i915/intel_hotplug.c:480:6: warning:
> symbol 'i915_hpd_poll_init_work' was not declared. Should it be static?
>
> Also move the '{' to new line.
Thanks for the patch, but we'
and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/846b3b46/attachment.sig>
Hi Heinrich,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to rec
On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> The GPU may still keep its state when in suspend, which breaks the
> assumption that the hardware is in a clean state before the init
> routine runs. Make sure to reset the GPU when coming back from
> suspend, so this assumption is vali
On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > The GPU may still keep its state when in suspend, which breaks the
> > > assumption that the
Hi Stefan,
What do you think about this patch for gamma correction.
I see many people approach gamma correction this way. Do you have any
comments?
Best Regards,
Meng
> +static void fsl_crtc_gamma_set(struct drm_crtc *crtc, struct drm_color_lut
> *lut,
> +
On Mon, 22 Aug 2016, Daniel Vetter wrote:
> Everyone knows them, except all the new folks joining from the ARM
> side haven't lived through all the pain of the past years and are
> entirely surprised when I raise this. Definitely time to document
> this.
>
> Last time this was a big discussion was
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160822/a0b6e532/attachment-0001.sig>
On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote:
> There is no linear window on MMUv2 and the FE can access the full 4GB
> address space either directly (as long as the MMU isn't configured) or
> through the MMU, once it is up.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/e
On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote:
>> That said, _note_ that some applications are built with -C89 -pedantic
>> [1] which means that using stdint.h may or may not work as expected.
>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
>> If the affected programs ar
On Mon, Aug 22, 2016 at 04:23:36PM +0800, Ying Liu wrote:
> On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter wrote:
> > On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote:
> +
> + /*
> + * The relevant plane's ->atomic_check callback may set
> + * crtc_state->mode_cha
On Mon, Aug 22, 2016 at 11:59:24AM +0200, Christian König wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> > Dear all,
> >
> > This is the initial proposal for extending DRM API with generic support for
> > hardware modules, which can be used for processing image data from the one
> >
On 22 August 2016 at 15:38, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote:
>>> That said, _note_ that some applications are built with -C89 -pedantic
>>> [1] which means that using stdint.h may or may not work as expected.
>>> So we'll want a __STDC_VESION__ check + #er
Convert dma-buf documentation over to sphinx.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
v2: Address review comments from Jonathan Corbet and Markus Heiser.
Sumit
Branch out dma-buf related documentation into its own rst file to allow
adding it to the sphinx documentation generated.
While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too;
adjust MAINTAINERS accordingly.
v2:
- Removed authorship as suggested by Jani,
- Address review comment
Include dma-buf sphinx documentation into top level index.
Signed-off-by: Sumit Semwal
---
Documentation/index.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index e0fc72963e87..8d05070122c2 100644
--- a/Documentation/index.rst
+++ b/D
On Mon, Aug 22, 2016 at 5:59 AM, Christian König
wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
>>
>> Dear all,
>>
>> This is the initial proposal for extending DRM API with generic support
>> for
>> hardware modules, which can be used for processing image data from the one
>> memory b
In STM SoC we have hardware block doing scaling/colorspace conversion,
we have decide to use v4l2 mem2mem API for it:
https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html
the code is here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/sti/bdis
Hope this didn't take too long! Here's the backported versions of the patches
you had trouble applying to stable. The patch for FBC won't be necessary as
that is already present in 4.7.y.
Cheers,
Lyude
Lyude (4):
drm/i915/vlv: Make intel_crt_reset() per-encoder
drm/i915/vlv: Reset the
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Acked-by: Daniel Vetter
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 fi
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA ge
One of the things preventing us from using polling is the fact that
calling valleyview_crt_detect_hotplug() when there's a VGA cable
connected results in sending another hotplug. With polling enabled when
HPD is disabled, this results in a scenario like this:
- We enable power wells and reset the
Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview
While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get t
On Mon, Aug 22, 2016 at 04:05:21PM +0100, Emil Velikov wrote:
> On 22 August 2016 at 15:38, Daniel Vetter wrote:
> > On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote:
> >>> That said, _note_ that some applications are built with -C89 -pedantic
> >>> [1] which means that using stdint.h may or may
ng 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/20160822/08a6b961/attachment-0001.html>
to TTY and back.
--
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/20160822/d6c63e21/attachment.html>
is 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/20160822/2f5f165c/attachment.html>
1 - 100 of 130 matches
Mail list logo
