Hi,
On 04-03-19 16:17, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
Hi Heikki,
On 28-02-19 15:47, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
On Mon, Mar 04, 2019 at 05:47:21PM +0100, Hans de Goede wrote:
> Hi All,
>
> This patch-series addresses the 2 TODO / FIXME items recently reported
> by Daniel and after that moves the vboxvideo driver out of staging.
>
> Note this applies on top of drm-misc-next + this patch:
>
On Tue, Mar 5, 2019 at 1:20 AM Rob Herring wrote:
>
> On Sat, Mar 2, 2019 at 12:23 PM Rob Clark wrote:
> >
> > On Fri, Mar 1, 2019 at 9:32 PM Qiang Yu wrote:
> > >
> > > On Thu, Feb 28, 2019 at 5:41 AM Rob Herring wrote:
> > > >
> > > > On Wed, Feb 27, 2019 at 7:42 AM Qiang Yu wrote:
> > > >
On Mon, Mar 4, 2019 at 6:53 AM Andrew F. Davis wrote:
> On 3/1/19 6:06 AM, Brian Starkey wrote:
> > On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
> >> +static long dma_heap_ioctl(struct file *filp, unsigned int cmd, unsigned
> >> long arg)
> >> +{
> >> +switch (cmd) {
> >>
https://bugzilla.kernel.org/show_bug.cgi?id=198123
crocket (crockabisc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=88501
crocket (crockabisc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=60623
crocket (crockabisc...@gmail.com) changed:
What|Removed |Added
CC|
On 02/26, Eric Biggers wrote:
> From: Eric Biggers
>
> If drm_gem_handle_create() fails in vgem_gem_create(), then the
> drm_vgem_gem_object is freed twice: once when the reference is dropped
> by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
>
> This was hit by syzkaller
On 02/28, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira
> wrote:
> >
> > On 02/26, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > If drm_gem_handle_create() fails in vkms_gem_create(), then the
> > > vkms_gem_object is freed twice: once when the reference is
On Thu, Feb 14, 2019 at 1:38 PM Brendan Higgins
wrote:
>
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> ## More information on KUnit
>
> There is a bunch of documentation near the end of this patch set that
> describes how to use
On Thu, Feb 28, 2019 at 10:02 AM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-28 01:03:24)
> > On Tue, Feb 26, 2019 at 12:35 PM Stephen Boyd wrote:
> > >
> > > when they need to abort and then the test runner would detect that error
> > > via the return value from the 'run test'
On Thu, Feb 28, 2019 at 5:55 AM Dan Carpenter wrote:
>
> On Thu, Feb 28, 2019 at 01:03:24AM -0800, Brendan Higgins wrote:
> > you could do:
> >
> > if (IS_ERR_OR_NULL(ptr)) {
> > KUNIT_FAIL(test, "ptr is an errno or null: %ld", ptr);
> > return;
> > }
>
> It's best to not mix
On Wed, Feb 13, 2019 at 05:52:19PM -0800, Jeykumar Sankaran wrote:
> Subclass drm private object state for DPU for handling driver
> specific data. Adds atomic private object to dpu crtc to
> track hw resources per display. Provide helper function to
> retrieve DPU private data from current atomic
Stefan Wahren writes:
>> Eric Anholt hat am 4. März 2019 um 19:28 geschrieben:
>>
>>
>> Stefan Wahren writes:
>>
>> > Hi Maxime,
>> >
>> > Am 04.03.2019 um 15:52 schrieb Maxime Ripard:
>> >> The current code assumes as soon as the device is an HDMI one that it
>> >> supports an audio sink.
On Tue, Feb 19, 2019 at 11:40:19AM -0700, Jordan Crouse wrote:
> (Resend since there was a compile error that I forgot to commit before
> sending)
>
> If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
> make sure to truncate the object name so that there isn't a chance
> Eric Anholt hat am 4. März 2019 um 19:28 geschrieben:
>
>
> Stefan Wahren writes:
>
> > Hi Maxime,
> >
> > Am 04.03.2019 um 15:52 schrieb Maxime Ripard:
> >> The current code assumes as soon as the device is an HDMI one that it
> >> supports an audio sink. However, strictly speaking, this
Maxime Ripard writes:
> Hi,
>
> The proprietary stack for the RaspberryPi allows for a number of video
> parameters widely used by their users, but yet don't have any equivalents
> in the mainline kernel.
>
> Those options are detailed here:
>
On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
>
> Maxime Ripard writes:
>
> > In some cases, in order to accomodate with displays with poor EDIDs, we
> > need to ignore that the monitor alledgedly supports audio output and
> > disable the audio output.
> >
> > Signed-off-by: Maxime Ripard
>
Maxime Ripard writes:
> Signed-off-by: Maxime Ripard
Googling for users of the firmware's hdmi_drive= flag, I'm seeing lots
of people with hdmi_drive=2 (force HDMI mode) due to Raspberry Pi not
allowing HDMI audio with DMT modes, which it looks like DRM does allow.
The only users of
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec =
A recent cleanup introduced a build failure when a variable
was spelled incorrectly:
In file included from drivers/video/fbdev/mbx/mbxfb.c:881:
drivers/video/fbdev/mbx/mbxdebugfs.c: In function 'mbxfb_debugfs_init':
drivers/video/fbdev/mbx/mbxdebugfs.c:217:2: error: 'mbfi' undeclared (first use
Maxime Ripard writes:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed,
On Fri, Mar 01, 2019 at 01:56:20PM +0100, Maarten Lankhorst wrote:
> Convert msm to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding
> destroy_state(), call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rob
On Sat, Mar 2, 2019 at 5:17 PM Colin King wrote:
>
> From: Colin Ian King
>
> An earlier commit replaced ttm_bo_wait with amdgpu_bo_sync_wait and
> removed the error return assignment to variable ret. Fix this by adding
> the assignment back. Also break line to clean up checkpatch overly
> long
Hi Luc,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0 next-20190304]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Luc
On Wed, Feb 13, 2019 at 05:19:09PM -0800, Jeykumar Sankaran wrote:
> Fixing some of the low hanging fruits by moving the hw resource
> parsing and assignment to encoder modeset. This series
> prepares DPU resource management to switch to state based
> resource tracking which is implemented in the
Stefan Wahren writes:
> Hi Maxime,
>
> Am 04.03.2019 um 15:52 schrieb Maxime Ripard:
>> The current code assumes as soon as the device is an HDMI one that it
>> supports an audio sink. However, strictly speaking, this is exposed as a
>> separate part of EDID.
>>
>> This can be checked through
On Wed, Feb 13, 2019 at 05:19:16PM -0800, Jeykumar Sankaran wrote:
> Removing unwanted access of crtc_state for finding this information.
> Use split role information to know whether we have slave ctl.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
>
On Wed, Feb 13, 2019 at 05:19:15PM -0800, Jeykumar Sankaran wrote:
> Iterate and assign HW intf block to physical encoders
> in encoder modeset. Moving all the HW block assignments
> to encoder modeset to allow easy switching to state
> based resource management.
>
> Signed-off-by: Jeykumar
On Wed, Feb 13, 2019 at 05:19:14PM -0800, Jeykumar Sankaran wrote:
> After resource allocation, iterate and populate mixer/ctl
> hw blocks in encoder modeset thereby centralizing all
> the resource mapping to the CRTC. This change is made
> for easy switching to state based allocation using
>
On Wed, Feb 13, 2019 at 05:19:13PM -0800, Jeykumar Sankaran wrote:
> encoder->crtc is not really meaningful for atomic path. Use
> crtc->encoder_mask to identify the crtc attached with
> an encoder.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7
On Wed, Feb 13, 2019 at 05:19:12PM -0800, Jeykumar Sankaran wrote:
> release resources allocated in mode_set if any of
> the hw check fails. Most of these checks are not
> necessary and they will be removed in the follow up
> patches with state based resource allocations.
>
> Signed-off-by:
On Wed, Feb 13, 2019 at 05:19:11PM -0800, Jeykumar Sankaran wrote:
> Not holding any video encoder specific data. Get rid of it.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 ---
>
On Wed, Feb 13, 2019 at 05:19:10PM -0800, Jeykumar Sankaran wrote:
> Both video and command physical encoders will have
> a hw interface assigned to it. So there is really no
> need to track the hw block in specific encoder subclass.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
Hi Thierry.
> Changes from v2
> * As per review comments from Sam Ravnborg
> * Lowercase sentinel
> * Drop '_panel' postfix
> * DRM_DEV_ logging instead of plain DRM_
> * Add Sam's Reviewed-by:
> * Add "panel-rocktech-" to the driver name following
> the pattern from other drm panel
Hi,
On Fri, Mar 01, 2019 at 11:39:06PM +0100, Sam Ravnborg wrote:
> Hi Guido.
>
> Thanks for addressing review comments in first round.
> Just a few nits in this follow-up.
> With these nits addressed:
> Reviewed-by: Sam Ravnborg
Thanks! I made all the suggested changes in v3, on top of that I
Support Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel. It is a MIPI
DSI video mode panel.
The panel seems to use a Sitronix ST7703 look alike (most of the
commands look similar to the ST7703's data sheet but use a different
number of parameters). The initial version of the DSI init sequence
Add ROCKTECH DISPLAYS LIMITED (https://rocktech.com.hk) LCD panel
supplier.
Signed-off-by: Guido Günther
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
It's a 5.5" 720x1440 TFT LCD MIPI DSI panel with built in touchscreen and
backlight as found in the Librem 5 devkit.
These patches are against linux next as of 2019-02-08.
Changes from v2
* As per review comments from Sam Ravnborg
* Lowercase sentinel
* Drop '_panel' postfix
* DRM_DEV_
The Rocktec jh057n00900 is a 5.5" MIPI DSI video mode panel with a
720x1440 resolution and a built in backlight.
Signed-off-by: Guido Günther
---
.../display/panel/rocktech,jh057n00900.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Den 04.03.2019 16.10, skrev Andy Shevchenko:
> On Mon, Mar 04, 2019 at 03:45:56PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 22.02.2019 16.58, skrev Andy Shevchenko:
>>> On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
Buffers passed to spi_sync() must be dma-safe even for
On Sun, Feb 24, 2019 at 10:15 AM Lubomir Rintel wrote:
>
> On Fri, 2019-02-22 at 14:23 -0600, Rob Herring wrote:
> > On Wed, Feb 13, 2019 at 4:37 PM Lubomir Rintel wrote:
> > > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=109819
--- Comment #2 from Dominic ---
Created attachment 143522
--> https://bugs.freedesktop.org/attachment.cgi?id=143522=edit
New 5.0 Kernel Crashlog
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109819
--- Comment #1 from Dominic ---
Per Linux Kernel 5.0 release here an updated report with that newest kernel and
updated head from git://anongit.freedesktop.org/mesa/drm
With the Linux Kernel 5.0 the dmesg log if full of amdgpu spam, that seems
On Sat, Mar 2, 2019 at 12:23 PM Rob Clark wrote:
>
> On Fri, Mar 1, 2019 at 9:32 PM Qiang Yu wrote:
> >
> > On Thu, Feb 28, 2019 at 5:41 AM Rob Herring wrote:
> > >
> > > On Wed, Feb 27, 2019 at 7:42 AM Qiang Yu wrote:
> > > > diff --git a/drivers/gpu/drm/lima/lima_drv.c
> > > >
Drop the initial_mode_queried workaround for kms clients which do not
support hotplug, all kms clients should be able to deal with hotplug.
Suggested-by: Daniel Vetter
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/TODO| 3 ---
drivers/staging/vboxvideo/vbox_drv.c | 25
Hi All,
This patch-series addresses the 2 TODO / FIXME items recently reported
by Daniel and after that moves the vboxvideo driver out of staging.
Note this applies on top of drm-misc-next + this patch:
https://patchwork.kernel.org/patch/10824279/
Currently that patch is not yet in drm-misc, I
The vboxvideo driver has been converted to the atomic modesetting API
and all FIXME and TODO items have been fixed, so it is time to move it out
of staging.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile
Refactor vbox_update_mode_hints to no longer use the obsolete
drm_modeset_lock_all() and switch it over to drm_connector_list_iter
instead of directly accessing the list using list_for_each_entry.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_irq.c | 15 +++
1 file
On Sun, Feb 17, 2019 at 10:55:54PM +, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_NOTE message. Fix this.
>
> Signed-off-by: Colin Ian King
Applied to drm-misc-next, thanks.
Sean
> ---
> drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
> 1 file
Hi Jyri,
On Mon, Mar 04, 2019 at 04:29:17PM +0200, Jyri Sarha wrote:
> On 04/03/2019 14:42, Laurent Pinchart wrote:
> > On Wed, Feb 27, 2019 at 11:54:18PM +0200, Jyri Sarha wrote:
> >> Changes since first version:
> >> - Moved reviewed patches to front:
> >> - drm/bridge: sii902x: add
On Fri, Mar 01, 2019 at 12:00:46PM +, Ben Dooks wrote:
> The ptr_to_compat() call takes a "void __user *", so cast
> the compat drm calls that use it to avoid the following
> warnings from sparse:
>
> drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1
> (different
Hi Jyri,
Thank you for the patch.
On Wed, Feb 27, 2019 at 11:54:22PM +0200, Jyri Sarha wrote:
> "drm/bridge/sii902x: Fix EDID readback"-commit added a dependency to
> I2C_MUX, but not indicate it in the Kconfig entry. Fix it by selecting
> I2C_MUX for DRM_SII902X config option.
>
> Fixes:
Hi Jyri,
Thank you for the patch.
On Wed, Feb 27, 2019 at 11:54:21PM +0200, Jyri Sarha wrote:
> The pixel clock unit in the first two registers (0x00 and 0x01) of
> sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
> 10 fixes the issue.
>
> Signed-off-by: Jyri Sarha
>
On Mon, Mar 04, 2019 at 03:52:35PM +0100, Maxime Ripard wrote:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.
>
> Signed-off-by: Maxime Ripard
> ---
>
Hi Peter,
On Mon, Mar 04, 2019 at 03:21:35PM +, Peter Stuge wrote:
> Hi,
>
> Maxime Ripard wrote:
> > properties to initialise the overscan or rotation parameters, or the
> > one to deal with broken displays.
>
> How does that work on systems with multiple connectors?
>
> On SBCs with only
Hi Maxime,
Am 04.03.2019 um 15:52 schrieb Maxime Ripard:
The current code assumes as soon as the device is an HDMI one that it
supports an audio sink. However, strictly speaking, this is exposed as a
separate part of EDID.
This can be checked through the drm_detect_monitor_audio function, so
On Sun, Mar 03, 2019 at 11:05:23PM +0530, Jagan Teki wrote:
> Loop N1 instruction delay for burst mode devices are computed
> based on horizontal sync and porch timing values.
>
> The current driver is using u16 type for computing this hsync_porch
> value, which would failed to fit within the u16
On 3/4/19 9:49 AM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken care
On Mon, 2019-03-04 at 17:47 +0200, Jani Nikula wrote:
> On Mon, 04 Mar 2019, Maxime Ripard wrote:
> > In some cases, in order to accomodate with displays with poor EDIDs, we
> > need to ignore that the monitor alledgedly supports audio output and
> > disable the audio output.
>
> *sad trombone*
On Sun, Mar 03, 2019 at 11:05:27PM +0530, Jagan Teki wrote:
> DSI timings are varies between burst/non-burst devices and
> current driver is handling this support via if, else statements
> which would difficult to read.
>
> Simplify it by using goto to make code more readable.
>
> Signed-off-by:
Hi Maxime,
Am 04.03.2019 um 15:52 schrieb Maxime Ripard:
Hi,
The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.
Those options are detailed here:
On Sun, Mar 03, 2019 at 11:05:25PM +0530, Jagan Teki wrote:
> Like other dsi setup timings, or hblk for that matter vblk would
> also require compute the timings based payload equation along with
> packet overhead.
>
> But, on the other hand vblk computation is also depends on device
> lane
On 3/4/19 9:49 AM, Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are performed in the
On Mon, 04 Mar 2019, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c0258b011bb2..2f6df10ed9f1 100644
> ---
On Mon, 04 Mar 2019, Maxime Ripard wrote:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.
*sad trombone*
Trying to figure this out automatically in kernel is better than
On Sun, Mar 03, 2019 at 11:05:24PM +0530, Jagan Teki wrote:
> TCON DRQ for non-burst DSI mode can computed based on horizontal
> front porch value, but the current driver trying to include sync
> timings along with front porch resulting wrong drq.
>
> This patch is trying to update the drq by
https://bugs.freedesktop.org/show_bug.cgi?id=109808
--- Comment #4 from Philip Yang ---
I will change the error message for this specific case to mention the missing
kernel config option.
I cannot add select ZONE_DEVICE in driver Kconfig file because there will be a
circular dependency issue.
Hi,
Maxime Ripard wrote:
> properties to initialise the overscan or rotation parameters, or the
> one to deal with broken displays.
How does that work on systems with multiple connectors?
On SBCs with only one output I guess it's fine to have a global option,
but it may be important for new
Hi,
On Mon, 2019-03-04 at 15:52 +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c
Hi,
On Mon, 2019-03-04 at 15:52 +0100, Maxime Ripard wrote:
> The current code assumes as soon as the device is an HDMI one that it
> supports an audio sink. However, strictly speaking, this is exposed as a
> separate part of EDID.
>
> This can be checked through the drm_detect_monitor_audio
On 3/1/19 6:06 AM, Brian Starkey wrote:
> Hi Andrew,
>
> Sorry for not managing to comment on this sooner, I've had a crazy few
> days.
>
> As the others have said, I quite like the direction here.
>
> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
>> This framework allows a
Properly configuring the overscan properties might be needed for the
initial setup of the framebuffer for display that still have overscan.
Let's allow for more properties on the kernel command line to setup each
margin.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 47
Rotations and reflections setup are needed in some scenarios to initialise
properly the initial framebuffer. Some drivers already had a bunch of
quirks to deal with this, such as either a private kernel command line
parameter (omapdss) or on the device tree (various panels).
In order to
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c0258b011bb2..2f6df10ed9f1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4156,6
From: Maxime Ripard
The drm subsystem also uses the video= kernel parameter, and in the
documentation refers to the fbdev documentation for that parameter.
However, that documentation also says that instead of giving the mode using
its resolution we can also give a name. However, DRM doesn't
In some cases, in order to accomodate with displays with poor EDIDs, we
need to ignore that the monitor alledgedly supports audio output and
disable the audio output.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git
From: Maxime Ripard
Rewrite the command line parser in order to get away from the state machine
parsing the video mode lines.
Hopefully, this will allow to extend it more easily to support named modes
and / or properties set directly on the command line.
Signed-off-by: Maxime Ripard
---
Hi,
The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.
Those options are detailed here:
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md
While not all
The current code assumes as soon as the device is an HDMI one that it
supports an audio sink. However, strictly speaking, this is exposed as a
separate part of EDID.
This can be checked through the drm_detect_monitor_audio function, so let's
use it and make sure that we can use the HDMI monitor
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Cc: # v4.14+: 25dc194b34dd: drm: Block fb changes for
async plane updates
Cc: # v4.14+: 8105bbaf9afd: drm: don't block fb
changes for async plane updates
Fixes: 25dc194b34dd
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the
Hello,
This series is a first attempt to fix the slow down in performance introduced by
"[PATCH v2] drm: Block fb changes for async plane updates" where async update
falls back to a sync update, causing igt failures of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleanup up (instead of the old_state, diferrently on what happen in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the
Den 22.02.2019 16.58, skrev Andy Shevchenko:
> On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
>> Buffers passed to spi_sync() must be dma-safe even for tiny buffers since
>> some SPI controllers use DMA for all transfers.
>>
>> Example splat with CONFIG_DMA_API_DEBUG enabled:
>>
Den 25.02.2019 15.42, skrev Noralf Trønnes:
> This patchset is part of the effort to remove tinydrm.ko. It removes
> struct tinydrm_device and tinydrm.h.
>
> Only one change in this version and that is expanding the driver
> example.
>
> The drm_dev_unplug() dependency series has been applied
On 04/03/2019 14:42, Laurent Pinchart wrote:
> Hi Jyri,
>
> On Wed, Feb 27, 2019 at 11:54:18PM +0200, Jyri Sarha wrote:
>> Changes since first version:
>> - Moved reviewed patches to front:
>> - drm/bridge: sii902x: add input_bus_flags
>> - drm/bridge: sii902x: Set output mode to HDMI or DVI
On 04/03/2019 14:52, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
> On Wed, Feb 27, 2019 at 11:54:20PM +0200, Jyri Sarha wrote:
>> Set output mode to HDMI or DVI according to EDID HDMI signature.
>>
>> Signed-off-by: Jyri Sarha
>> Reviewed-by: Andrzej Hajda
>> ---
>>
Op 01-03-2019 om 23:47 schreef Eric Anholt:
> Maarten Lankhorst writes:
>
>> Convert vc4 to using __drm_atomic_helper_crtc_reset(), instead of
>> writing its own version. Instead of open coding destroy_state(),
>> call it directly for freeing the old state.
>>
>> Signed-off-by: Maarten Lankhorst
https://bugzilla.kernel.org/show_bug.cgi?id=202735
--- Comment #4 from Ilya (kazakevichi...@gmail.com) ---
Not a bug at all. I'd call it "usability problem")
User can't enable TTM (which is required for virtualbox) unless she enables
some redundant driver.
--
You are receiving this mail
On Mon, Mar 04, 2019 at 03:06:16PM +0200, Priit Laes wrote:
> From: Priit Laes
>
> Even though HDMI connector features hotplug detect pin (HPD), there
> are older devices which do not support it. For these devices fall
> back to additional check on I2C bus to probe for EDID data.
>
> One known
On Fri, Mar 01, 2019 at 01:56:24PM +0100, Maarten Lankhorst wrote:
> Convert tegra to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc:
Hi Sam,
Thanks, I'll fix them in next version.
Regards,
Qiang
On Sun, Mar 3, 2019 at 11:02 PM Sam Ravnborg wrote:
>
> Hi Qiang.
>
> Good to see you do prompt follow-up on the feedback you get.
> I applied the patch and noticed that git compains about
> a few whitespace errors.
> So for good
https://bugzilla.kernel.org/show_bug.cgi?id=202735
--- Comment #3 from Jani Nikula (jani.nik...@intel.com) ---
Arguably not a bug in kernel.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
Hi Jyri,
Thank you for the patch.
On Wed, Feb 27, 2019 at 11:54:20PM +0200, Jyri Sarha wrote:
> Set output mode to HDMI or DVI according to EDID HDMI signature.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/sii902x.c | 9 +
> 1 file changed,
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 320 +++
4 files changed, 334 insertions(+)
create mode 100644
---
.../bindings/display/panel/ilitek,ili9341.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
These patches add panel driver for ili9341-based panels in parallel RGB mode.
The driver was developed for DispleyTech DT024CTFT LCD panel [1] which features
ILI9341 chip [2].
The driver was tested on the Allwinner A13 (sun5i) platform.
The driver supports 240x320 pixel resolution with 18-bit
1 - 100 of 147 matches
Mail list logo
