s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/68c2f7e8/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/6f7d370c/attachment.html>
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:827:59-60:
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:828:55-56:
Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm_types.c:829:57-58:
Unneeded semicolon
drivers/gpu/drm/amd/
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.7
head: af8331c5eae54c760bd990e9c96966436451fec7
commit: a0dec5cf512edb0ba5f0b34d5b83d911a890fd5c [367/1327] drm/amdgpu: Use dal
driver for CZ
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/../da
Hi, YT:
On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initial
Hi CK,
On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> Hi, YT:
>
> On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > Hi CK,
> >
> > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > Hi, YT:
> > >
> > > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > > From: shaoming chen
> >
Hi, YT:
On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> Hi CK,
>
> On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > > Hi CK,
> > >
> > > On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > > > Hi, YT:
> > > >
> > > >
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
Am 14.09.2016 um 08:10 schrieb Baoyou Xie:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/radeon/radeon_device.c:1961:5: warning: no previous prototype
> for 'radeon_debugfs_init' [-Wmissing-prototypes]
> drivers/gpu/drm/radeon/radeon_device.c:1966:6: warning: no previous pro
Hi CK,
On Wed, 2016-09-14 at 14:39 +0800, CK Hu wrote:
> Hi, YT:
>
> On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> > Hi CK,
> >
> > On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > > Hi, YT:
> > >
> > > On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> > > > Hi CK,
> > > >
> > > > O
Hi, YT:
On Wed, 2016-09-14 at 15:22 +0800, YT Shen wrote:
> Hi CK,
>
> On Wed, 2016-09-14 at 14:39 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Wed, 2016-09-14 at 14:19 +0800, YT Shen wrote:
> > > Hi CK,
> > >
> > > On Tue, 2016-09-13 at 17:25 +0800, CK Hu wrote:
> > > > Hi, YT:
> > > >
> > > >
On Wed, 14 Sep 2016, Pavel Machek wrote:
> Hi!
>
>> I have
>>
>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>> Integrated Graphics Controller (rev 03)
>>
>> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
>> in 10 resumes?) get in state where prim
On Tue 2016-09-13 22:38:45, Martin Steigerwald wrote:
> Hi.
>
> Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek:
> > I have
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
>
> 00:02.0 VGA compatible co
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> Hi!
>>
>>> I have
>>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>>> Integrated Graphics Controller (rev 03)
>>>
>>> In previous kernels, resume worked ok. With 4.8-rc1, I quite
On Wed 2016-09-14 10:38:18, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
> > Hi!
> >
> >> I have
> >>
> >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> >> Integrated Graphics Controller (rev 03)
> >>
> >> In previous kernels, resume worked ok. With 4.8
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index c6aa291..d850dda 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1054,6 +
On Tue, 13 Sep 2016, Bjorn Andersson wrote:
> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
>
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been cre
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.
Signed-off-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/video/bridge/sil-sii8620.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/dev
Hi,
This is 2nd RESEND of the patchset from Jan 2016.
There are no changes beside more informative log message about discovered dongle
and sink.
This patchset adds MHL bridge driver for Silicon Image SiI8620 chip.
The chip is quite powerful, supports MHL versions up to 3.0. It is present
in multi
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interfac
This header adds definitions specific to MHL protocol.
Signed-off-by: Andrzej Hajda
---
include/linux/mhl.h | 292
1 file changed, 292 insertions(+)
create mode 100644 include/linux/mhl.h
diff --git a/include/linux/mhl.h b/include/linux/mhl.
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/954ad406/attachment.html>
On Wed, 14 Sep 2016, Pavel Machek wrote:
> For the "sometimes need xrandr after resume": I don't think I can
> bisect that. It only happens sometimes :-(. But there's something
> helpful in the logs:
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/bcf80605/attachment.html>
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/ff753be6/attachment.sig>
On Sun, 28 Aug 2016, Andrea Arcangeli wrote:
> I was bitten by this bug all last week while running latest kernels on
> my laptop at KVMForum.
>
> I then found the bug was also reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=151731
Fixed by
commit ea54ff4008892b46c7a3e6bc8ab8aaec9
On Mon, 20 Jun 2016, James Bottomley
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu,
make the problem visibly disappear? If not, it sounds like it
might be a kernel driver issue.
--
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/
re visually a little corrupted, that means,
the color of some pixel changed.
--
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/20160914/66f229cb/attachment-0001.html>
On Wed, 14 Sep 2016, Pavel Machek wrote:
> Intel folks, any ideas? Can you reproduce it?
It's possible (but not confirmed yet) we've seen this in our CI, but has
slipped through because it's sporadic.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> The refcount of a fence should be increased whenever it is added to a merged
> fence, since it will later be decreased when the merged fence is destroyed.
> Failing to do so will cause the original fence to be freed if the merged
n-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/a566c40c/attachment.sig>
On Tue, Sep 13, 2016 at 11:04:37PM +0200, Pavel Machek wrote:
> Hi!
>
> > I have
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> >
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resum
Hi Dave,
Am Montag, den 29.08.2016, 17:44 +0200 schrieb Daniel Vetter:
> On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel
> wrote:
> > Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
> >> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> > This patch adds active plane re
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> For the "sometimes need xrandr after resume": I don't think I can
>> bisect that. It only happens sometimes :-(. But there's something
>> helpful in the logs:
>
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERRO
87ee8..4e79d6159856 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -25,6 +25,25 @@
> #include
> #include
>
> +/**
> + * struct drm_format_info - information about a DRM format
> + * @format: 4CC format identifier (DRM_FORMAT_*)
> + * @depth: color depth (number of bits per pixel excluding padding bits)
Depth is zero for yuv formats. Maybe that should be made clear here.
Tomi
-- next part --
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/20160914/cabfeb76/attachment-0001.sig>
GP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/559e4a02/attachment.sig>
When a plane is going to be enabled we re-evaluate the possible crtcs
for the associated drm plane. Only the crtc on which the plane should be
displayed is considered possible until the plane is disabled.
Indeed STI hardware does not allow to dynamically change
the plane's crtc/mixer assignment whe
The display controller found on Rockchip SoCs supported by Rockchip DRM
driver (VOP) is a bit problematic, because it does not provide hardware
vblank counter. Because vblank interrupt is used to feed the software
counter, the driver had custom code to wait for flip completion to avoid
race between
The enable register only masks the raw status bits to signal CPU
interrupt only for enabled interrupts. The status bits are activated
regardless of the enable register. This means that we might have an old
interrupt event queued, which we are not interested in. To avoid getting
a spurious interrupt
Currently the driver uses a custom function to wait for flip to complete
after an atomic commit. It was needed before because of two problems:
- there is no hardware vblank counter, so the original helper would
have a race condition with the vblank interrupt,
- the driver didn't support unrefe
Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18
Since VOP does not have a hardware vblank count register, the ongoing
commit might be racing with a requested vblank interrupt, which would
increment the software vblank counter before the changes being committed
actually happen.
To avoid this, we can extend .atomic_flush(), so after it sets cfg_d
Currently the driver waits for vblank and then unreferences old
framebuffers from atomic commit code path. This is however breaking the
legacy cursor API, which requires the updates to be fully asynchronous.
Instead of just adding a special case for cursor, we can have actually
smaller amount of co
Originally we needed to enable vblank for any atomic commit to kick the
PSR machine, but that was changed and we no longer need to do so from
a vblank interrupt. Let's return to original behavior of enabling
vblank only if it is really necessary.
This essentially reverts commit 5b6804034ae9 ("drm/
This patch makes the driver send the pending vblank event in next vblank
following the commit, relying on vblank signalling improvements done in
previous patches. This gives us vblank events that always represent the
real moment of changes hitting on the screen (which was the case only
for complete
After changes introduced by last patches, there is no useful data stored
in vop_plane_state struct. Let's remove it and make the driver use
generic plane state alone.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 +
1 file changed, 1
https://bugzilla.kernel.org/show_bug.cgi?id=153121
Kontantin Ivanov changed:
What|Removed |Added
Kernel Version|4.8.0-040800rc2 |4.8.0-040800rc5
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #37 from Kontantin Ivanov ---
I'm always ready to help with this bug. Actually, UVD is not important for me.
But the card I want to use. May be there is some documentation how to work with
similar problems... ?
--
You are receiving
planes; i++) {
> seq_printf(m, " %d: offset=%d pitch=%d, obj: ",
> i, fb->offsets[i], fb->pitches[i]);
> drm_gem_cma_describe(fb_cma->obj[i], m);
This change doesn't seem to improve the function. Afaics, only the num
planes is retrieved and used.
Tomi
-- next part --
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/20160914/675c2d72/attachment.sig>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/176d73d1/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160914/6a379997/attachment.html>
2016-09-14 Chris Wilson :
> On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> > The refcount of a fence should be increased whenever it is added to a merged
> > fence, since it will later be decreased when the merged fence is destroyed.
> > Failing to do so will cause the origin
vel/attachments/20160914/2606019c/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/20160914/1d2adef5/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/415519b7/attachment.html>
This just rebases my i915 perf series on a recent drm-intel-nightly.
Considering now that this series has been reviewed a number of times by Chris,
and I think I've responded to his feedback: I wonder if this series is ready
to be added to drm-intel-nightly soon?
I think most of the effort for th
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files chang
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gpu
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_dr
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Robert Br
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-pe
In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 163 +++
These should be the last vc4 fixes for 4.8.
The following changes since commit 552416c146fadc67cd9b53ef7adf88d3381c43a6:
drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39
-0700)
are available in the git repository at:
https://github.com/anholt/linux tags/drm-vc4-fixe
Hi Robert,
I think I've spotted one interesting, yet trivial bit.
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream o
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/8491d984/attachment-0001.html>
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/ba2cd3db/attachment.html>
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/5a72e250/attachment.html>
size
to inform userspace.
i915 perf moved to taking an array of u64 properties and no longer writes
back a size member in the param struct like perf.
Thanks,
- Robert
>
> Regards,
> Emil
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/b1d161bb/attachment.html>
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> 2016-09-14 Chris Wilson :
>
> > On Tue, Sep 13, 2016 at 04:24:27PM -0700, Rafael Antognolli wrote:
> > > The refcount of a fence should be increased whenever it is added to a
> > > merged
> > > fence, since it will later be decrea
On Tue, Sep 13, 2016 at 3:59 PM, Rob Clark wrote:
> On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen
> wrote:
>> The only current user of this open codes the ioctl. Let's add an entry
>> point for this to libdrm.
>>
>> Signed-off-by: Kristian H. Kristensen
>> ---
>> xf86drmMode.c | 21 ++
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/b7f7e04c/attachment.html>
trunk with llvm-svn
trunk. It's working with mesa-git trunk with llvm-3.8.1
--
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/attach
On Tue, Sep 13, 2016 at 5:20 PM, Kristian H. Kristensen
wrote:
> Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
> unaligned 64 bit field (modifier). This get packed differently between
> 32 bit and 64 bit modes on architectures that can handle unaligned 64
> bit access (X86 and
On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> 2016-09-14 Chris Wilson :
> > I think there still seems to be a memory leak when calling
> > sync_file_set_fence() here with i == 1.
>
> I think that is something we discussed already, we don't hold an extra
> ref there for i == 1
On 9/14/2016 3:14 AM, Stephen Boyd wrote:
> On 09/13/2016 08:21 AM, Archit Taneja wrote:
>> APQ8064 contains a MDP4 based display controller. It contains a HDMI, LVDS
>> and 2 DSI outputs.
>>
>> Add display DT nodes for MDP4, HDMI TX and HDMI PHY. MDP4 based display
>> blocks have a flat device h
On Pi0/1/2, we use an external GPIO line for hotplug detection, since
the HDMI_HOTPLUG register isn't connected to anything. However, with
the Pi3 the HPD GPIO line has moved off to a GPIO expander that will
be tricky to get to (the firmware is constantly polling the expander
using i2c0, so we'll
Hi Philipp,
On 08/29/2016 06:50 PM, Rob Herring wrote:
> On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
>> The change adds support of internal HDMI I2C master controller, this
>> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>>
>> The main purpose of t
eiving 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/20160914/b7847965/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/ff0ac033/attachment.html>
When we merge several fences, if all of them are signaled already, we
still keep one of them. So instead of using add_fence(), which will not
increase the refcount of signaled fences, we should explicitly call
fence_get() for the fence we are keeping.
This patch fixes a kernel panic that can be tr
Hi Chris and Gustavo,
On Mon, Aug 29, 2016 at 07:16:13PM +0100, Chris Wilson wrote:
> If we being polled with a timeout of zero, a nonblocking busy query,
> we don't need to install any fence callbacks as we will not be waiting.
> As we only install the callback once, the overhead comes from the a
Hi Bjorn
On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
>
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and
>>> also includes
>>> a p
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 ++
rm/radeon/radeon_drv.h
>> @@ -119,4 +119,9 @@
>> long radeon_drm_ioctl(struct file *filp,
>> unsigned int cmd, unsigned long arg);
>> +#if defined(CONFIG_DEBUG_FS)
>> +int radeon_debugfs_init(struct drm_minor *minor);
>> +void radeon_debugfs_cleanup(struct drm_minor *minor);
>> +#endif
>> +
>> #endif/* __RADEON_DRV_H__ */
>>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160914/842ffec2/attachment-0001.html>
Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
Signed-off-by: Fabien Lahoudere
Acked-by: Rob Herring
---
.../devicetree/bindings/display/panel/nvd,9128.txt | 7 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/gpu/drm/panel/panel-simple.c | 26 ++
Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
> > For the "sometimes need xrandr after resume": I don't think I can
> > bisect that. It only happens sometimes :-(. But there's something
> > helpful in the logs:
> >
> > [ 1856.218863
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
>
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 52
> +++
> 1 file
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 80
> +++
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 +++
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 28
Hi Peter
On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 8
>
On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
>
> Sorry about that.
>
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> >
>
> I think the remoteproc part looks good.
yeah I was waiting for
1 - 100 of 110 matches
Mail list logo