Regards
Shashank
On 7/15/2017 12:32 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote:
Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
which is currently supported on HDMI 2.0 sources/sinks. Due to lower
chroma sub-sampling rate,
Regards
Shashank
On 7/15/2017 12:06 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color
Regards
Shashank
On 7/15/2017 12:03 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in
Regards
Shahank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI
Regards
Shashank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420
On 15/07/17 04:47 AM, Felix Kuehling wrote:
> On 17-07-13 11:26 PM, Michel Dänzer wrote:
>> On 14/07/17 06:08 AM, Felix Kuehling wrote:
>>> Allows gdb to access contents of user mode mapped BOs. VRAM access
>>> requires the driver to implement a new callback in ttm_bo_driver.
>> Thanks for doing
Archit Taneja writes:
> On 06/29/2017 04:09 PM, Andrzej Hajda wrote:
>> On 29.06.2017 07:03, Archit Taneja wrote:
>>>
>>> On 06/28/2017 01:28 AM, Eric Anholt wrote:
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible
Archit Taneja writes:
> On 06/28/2017 01:28 AM, Eric Anholt wrote:
>> When a mipi_dsi_host is registered, the DT is walked to find any child
>> nodes with compatible strings. Those get registered as DSI devices,
>> and most DSI panel drivers are mipi_dsi_drivers that
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the
On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote:
> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> wrote:
>> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>>> So, if you think this is wrong, can you fix this
Boris Brezillon writes:
> When we are enabling a CRTC, drm_crtc_vblank_get() is called before
> drm_crtc_vblank_on(), which is not supposed to happen (hence the
> WARN_ON() in the code). To solve the problem, we delay the 'update
> display list' operation
On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds
wrote:
> On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
> wrote:
>>
>> NAK. This takes unintentionally insane code and turns it intentionally
>> insane. Any non-zero return is
On 17-07-13 11:26 PM, Michel Dänzer wrote:
> On 14/07/17 06:08 AM, Felix Kuehling wrote:
>> Allows gdb to access contents of user mode mapped BOs. VRAM access
>> requires the driver to implement a new callback in ttm_bo_driver.
> Thanks for doing this. Looks mostly good, but I still have some
On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds
wrote:
> On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
>> FIFO_MODE is an macro expression with a '<<' operator, which
>> gcc points out could be misread as a '<':
>
> Yeah, no, NAK again.
>
>
On 17-07-14 06:06 AM, Christian König wrote:
> Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
>> Allows gdb to access contents of user mode mapped BOs. VRAM access
>> requires the driver to implement a new callback in ttm_bo_driver.
>
> One more comment additionally to what Michel already wrote
On 17-07-14 06:08 AM, Christian König wrote:
> Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
>> Allows gdb to access contents of user mode mapped VRAM BOs.
>>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59
>>
On Fri, Jul 14, 2017 at 06:33:01PM +0200, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote:
> > On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> > > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> >
> > > > Urgh, is for some mysterious
Quoting Daniel Vetter (2017-07-14 20:14:39)
> We first need to make sure no one else can get at us anymore,
> before we can proceed to tear down all the datastructures.
>
> Just a small step towards eventually the perfect unload code ...
>
> Signed-off-by: Daniel Vetter
Quoting Daniel Vetter (2017-07-14 20:14:38)
Second nit:
> +void intel_fbdev_fini(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> +
> + if (!ifbdev)
> + return;
> +
> intel_fbdev_destroy(ifbdev);
>
On Fri, Jul 14, 2017 at 3:09 PM, Dan Carpenter wrote:
> On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
>> I don't agree with it as a static analysis dev...
>
> What I mean is if it's a macro that returns -ENODEV or a function that
> returns -ENODEV, they
Quoting Daniel Vetter (2017-07-14 20:14:38)
> First thing we need to do is unregister the fbdev instance, but we
> can't just go ahead and kfree it. That must wait until the hotplug and
> polling work are stopped, since they can race with the with the
> teardown. That means we need to split up the
Quoting Daniel Vetter (2017-07-14 20:14:37)
> The legacy plane->fb pointer is refcounted by calling
> drm_atomic_clean_old_fb().
>
> In practice this isn't a real problem because:
> - The caller in the i915 gpu reset code restores the original state
> again, which means the plane->fb pointer
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> FIFO_MODE is an macro expression with a '<<' operator, which
> gcc points out could be misread as a '<':
Yeah, no, NAK again.
We don't make the code look worse just because gcc is being a f*cking
moron about things.
This
On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
wrote:
>
> NAK. This takes unintentionally insane code and turns it intentionally
> insane. Any non-zero return is considered an error.
>
> The right fix is almost certainly to just return -EINVAL unconditionally.
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
NAK. This takes unintentionally insane code and turns it intentionally
insane. Any non-zero return is considered an
2017-07-11 Chris Wilson :
> Quoting Chris Wilson (2017-02-14 12:40:01)
> > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> > memory (8802538683d0)
> > [ 236.828642]
> > 42001e7f0008
> >
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using
On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote:
> On 17-06-29 22:49:44, Ville Syrjälä wrote:
>
> [snip]
>
> >
> >... but here it's ALIGN(formats_offset+formats_size). I think we should
> >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
> >make sure the header
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote:
> Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
> which is currently supported on HDMI 2.0 sources/sinks. Due to lower
> chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half
> the pixel clock
On 17-06-29 22:49:44, Ville Syrjälä wrote:
[snip]
... but here it's ALIGN(formats_offset+formats_size). I think we should
be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
make sure the header size always stays a multiple of 8 bytes.
That's mainly because the design of
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
> To support ycbcr output, we need a pipe CSC block to do
> RGB->YCBCR conversion.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
> This patch checks encoder level support for YCBCR420 outputs.
> The logic goes as simple as this:
> If the input mode is YCBCR420-only mode: prepare HDMI for
> YCBCR420 output, else continue with RGB output mode.
>
> It checks if
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for
Hi Mikko, Thierry,
While setting up my Jetson TK1 using the mainline kernel I discovered that the
HDMI output
didn't work.
After some more debugging I discovered that this commit
404bfb78daf3bedafb0bfab24947059575cbea3d
(gpu: host1x: Add IOMMU support) was the culprit.
As far as I understand
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Try to allocate huge pages when it makes sense.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |
On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> > Urgh, is for some mysterious reason the __bug_table section of modules
> > ending up in RO memory?
> >
> > I forever get lost in that link magic :/
>
> +1
>
> drm.ko
>
On Thu, Jul 13, 2017 at 03:50:56PM +0200, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> > Dear All,
> >
> > I am looking for an solution to have early smooth splashscreen on the
> > Linux system with Weston and drm-backend.
> >
> > I tried
On Fri, Jul 14, 2017 at 11:20:01AM -0400, Ilia Mirkin wrote:
> On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
> wrote:
> > The conversion is a nice catch, but i'd like to have a bit more context, see
> > below!
> >
> > With a better description:
> >
> >
On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote:
> Ok, a network outage gave me time to go hunting. Indeed it is a bad
> interaction with the tree DRM merged into. All DRM did was to slip a
> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> things no longer
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Remove unused defines and variables. Also stop computing the
> gfp_flags when they aren't used.
>
> No intended functional change.
>
> Signed-off-by: Christian
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Correctly handle different page sizes in the memory accounting.
>
> Signed-off-by: Christian König
I'd split this patch in two, one
On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
wrote:
> The conversion is a nice catch, but i'd like to have a bit more context, see
> below!
>
> With a better description:
>
> Tobias Klausmann
I don't think it was
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 6 +-
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 90 +--
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 123
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Generic DRM support is available here [1] and will be merged once
this
On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
>> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
>> usage we could convert to WARN_ONCE?
>
> Shooting the messenger is generally considered uncool
On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git
On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote:
> Now that all drivers check the return value, convert swap_state to
> __must_check. This is done separately to force build warnings if we
> missed a driver.
>
> Signed-off-by: Maarten Lankhorst
On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> VC4 has its own nonblocking modeset tracking through the
On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> Signed-off-by: Maarten Lankhorst
On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> MSM has its own busy tracking, which means the swap_state call can
On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state could previously never fail, in order to still
> continue it would set a limit of 10s on waiting for previous updates to
> complete,
> then it moved forward. This can be very bad when ignoring
On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> > We want to change swap_state to wait indefinitely, but to do this
> > swap_state should wait interruptibly. This requires propagating
> > the error to each
While this is no build dependency, etnaviv will only work correctly on most
systems if CMA and DMA_CMA are enabled. Select both options if available to
avoid users ending up with a non-working GPU due to a lacking kernel config.
Signed-off-by: Lucas Stach
---
On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver.
>
> Cc: dri-devel@lists.freedesktop.org
> Cc:
On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote:
> Make it more clear that post commit return ret is really return 0,
>
> and add a missing drm_atomic_helper_cleanup_planes when
> drm_atomic_helper_wait_for_fences fails.
>
> Fixes: 839ca903f12e ("drm/nouveau/kms/nv50:
On Thu, Jul 13, 2017 at 6:04 AM, wrote:
> From: Patrick Bruenn
>
> This is a fix for the CX9020 Embedded PC. On that device the 24-bit
> parallel-display signal of the imx53 is combined with an I2C channel
> and converted to DVI-D port.
https://bugs.freedesktop.org/show_bug.cgi?id=26345
Ленар changed:
What|Removed |Added
i915 platform||ALL
On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.
>
>
On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.
>
>
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE -
On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote:
> On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> >> Dear All,
> >>
> >> I am looking for an solution to have early smooth
On Thu, Jul 13, 2017 at 06:25:27PM +0200, Peter Rosin wrote:
> The legacy path implements setcmap in terms of crtc .gamma_set.
>
> The atomic path implements setcmap by directly updating the crtc gamma_lut
> property.
>
> This has a couple of benefits:
> - it makes the redundant fb helpers
On Fri, Jul 14, 2017 at 12:57:23PM +0300, Jani Nikula wrote:
> On Thu, 13 Jul 2017, Sean Paul wrote:
> > On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote:
> >> The problem is that we have a distributed cache - every committer has
> >> a copy. Which means even
On Thu, Jul 06, 2017 at 03:05:19PM +0200, Maarten Lankhorst wrote:
> Op 06-07-17 om 15:00 schreef Daniel Vetter:
> > With deferred fbdev setup we always need to forward hotplug events,
> > even if fbdev isn't fully set up yet. Otherwise the deferred setup
> > will neer happen.
> >
> > Originally
On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
> I don't agree with it as a static analysis dev...
What I mean is if it's a macro that returns -ENODEV or a function that
returns -ENODEV, they should both be treated the same. The other
warnings this check prints are quite clever.
Ah... I see why it's complaining about these ones in particular...
I don't agree with it as a static analysis dev, and I don't like the
changes too much. But since it's only generating a hand full of
warnings then I don't care.
regards,
dan carpenter
On Fri, Jul 14, 2017 at 11:36:56AM +0200, Arnd Bergmann wrote:
> @@ -1158,7 +1158,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
>*/
> fmt_src.pad = pad->index;
> fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> - if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL,
On Fri, Jul 14, 2017 at 2:05 PM, Dan Carpenter wrote:
> Changing:
>
> - if (!frob()) {
> + if (frob() == 0) {
>
> is a totally pointless change. They're both bad, because they're doing
> success testing instead of failure testing, but probably the second one
> is
Changing:
- if (!frob()) {
+ if (frob() == 0) {
is a totally pointless change. They're both bad, because they're doing
success testing instead of failure testing, but probably the second one
is slightly worse.
This warning seems dumb. I can't imagine it has even a 10% success rate
at finding
https://bugs.freedesktop.org/show_bug.cgi?id=101528
Sverd Johnsen changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #5 from Sverd Johnsen ---
Works for me on 4.11.10. Display off, MCLK is low and card temperature is 27°C
as expected. Thanks.
--
You are receiving this mail because:
You are the assignee for the
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
CP States defined:
DRM_CP_UNSUPPORTED - CP is not supported
DRM_CP_DISABLE - CP is disabled
DRM_CP_ENABLE - CP is enabled
V2:
On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
wrote:
> Huarui Lighting makes display panel, add it to the list of panels.
I could not find any information on "Huarui Lighting" within the
context of LCD panels. The company I found makes LED lighting
fixtures,
Hi,
On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
wrote:
> In the earlier display engine designs, any register access while a commit
> is pending is forbidden.
>
> One of the symptoms is that reading a register will return another, random,
> register value
Adding drm_add_modes_noedid_cea API for supporting cea modes
for drm devices which does not have panel framework or edid
support.
Protocols like SDI whic have minimal support in linux kernel can
benifit from this.
There is already a API drm_add_modes_noedid, but that supports only
dmt modes.
On 14/07/17 00:31, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Thursday 13 Jul 2017 18:49:19 Kieran Bingham wrote:
>> On 26/06/17 19:12, Laurent Pinchart wrote:
>>> New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
>>> as well as a new VSP2-D variant on V3M and V3H SoCs.
On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
>> Dear All,
>>
>> I am looking for an solution to have early smooth splashscreen on the
>> Linux system with Weston and drm-backend.
>>
>> I
On Fri, Jul 14, 2017 at 12:52 AM, Rajendra Nayak wrote:
> Hi Rob,
>
> On 07/11/2017 11:50 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to
On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C wrote:
On Thursday 13 July 2017 02:15 PM,
On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
>> We test whether a bit is set in a mask here, which is correct
>> but gcc warns about it as it thinks it might be confusing:
>>
>>
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which
On Fri, Jul 14, 2017 at 11:25:12AM +0200, Arnd Bergmann wrote:
> This series should shut up all warnings introduced by gcc-6 or gcc-7 on
> today's linux-next, as observed in "allmodconfig" builds on x86,
> arm and arm64.
>
> I have sent some of these before, but some others are new, as I had
> at
On Fri, Jul 14, 2017 at 11:55 AM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
>> When we pass the result of a multiplication as the timeout, we
>> can get a warning:
>>
>> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
/linux/commits/Maxime-Ripard/drm-sun4i-Allwinner-MIPI-DSI-support/20170714-123103
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin
On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
> We test whether a bit is set in a mask here, which is correct
> but gcc warns about it as it thinks it might be confusing:
>
> drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in
> boolean context, the expression
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
Allows gdb to access contents of user mode mapped VRAM BOs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
Allows gdb to access contents of user mode mapped BOs. VRAM access
requires the driver to implement a new callback in ttm_bo_driver.
One more comment additionally to what Michel already wrote below, apart
from that it looks good to me.
On Fri, 14 Jul 2017, Arnd Bergmann wrote:
> gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
> operand in ?: will
On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
> When we pass the result of a multiplication as the timeout, we
> can get a warning:
>
> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
> '&&' instead [-Werror=int-in-bool-context]
>
1 - 100 of 132 matches
Mail list logo