From: Gustavo Padovan
Signalling doesn't need to be enabled at sync_file creation, it is only
required if userspace waiting the fence to signal through poll().
Thus we delay fence_add_callback() until poll is called. It only adds the
callback the first time poll() is called. This avoid re-adding
From: Gustavo Padovan
Document the new function added to sync_file.c
v2: Adapt to fence_array
Signed-off-by: Gustavo Padovan
Acked-by: Christian König
---
Documentation/sync_file.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/sync_file.txt b/Documenta
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence containing all fences in the sync_file.
v2: Comments by Daniel Vetter
- Adapt to new version of fence_collection_init()
- Hold a reference for the fence we return
v3:
- Adapt to u
From: Gustavo Padovan
Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.
This change cleans up sync_file a bit. We don'
From: Gustavo Padovan
Add helper to check if fence is array.
v2: Comments from Chris Wilson
- remove ternary if from ops comparison
- add EXPORT_SYMBOL(fence_array_ops)
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
Reviewed-by: Chris Wilson
Reviewed-by
On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote:
> 2016-08-03 Chris Wilson :
>
> > On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Signalling doesn't need to be enabled at sync_file creation, it is only
> > > required if us
Hi Lin,
Am Freitag, 29. Juli 2016, 15:56:56 schrieb Lin Huang:
> 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
pl
Hi
On Thu, Aug 4, 2016 at 10:01 PM, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 02:50:37PM -0500, Ken Phillis Jr wrote:
>> I believe this driver is extremely useful, and I see possible issues with
>> the fact that the driver is GPL Only. This driver is critical for devices
>> that lack a prope
On Thu, Aug 04, 2016 at 02:50:37PM -0500, Ken Phillis Jr wrote:
> I believe this driver is extremely useful, and I see possible issues with
> the fact that the driver is GPL Only. This driver is critical for devices
> that lack a proper DRM driver, and locking it into GPL Only could lead to
> issue
To indicate an error, debugfs_create_file can return an ERR_PTR for
!CONFIG_DEBUG_FS and NULL otherwise, so in case the result is
dereferenced there should be a previous IS_ERR and a NULL check.
The Coccinelle semantic patch used to find the issue is as follows:
@@
expression e;
identifier f;
@@
To indicate an error, debugfs_create_file can return an ERR_PTR for
!CONFIG_DEBUG_FS and NULL otherwise, so in case the result is
dereferenced there should be a previous IS_ERR and a NULL check.
The Coccinelle semantic patch used to find the issue is as follows:
@@
expression e;
identifier f;
@@
On Thu, Aug 04, 2016 at 06:58:55PM +0200, Noralf Trønnes wrote:
>
> I didn't read the binding document[1], which I should have done.
> If simpledrm claims to be compatible with simple-framebuffer I assume it
> should support the entire binding doc which includes clocks, regulators
> and having th
Regards
Shashank
On 8/4/2016 7:46 PM, Jose Abreu wrote:
> Hi Sharma,
>
>
> On 03-08-2016 16:47, Sharma, Shashank wrote:
>> Hello Joes,
>>> I've also seen this before and I am using them in order to pass HDMI
>>> compliance. Without
>>> these patches the compliance fails. Still, I've made some c
Den 04.08.2016 16:36, skrev Daniel Vetter:
> On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
>> This patchset adds the simpledrm driver by David Herrmann based on a
>> patchset[1] from 2014. That patchset also included patches for kicking
>> out simpledrm by real drivers. I have s
On Thu, Aug 04, 2016 at 12:53:04PM -0400, Alex Deucher wrote:
> On Thu, Aug 4, 2016 at 12:24 PM, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 10:59:38AM -0400, Alex Deucher wrote:
> >> Adding dri-devel.
> >>
> >> This patch set basically adds a driver option to enable virtual
> >> display hw i
On Thu, Aug 04, 2016 at 07:05:19PM +0200, Noralf Trønnes wrote:
>
> Den 04.08.2016 16:03, skrev Noralf Trønnes:
> > The SimpleDRM driver binds to simple-framebuffer devices and provides a
> > DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> > plus one initial mode.
> >
On Thu, Aug 04, 2016 at 05:59:42PM +0200, Luc Verhaegen wrote:
> On Thu, Aug 04, 2016 at 05:44:23PM +0200, David Herrmann wrote:
> > On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen wrote:
> > > Do we really want to recreate a 400+ email thread again, or are we
> > > capable of learning from the past
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
Most of those have firmware interfaces for things like colour setting and
hardware scrolling. I
This patch adds the device nodes for the DISP function blocks for MT2701
Signed-off-by: YT Shen
---
arch/arm/boot/dts/mt2701.dtsi | 86 +
1 file changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index f
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 ++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c |
This patch update enable/disable flow of DSI module and MIPI TX module
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 103 ++--
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 32 +-
2 files changed, 102 insertion
From: shaoming chen
add dsi read/write commands for transfer function
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 261
1 file changed, 261 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/
From: shaoming chen
add dsi interrupt control
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 76
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a9cf5a1..
cleaning up unused define and refine function name and variable
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 77 +++-
drivers/gpu/drm/mediatek/mtk_mipi_tx.c |8 ++--
2 files changed, 41 insertions(+), 44 delet
update connections for OVL, RDMA, BLS, DSI
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 10
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT Shen
---
drivers/gpu/drm/media
Add MT8173 prefix for hardware related macros.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 60
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp
This is MT2701 DRM support PATCH v6, based on 4.7-rc1.
We add DSI interrupt control, transfer function for MIPI DSI panel support.
Most codes are the same, except some register changed.
For example:
- DISP_OVL address offset changed, color format definition changed.
- DISP_RDMA fifo size changed
Den 04.08.2016 16:03, skrev Noralf Trønnes:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into the real
> frameb
On 04.08.2016 18:51, Daniel Stone wrote:
> On 4 August 2016 at 04:39, Michel Dänzer wrote:
>> Patch 6 extends the ioctl with new flags, which allow userspace to
>> explicitly specify the target vblank seqno. This can also avoid delaying
>> flips in some cases where we are already in the target ve
Den 04.08.2016 16:15, skrev Luc Verhaegen:
> On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
>> I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
>> framebuffer and producing this node:
>>
>> framebuffer at 1e887000 {
>> compatible =
Regards
Shashank
On 8/4/2016 5:04 PM, Emil Velikov wrote:
> On 4 August 2016 at 11:16, Sharma, Shashank
> wrote:
>> Hello Emil,
>>
>> Thanks for your time.
>>
>> I have got mixed opinion on this.
>>
>> IMHO we should expose them to userspace too, as UI agents like Hardware
>> composer/X/Waylan
Thanks Daniel.
My comments, inline.
Regards
Shashank
On 8/4/2016 4:06 PM, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 03:46:09PM +0530, Sharma, Shashank wrote:
>> Hello Emil,
>>
>> Thanks for your time.
>>
>> I have got mixed opinion on this.
>>
>> IMHO we should expose them to userspace too,
drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:
==
[ INFO: possible circular locking dependency detect
ion public domain.
>
> Thanks
> David
>
Thank you for the quick response, and I'll make a note of this.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160804/0557a7c0/attachment.html>
On Thu, Aug 04, 2016 at 10:59:38AM -0400, Alex Deucher wrote:
> Adding dri-devel.
>
> This patch set basically adds a driver option to enable virtual
> display hw if the user needs it (e.g., virtualization environments,
> headless cards, pre-silicon environments, etc.). It looks like a
> regular
2016-08-03 Chris Wilson :
> On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Signalling doesn't need to be enabled at sync_file creation, it is only
> > required if userspace waiting the fence to signal through poll().
> >
> > Thus we delay fenc
Hi Russell,
On 04-08-2016 16:04, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
>> Hmm, I am not debugging it right now but I remember that
>> drm_fb_helper_probe_connector_modes() was not being called at the
>> time I set the new EDID but only after
On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
> On 4 August 2016 at 14:15, Sharma, Shashank
> wrote:
> > On 8/4/2016 5:04 PM, Emil Velikov wrote:
> >>
> >> On 4 August 2016 at 11:16, Sharma, Shashank
> >> wrote:
> >>>
> >>> Hello Emil,
> >>>
> >>> Thanks for your time.
> >>>
> >>
On Thu, Aug 04, 2016 at 04:50:35PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > > The causes of clock recovery and channel equalization failures are not
> > > explicitly print
On Thu, Aug 04, 2016 at 06:35:52PM +0530, Sharma, Shashank wrote:
> Thanks Daniel.
>
> My comments, inline.
>
> Regards
> Shashank
> On 8/4/2016 4:06 PM, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 03:46:09PM +0530, Sharma, Shashank wrote:
> > > Hello Emil,
> > >
> > > Thanks for your time.
On Thu, Aug 04, 2016 at 05:44:23PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen wrote:
> > Do we really want to recreate a 400+ email thread again, or are we
> > capable of learning from the past?
>
> No we don't. And no-one intends to. I am fully aware of
Hi
On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen wrote:
> Do we really want to recreate a 400+ email thread again, or are we
> capable of learning from the past?
No we don't. And no-one intends to. I am fully aware of the discussion
that introduced the clock-dependencies to simplefb, and I gladl
On Thu, Aug 04, 2016 at 05:08:43PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 04:15:25PM +0200, Luc Verhaegen wrote:
> > On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> > >
> > > I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> > > framebuffer
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Daniel Vetter
>Sent: Thursday, August 04, 2016 1:23 PM
>To: Alex Deucher
>Cc: Deng, Emily; amd-gfx list; Maling list - DRI developers
>Subject: Re: [PATCH 00/13] drm/amdgpu: Add virtual di
Hi Russell,
On 04-08-2016 16:32, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
>> Currently ISCR and ACP packets are not being sent causing
>> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
> Hmm. Reading the HDMI specifications (v1.3, bein
On Thu, Aug 04, 2016 at 12:15:14PM +0200, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
>
> Cc: Imre Deak
> Cc: Chris Wilson
On Thu, Aug 04, 2016 at 04:15:25PM +0200, Luc Verhaegen wrote:
> On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> >
> > I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> > framebuffer and producing this node:
> >
> > framebuffer at 1e887000 {
> >
Reviewed-by: Sinclair Yeh
On Tue, Aug 02, 2016 at 06:50:25PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had
On 08/02/2016 02:16 PM, Takashi Iwai wrote:
> This is a preliminary patch for building drm-mipi-dsi as a module.
> Add the module exit callback to unregister the bus properly.
>
> Suggested-by: Thierry Reding
> Signed-off-by: Takashi Iwai
For both patches:
Reviewed-by: Andrzej Hajda
--
Regard
On Thu, 2016-08-04 at 04:07 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:38PM -0700, Dhinakaran Pandiyan wrote:
> > @@ -2588,7 +2592,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > *DP |= DP_LINK_TRAIN_PAT_2_CPT;
> > break;
> >
On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > The causes of clock recovery and channel equalization failures are not
> > explicitly printed in debug messages. Help debugging link training
> > failures by printing wh
On Thu, 2016-08-04 at 10:46 +0300, Jani Nikula wrote:
> On Thu, 04 Aug 2016, Dhinakaran Pandiyan
> wrote:
> > A full dump of link status can be handy in debugging link training
> > failures. Let's add that to the debug messages when link training fails.
> >
> > Signed-off-by: Dhinakaran Pandiyan
On Thu, Aug 04, 2016 at 04:03:19PM +0200, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit in
On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> This patchset adds the simpledrm driver by David Herrmann based on a
> patchset[1] from 2014. That patchset also included patches for kicking
> out simpledrm by real drivers. I have stayed away from that since it
> involves another
On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
> Currently ISCR and ACP packets are not being sent causing
> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
Hmm. Reading the HDMI specifications (v1.3, being the publically
available one), the specification does _not_ say that a
I have no idea or clue on this, but adding dri-devel can't hurt.
-Daniel
On Thu, Aug 4, 2016 at 9:47 AM, Christian König
wrote:
> Hi guys,
>
> yeah good idea, I was about to complain as well. Especially since we can't
> be sure if the design of this will be accepted or not.
>
> Dave & Daniel pl
On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
>
> I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> framebuffer and producing this node:
>
> framebuffer at 1e887000 {
> compatible = "simple-framebuffer";
> reg = <0
On 04-08-2016 15:29, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 8/4/2016 7:46 PM, Jose Abreu wrote:
>> Hi Sharma,
>>
>>
>> On 03-08-2016 16:47, Sharma, Shashank wrote:
>>> Hello Joes,
I've also seen this before and I am using them in order to
pass HDMI compliance. Without
>>
On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
> Hmm, I am not debugging it right now but I remember that
> drm_fb_helper_probe_connector_modes() was not being called at the
> time I set the new EDID but only after I stopped sending video (I
> was using modetest).
Please investigate -
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Original work by David Herrmann.
Cc: dh.herrmann at gmail.com
Signed-off-by: Noralf Trønnes
---
Changes from previous version:
- Remove the DRM_SIMPLEDRM_FBDEV kconfig option and use DRM_FBDEV_EMULAT
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create dumb-buffers which can be blit into the real
framebuffer similar to UDL. No access to the real framebuffer i
This patchset adds the simpledrm driver by David Herrmann based on a
patchset[1] from 2014. That patchset also included patches for kicking
out simpledrm by real drivers. I have stayed away from that since it
involves another subsystem and I would probably be unable to answer any
questions about th
Hi Russell,
On 04-08-2016 15:31, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>> I am not sure if this is a bug in DRM or a bad implementation of
>> dw-hdmi. I've seen at least two more drivers that do the edid
>> reading at the .
Hello Emil,
Thanks for your time.
I have got mixed opinion on this.
IMHO we should expose them to userspace too, as UI agents like Hardware
composer/X/Wayland must know what does these
flags means, so that they can display them on the end user screen (like
settings menu)
But few people even
On 4 August 2016 at 14:15, Sharma, Shashank
wrote:
> On 8/4/2016 5:04 PM, Emil Velikov wrote:
>>
>> On 4 August 2016 at 11:16, Sharma, Shashank
>> wrote:
>>>
>>> Hello Emil,
>>>
>>> Thanks for your time.
>>>
>>> I have got mixed opinion on this.
>>>
>>> IMHO we should expose them to userspace to
On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote:
> Hi Russell,
>
> I am not sure if this is a bug in DRM or a bad implementation of
> dw-hdmi. I've seen at least two more drivers that do the edid
> reading at the .detect() callback: nouveau and gma500. This is
> noticeable if while sendi
Hi Sharma,
On 03-08-2016 16:47, Sharma, Shashank wrote:
> Hello Joes,
>> I've also seen this before and I am using them in order to pass HDMI
>> compliance. Without
>> these patches the compliance fails. Still, I've made some changes which I
>> can submit. I've
>> some comments to you (Shashank
On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote:
> + memcpy(audio.status, params->iec.status,
> +min(sizeof(audio.status), sizeof(params->iec.status)));
As mentioned in the other patch, the audio status does not directly
correspond with the AES bytes, so this ends up cau
On Thu, Aug 4, 2016 at 2:23 AM, Tomeu Vizoso
wrote:
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
> Besides the obvious code reduction, other helpers are being added to the
> core that could be used in this driver and will be good to be able to
> use them ins
https://bugzilla.kernel.org/show_bug.cgi?id=36522
--- Comment #15 from bastienphilbert at gmail.com ---
Created attachment 227551
--> https://bugzilla.kernel.org/attachment.cgi?id=227551&action=edit
Cmap Fix
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=36522
bastienphilbert at gmail.com changed:
What|Removed |Added
CC||bastienphilbert at gmail.com
Add support for the R8A7792 DU; it has 2 DPAD (RGB) outputs.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'drm/next/du' branch of Laurent Pinchart's 'media.git'
repo...
Documentation/devicetree/bindings/display/renesas,du.txt |4 ++
drivers/gpu/drm/rcar-du/rcar_du_drv.c
Hi Russell,
On 04-08-2016 11:47, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:51AM +0100, Jose Abreu wrote:
>> When running HDMI compliance tests we noticed that sometimes
>> the edid changes but the get_modes() function is not called
>> so the edid is not updated. Moving the e
Regards
Shashank
On 8/3/2016 11:14 PM, Sean Paul wrote:
> On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
> wrote:
>> Current DRM layer functions dont parse aspect ratio information
> s/dont/don't/
Got it.
>
>> while converting a user mode->kernel mode or viceversa. This
> s/viceversa/vice vers
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160804/996b2d54/attachment.html>
Thanks for the review, Sean.
My comments, inline.
Regards
Shashank
On 8/3/2016 11:10 PM, Sean Paul wrote:
> On Wed, Aug 3, 2016 at 6:56 AM, Shashank Sharma
> wrote:
>> This patch adds drm flag bits for aspect ratio information
>>
>> Currently drm flag bits don't have field for mode's picture
>>
vel/attachments/20160804/b5c78a5d/attachment.html>
On Tue, Aug 02, 2016 at 03:05:07PM +0300, Jyri Sarha wrote:
> @@ -787,19 +792,13 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_CTS);
>
> /* Write the channel status */
> - buf[0] = IEC958_AES0_CON_NOT_COPYRIGHT;
> - bu
On Wed, Aug 3, 2016 at 10:59 PM, Bibby Hsieh
wrote:
> These patches based on 4.7-rc1 to clean up unused function
> & variable and use drm core function instead.
>
> The following patches are needed to cleanly apply on top of v4.7-rc1:
> - https://patchwork.kernel.org/patch/8044001/
>(drm: De
On Thu, Aug 04, 2016 at 11:12:27AM +0100, Daniel Stone wrote:
> On 4 August 2016 at 11:01, Michel Dänzer wrote:
> > On 04.08.2016 18:51, Daniel Stone wrote:
> >> On 4 August 2016 at 04:39, Michel Dänzer wrote:
> >>> Patch 6 extends the ioctl with new flags, which allow userspace to
> >>> explic
Hi...
I've noticed the last couple of days that I can't boot
Linus' tree of the day on my VM...
I was moving backwards a day at a time to find one that would
boot so I could bisect, when I landed on 731c7d3, Dave Airlie's
"main drm pull request for 4.8" and saw "I'm down with a cold at the
moment
On Thu, 04 Aug 2016, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
>
> ==
On Tue, Jul 12, 2016 at 12:13:52PM +0200, Daniel Vetter wrote:
> Might be better to just do a request_firmware on driver load, and
> simply proceed if it's not there.
That is almost never a good idea - if the driver is built-in, then
the request_firmware call happens before the real rootfs is moun
On Thu, Aug 04, 2016 at 12:47:38PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:39:36PM +0900, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > Mostly the same as the existing page_flip hook, but takes an additional
> > parameter specifying the target vertical blank period when
On Thu, Aug 04, 2016 at 12:35:59PM +0200, Enric Balletbo Serra wrote:
> 2016-07-12 12:13 GMT+02:00 Daniel Vetter :
> > On Wed, Jun 29, 2016 at 6:31 AM, Daniel Kurtz
> > wrote:
> >> On Fri, Jun 17, 2016 at 3:14 AM, Emil Velikov >> gmail.com> wrote:
> +static ssize_t ps8640_update_fw_store(st
On Thu, Aug 04, 2016 at 12:39:41PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> These flags allow userspace to explicitly specify the target vertical
> blank period when a flip should take effect.
>
> Signed-off-by: Michel Dänzer
> ---
>
> Note that the previous patches in this ser
On Thu, Aug 4, 2016 at 12:24 PM, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 10:59:38AM -0400, Alex Deucher wrote:
>> Adding dri-devel.
>>
>> This patch set basically adds a driver option to enable virtual
>> display hw if the user needs it (e.g., virtualization environments,
>> headless cards,
On Thu, Aug 04, 2016 at 12:39:36PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Mostly the same as the existing page_flip hook, but takes an additional
> parameter specifying the target vertical blank period when the flip
> should take effect.
>
> Signed-off-by: Michel Dänzer
> ---
On Thu, Aug 04, 2016 at 10:59:57AM +0800, Bibby Hsieh wrote:
> To properly implement atomic w/ runtime pm, we move
> drm_atomic_helper_commit_modeset_enables() above
> drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before
> modifying plane registers, and set active_only to true to fi
From: Michel Dänzer
These flags allow userspace to explicitly specify the target vertical
blank period when a flip should take effect.
Signed-off-by: Michel Dänzer
---
Note that the previous patches in this series can avoid delaying page
flips in some cases even without this patch or any cor
From: Michel Dänzer
With the previous change, it's safe to let page flips take effect
anytime during a vertical blank period.
This can avoid delaying a flip by a frame in some cases where we get to
radeon_flip_work_func -> adev->mode_info.funcs->page_flip during a
vertical blank period.
Signed
From: Michel Dänzer
Now we can program a flip during a vertical blank period, if it's the
one targeted by the flip (or a later one). This allows simplifying
radeon_flip_work_func considerably.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/ra
From: Michel Dänzer
With the previous change, it's safe to let page flips take effect
anytime during a vertical blank period.
This can avoid delaying a flip by a frame in some cases where we get to
amdgpu_flip_work_func -> adev->mode_info.funcs->page_flip during a
vertical blank period.
Signed
From: Michel Dänzer
Now we can program a flip during a vertical blank period, if it's the
one targeted by the flip (or a later one). This allows simplifying
amdgpu_flip_work_func considerably.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
drivers/gpu/d
From: Michel Dänzer
Mostly the same as the existing page_flip hook, but takes an additional
parameter specifying the target vertical blank period when the flip
should take effect.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h
The purpose of this series is to allow drivers to avoid unnecessarily
delaying page flips, by explicitly telling the driver which vblank seqno
a flip is supposed to take effect in.
Patch 1 sets the target to the vblank seqno after the current one when
the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called,
On Thu, Aug 04, 2016 at 03:46:09PM +0530, Sharma, Shashank wrote:
> Hello Emil,
>
> Thanks for your time.
>
> I have got mixed opinion on this.
>
> IMHO we should expose them to userspace too, as UI agents like Hardware
> composer/X/Wayland must know what does these
>
> flags means, so that the
2016-07-12 12:13 GMT+02:00 Daniel Vetter :
> On Wed, Jun 29, 2016 at 6:31 AM, Daniel Kurtz wrote:
>> On Fri, Jun 17, 2016 at 3:14 AM, Emil Velikov
>> wrote:
+static ssize_t ps8640_update_fw_store(struct device *dev,
+ struct device_attribute *attr,
>
1 - 100 of 192 matches
Mail list logo
