On 2019-06-26 2:54 a.m., Koenig, Christian wrote:
> Am 26.06.19 um 08:40 schrieb Kuehling, Felix:
>> Returning -EAGAIN prevents ttm_bo_mem_space from trying alternate
>> placements and can lead to live-locks in amdgpu_cs, retrying
>> indefinitely and never succeeding.
>>
>> Fixes: cfcc52e477e4 ("dr
Those patches would become superfluous when merging Gerd's work.
But I'm not sure if that is going to fly soon or not.
Christian.
Am 25.06.19 um 22:42 schrieb Daniel Vetter:
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object al
Am 24.06.19 um 08:32 schrieb Gerd Hoffmann:
Hi,
Yeah, my point was not really suggesting that we do this, but rather that
people would rightfully get upset because the struct contains unused stuff.
Well, struct drm_gem_object isn't that big, lets have a look:
320 bytes in total, of which a
Hi Jitao.
Driver looks good, one detail.
> +
> +struct panel_desc {
> + const struct drm_display_mode *modes;
> + unsigned int bpc;
> +
> + /**
> + * @width: width (in millimeters) of the panel's active display area
> + * @height: height (in millimeters) of the panel's activ
On Wed, Jun 26, 2019 at 10:53:57AM +0800, Jitao Shi wrote:
> Add documentation for boe tv101wum-n16 panel.
>
> Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
> ---
> .../display/panel/boe,tv101wum-nl6.txt| 34 +++
> 1 file changed, 34 insertions(+)
> create mode 100
On Wed, Jun 26, 2019 at 10:54:00AM +0800, Jitao Shi wrote:
> Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
> The most codes can be reuse.
> So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
> Add the different parts in driver data.
Very nice consolidation.
Have you consid
Hi Nikolaus.
> >
> > any progress towards merging this somewhere? It did not yet arrive in
> > linux-next.
> >
> > BTW: should also be applied to 5.2
> The drm bits are reviewed. The DT bits needs OK from DT people.
> When we have OK from DT people we can apply them all to drm-misc-next.
I got
Am 25.06.19 um 18:05 schrieb Daniel Vetter:
On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
On Fri, 5 Apr 2019 06:46:02 +0200
Gerd Hoffmann wrote:
> drm_connector_update_edid_property can sleep, we must not
> call it while holding a spinlock. Move the callsize.
s/callsize/callsite/
>
> Reported-by: Max Filippov
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgp
On Wed, Jun 26, 2019 at 4:00 AM Rodrigo Siqueira
wrote:
>
> On 06/19, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 09:48:56AM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote:
> > > > For historical reason, the function drm_wait_vblank_ioctl al
On Tue, Jun 25, 2019 at 4:22 PM Luis Chamberlain wrote:
>
> On Mon, Jun 17, 2019 at 01:26:02AM -0700, Brendan Higgins wrote:
> > diff --git a/kunit/example-test.c b/kunit/example-test.c
> > new file mode 100644
> > index 0..f44b8ece488bb
> > --- /dev/null
> > +++ b/kunit/example-test.c
On Wed, 26 Jun 2019 02:00:46 +0200
Gerd Hoffmann wrote:
> On Tue, Jun 25, 2019 at 05:15:41PM +0200, Cornelia Huck wrote:
> > Hi Gerd,
> >
> > flipping the virtio-gpu edid support in QEMU to default enabled exposed
> > the following backtrace in my guest (from my bisect run down to the
> > initia
On Wed, Jun 26, 2019 at 3:44 AM Rodrigo Siqueira
wrote:
>
> On 06/19, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira
On Tue, Jun 25, 2019 at 5:01 PM Luis Chamberlain wrote:
>
> On Mon, Jun 17, 2019 at 01:26:08AM -0700, Brendan Higgins wrote:
> > create mode 100644
> > tools/testing/kunit/test_data/test_is_test_passed-all_passed.log
> > create mode 100644
> > tools/testing/kunit/test_data/test_is_test_passed-
Hi David,
The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:
Linux 5.1 (2019-05-05 17:42:58 -0700)
are available in the git repository at:
git://git.armlinux.org.uk/~rmk/linux-arm.git tags/for-airlie-tda998x
for you to fetch changes up to 45a19dd397886a9591110c0e9
On Tue, Jun 25, 2019 at 09:29:15AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 20, 2019 at 09:26:48PM +0200, Michal Hocko wrote:
> > On Thu 13-06-19 11:43:21, Christoph Hellwig wrote:
> > > The code hasn't been used since it was added to the tree, and doesn't
> > > appear to actually be usable.
Hi Russell,
W dniu 25.06.2019 o 12:03, Russell King - ARM Linux admin pisze:
On Tue, Jun 25, 2019 at 11:46:34AM +0200, Andrzej Pietrasiewicz wrote:
It is difficult for a user to know which of the i2c adapters is for which
drm connector. This series addresses this problem.
The idea is to have a
On Mon, Jun 24, 2019 at 1:36 PM Sam Ravnborg wrote:
>
> Hi Derek.
>
> On Fri, Jun 21, 2019 at 08:41:02PM -0700, Derek Basehore wrote:
> > This adds a helper function for reading the rotation (panel
> > orientation) from the device tree.
> >
> > Signed-off-by: Derek Basehore
> > ---
> > drivers/g
On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
>
>> ...
On Tue, Jun 18, 2019 at 03:56:23PM +0300, Dan Carpenter wrote:
> The copy_to_user() function returns the number of bytes remaining to be
> copied, but we want to return -EFAULT. This function is called from
> __drm_legacy_infobufs() which expects negative error codes.
>
> Fixes: 5c7640ab6258 ("sw
On Mon, 2019-06-24 at 22:19 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote:
> > The change actions Jani's suggestion:
> > https://lkml.org/lkml/2019/6/20/343
>
> I suggest not changing any of the existing uses of
> hex_dump_to_buffer and only use hex_dump_to_
On 6/25/19 10:45 PM, Michal Hocko wrote:
> On Tue 25-06-19 20:15:28, John Hubbard wrote:
>> On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
>>> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
On 6/13/19 5:43 PM, Ira Weiny wrote:
> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason G
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > Apologies for the large CC list, it's a heads up for those
> > responsible
> > for subsystems where a prototype change in generic code causes a
> >
On Mon, 2019-06-24 at 22:37 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > With the wider display format, it can become hard to identify how
> > many
> > bytes into the line you are looking at.
> >
> > The patch adds new
I would like to deprecate the old prefix in the future after communicating
with all chip customers, which is why the old prefix is not documented in
the new bindings.
On Tue, Jun 25, 2019, 4:55 AM Daniel Thompson
wrote:
> On Tue, Jun 25, 2019 at 12:05:28AM -0400, Brian Dodge wrote:
> > The
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > In order to support additional features, rename hex_dump_to_buffer
> > to
> > hex_dump_to_buffer_ext, and replace the ascii bool parameter with
> >
On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> > On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> > > On the exporter side we add optional explicit pinning callbacks. If those
> > > callbacks are implemented the fra
On Wed, Jun 26, 2019 at 07:10:21AM +, Koenig, Christian wrote:
> Those patches would become superfluous when merging Gerd's work.
Not entirely, they still remove the gem_prime_res_obj. Setting up
gem_bo.resv is only one half of what these do here. And yeah I think that
single addition can be r
On Tue, 2019-06-25 at 22:22 +0200, Daniel Vetter wrote:
> On Tue, Jun 25, 2019 at 06:59:15PM +0100, Robert Beckett wrote:
> > The event will be sent as part of the vblank enable during the modeset
> > if the crtc is not being kept disabled.
> >
> > Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 ste
Op 24-06-2019 om 16:03 schreef Daniel Vetter:
> On Mon, Jun 24, 2019 at 03:07:26PM +0200, Maarten Lankhorst wrote:
>> Op 24-06-2019 om 11:21 schreef Daniel Vetter:
>>> Fixes linking fail when fbcon/fbdev is modular and vgaswitcheroo is
>>> enabled:
>>>
>>> x86_64-linux-gnu-ld: drivers/gpu/vga/vga_s
On Mon, Jun 24, 2019 at 11:21:53AM +0200, Daniel Vetter wrote:
> Fixes linking fail when fbcon/fbdev is modular and vgaswitcheroo is
> enabled:
>
> x86_64-linux-gnu-ld: drivers/gpu/vga/vga_switcheroo.o: in function
> `vga_switchto_stage2':
> vga_switcheroo.c:(.text+0x997): undefined reference to
Op 26-06-2019 om 10:35 schreef Daniel Vetter:
> On Mon, Jun 24, 2019 at 11:21:53AM +0200, Daniel Vetter wrote:
>> Fixes linking fail when fbcon/fbdev is modular and vgaswitcheroo is
>> enabled:
>>
>> x86_64-linux-gnu-ld: drivers/gpu/vga/vga_switcheroo.o: in function
>> `vga_switchto_stage2':
>> vg
https://bugs.freedesktop.org/show_bug.cgi?id=110984
--- Comment #4 from Michel Dänzer ---
(In reply to Olivier Fourdan from comment #2)
> Last thing, with single buffer, I would expect tearing more than stuttering,
It's a race between the Wayland server reading from the buffer and Xwayland
drawi
https://bugs.freedesktop.org/show_bug.cgi?id=110994
--- Comment #2 from Jason Playne ---
This is has just started effecting me too. Playing "Hellblade: Senuas
Sacrifice" on steam (so steam play / radv / dxvk)
mesa via pkppa
kernel 5.1.15-050115-generic (ubuntu kernel ppa)
libdrm-amdgpu1:amd64
https://bugs.freedesktop.org/show_bug.cgi?id=110994
--- Comment #3 from Jason Playne ---
(In reply to Jason Playne from comment #2)
> This is has just started effecting me too. Playing "Hellblade: Senuas
> Sacrifice" on steam (so steam play / radv / dxvk)
>
> mesa via pkppa
>
> kernel 5.1.15-05
Hi all,
This is the followup pull request for the remove-fbcon-notifiers topic branch.
No major changes, just a few compile fixes.
This will be pulled into drm-misc-next, but it might be useful for the fbdev
and backlight trees too.
Cheers,
Maarten
topic/remove-fbcon-notifiers-2019-06-26:
- Ex
https://bugs.freedesktop.org/show_bug.cgi?id=110994
--- Comment #4 from Jason Playne ---
(In reply to Jason Playne from comment #2)
> This is has just started effecting me too. Playing "Hellblade: Senuas
> Sacrifice" on steam (so steam play / radv / dxvk)
>
> mesa via pkppa
>
> kernel 5.1.15-05
On Tue, Jun 25, 2019 at 11:38:39AM +0200, Thierry Reding wrote:
> On Mon, Jun 24, 2019 at 12:28:44PM +0100, Daniel Thompson wrote:
> > [...] although given pwm-backlight is essentially a wrapper driver
> > round a PWM I wondered why the pinctrl was on the backlight node
> > (rather than the PWM nod
https://bugs.freedesktop.org/show_bug.cgi?id=110994
--- Comment #5 from Jason Playne ---
(In reply to Jason Playne from comment #4)
> (In reply to Jason Playne from comment #2)
> > This is has just started effecting me too. Playing "Hellblade: Senuas
> > Sacrifice" on steam (so steam play / radv
On Wed, Jun 26, 2019 at 09:51:46AM +0200, Cornelia Huck wrote:
> On Fri, 5 Apr 2019 06:46:02 +0200
> Gerd Hoffmann wrote:
>
> > drm_connector_update_edid_property can sleep, we must not
> > call it while holding a spinlock. Move the callsize.
>
> s/callsize/callsite/
Fixed on commit.
> This
On 24/06/2019 16:59, Andrzej Hajda wrote:
> On 26.05.2019 23:20, Jonas Karlman wrote:
>> This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and
>> G12A.
>>
>> Cc: Neil Armstrong
>> Signed-off-by: Jonas Karlman
>> ---
>> drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 +
>> 1 fil
Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
>> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
>>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If
We gracefully handle the caller specifying a zero range, so don't force
them to special case that condition if it naturally falls out of their
setup. What we don't check is if the end < start, so keep that as an
assert for an illegal call.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Dani
On 25.06.2019 18:26, Doug Anderson wrote:
> Hi,
>
>
> On Tue, Jun 25, 2019 at 9:07 AM Andrzej Hajda wrote:
>> On 19.06.2019 23:07, Douglas Anderson wrote:
>>> Let's add some better support for HDMI audio to dw_hdmi.
>>> Specifically:
>>>
>>> 1. For 44.1 kHz audio the old code made the assumption t
On Wed, Jun 26, 2019 at 10:58:27AM +0200, Uwe Kleine-König wrote:
> On Tue, Jun 25, 2019 at 11:38:39AM +0200, Thierry Reding wrote:
> > On Mon, Jun 24, 2019 at 12:28:44PM +0100, Daniel Thompson wrote:
> > > [...] although given pwm-backlight is essentially a wrapper driver
> > > round a PWM I wonde
On 26.06.2019 11:56, Andrzej Hajda wrote:
> On 25.06.2019 18:26, Doug Anderson wrote:
>> Hi,
>>
>>
>> On Tue, Jun 25, 2019 at 9:07 AM Andrzej Hajda wrote:
>>> On 19.06.2019 23:07, Douglas Anderson wrote:
Let's add some better support for HDMI audio to dw_hdmi.
Specifically:
1.
On 2019-06-26 9:04 a.m., Kuehling, Felix wrote:
> On 2019-06-26 2:54 a.m., Koenig, Christian wrote:
>> Am 26.06.19 um 08:40 schrieb Kuehling, Felix:
>>> Returning -EAGAIN prevents ttm_bo_mem_space from trying alternate
>>> placements and can lead to live-locks in amdgpu_cs, retrying
>>> indefinitel
Hi,
On 6/26/19 10:48 AM, Maarten Lankhorst wrote:
> Hi all,
>
> This is the followup pull request for the remove-fbcon-notifiers topic branch.
> No major changes, just a few compile fixes.
>
> This will be pulled into drm-misc-next, but it might be useful for the fbdev
> and backlight trees to
I'll try testing this on my Skylake/Tonga setup tonight
On Tue, 25 Jun 2019 at 21:42, Daniel Vetter wrote:
>
> Hi all,
>
> Here's the unmerged leftovers from my big prime cleanup series:
> - using the prepare_fb helper in vc4&msm, now hopefully fixed up. The
> helper should be now even more use
On Wed, Jun 26, 2019 at 11:58:44AM +0200, Thierry Reding wrote:
> On Wed, Jun 26, 2019 at 10:58:27AM +0200, Uwe Kleine-König wrote:
> > On Tue, Jun 25, 2019 at 11:38:39AM +0200, Thierry Reding wrote:
> > > On Mon, Jun 24, 2019 at 12:28:44PM +0100, Daniel Thompson wrote:
> > > > [...] although given
On 24.06.2019 11:08, Neil Armstrong wrote:
> Add myself as co-maintainer of DRM Bridge Drivers then add Jonas Karlman
> and Jernej Škrabec as Reviewers of DRM Bridge Drivers.
>
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Andrzej Hajda
> Cc: Jernej Škrabec
> Cc: Daniel Vetter
> Signed-off-
Adds to support register dump on lpu and dou of pipeline and gcu on D71
Signed-off-by: Lowry Li (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 86 +-
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 23 +++---
drivers/gpu/drm/arm/display/k
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1
This patch-set contains the DRM panel driver and dt-bindings documentation
for the DSI driven panel: Raydium RM67191.
v5:
- Removed unnecessary debug messages (fabio)
- Handled error case for gpio pin (fabio)
v4:
- Changed default_timing structure type from 'struct display_timing' to
'struct dr
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
---
.../bindings/display/panel/raydium,rm67191.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display
Op 26-06-2019 om 12:03 schreef Bartlomiej Zolnierkiewicz:
> Hi,
>
> On 6/26/19 10:48 AM, Maarten Lankhorst wrote:
>> Hi all,
>>
>> This is the followup pull request for the remove-fbcon-notifiers topic
>> branch.
>> No major changes, just a few compile fixes.
>>
>> This will be pulled into drm-mis
Document the vcc-supply and iovcc-supply properties of the Rocktech
jh057n00900 panel.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
.../bindings/display/panel/rocktech,jh057n00900.txt | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindi
Add a mail alias as reviewer for the rocktech jh057n00900 panel driver.
Signed-off-by: Guido Günther
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 10359a30ed3c..b7de43a4910d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5133,6 +5133,7 @@ F:
Fix the omission of a regulators for the recently added panel and make sure all
dsi commands start with a command instead of one having a magic constant (which
already caused confusion).
Also adds a mail alias to the panel's MAINTAINER entry to reduce the bus
factor.
Changes from v1:
* As per rev
0xBF isn't in any ST7703 data sheet so mark it as unknown. This avoids
confusion on whether there is a missing command in that
dsi_generic_write_seq() call.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 3 ++-
1 file changed, 2 i
Allow to specify regulators for vcc and iovcc. According to the data
sheet the panel wants vcc (2.8V) and iovcc (1.8V) and there's no startup
dependency between the two.
Signed-off-by: Guido Günther
---
.../drm/panel/panel-rocktech-jh057n00900.c| 41 +++
1 file changed, 41 in
Hi Sam,
On Tue, Jun 25, 2019 at 11:24:19PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 25, 2019 at 07:05:19PM +0200, Guido Günther wrote:
> > Allow to specify regulators for vcc and iovcc. According to the data
> > sheet the panel wants vcc (2.8V) and iovcc (1.8V) and there's no startup
> > dependency
On Tue, Jun 25, 2019 at 12:05:29AM -0400, Brian Dodge wrote:
> The original patch adding this driver and DT bindings improperly
> used "arc" as the vendor-prefix. This adds "arctic" which is the
> proper prefix and retains "arc" to allow existing users of the
> "arc" prefix to update to new kernels
On Tue, Jun 25, 2019 at 07:44:06AM -0400, Brian Dodge wrote:
> I would like to deprecate the old prefix in the future after communicating
> with all chip customers, which is why the old prefix is not documented in
> the new bindings.
Deprecation is fine (by me at least) it's just that I'm not sure
On Wed, 19 Jun 2019, Andy Shevchenko wrote:
> Reduce size of duplicated comments by switching to use SPDX identifier.
>
> No functional change.
>
> While here, correct MODULE_LICENSE() string to be aligned with license text.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/video/backlight/p
On Wed, Jun 26, 2019 at 11:28 AM Koenig, Christian
wrote:
>
> Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> >> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> >>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> >
On Wed, 19 Jun 2019, Andy Shevchenko wrote:
> ACPI allows to enumerate specific devices by using compatible strings.
> Enable that enumeration for GPIO based backlight devices.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/video/backlight/gpio_backlight.c | 23 +--
> 1
On Wed, Jun 26, 2019 at 7:21 AM Robert Chiras wrote:
>
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> Reviewed-by: Sam Ravnborg
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.f
Hi Robert,
On Wed, Jun 26, 2019 at 7:21 AM Robert Chiras wrote:
>
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
>
> Signed-off-by: Robert Chiras
> Reviewed-by: Sam Ravnborg
Looks good to me:
Reviewed-by: Fabio Estevam
Thanks
Hi Robert.
On Wed, Jun 26, 2019 at 01:20:20PM +0300, Robert Chiras wrote:
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
I was about to apply these - but I get following warnings during build:
CC drivers/gpu/drm/panel/panel-raydium-rm67191.o
/home/sam/drm/lin
[SNIP]
I'm confused here: Atm ->moving isn't in resv_obj, there's only one
exclusive fence. And yes you need to set that every time you do a move
(because a move needs to be pretty exclusive access). But I'm not seeing a
separate not_quite_exclusive fence slot for moves.
Yeah, but shouldn't tha
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
Reviewed-by: Fabio Estevam
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Ma
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
Reviewed-by: Sam Ravnborg
Reviewed-by: Fabio Estevam
---
.../bindings/display/panel/raydium,rm67191.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation
This patch-set contains the DRM panel driver and dt-bindings documentation
for the DSI driven panel: Raydium RM67191.
v6:
- Collected Reviewed-by from Fabio
- Removed unused variables (sam)
v5:
- Removed unnecessary debug messages (fabio)
- Handled error case for gpio pin (fabio)
v4:
- Changed d
Hi Sam,
On Mi, 2019-06-26 at 13:33 +0200, Sam Ravnborg wrote:
> Hi Robert.
>
> On Wed, Jun 26, 2019 at 01:20:20PM +0300, Robert Chiras wrote:
> >
> > This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> > protocol).
> I was about to apply these - but I get following warnings during
>
On Wed, Jun 26, 2019 at 1:53 PM Christian König
wrote:
>
> [SNIP]
> > I'm confused here: Atm ->moving isn't in resv_obj, there's only one
> >>> exclusive fence. And yes you need to set that every time you do a move
> >>> (because a move needs to be pretty exclusive access). But I'm not seeing
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file changed
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging lefto
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
On Wed, Jun 26, 2019 at 10:44:38AM +, Xin Ji wrote:
> Move analogix chip ANX78XX bridge driver into "analogix" directory.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/Kconfig | 10 -
> drivers/gpu/drm/bridge/Makefile|3 +-
> drivers/g
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
On Wed 26-06-19 14:27:05, Christoph Hellwig wrote:
> nouveau is currently using this through an odd hmm wrapper, and I plan
> to switch it to the real thing later in this series.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: John Hubbard
Acked-by: Michal Hocko
Thanks!
> ---
> mm/mempo
On Wed, Jun 26, 2019 at 03:08:25PM +0300, Robert Chiras wrote:
> This patch-set contains the DRM panel driver and dt-bindings documentation
> for the DSI driven panel: Raydium RM67191.
>
> v6:
> - Collected Reviewed-by from Fabio
> - Removed unused variables (sam)
>
> v5:
> - Removed unnecessary
Hi Guido.
On Wed, Jun 26, 2019 at 12:37:47PM +0200, Guido Günther wrote:
> Fix the omission of a regulators for the recently added panel and make sure
> all
> dsi commands start with a command instead of one having a magic constant
> (which
> already caused confusion).
>
> Also adds a mail alia
On Mon, Jun 03, 2019 at 05:25:54PM +0200, Paul Cercueil wrote:
> The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.
>
> Signed-off-by: Paul Cercueil
Both patches applied to drm-misc-next and pushed out.
Sam
___
dri-devel mailing list
dri
On Mon, Jun 03, 2019 at 05:31:18PM +0200, Paul Cercueil wrote:
> The LS020B1DD01D is a 2.0" 240x160 16-bit TFT LCD panel.
>
> Signed-off-by: Paul Cercueil
> Reviewed-by: Rob Herring
All patches applied to drm-misc-next and pushed out.
I had hoped for feedback form other on the trick with bus_fo
Hi Marek.
On Mon, Jun 24, 2019 at 12:43:49AM +0200, Marek Vasut wrote:
> On 5/29/19 12:25 PM, Marek Vasut wrote:
> > The ETM0700G0DH6 is currently documented as using edt,etm070080dh6
> > compatible string, however the Linux kernel driver as well as a
> > couple of DTs use edt,etm0700g0dh6 compati
Hi Jerry.
On Thu, Apr 25, 2019 at 11:27:12AM +0800, Jerry Han wrote:
> Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
>
> Signed-off-by: Jerry Han
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Derek Basehore
> Cc: Jitao Shi
> Cc: Rock wang
> ---
> MAINTAINERS
On Thu, Apr 25, 2019 at 11:18:42AM +0800, Jerry Han wrote:
> The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
> connected to DSI using four lanes.
>
> V8:
> - Modify communication address
>
> V7:
> - Add the information of the reviewer
>
> V6:
> - Add the information of the rev
Hi Josef.
On Tue, Feb 19, 2019 at 02:20:59PM +0100, Josef Lusticky wrote:
> 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
Hi Douglas.
On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree. The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
>
> No code is different bet
Hi,
On Wed, Jun 26, 2019 at 02:41:39PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Wed, Jun 26, 2019 at 12:37:47PM +0200, Guido Günther wrote:
> > Fix the omission of a regulators for the recently added panel and make sure
> > all
> > dsi commands start with a command instead of one having a ma
On Wed, 26 Jun 2019, Daniel Thompson wrote:
> On Tue, Jun 25, 2019 at 07:44:06AM -0400, Brian Dodge wrote:
> > I would like to deprecate the old prefix in the future after communicating
> > with all chip customers, which is why the old prefix is not documented in
> > the new bindings.
>
> Depreca
From: Colin Ian King
There are a couple of spelling mistakes in dm_error messages and
a comment. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 8
2 files changed, 5 insertions(+)
Hi Colin,
On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
> There are a couple of spelling mistakes in dm_error messages and
> a comment. Fix these.
Whilst there, you might fix the '[next[' typo in the commit message.
Cheers,
Daniel
___
dri-devel mail
On Tue, Jun 25, 2019 at 06:59:14PM +0100, Robert Beckett wrote:
> If interrupts are disabled (e.g. via vblank_disable_fn) and we come to
> disable vblank, update the vblank count to best guess as to what it
> would be had the interrupts remained enabled, and update the timesamp to
> now.
>
> This
Currently, the vblank support is not correctly implemented in MXSFB_DRM
driver. The call to drm_vblank_init is made with mode_config.num_crtc
which at that time is 0. Because of this, vblank is not activated, so
there won't be any vblank event submitted.
For example, when running modetest with the
1 - 100 of 235 matches
Mail list logo
