ves/dri-devel/attachments/20161219/049d5ab2/attachment.html>
On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote:
> On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > > On Fri, 16 Dec 2016, Daniel Vetter wrote:
> > > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wr
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/20161219/db7ac126/attachment.html>
Hello!
On 12/14/2016 11:55 PM, Laurent Pinchart wrote:
>> We're going to use R8A7791 VSPDs to control DU, so set the corresponding
>> flag.
>>
>> Signed-off-by: Sergei Shtylyov
>
> For the same reason I nacked the corresponding patch to the VSP1 driver, I
> have to nack this one as well. The Gen
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_d
Hi Sergei,
On Monday 19 Dec 2016 22:58:57 Sergei Shtylyov wrote:
> On 12/14/2016 11:55 PM, Laurent Pinchart wrote:
> >> We're going to use R8A7791 VSPDs to control DU, so set the corresponding
> >> flag.
> >>
> >> Signed-off-by: Sergei Shtylyov
> >
> > For the same reason I nacked the correspon
d are the captured images.
--
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/20161219/baa9db20/attachment-0001.html>
Attached are the captured images.
--
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/20161219/c15c6934/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/bd176f42/attachment.html>
ate supported by the
>> * sink in kHz. 0 means undefined.
>> @@ -185,6 +225,14 @@ struct drm_display_info {
>> u8 edid_hdmi_dc_modes;
>>
>> /**
>> + * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
>> + * various sinks can support
Hi Rob,
On Monday 19 Dec 2016 09:38:49 Rob Herring wrote:
> On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
> >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
> >>> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
>
On 12/19/16 16:19, Bartosz Golaszewski wrote:
>> I would add here:
>> + if ((tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
>> + LCDC_RASTER_ENABLE)) {
>>
>>> + tilcdc_clear(dev,
>>> + LCDC_RASTER_CTRL_REG,
uild test WARNING on asoc/for-next]
> [also build test WARNING on v4.9 next-20161219]
> [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/Arnaud-Pouliquen/Generic-HDMI-codec-
On Mon, Dec 19, 2016 at 05:00:49PM +0100, Daniel Vetter wrote:
> On Mon, Dec 19, 2016 at 05:38:57PM +0530, Archit Taneja wrote:
> > @@ -873,6 +894,81 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> > return ret;
> > }
> >
> > +static int mdp5_update_cursor_plane_legacy(struct dr
Register cursor drm_planes. The loop in modeset_init that inits the
planes and crtcs has to be refactored a bit. We first iterate all the
hwpipes to find the cursor planes. Then, we loop again to create
crtcs.
In msm_atomic_wait_for_commit_done, remove the check which bypasses
waiting for vsyncs i
This code has been more or less picked up from the vc4 and intel
implementations of update_plane() funcs for cursor planes.
The update_plane() func is usually the drm_atomic_helper_update_plane
func that will issue an atomic commit with the plane updates. Such
commits are not intended to be done f
In mdp5_plane_atomic_check, we get crtc_state from
drm_plane_state.
Later, for cursor planes, we'll populate the update_plane()
func that takes a fast asynchronous path to implement cursor
movements. There, we would need to call a similar atomic_check
func to validate the plane state, but crtc_sta
These are various changes in preparation for cursor planes:
- Add a pipe_cursor block for 8x96 in mdp5_cfg.
- Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
- Update mdp5_ctl_blend/ext_blend masks to inco
In MDP5 Layer Mixer HW, the blender output is only the blended color
components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
is fed to the BG input of the next blender. We also need to provide an
alpha (COLOR3) value for the BG input at the next stage.
This is configured via using
The MDP5 plane's atomic_check ops doesn't perform clipping tests.
This didn't hurt us much in the past, but clipping becomes important
with cursor planes.
Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers
already do. Clipping requires knowledge of the crtc width and height.
This
Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
the drm_plane. Returning '0' means we are returning VIG0 pipe.
Also, use the mdp5_pipe enum to pass around the stage array. Initialize
the stage to SSPP_NONE by default.
We do the above because 1) Cursor plane has to be stage
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index 27d5371..6db1b8b 100644
--- a/driv
Define the block in advance so that the generated mdp5.xml.h doesn't
break build.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index
This series does some mdp5_plane related clean ups (use plane helpers
for clipping etc), adds MDP5 bits needed for cursor plane blocks, and
then add cursor planes.
On older MDP5 versions, we had cursor HW in Layer Mixer blocks, and
that's implemented in mdp5_crtc.c. With newer hardware, the cursor
--
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/20161219/aa957e5f/attachment.html>
On Mon, Dec 19, 2016 at 05:38:57PM +0530, Archit Taneja wrote:
> This code has been more or less picked up from the vc4 and intel
> implementations of update_plane() funcs for cursor planes.
>
> The update_plane() func is usually the drm_atomic_helper_update_plane
> func that will issue an atomic
On Mon, Dec 19, 2016 at 05:38:49PM +0530, Archit Taneja wrote:
> This series does some mdp5_plane related clean ups (use plane helpers
> for clipping etc), adds MDP5 bits needed for cursor plane blocks, and
> then add cursor planes.
>
> On older MDP5 versions, we had cursor HW in Layer Mixer block
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/868f4301/attachment.html>
From: Sourab Gupta
In the current scenario, the relay API fit well only with debugfs, due to
availability of parent dentry. Any other existing filesystem was not feasible
for
holding guc logs, due to incompatibility with relay. But this makes the guc_log
file unavailable on the production kerne
From: Sourab Gupta
A driver specific directory is created inside drmfs root, and dentry of
this directory is saved for subsequent use by the driver (e.g. i915).
The driver can then create files/directories inside this root directory
directly.
In case of i915 driver, the top directory is created
From: Sourab Gupta
The drmfs filesystem will not be registered standalone during kernel init time,
instead it is intended to be initialized/registered during drm initialization.
This again is dependent on CONFIG_DRMFS being defined.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
From: Sourab Gupta
The patch introduces a new pseudo filesystem type, named 'drmfs' which is
intended to house the files for the data generated by drm subsystem that
cannot be accommodated by any of the existing filesystems.
The filesystem is modelled on the lines of existing pseudo-filesystems s
From: Swati Dhingra
Currently, we don't have a stable ABI which can be used for the purpose of
providing output debug/loggging/crc and other such data from DRM.
The ABI in current use (filesystems, ioctls, et al.) have their own
constraints and are intended to output a particular type of data.
Fe
Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
caused by limited memory bandwidth may leave the picture shifted a
couple pixels to the right.
This issue has not been observed on revision 1, while the recovery
mechanism introduces a different issue, where the END_OF_FRAME
interrup
We currently create CRTCs equaling to the # of Layer Mixer blocks we
have on the MDP5 HW. This number is generally more than the # of encoders
(INTFs) we have in the MDSS HW. The number of encoders connected to
displays on the platform (as described by DT) would be even lesser.
Create only N drm_c
Count can't be non-zero. Changing to uint will also prevent future
warnings.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_c
For the DSI interfaces, the mdp5_kms core creates 2 encoders for video
and command modes.
Create only a single encoder per interface. When creating the encoder, set
the interface type to MDP5_INTF_MODE_NONE. It's the bridge (DSI/HDMI/eDP)
driver's responsibility to set a different interface type.
Rename the mdp5_encoder_* ops for active displays to
mdp5_vid_encoder_* ops.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 31 ++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 3 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 4 ++-
The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for video mode and the other
for command mode operation. The reason behind this approach could have
been that we aren't aware of th
We currently create 2 encoders for DSI interfaces, one for command
mode and other for video mode operation. This isn't needed as we
can't really use both the encoders at the same time. It also makes
connecting bridges harder.
Switch to creating a single encoder. For now, we assume that the
encoder
The MDP5 and DSI drivers created 2 drm_encoders for a DSI interface (one
for each mode of operation). This patch fixes that.
Now, with the # encoders equal to the # of displays, we can create the
right # of CRTCs. We previously created LM # of CRTCs, which ate up
too many primary planes.
Archit T
2016ë
12ì 18ì¼ 07:12ì Laurent Pinchart ì´(ê°) ì´ ê¸:
> Hello Inki,
>
> On Saturday 17 Dec 2016 09:33:31 Inki Dae wrote:
>> HI,
>>
>> Thanks for patch. Reasonable to me and go to misc excepting below one thing.
>> Please check my comment.
>>
>> 2016-12-14 4:34 GMT+09:00 Laurent Pinchar
2016-12-19 14:09 GMT+01:00 Jyri Sarha :
> One comment bellow.
>
> On 12/13/16 17:07, Bartosz Golaszewski wrote:
>> Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
>> caused by limited memory bandwidth may leave the picture shifted a
>> couple pixels to the right.
>>
>> This issue h
On 19/12/16 13:29, Chris Wilson wrote:
> On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
>> With recent 4.10 kernel the graphics isn't coming up under Xen. First
>> failure message is:
>>
>> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes)
>
> Do we get a
One comment bellow.
On 12/13/16 17:07, Bartosz Golaszewski wrote:
> Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
> caused by limited memory bandwidth may leave the picture shifted a
> couple pixels to the right.
>
> This issue has not been observed on revision 1, while the rec
Hi,
On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote:
> On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen
> wrote:
>
> > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan.
> >
> > ...
> >
> > I just don't have time to even pretend I maintain fbdev, so mark it a
On 12/19/2016 11:54 AM, Jani Nikula wrote:
> On Wed, 31 Aug 2016, Daniel Vetter wrote:
>> On Wed, Aug 31, 2016 at 02:09:05PM +0300, Peter Ujfalusi wrote:
>>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>>> pending and if we have, schedule the work to run without delay
Reviewed-by: Sinclair Yeh
thanks!
On Fri, Dec 16, 2016 at 05:04:02PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with mos
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/20161219/6d2d7acc/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/d7fce248/attachment.html>
Hi Maarten,
Thank you for the patch.
On Monday 19 Dec 2016 12:08:16 Maarten Lankhorst wrote:
> Op 13-12-16 om 18:10 schreef Daniel Vetter:
> > On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
> >> Op 09-12-16 om 09:25 schreef Daniel Vetter:
> >>> On Fri, Dec 09, 2016 at 12:42:19
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/d2e5133a/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/06d87208/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/0f23eb48/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/ebc24d09/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/3de77b98/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/4e52966a/attachment.html>
|are set to defaults |are set to defaults
--
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/20161219/e3d4c
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/9ff831b1/attachment.html>
|high
--
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/20161219/e508806a/attachment.html>
Op 19-12-16 om 13:08 schreef Archit Taneja:
> This code has been more or less picked up from the vc4 and intel
> implementations of update_plane() funcs for cursor planes.
>
> The update_plane() func is usually the drm_atomic_helper_update_plane
> func that will issue an atomic commit with the plan
|Linux (All)
--
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/20161219/283ec744/attachment.html>
- dri-devel at lists.kernel.org
+ dri-devel at lists.freedesktop.org
Regards
Shashank
-Original Message-
From: Sharma, Shashank [mailto:shashank.sha...@intel.com]
Sent: Monday, December 19, 2016 7:00 PM
To: Thierry Reding ; dri-devel at lists.kernel.org
Cc: Jani Nikula ; Ville Syrjälä
amdgpu and radeon development has moved to this list.
Signed-off-by: Alex Deucher
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a7a7731..3e21c61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4066,7 +4066,7 @@ F:drive
On Sun, Dec 18, 2016 at 8:46 AM, Daniel Vetter wrote:
> On Sat, Dec 17, 2016 at 04:35:09PM +, 'Liviu Dudau' wrote:
>> On Fri, Dec 16, 2016 at 07:16:25PM +, Deucher, Alexander wrote:
>> > > -Original Message-
>> > > From: Liviu Dudau [mailto:liviu at dudau.co.uk]
>> > > Sent: Friday
On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off
On Fri, Dec 16, 2016 at 07:25:13PM +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the
On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote:
> The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
>
> Signed-off-by: Caesar Wang
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7
> +++
> 1
...
Name: boris.patch
Type: text/x-patch
Size: 3759 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/06ce54cf/attachment-0001.bin>
xt attachment was scrubbed...
Name: 0001-drm-i915-Fallback-to-single-PAGE_SIZE-segments-for-D.patch
Type: text/x-diff
Size: 2486 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/68ef548d/attachment.patch>
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When con
During probe, DAIs can need to perform some actions that request
the knowledge of the pcm runtime handle.
The callback is called during DAIs linking, after PCM device creation.
For instance this can be used to add relationship between a DAI pcm
control and the pcm device.
Signed-off-by: Arnaud Pou
For HDMI, channel mapping can be retrieved from ELD. In this case mapping
can change during runtime (plug/unplug).
This patch removes the 'const' property of the struct chmap.
Signed-off-by: Arnaud Pouliquen
---
include/sound/pcm.h | 4 ++--
sound/core/pcm_lib.c | 6 +++---
2 files changed, 5 i
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d44..de935
Aim of this patch is to add 'Playback Channel Map' control to export
audio capabilities in term of HDMI sink speakers allocation.
V3:
- "ASoC: hdmi-codec: add channel mapping control":
=> Minor fixes:
- select stereo speaker config by default if HDMI cable unplugged
- fix
Op 13-12-16 om 18:10 schreef Daniel Vetter:
> On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
>> Op 09-12-16 om 09:25 schreef Daniel Vetter:
>>> On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
Hi Daniel,
On Thursday 08 Dec 2016 16:41:04 Daniel Vet
I detected 2 issues in this version, details below.
V3 is following.
Sorry for the inconvenience...
Regards
Arnaud
On 12/14/2016 04:16 PM, Arnaud Pouliquen wrote:
> +static unsigned long hdmi_codec_spk_mask_from_alloc(int spk_alloc)
> +{
> + int i;
> + const unsigned long hdmi_codec_eld
On Wed, 31 Aug 2016, Daniel Vetter wrote:
> On Wed, Aug 31, 2016 at 02:09:05PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only
bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/ddfcd371/attachment.sig>
cribe / Change Profile: http://ymlp165.net/ughmswhmgsgwwqjqjgewesggehswj
Powered by YourMailingListProvider
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/b67ed438/attachment.html>
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the rem
On Wed, 14 Dec 2016, Arnaud Pouliquen wrote:
> Add helper to allow users to retrieve the speaker allocations without
> knowledge of the ELD structure.
>
> Signed-off-by: Arnaud Pouliquen
For this one patch,
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_edid.h | 13 +
> 1 file
t --
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/20161219/64911a0f/attachment.sig>
On Mon, Dec 19, 2016 at 11:09:55AM +0200, Jani Nikula wrote:
> On Wed, 14 Dec 2016, Arnaud Pouliquen wrote:
> > Add helper to allow users to retrieve the speaker allocations without
> > knowledge of the ELD structure.
> >
> > Signed-off-by: Arnaud Pouliquen
>
> For this one patch,
>
> Reviewed-
2016ë
08ì 16ì¼ 01:02ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding renderi
On 12/18/16 00:39, Laurent Pinchart wrote:
> The field contains a pointer to the parent platform device of the DRM
> device. As struct drm_device also contains a dev pointer to the struct
> device embedded in the platform_device structure, the platformdev field
> is redundant. Remove it and use the
On Mon, Dec 19, 2016 at 10:40:41AM +0900, Inki Dae wrote:
>
>
> 2016ë
08ì 16ì¼ 01:02ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> >> Rendering operations to the dma-buf are tracked implicitly via the
> >> reservation_object (dmabuf->r
On Mon, 19 Dec 2016 14:34:12 +0100 Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote:
> > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen
> > wrote:
> >
> > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan.
> >
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwin
On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
>> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
>> > On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
>> >> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart
Hi Laurent,
On 17 December 2016 at 22:29, Laurent Pinchart
wrote:
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the device nodes. Its usage is
> deprecated, inline it in the probe function and call drm_dev_alloc() and
> drm_dev_reg
I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.
One thing I failed at is getting DOT to layout the overview grap
I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.
One thing I failed at is getting DOT to layout the overview grap
Resulted in confusion a few times in the past.
Cc: Laurent Pinchart
Cc: Manasi Navare
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 0
First overview text (if there is any), then headers (since generally
you want to start out with the data structures), then all the other
stuff with functions.
Most of this is pre-shpinx, since with the old docbook only the
overview stuff was pulled in directly. Everything else was put in a
per-sec
Oh, the shiny and pretties!
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 4 ++
Documentation/gpu/drm-kms.rst | 132 ++
2 files changed, 136 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rs
Some addition comments on the implementation:
- Also needs to be hacked up for svg conversion.
- Inline kernel-render creates temp files and caches them, doesn't
seem that good an idea. Probably should switch over to using pipes.
- Reimplements sphinx' depency tracking. Might be fixable if we jus
From: Markus Heiser
This patch brings scalable figure, image handling and a concept to
embed *render* markups:
* DOT (http://www.graphviz.org)
* SVG
For image handling use the 'image' replacement::
.. kernel-image:: svg_image.svg
:alt:simple SVG image
For figure handling use t
Hi all,
So this is my first stab at doing some overview diagrams for drm. Pretty much
like what it looks like, both input and output. Well there's one layout issue
where I couldn't convince DOT to do what I want it to do. All based on Markus'
kernel-figures script.
I think the script needs a bit
Thanks Thierry and Daniel for concluding this discussion, while I was on
vacation.
Here are the next steps, which I am planning to go for (Please correct me if my
understanding is not right)
- Shashank to review first of the SCDC patch, and give comments or R-B.
- Shashank to work on Thierry
1 - 100 of 105 matches
Mail list logo
