On Tue, 02 May 2017 07:45:25 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
> > I presume that if "desktop" is set to "true", it implies that the HMD
> > is capable of showing a simple 2D canvas in stereo without any special
> > rendering and with the default video mode. That is, creating
Hi all,
Very minor cleanups from Neil's review, and a minimal rebase because nouveau
changed something. Otherwise unchanged.
Still would like an ack from Ville/Mario before merging.
Thanks, Daniel
Daniel Vetter (5):
drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool
drm/vb
It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.
Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.
v2: Fixup misplaced hunks (Neil).
Cc: Mario
This is going to be a bit too much, but good to have at least a small
note about where this should all head towards.
Reviewed-by: Neil Armstrong
Signed-off-by: Daniel Vetter
---
include/drm/drm_drv.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_drv.h b/include
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is updated already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence t
There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
drm_crtc_handle_vblank at the wrong time) or a core bug (for
anything else)
In the previous patch we've implemented hwmode tracking a la i915 for
the vblank timestamp calculations. But that was just the basic
semantics, i915 has some nice sanity checks to make sure we keep
getting this right. Move them over too.
Cc: Ville Syrjälä
Reviewed-by: Neil Armstrong
Signed-off-b
On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > /**
> > + * drm_gem_prime_import_platform - alternate implementation of the import
> > callback
> > + * @dev: drm_device to import into
> > + * @dma_buf: dma-buf objec
On Mon, May 01, 2017 at 11:36:59AM -0700, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran"
>
> Use the added helpers to track MST link bandwidth for atomic modesets.
> Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> enabled with drm_atomic_find_vcpi_slots(). Simi
On Tue, 2017-05-02 at 17:38 +0200, Lucas Stach wrote:
> By setting the SFTRST bit, the PRE will be held in the lowest power state
> with clocks to the internal blocks gated. When external clock gating is
> used (from the external clock controller, or by setting the CLKGATE bit)
> the PRE will spora
By setting the SFTRST bit, the PRE will be held in the lowest power state
with clocks to the internal blocks gated. When external clock gating is
used (from the external clock controller, or by setting the CLKGATE bit)
the PRE will sporadically fail to start.
Signed-off-by: Lucas Stach
---
v2: ad
On Wed, Apr 26, 2017 at 03:59:28PM +0800, Chen-Yu Tsai wrote:
> >> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> >> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> >> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> >> > +
> >> > + x = mode->htotal -
On Wed, 2017-05-03 at 10:38 +0200, Lucas Stach wrote:
> By setting the SFTRST bit, the PRE will be held in the lowest power state
> with clocks to the internal blocks gated. When external clock gating is
> used (from the external clock controller, or by setting the CLKGATE bit)
> the PRE will spora
On Sat, Apr 29, 2017 at 05:48:14AM +1000, Dave Airlie wrote:
> On 27 April 2017 at 03:01, Liviu Dudau wrote:
> > Hi Dave,
> >
> > Updated pull request to fix the all-modconfig build on 32bit arm
> > builds.
> >
> > This pull request includes the latest updates on Mali DP, adding
> > support for co
Hi,
On 04/27/2017 10:06 PM, Eric Anholt wrote:
Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel. By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.
Signed-off-by: Eric Anhol
Hi,
> > R600+ supports bigendian framebuffer formats, so no byteswapping on
> > access is needed. Not sure whenever that includes 16bpp formats or
> > whenever this is limited to the 8 bit-per-color formats [...]
>
> It includes 16bpp. Looking at
> drivers/gpu/drm/radeon/atombios_crtc.c:dce4_c
Hi Archit,
On Wednesday 03 May 2017 14:53:00 Archit Taneja wrote:
> On 04/27/2017 10:06 PM, Eric Anholt wrote:
> > Many DRM drivers have common code to make a stub connector
> > implementation that wraps a drm_panel. By wrapping the panel in a DRM
> > bridge, all of the connector code (including
On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> +panel/bridge reviewers.
>
> This does make things much cleaner, but it seems a bit strange to create
> a drm_bridge when there isn't really a HW bridge in the display chain (i.e,
> when the DSI encoder is directly connected to a DSI
Hi Daniel,
On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> > +panel/bridge reviewers.
> >
> > This does make things much cleaner, but it seems a bit strange to create
> > a drm_bridge when there isn't really a HW bridge in
(I can't see this email that I have sent on 24th of April in the
dri-devel archives, so I'm guessing it fell through the cracks of my
wonderful email infrastructure. Please let me know if you want me
to rebase the tree on top of a more recent tag)
Hi Dave,
I'm not sure what is the best tree to t
On Thu, Apr 27, 2017 at 09:36:00AM -0700, Eric Anholt wrote:
> Many DRM drivers have common code to make a stub connector
> implementation that wraps a drm_panel. By wrapping the panel in a DRM
> bridge, all of the connector code (including calls during encoder
> enable/disable) goes away.
>
> Si
Hi Eric,
Am Mittwoch, den 12.04.2017, 12:12 -0700 schrieb Eric Anholt:
> If we follow the typical pattern of the base class being the first
> member, we can use the default dma_fence_free function.
Sorry, I don't like this change.
While it provides a bit of code simplification, it also bakes the
On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
> v2: A minor addition from Daniel
>
> Cc: Daniel Stone
You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
the drivers you touch. You do want reviews, don't you?
> Signed-off-by: Ben Widawsky
> ---
> drive
Hi,
Having just caught up on IRC I'm sure I'm far too late for this party,
but...
Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
stored "pointers" to separate blobs for the format and modifier lists?
struct drm_format_modifier_blob {
#define FORMAT_BLOB_CURRENT 1
/* Ve
Hi Brian,
On 3 May 2017 at 12:00, Brian Starkey wrote:
> Having just caught up on IRC I'm sure I'm far too late for this party,
> but...
>
> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
> stored "pointers" to separate blobs for the format and modifier lists?
>
> I've used/writ
divider_round_rate already evaluates changing the parent rate if
CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's
just use it.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu_div.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
Hi,
Here is an attempt at getting the HDMI controller running.
This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s,
A20, A31).
This driver only supports for now the A10s because it was an easy target,
being very close to the A13 that is already supported by our DRM driver.
The clocks might need to modify their parent clocks. In order to make that
possible, give them access to the parent clock being evaluated, and to a
pointer to the parent rate so that they can modify it if needed.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu_div.c | 7 ---
driv
The pre-divider retrieval code was merged into the function to apply the
current pre-divider onto the parent clock rate so that we can use that
adjusted value to do our factors computation.
However, since we'll need to do the reverse operation, we need to split out
that code into a function that w
The current code only rely on the parent to change its rate in the case
where CLK_SET_RATE_PARENT is set.
However, some clock rates might be obtained only through a modification of
the parent and the clock divider. Just rely on the round rate of the clocks
to give us the best computation that migh
So far, divider_round_rate only considers the parent clock returned by
clk_hw_get_parent.
This works fine on clocks that have a single parents, this doesn't work on
muxes, since we will only consider the first parent, while other parents
may totally be able to provide a better combination.
Clocks
The current function name is a bit confusing, and doesn't really allow to
create an explicit function to reverse the operation.
We also for now change the parent rate through a pointer, while we don't
return anything.
In order to be less confusing, and easier to use for downstream users,
change t
The video PLLs are used directly by the HDMI controller. Export them so
that we can use them in our DT node.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu-sun5i.h | 6 --
include/dt-bindings/clock/sun5i-ccu.h | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --
The Allwinner Timings Controller has two, mutually exclusive, channels.
When the binding has been introduced, it was assumed that there would be
only a single user per channel in the system.
While this is likely for the channel 0 which only connects to LCD displays,
it turns out that the channel 1
While all functions have debug logs, the channel enable and disable are not
logged. Make sure this is the case.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4
1 file changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/sun4
The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
controller.
That HDMI controller is able to do audio and CEC, but those have been left
out for now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 9 +-
drivers/gpu/drm/sun4i/Makefile
Currently, the parent rate given back to the clock framework in our
request is the original parent rate we calculated before trying to round
the rate of our clock.
This works fine unless our clock also changes its parent rate, in which
case we will simply ignore that change and still use the previ
The A10s Olinuxino has an HDMI connector. Make sure we can use it.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 29 +-
1 file changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinux
The A10s has an HDMI controller connected to the second TCON channel. Add
it to our DT.
Since the TV Encoder was the only channel 1 user so far, also add the
property now that we have several users.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a10s.dtsi | 50
The muxing can actually happen on both channels on some SoCs, so it makes
more sense to just move it out of the sun4i_tcon1_mode_set function and
create a separate function that needs to be called by the encoders.
Let's do that and convert the existing drivers.
Signed-off-by: Maxime Ripard
---
The generic connectors such as hdmi-connector doesn't have any driver in,
so if they are added to the component list, we will be waiting forever for
a non-existing driver to probe.
Add a list of the connectors we want to ignore when building our component
list.
Signed-off-by: Maxime Ripard
---
Both TCON channels need to have the resolution doubled, since the size the
hardware is going to use is whatever we put in the register divided by two.
However, we handle it differently for the two channels: in the channel 0,
our register access macro does the multiplication of the value passed as
It appears that the total vertical resolution needs to be doubled when
we're not in interlaced. Make sure that is the case.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon
Even though that mux is undocumented, it seems like it needs to be set to 1
when using composite, and 0 when using HDMI.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tc
One of the possible output of the display pipeline, on the SoCs that have
it, is the HDMI controller.
Add a binding for it.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 79 +++-
1 file changed, 79 insertions(+), 0 d
It seems like what's called a backporch in the datasheet is actually the
backporch plus the sync period. Fix that in our driver.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
Hi Daniel,
On Wed, May 03, 2017 at 12:47:18PM +0100, Daniel Stone wrote:
Hi Brian,
On 3 May 2017 at 12:00, Brian Starkey wrote:
Having just caught up on IRC I'm sure I'm far too late for this party,
but...
Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
stored "pointers" to
Am 02.05.2017 um 22:04 schrieb SF Markus Elfring:
From: Markus Elfring
Date: Tue, 2 May 2017 22:00:02 +0200
Three update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
Use seq_putc() in radeon_sa_bo_dump_debug_info()
Use seq_puts() in radeon_deb
Hi,
On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
Updated blob layout (Rob, Daniel, Kristian, xerpi)
Cc: Rob Clark
Cc: Daniel Stone
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mode_config.c | 7 +++
drivers/gpu/drm/drm_plane.c | 119
On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> Cc: Rob Clark
> Cc: Daniel Stone
> Cc: Kristian H. Kristensen
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/drm_mode_config.c | 7 +++
> drivers/gpu/drm/drm_plane.c
Hi Ben,
On 3 May 2017 at 06:14, Ben Widawsky wrote:
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> + /* Version of this blob format */
> + u32 version;
> +
> + /* Flags */
> + u32 flags;
> +
> + /* Number of fourcc formats supported */
> +
Hi Liviu,
On 3 May 2017 at 11:34, Liviu Dudau wrote:
> On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
>> v2: A minor addition from Daniel
>
> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
> the drivers you touch. You do want reviews, don't you?
Ouch.
Hi Brian,
On 3 May 2017 at 13:51, Brian Starkey wrote:
> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> + modifiers_size =
>> + sizeof(struct drm_format_modifier) *
>> format_modifier_count;
>> +
>> + blob_size = ALIGN(sizeof(struct drm_format_modifier_
On Tue, May 2, 2017 at 5:01 AM, Daniel Vetter wrote:
> On Fri, Apr 28, 2017 at 8:05 PM, Rob Clark wrote:
>> The ->preclose() hook is a good place to block for pending atomic
>> updates. We can't do this in ->postclose(), as it needs to happen
>> before drm_fb_release(). Otherwise, since we have
On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
Hi Brian,
On 3 May 2017 at 13:51, Brian Starkey wrote:
On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
+ modifiers_size =
+ sizeof(struct drm_format_modifier) *
format_modifier_count;
+
+ blo
Hi Brian,
On 3 May 2017 at 15:03, Brian Starkey wrote:
> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>> formats_offset is the end of the fixed-size element, which is
>> currently aligned to 32 bytes, and practically speaking would always
>> have to be anyway. As it is an array o
On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> Hi Liviu,
>
> On 3 May 2017 at 11:34, Liviu Dudau wrote:
> > On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
> >> v2: A minor addition from Daniel
> >
> > You are *really* pushing your luck by not Cc-ing *any* of the ma
On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> In the previous patch we've implemented hwmode tracking a la i915 for
> the vblank timestamp calculations. But that was just the basic
> semantics, i915 has some nice sanity checks to make sure we keep
> getting this right. Move them
On 3 May 2017 at 15:07, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
>> On 3 May 2017 at 11:34, Liviu Dudau wrote:
>> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers
>> > of
>> > the drivers you touch. You do want reviews, don't y
Hi Daniel,
On Wed, May 03, 2017 at 03:07:40PM +0100, Daniel Stone wrote:
Hi Brian,
On 3 May 2017 at 15:03, Brian Starkey wrote:
On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
formats_offset is the end of the fixed-size element, which is
currently aligned to 32 bytes, and pract
Hi Harry,
while this looks more and more like it could work something which would
really help would be to have a set of patches squashed together and
rebased on drm-next.
The dc-drm-next-atomic-wip looks like a start, but we need more
something like:
drm/amdgpu: add base DC components
drm/a
Hi all,
Over the last few months we (mostly Andrey and myself) have taken and
addressed some of the feedback received from December's DC RFC. A lot of
our work so far centers around atomic. We were able to take a whole
bunch of the areas where we rolled our own solution and use DRM atomic
hel
On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> > On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> > > +panel/bridge reviewers.
> > >
> > > This does make things much cleaner, but it seems
Somehow the helper was never retrofitted for mdp5. Which meant when
plane_state->fence was added, it could get copied into new state in
mdp5_plane_duplicate_state().
If an update to disable the plane (for example on rmfb) managed to sneak
in after an nonblock update had swapped state, but before
On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
>> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
>>> /**
>>> + * drm_gem_prime_import_platform - alternate implementation of the import
>>> callback
>>> + * @dev: drm_devic
Hi Daniel,
On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote:
> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
> > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
> >> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> >>> +panel/bridge reviewers.
> >>>
On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> On 3 May 2017 at 15:07, Liviu Dudau wrote:
> > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> >> On 3 May 2017 at 11:34, Liviu Dudau wrote:
> >> > You are *really* pushing your luck by not Cc-ing *any* of the
> >> >
On Wed, May 03, 2017 at 03:16:13PM +0100, Jose Abreu wrote:
> Hi Daniel,
>
>
> On 03-05-2017 07:19, Daniel Vetter wrote:
> > On Tue, May 2, 2017 at 11:29 AM, Jose Abreu wrote:
> >> On 02-05-2017 09:48, Daniel Vetter wrote:
> >>> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>
On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:
> Hi Harry,
>
> while this looks more and more like it could work something which would
> really help would be to have a set of patches squashed together and rebased
> on drm-next.
>
> The dc-drm-next-atomic-wip looks like a start,
On Wed, May 03, 2017 at 10:40:36AM -0400, Rob Clark wrote:
> Somehow the helper was never retrofitted for mdp5. Which meant when
> plane_state->fence was added, it could get copied into new state in
> mdp5_plane_duplicate_state().
>
> If an update to disable the plane (for example on rmfb) manage
On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> >>> /**
> >>> + * drm_gem_prime_import_platform - alte
On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> Cc: Rob Clark
> Cc: Daniel Stone
> Cc: Kristian H. Kristensen
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/drm_mode_config.c | 7 +++
> drivers/gpu/drm/drm_plane.c
2017-05-02 Daniel Vetter :
> On Thu, Apr 27, 2017 at 11:35:06AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Use "non-blocking" and "blocking" instead of old names.
> >
> > Signed-off-by: Gustavo Padovan
>
> Reviewed-by: Daniel Vetter
Thanks for the review. Pushed to drm-
On Wed, May 03, 2017 at 05:00:31PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 03:16:13PM +0100, Jose Abreu wrote:
> > Hi Daniel,
> >
> >
> > On 03-05-2017 07:19, Daniel Vetter wrote:
> > > On Tue, May 2, 2017 at 11:29 AM, Jose Abreu
> > > wrote:
> > >> On 02-05-2017 09:48, Daniel Vet
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura
On Wed, May 3, 2017 at 11:04 AM, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 10:40:36AM -0400, Rob Clark wrote:
>> Somehow the helper was never retrofitted for mdp5. Which meant when
>> plane_state->fence was added, it could get copied into new state in
>> mdp5_plane_duplicate_state().
>>
>> I
Lucas Stach writes:
> Hi Eric,
>
> Am Mittwoch, den 12.04.2017, 12:12 -0700 schrieb Eric Anholt:
>> If we follow the typical pattern of the base class being the first
>> member, we can use the default dma_fence_free function.
>
> Sorry, I don't like this change.
> While it provides a bit of code
The counter load enable bit has no effect when the shadow register
set is activated. As we always operate the PRG with shadow enabled
it is safe to remove this.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-prg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu
Laurent Pinchart writes:
> Hi Daniel,
>
> On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote:
>> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote:
>> > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote:
>> >> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
>>
This adds FB modifier support for the Vivante single buffer tiled formats,
when the PRG/PRE engines are present.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/imx-drm-core.c | 1 +
drivers/gpu/drm/imx/ipuv3-plane.c | 55 ++
2 files changed, 51 insertion
This adds the required bits to the ipu-v3 and imx-drm driver to make
scanout of the Vivante (super-)tiled single buffer format work on
i.MX6 QuadPlus. A userspace taking advantage of this support is able
to skip the linear resolve step in the GPU, saving quite a lot of memory
bandwidth especially w
This configures the TPR unit, using the DRM format modifier. For now only
the single buffer modifiers are supported, as split buffer needs more
configuration for the required cropping.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-pre.c | 24 ++--
drivers/gpu/ipu-v3/i
Allow to pass through the modifier to the PRE unit and extend the
format check with the supported modifiers.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 4 +++-
drivers/gpu/ipu-v3/ipu-prg.c | 13 ++---
include/video/imx-ipu-v3.h| 2 +-
3 files change
Let userspace know about the supported modifiers, to make automatic
selection of a proper modifier possible.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/im
Archit Taneja writes:
> Hi,
>
> On 04/27/2017 10:06 PM, Eric Anholt wrote:
>> Many DRM drivers have common code to make a stub connector
>> implementation that wraps a drm_panel. By wrapping the panel in a DRM
>> bridge, all of the connector code (including calls during encoder
>> enable/disable
On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> > On 3 May 2017 at 15:07, Liviu Dudau wrote:
> > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
> > >> It does deserve a much better commit message than w
Hi Lucas,
On 3 May 2017 at 17:28, Lucas Stach wrote:
> int available_pres = ipu_prg_max_active_channels();
> int i;
>
> + /*
> +* We are going over the planes in 2 passes: first we assign PREs to
> +* planes with a tiling modifier, which need the PREs to reso
On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote:
> > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> > > On 3 May 2017 at 15:07, Liviu Dudau wrote:
> > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel
Hi Ben,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170503]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb
Hi Ben,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170503]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb
Daniel Vetter writes:
> On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote:
>> The FBDEV initialization would throw an error in dmesg, when we just
>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>
>> Signed-off-by: Eric Anholt
>
> With the commit message updated
https://bugs.freedesktop.org/show_bug.cgi?id=100919
Bug ID: 100919
Summary: "Out of range" on a display connected to a DVI-D
output of RX460 card via DVI-D<=>HDMI-A cable
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD6
On Wed, May 03, 2017 at 08:44:53AM +0800, Shawn Guo wrote:
> Hi Sean,
>
> On Tue, Apr 11, 2017 at 7:30 PM, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > It adds VGA driver support, which needs to configure corresponding VOU
> > interface in RGB_888 format, and thus the following changes are neede
On 2017-05-03 11:02 AM, Daniel Vetter wrote:
On Wed, May 03, 2017 at 04:26:51PM +0200, Christian König wrote:
Hi Harry,
while this looks more and more like it could work something which would
really help would be to have a set of patches squashed together and rebased
on drm-next.
The dc-drm-
On Thu, Mar 30, 2017 at 01:16:26PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 10:10 +0100, Chris Wilson wrote:
> > Scatter a few cond_resched() in between phases of the drm_mm selftests
> > to try and prevent us incurring the wrath of the NMI watchdog.
> >
> > Signed-off-by: Chris Wilson
hean.loong@intel.com writes:
> From: Ong Hean Loong
>
> Hi,
>
> The new Intel Arria10 SOC FPGA devkit has a Display Port IP component
> which requires a new driver. This is a virtual driver in which the
> FGPA hardware would enable the Display Port based on the information
> and data provide
hean.loong@intel.com writes:
> From: "Ong, Hean Loong"
>
> Driver for Intel FPGA Video and Image Processing
> Suite Frame Buffer II. The driver only supports the Intel
> Arria10 devkit and its variants. This driver can be either
> loaded staticlly or in modules. The OF device tree binding
> i
On Fri, Apr 28, 2017 at 02:47:11PM +0100, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if t
Hi all,
On Fri, 21 Apr 2017 12:10:14 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in
> initializer
> .kmap_atomic = tee_shm_op
Pekka Paalanen writes:
> do you mean to list all kinds of display devices in the database? I was
> assuming it would list only HMDs, so not in database would imply it's a
> normal display and good for extending the desktop to.
I intended for it to be a general database to which we could add almo
1 - 100 of 103 matches
Mail list logo
