On Wed, Apr 25, 2018 at 8:43 AM, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
>> For more fun:
>>
>> https://www.spinics.net/lists/dri-devel/msg173630.html
>>
>> Yeah, sometimes we want to disable the iommu because the on-gpu
>> pagetables are faster ..
On Tue, Apr 24, 2018 at 02:24:59PM +0200, Hans de Goede wrote:
> Hi,
>
> On 24-04-18 14:18, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 12:26:04PM +0200, Maarten Lankhorst wrote:
> > > Op 24-04-18 om 12:09 schreef Hans de Goede:
> > > > Hi,
> > > >
> > > > On 18-04-18 14:36, Hans de Goede wr
On Tue, Apr 24, 2018 at 03:14:40PM +0200, Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by using 'enum drm_mode_status' in t
On Tue, Apr 24, 2018 at 03:14:47PM +0200, Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by using 'enum drm_mode_status' in t
On Tue, Apr 24, 2018 at 03:15:17PM +0200, Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by using 'enum drm_mode_status' in t
On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> Can we please not nack everything right away? Doesn't really motivate
> me to show you all the various things we're doing in gpu to make the
> dma layer work for us. That kind of noodling around in lower levels to
> get them to do wha
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/nouvea
The method (*hqd_destroy) is defined as using an 'uint32_t'
as 3rd argument but the the actual implementation of this
method and all its calls actually uses an 'enum kfd_preempt_type'
for this argument.
Fix this by using 'enum kfd_preempt_type' for (*hqd_destroy) too.
Signed-off-by: Luc Van Ooste
On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote:
> On Wed, 11 Apr 2018, Simon Horman wrote:
>
> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > > of the GPIOF_* flags. The docs were fixed wit
AGP mode is unstable on PowerPC. Symptoms are generally of the form:
[ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec
Reviewed-by: Christian König
Signed-off-by: Mathieu Malaterre
---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
1 file changed, 5 insertions(+)
diff
The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, radeon_atpx_get_client_id(), returns an 'int'.
Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: Luc V
On Tue, Apr 24, 2018 at 11:08:41AM +0200, Juergen Gross wrote:
> On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
> > On 04/24/2018 11:40 AM, Juergen Gross wrote:
> >> On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
> >>> On 04/24/2018 10:51 AM, Juergen Gross wrote:
> On 24/04/18 07:43, Ole
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/mgag20
On 2018-04-24 10:08, Russell King - ARM Linux wrote:
> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
>> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
>>> On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
static int tda998x_remove(struct i2c_client *client)
>>>
On Tue, Apr 24, 2018 at 9:10 PM, Kieran Bingham
wrote:
> Replace the initialisation of the vsps table with a NULL specifier.
>
> Fixes the following warning:
> linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
> warning: Using plain integer as NULL pointer
> CC drivers/gpu/drm/rc
The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, amdgpu_atpx_get_client_id(), returns an 'int'.
Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: Luc V
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/qxl/qx
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method, psb_intel_lvds_mode_valid(), uses an 'int' for it.
Fix this by using 'enum drm_mode_status' for psb_intel_lvds_mode_valid().
Signed-off-by: Luc
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/gma500
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/bridge
On 2018-04-21 01:13, Sean Paul wrote:
On Thu, Apr 19, 2018 at 11:26:07PM +0530, Sandeep Panda wrote:
Add support for Innolux TV123WAM 12.3" panel which
is an eDP panel.
It seems like you could just use the panel-simple driver, no? Given
that this
driver doesn't have any power timing, that wil
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable")
Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets
On 2018-04-21 01:06, Sean Paul wrote:
On Thu, Apr 19, 2018 at 11:26:05PM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c in
Andrey Grodzovsky writes:
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
>> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>>> Adding the dri-devel list, since this is driver independent code.
>>>
>>>
>>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_eve
On 04/24/2018 12:08 PM, Juergen Gross wrote:
On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
On 04/24/2018 11:40 AM, Juergen Gross wrote:
On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
On 04/24/2018 10:51 AM, Juergen Gross wrote:
On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
On 04/2
On Tue, Apr 24, 2018 at 2:38 PM John Stultz wrote:
> On Tue, Apr 24, 2018 at 3:34 AM, Stefan Schake wrote:
> > On Tue, Apr 24, 2018 at 10:09 AM, Alexandru-Cosmin Gheorghe
> > wrote:
> >> On Mon, Apr 23, 2018 at 05:06:44PM -0700, John Stultz wrote:
> >>> @@ -695,6 +704,15 @@ HWC2::Error
DrmHwcTw
The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, nouveau_dsm_get_client_id(), returns an 'int'.
Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: Luc V
On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> On 24/04/18 13:14, Peter Rosin wrote:
> > On 2018-04-24 10:08, Russell King - ARM Linux wrote:
> >> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> >>> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
> On Mon, Ap
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/bochs/
On Tue, 2018-04-24 at 09:39 -0500, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 06:24:54PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Add bindings to g3dsys providing necessary clock and reset control to
> > Mali-450.
> >
> > Signed-off-by: Sean Wang
> > ---
> > .../bindi
On 24/04/18 22:35, Dongwon Kim wrote:
> Had a meeting with Daniel and talked about bringing out generic
> part of hyper-dmabuf to the userspace, which means we most likely
> reuse IOCTLs defined in xen-zcopy for our use-case if we follow
> his suggestion.
>
> So assuming we use these IOCTLs as the
On 2018-04-24 20:13, Rob Herring wrote:
On Wed, Apr 18, 2018 at 05:50:02PM +0530, Sandeep Panda wrote:
The Innolux TV123WAM is a 12.3" eDP display panel
with 2160x1440 resolution.
Why don't you just submit this for upstream?
Sean Paul has suggested to reuse simple panel driver instead of havin
On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
> On 04/24/2018 10:51 AM, Juergen Gross wrote:
>> On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
>>> On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:
On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
> On 04/23/2018 02:52 PM, Wei Liu
On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
> On 04/24/2018 11:40 AM, Juergen Gross wrote:
>> On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
>>> On 04/24/2018 10:51 AM, Juergen Gross wrote:
On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
> On 04/24/2018 01:41 AM, Boris Ostrovsky
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/bridge
On 24/04/18 07:43, Oleksandr Andrushchenko wrote:
> On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:
>> On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>> On 04/23/2018 02:52 PM, Wei Liu wrote:
On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko
wrote:
>>> th
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/ast/as
On Tue, Apr 24, 2018 at 9:09 PM, Kieran Bingham
wrote:
> The symbol 'rcar_du_of_init' is defined by the rcar_du_of module header,
> but it is not included by the C implementation.
>
> Include the header to correctly define the function prototypes.
>
> Fixes the following warning:
>
> linux/drivers
On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
> > On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
> >> static int tda998x_remove(struct i2c_client *client)
> >> {
> >> - component_del(&client->dev, &tda998x_ops);
Hi Philippe,
Reviewed-by: Yannick Fertré
On 04/17/2018 01:34 PM, Philippe Cornu wrote:
> When a driver related to one of the endpoints is deferred
> due to probe dependencies (i2c, spi...) but the other one
> is ready, ltdc probe continues and the deferred driver
> will never be probed again.
>
Hi Lee,
On 04/24/2018 07:48 AM, Lee Jones wrote:
> On Mon, 23 Apr 2018, matthias@kernel.org wrote:
>
>> From: Matthias Brugger
>>
>> Changes since v1:
>> - add binding documentation
>> - ddp: use regmap_update_bits
>> - ddp: ignore EPROBE_DEFER on clock probing
>> - mfd: delete mmsys_private
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/amd/am
For reference:
https://lists.freedesktop.org/archives/mesa-dev/2016-May/115453.html
2018-04-24 21:55 GMT+02:00 Mathieu Malaterre :
> AGP mode is unstable on PowerPC. Symptoms are generally of the form:
>
> [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec
>
> Reviewed-by:
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/hisili
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/radeon
On 24/04/18 12:14, Oleksandr Andrushchenko wrote:
> On 04/24/2018 01:01 PM, Wei Liu wrote:
>> On Tue, Apr 24, 2018 at 11:08:41AM +0200, Juergen Gross wrote:
>>> On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
On 04/24/2018 11:40 AM, Juergen Gross wrote:
> On 24/04/18 10:07, Oleksandr And
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/i2c/td
On 2018-04-24 12:14, Peter Rosin wrote:
> On 2018-04-24 10:08, Russell King - ARM Linux wrote:
>> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
>>> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
> static int
Andrey Grodzovsky writes:
> On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
>> Andrey Grodzovsky writes:
>>
>>> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> Adding the dri-devel list, since this is driver independent code
On 04/24/2018 01:01 PM, Wei Liu wrote:
On Tue, Apr 24, 2018 at 11:08:41AM +0200, Juergen Gross wrote:
On 24/04/18 11:03, Oleksandr Andrushchenko wrote:
On 04/24/2018 11:40 AM, Juergen Gross wrote:
On 24/04/18 10:07, Oleksandr Andrushchenko wrote:
On 04/24/2018 10:51 AM, Juergen Gross wrote:
On 04/24/2018 02:47 AM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/mfd/Kconf
Daniel Vetter writes:
> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>>
>> Adding the dri-devel list, since this is driver independent code.
>>
>>
>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
>> > Avoid calling wait_event_killable when you are possibly being called
>>
Sparse complains with following warning:
drivers/gpu/drm/vc4/vc4_v3d.c:222:1: warning: symbol
'vc4_allocate_bin_bo' was not declared. Should it be static?
Make vc4_allocate_bin static as it is not used outside of
vc4_v3d.c.
Signed-off-by: Vaishali Thakkar
---
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/virtio
On Tue, 2018-04-24 at 09:40 -0500, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 06:24:55PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Add clock driver support for g3dsys on MT2701 and MT7623, which is
> > providing essential clock gate and reset controller to Mali-450.
> >
David,
Please incorporate support for TDA998x I2C driver CEC, which can be
found at:
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
with SHA1 ba52762fb1430b2a2ea8127c1a292c15f13b8dac, based on v4.16.
This set of changes brings support for HDMI CEC to the TDA998x driver.
There
> -Ursprüngliche Nachricht-
> Von: Shawn Guo Gesendet: Montag, 23. April 2018 10:45
> Re: [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series
>
> On Fri, Apr 20, 2018 at 02:50:52PM +0200, jan.tu...@emtrion.com wrote:
> > From: Jan Tuerk
> >
> > This patch adds support for th
All implementations of the method intel_dvo_dev_ops::mode_valid(), as
well as the underlying struct drm_connector_helper_funcs::mode_valid()
use 'enum drm_mode_status' for the method's return type but the
declaration of intel_dvo_dev_ops::mode_valid() uses an 'int' for it.
Fix this by using 'enum
On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote:
> On 24/04/18 20:06, Russell King - ARM Linux wrote:
> > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> >> On 24/04/18 13:14, Peter Rosin wrote:
> >>> On 2018-04-24 10:08, Russell King - ARM Linux wrote:
> On Tue, Apr 2
The method struct drm_connector_helper_funcs::mode_valid is defined
as returning an 'enum drm_mode_status' but the driver implementation
for this method uses an 'int' for it.
Fix this by using 'enum drm_mode_status' in the driver too.
Signed-off-by: Luc Van Oostenryck
---
drivers/gpu/drm/udl/ud
Use new return type vm_fault_t for fault and huge_fault
handler. For now, this is just documenting that the
function returns a VM_FAULT value rather than an errno.
Once all instances are converted, vm_fault_t will become
a distinct type.
Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
On 04/24/2018 08:22 AM, Chris Wilson wrote:
Quoting Gustavo A. R. Silva (2018-04-24 14:15:45)
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
err is only returned along an error
On Tue, Apr 24, 2018 at 11:29:42AM +0200, Hans Verkuil wrote:
> On 04/09/18 14:15, Russell King - ARM Linux wrote:
> > Hi,
> >
> > This patch series adds CEC support to the DRM TDA998x driver. The
> > TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> > address from the HDMI en
Hi Philippe,
Reviewed-by: Yannick Fertré
On 04/19/2018 03:28 PM, Philippe Cornu wrote:
> "make C=1" returns 2 warnings in ltdc_plane_create()
> ("Using plain integer as NULL pointer"). This patch
> fixes them.
>
> Signed-off-by: Philippe Cornu
> ---
> drivers/gpu/drm/stm/ltdc.c | 4 ++--
>
On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:
From: Kieran Bingham
The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.
Allow a device tree node to override the defaul
Hi Philippe,
Reviewed-by: Yannick Fertré
On 04/17/2018 01:40 PM, Philippe Cornu wrote:
> Add mode_valid() function to filter modes according to available
> pll clock values and "preferred" modes. It is particularly
> useful for hdmi modes that require precise pixel clocks.
>
> Note that "prefer
On Tuesday 13 February 2018 11:18 PM, Kieran Bingham wrote:
From: Kieran Bingham
The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.
Extend the device tree node bindings to be able
On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
>
>
> On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
> > Andrey Grodzovsky writes:
> >
> > > On 04/24/2018 03:44 PM, Daniel Vetter wrote:
> > > > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> > > > > Adding
On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote:
> malidp_pm_suspend_late checks if the runtime status is not suspended
> and if so, invokes malidp_runtime_pm_suspend which disables the
> display engine/core interrupts and the clocks. It sets the runtime status
> as suspended.
>
On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > Can we please not nack everything right away? Doesn't really motivate
> > me to show you all the various things we're doing in gpu to make the
> > dma layer work f
On Tue, Apr 24, 2018 at 03:15:24PM +0200, Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by using 'enum drm_mode_status' in t
On Tue, Apr 24, 2018 at 11:43:35PM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
> > For more fun:
> >
> > https://www.spinics.net/lists/dri-devel/msg173630.html
> >
> > Yeah, sometimes we want to disable the iommu because the on-gpu
> > pagetabl
On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > Can we please not nack everything right away? Doesn't really motivate
> > me to show you all the various things we're doing in gpu to make the
> > dma layer work f
Add optional power supplies using the description found in
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
There is a single 1v2 supply voltage named vcc12 from which cvcc12
(digital core) and avcc12 (TMDS analog) are derived because according
to this data sheet:
"cvcc12 and avcc12
This patchset adds optional power supplies to the sii902x
drm bridge driver.
Version 2:
- merge avcc12 & cvcc12 to a single vcc12 supply as suggested by
Laurent Pinchart (see discussion details in
https://patchwork.freedesktop.org/patch/216058/)
- improve error messages following Laurent Pinch
Add the optional power supplies using the description found in
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
The sii902x input IOs are not "io safe" so it is important to
enable/disable voltage regulators during probe/remove phases to
avoid damages.
Signed-off-by: Philippe Cornu
On Wed, Apr 25, 2018 at 09:30:39AM +0200, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote:
> > > Can we please not nack everything right away? Doesn't really motivate
> > > me to show you all
Hi Daniel,
Could you please check changes in the documentation,
I've added a new HDMI connector properties section, based on our discussion.
I think now other HDMI specific properties can be transferred there as well.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #1 from Michel Dänzer ---
The journalctl log file shows oopses from the evdev driver, no obvious amdgpu
related issues.
Can you attach a picture of the output from the actual kernel panic?
--
You are receiving this mail because:
Y
On 04/25/2018 08:49 AM, Daniel Vetter wrote:
On Wed, Apr 25, 2018 at 8:42 AM, Thomas Hellstrom wrote:
Hi,
On 12/07/2017 03:49 PM, Daniel Vetter wrote:
We're spotting this very rarely in CI, but have no idea. Let's add
more debug info about what's going on here.
References:
https://urldefens
[discussion about this patch, which should have been cced to the iommu
and linux-arm-kernel lists, but wasn't:
https://www.spinics.net/lists/dri-devel/msg173630.html]
On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote:
> > API from the iommu/dma-mapping code. Drivers have no busines
On Wed, Apr 25, 2018 at 09:56:43AM +0200, Thierry Reding wrote:
> And to add to the confusion, none of this seems to be an issue on 64-bit
> ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is
> used.
In the long term I want everyone to use that code. Help welcome!
Hi Philippe,
Thank you for the patch.
On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
> Add optional power supplies using the description found in
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>
> There is a single 1v2 supply voltage named vcc12 from which cvcc
Hi Tomi,
On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> I don't think it's worth it renaming the common symbols. They will change
> >> over time as omapdrm is under heavy rework, and it's painful enough
> >> without having to
It's going away.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Jordan Crouse
Cc: Nicolas Dechesne
Cc: Archit Taneja
Cc: Bjorn Andersson
Cc: Arnd Bergmann
Cc: Daniel Vetter
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ms
From: Thierry Reding
Use the new dma_iommu_detach_device() function to replace the open-coded
equivalent.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nou
From: Thierry Reding
The dma_iommu_detach_device() API can be used by drivers to forcibly
detach a device from an IOMMU that architecture code might have attached
to. This is useful for drivers that need explicit control over the IOMMU
using the IOMMU API directly.
Signed-off-by: Thierry Reding
From: Thierry Reding
Implement this function to enable drivers from detaching from any IOMMU
domains that architecture code might have attached them to so that they
can take exclusive control of the IOMMU via the IOMMU API.
Signed-off-by: Thierry Reding
---
arch/arm/include/asm/dma-mapping.h |
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page table
On Tue, Apr 24, 2018 at 02:58:10PM -0400, Felix Kuehling wrote:
> Reviewed-by: Felix Kuehling
>
> We could probably add a sanity check for n_devices to avoid user mode
> causing excessive memory allocations in the kernel. There is no good
> reason for this to be bigger than the number of GPUs in
On Wed, Apr 25, 2018 at 11:18:14AM +0200, Thierry Reding wrote:
[...]
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 8c398fedbbb6..1957938d8c9c 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2366,6 +2366,21 @@ static void arm_teardown_
On 25/04/18 12:03, Laurent Pinchart wrote:
> Could we trim down omapfb to remove support for the devices supported by
> omapdrm ?
I was thinking about just that. But, of course, it's not quite
straightforward either.
We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which
covers a
On 2018-04-24 09:55 PM, Mathieu Malaterre wrote:
> AGP mode is unstable on PowerPC. Symptoms are generally of the form:
>
> [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec
>
> Reviewed-by: Christian König
> Signed-off-by: Mathieu Malaterre
> ---
> drivers/gpu/drm/rad
Hi Tomi,
On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote:
> On 25/04/18 12:03, Laurent Pinchart wrote:
> > Could we trim down omapfb to remove support for the devices supported by
> > omapdrm ?
>
> I was thinking about just that. But, of course, it's not quite
> straightforward eit
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #50 from i...@yahoo.com ---
If this `messages` file is from the failed apitrace crash recording, then maybe
you should try again.
In the previous file I could see that SysRq has been used. Since the first
command you use also kills a
On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
> and linux-arm-kernel lists, but wasn't:
> https://www.spinics.net/lists/dri-devel/msg173630.html]
>
> On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Re
From: Thierry Reding
Use the new dma_iommu_detach_device() function to replace the open-coded
equivalent.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nou
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page table
From: Thierry Reding
The dma_iommu_detach_device() API can be used by drivers to forcibly
detach a device from an IOMMU that architecture code might have attached
to. This is useful for drivers that need explicit control over the IOMMU
using the IOMMU API directly.
Signed-off-by: Thierry Reding
From: Thierry Reding
Implement this function to enable drivers from detaching from any IOMMU
domains that architecture code might have attached them to so that they
can take exclusive control of the IOMMU via the IOMMU API.
Signed-off-by: Thierry Reding
---
Changes in v2:
- fix compilation
ar
1 - 100 of 199 matches
Mail list logo
