attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/1b83792b/attachment.html>
Am 25.05.2015 um 18:50 schrieb Oleg Nesterov:
> On 05/25, Richard Weinberger wrote:
>>
>> Is this functionality still in use/needed?
>
> All I can say it doesn't work.
>
>> Otherwise we could get rid of block_all_signals() and unpuzzle the signaling
>> code a bit. :-)
>
> Yes. I do not even
Atomic modesetting: now with modesetting support.
v2: Moved drm_atomic_set_mode_prop_for_crtc from previous patch; removed
state->active fiddling, documented return code. Changed property
type to DRM_MODE_PROP_BLOB.
Signed-off-by: Daniel Stone
Tested-by: Sean Paul
---
Add a blob property tracking the current mode to the CRTC state, and
ensure it is properly updated and referenced.
v2: Continue using crtc_state->mode inside getcrtc, instead of reading
out the mode blob. Use IS_ERR and PTR_ERR from create_blob. Move
set_mode_prop_for_crtc to later patch
Add a new helper, to be used later for blob property management, that
sets the mode for a CRTC state, as well as updating the CRTC enable/active
state at the same time.
v2: Do not touch active/mode_changed in CRTC state. Document return
value. Remove stray drm_atomic_set_mode_prop_for_crtc
When we look up a blob property, make sure we retain a reference to the
blob for the lifetime.
v2: Use DRM_MODE_PROP_BLOB, not PROP_OBJECT + OBJECT_BLOB.
Signed-off-by: Daniel Stone
Tested-by: Sean Paul
---
drivers/gpu/drm/drm_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hi,
Respin with the fixups from Daniel Vetter's review. The two changes
visible to userspace is that we now require anyone clearing MODE_ID to
explicitly set the CRTC active property to false, and that the property
type is BLOB, rather than OBJECT/BLOB.
The rest are fairly minor.
Cheers,
Daniel
On 05/25, Richard Weinberger wrote:
>
> Is this functionality still in use/needed?
All I can say it doesn't work.
> Otherwise we could get rid of block_all_signals() and unpuzzle the signaling
> code a bit. :-)
Yes. I do not even remember when I reported this the first time. Perhaps
more
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/b13f6803/attachment.html>
On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau wrote:
> Most _DSM will return an integer value of 0x8002 when given an unknown
> UUID, revision ID or function ID. Checking locally allows us to differentiate
> that case from other ACPI errors, and to not report a "failed to evaluate
> _DSM"
>
Hi Paul,
å¨ 2015/5/25 16:24, Paul Bolle åé:
> Just a nit: a license mismatch.
>
> On Fri, 2015-05-22 at 10:14 -0500, Yakir Yang wrote:
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
>> + * This program is free software; you can redistribute it and/or modify
>> + * it
On Mon, 25 May 2015, Jani Nikula wrote:
> On Mon, 25 May 2015, Jani Nikula wrote:
>> On Mon, 25 May 2015, Andrey Ryabinin wrote:
>>> On 05/25/2015 04:12 PM, Jani Nikula wrote:
On Mon, 25 May 2015, Andrey Ryabinin wrote:
> for_each_*_in_state validate array index after
> access to
Hi!
drivers/gpu/drm/drm_lock.c is the only remaining user of block_all_signals():
/* don't set the block all signals on the master process for now
* really probably not the correct answer but lets us debug xkb
* xserver for now */
if (!file_priv->is_master) {
On Mon, May 25, 2015 at 04:52:31PM +0300, Jani Nikula wrote:
> On Mon, 25 May 2015, Jani Nikula wrote:
> > On Mon, 25 May 2015, Andrey Ryabinin wrote:
> >> On 05/25/2015 04:12 PM, Jani Nikula wrote:
> >>> On Mon, 25 May 2015, Andrey Ryabinin wrote:
> for_each_*_in_state validate array
When looking up a dpaux device through its DT node, ensure that the
corresponding device has been registered.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/tegra/dpaux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index
When looking up a panel through its DT node, ensure that the
corresponding device has been registered.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index
Hello,
I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or
On Mon, 25 May 2015, Jani Nikula wrote:
> On Mon, 25 May 2015, Andrey Ryabinin wrote:
>> On 05/25/2015 04:12 PM, Jani Nikula wrote:
>>> On Mon, 25 May 2015, Andrey Ryabinin wrote:
for_each_*_in_state validate array index after
access to array elements, thus perform out of bounds read.
On Mon, 25 May 2015, Andrey Ryabinin wrote:
> On 05/25/2015 04:12 PM, Jani Nikula wrote:
>> On Mon, 25 May 2015, Andrey Ryabinin wrote:
>>> for_each_*_in_state validate array index after
>>> access to array elements, thus perform out of bounds read.
>>>
>>> Fix this by validating index in the
a by default.
>
> Regards,
> Christian.
We are using kernel 4.0.3
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/fa8e42eb/attachment.html>
On 05/25/2015 04:12 PM, Jani Nikula wrote:
> On Mon, 25 May 2015, Andrey Ryabinin wrote:
>> for_each_*_in_state validate array index after
>> access to array elements, thus perform out of bounds read.
>>
>> Fix this by validating index in the first place and read
>> array element iff validation
On Mon, 25 May 2015, Andrey Ryabinin wrote:
> for_each_*_in_state validate array index after
> access to array elements, thus perform out of bounds read.
>
> Fix this by validating index in the first place and read
> array element iff validation was successful.
>
> Fixes: df63b9994eaf
On Mon 25-05-15 13:37:56, Hans Verkuil wrote:
> Hi Jan,
>
> On 05/13/2015 03:08 PM, Jan Kara wrote:
> > Hello,
> >
> > I'm sending the fifth version of my patch series to abstract vma handling
> > from the various media drivers. The patches got some review from mm people
> > and
> > testing
And the subject line should obviously have mentioned v4.2, not v4.2. Sorry
about that.
On Monday 25 May 2015 15:40:53 Laurent Pinchart wrote:
> Hi Dave,
>
> The following changes since commit bdcddf95e82b1c4e370fc1196b1f4f50f775dab4:
>
> Backmerge v4.1-rc4 into into drm-next (2015-05-20
Hi Dave,
The following changes since commit bdcddf95e82b1c4e370fc1196b1f4f50f775dab4:
Backmerge v4.1-rc4 into into drm-next (2015-05-20 16:23:53 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbdev.git drm/next/adv7511
for you to fetch changes up to
Hi Dave,
The following changes since commit bdcddf95e82b1c4e370fc1196b1f4f50f775dab4:
Backmerge v4.1-rc4 into into drm-next (2015-05-20 16:23:53 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbdev.git drm/next/rcar-du
for you to fetch changes up to
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/1fb02ac5/attachment-0001.html>
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/bd182690/attachment.html>
On Mon, May 25, 2015 at 10:17:25AM -0300, Fabio Estevam wrote:
> Use '%zd' for printing 'ssize_t' format in order to fix the following
> build warning on ARM64:
>
> drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_write_avi':
> drivers/gpu/drm/i2c/tda998x_drv.c:647:3: warning: format '%d'
Hi,
On 22 May 2015 at 15:34, Daniel Vetter wrote:
> On Fri, May 22, 2015 at 01:34:54PM +0100, Daniel Stone wrote:
>> - /* FIXME: Mode prop is missing, which also controls ->enable. */
>> if (property == config->prop_active)
>> state->active = val;
>> + else if
Hi Jan,
On 05/13/2015 03:08 PM, Jan Kara wrote:
> Hello,
>
> I'm sending the fifth version of my patch series to abstract vma handling
> from the various media drivers. The patches got some review from mm people and
> testing from device driver guys so unless someone objects, patches will be
>
for_each_*_in_state validate array index after
access to array elements, thus perform out of bounds read.
Fix this by validating index in the first place and read
array element iff validation was successful.
Fixes: df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state
helper
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150525/4d59936b/attachment.html>
Hi Emil,
Do you have chance to have a look at this new version? Thanks!
Regards,
Jammy
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Zhou, Jammy
Sent: Tuesday, May 19, 2015 11:31 PM
To: dri-devel at lists.freedesktop.org;
an.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150525/7ca61ea2/attachment.html>
Hi Thierry,
Thank you for your thorough analysis - and sorry for a bunch of very
silly mistakes.
I am skipping most trivial parts and focus on the trickier comments and
questions.
On 05/22/2015 02:47 PM, Thierry Reding wrote:
>> +
>> +struct tegra_bo *ucode_bo;
>> +bool ucode_valid;
https://bugzilla.kernel.org/show_bug.cgi?id=98751
Andy Furniss changed:
What|Removed |Added
CC||adf.lists at gmail.com
--- Comment #9
On 05/22/2015 07:46 PM, Hai Li wrote:
> DSI video mode engine can only take active-high sync signals. This
> change prevents MDP5 sending active-low sync signals to DSI in any
> case.
>
> Signed-off-by: Hai Li
Tested-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 12
https://bugzilla.kernel.org/show_bug.cgi?id=98751
--- Comment #8 from Mikkel Oscar Lyderik ---
It's actually a 6950 card I have, same as in #98651.
I called it 6990 because that is what lspci tells me, but that might narrow it
down?
--
You are receiving this mail because:
You are watching the
Just a nit: a license mismatch.
On Fri, 2015-05-22 at 10:14 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2
https://bugzilla.kernel.org/show_bug.cgi?id=98751
Robin Bankhead changed:
What|Removed |Added
CC||kernel at headbank.co.uk
--- Comment #7
Use '%zd' for printing 'ssize_t' format in order to fix the following
build warning on ARM64:
drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_write_avi':
drivers/gpu/drm/i2c/tda998x_drv.c:647:3: warning: format '%d' expects
argument of type 'int', but argument 3 has type 'ssize_t'
On 05/22/2015 01:25 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Thu, May 21, 2015 at 05:40:31PM +0300, Mikko Perttunen wrote:
>> On 05/21/2015 04:20 PM, Arto Merilainen wrote:
> [...]
>>> +static int vic_is_addr_reg(struct device *dev, u32 class, u32 offset, u32
>>> val)
>>>
On Sat, 23 May 2015, Andrew Morton wrote:
> On Sat, 23 May 2015 14:30:09 +0100 Damien Lespiau intel.com> wrote:
>
>> On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote:
>> > I'm not sure what's happened to the drm code in linux-next - it's
>> > exploding all over the place. Did
44 matches
Mail list logo
