Hi Laurent,
On 2018-04-04 00:11, Laurent Pinchart wrote:
>> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
>> +{
>> +struct dma_device *dma_dev = dmm->wa_dma_chan->device;
>> +struct dma_async_tx_descriptor *tx;
>> +enum dma_status status;
>> +dma_cookie_
Am 09.04.2018 um 17:17 schrieb Jean-Marc Valin:
On 04/09/2018 05:42 AM, Christian König wrote:
Backporting all the detection logic is to invasive, but you could just
go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
other code path.
Just look out for "#ifdef CONFIG_SWIOTLB"
Am 09.04.2018 um 23:45 schrieb Manasi Navare:
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
Adding dri-devel, which I should've included from the start.
On 2018-04-09 03:56 PM, Harry Wentland wrote:
=== What is ad
On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote:
> On 2018-04-09 13:17, Russell King - ARM Linux wrote:
> > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
> >> During this, I found that the tda998x driver never sets the format in
> >> the connector display_info. Thus, the
Am 09.04.2018 um 23:06 schrieb Laura Abbott:
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms.
Actually that isn't correct.
Could be that we haven't upstreamed KF
On 2018-04-09 14:02, Russell King - ARM Linux wrote:
> On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote:
>> On 2018-04-09 13:17, Russell King - ARM Linux wrote:
>>> On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
During this, I found that the tda998x driver never sets t
Hi Daniel,
On Mon, 2018-04-09 at 11:17 +0200, Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> > Hi Daniel,
> >
> > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> > > > Hi Dani
On 04/09/2018 05:42 AM, Christian König wrote:
> Backporting all the detection logic is to invasive, but you could just
> go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
> other code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
Do you mean ju
Hi Daniel,
On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> > Hi Daniel, all,
[snip]
> > Ok it was quite some time ago so I forgot about that completely.
> > I really made one trivial change in xf86-video-armada:
> >
On Fri, Apr 06, 2018 at 04:33:21PM +0300, Laurent Pinchart wrote:
> On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote:
> > From: Sergei Shtylyov
> >
> > Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> > the next patch...
> >
> > Based on the original (and large) pat
On 2018-04-09 14:51, Laurent Pinchart wrote:
> Hi Peter,
>
> On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
>> On 2018-04-04 14:35, Peter Rosin wrote:
>>> On 2018-04-04 11:07, Laurent Pinchart wrote:
On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> On Wed, Apr 4,
Hi Archit,
Thanks a lot for your reply.
On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:
> On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
>> I'm having issues with the GPU/DRM drivers on a msm8916 based platform
>> which is very similar to the DragonBoard 410c. In my setup, a DSI
Hi,
On 2018년 04월 09일 15:27, Andrzej Hajda wrote:
> The driver can work with or without extcon framework, but if extcon is
> build as module, sii8620 should be build as module as well.
>
> Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic
> to detect MHL")
> Reported-b
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 encoder.
Implementation of the CEC part is separate to allow independent CEC
implementations, or independent HDMI implementations (since
On 2018-04-04 14:35, Peter Rosin wrote:
> On 2018-04-04 11:07, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
>>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
>
On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
> During this, I found that the tda998x driver never sets the format in
> the connector display_info. Thus, the atmel-hlcdc driver fails to select
> output format. Since I had similar problems with ds90c185 lvds encoder
> I added patches
On Fri, Apr 06, 2018 at 04:28:17PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Friday, 6 April 2018 16:08:06 EEST Jacopo Mondi wrote:
> > From: Sergei Shtylyov
> >
> > Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in
> > the next patch
The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
onto the same die. Add support for the TDA9950 CEC engine to the
TDA998x driver.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/Kconfig | 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 195
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
but is also integrated into HDMI transceivers such as the TDA9989 and
TDA19989.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol. The driver just has to read and write
the
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if the encoder and connector provided by the tda998x driver
is in use in which case the connec
HLCD Controller DRM",
- .date = "20141504",
+ .date = "20180409",
.major = 1,
- .minor = 0,
+ .minor = 1,
};
static int atmel_hlcdc_dc_drm_init(struct platform_device *pdev)
--
2.11.0
___
dri-devel
This patchset add support for ti based sn65dsu86 bridge chip,
which takes dsi video mode signal as input and coverts it
to eDP signal as output.
Current driver uses device tree entries to get the required
gpio pin numbers that needs to be configured to enable the
DSI reciever and eDP connector par
Useful for beating cases where an output mode selection heuristic
fails.
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
b/Documentati
When the of-graph points to a tda998x-compatible HDMI encoder, register
as a component master and bind to the encoder/connector provided by
the tda998x driver.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 81 --
drivers/gpu/drm/atmel-hlcdc/atmel_
Add the optional calibration gpio for integrated TDA9950 CEC support.
This GPIO corresponds with the interrupt from the TDA998x, as the
calibration requires driving the interrupt pin low.
Reviewed-by: Rob Herring
Signed-off-by: Russell King
---
Documentation/devicetree/bindings/display/bridge/t
On 2018-04-09 13:17, Russell King - ARM Linux wrote:
> On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
>> During this, I found that the tda998x driver never sets the format in
>> the connector display_info. Thus, the atmel-hlcdc driver fails to select
>> output format. Since I had simi
Always disable and clear interrupts at probe time to ensure that the
TDA998x is in a sane state. This ensures that the interrupt line,
which is also the CEC clock calibration signal, is always deasserted.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c
Hi!
I naively thought that since there was support for both nxp,tda19988 (in
the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
But it wasn't, so I started looking around, and found some missing
pieces in the tilcdc driver. A "stole" some things and made it work
for my use cas
Move the mutex, waitqueue, timer and detect work initialisation early
in the driver's initialisation, rather than being after we've registered
the CEC device.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 11 +--
1 file changed, 5 insertions(
We no longer use the CEC client to access the CEC part itself, so we can
move this later in the initialisation sequence.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/dri
If tda998x_get_audio_ports() fails, and we requested the interrupt, we
fail to free the interrupt before returning failure. Rework the failure
cleanup code and exit paths so that we always clean up properly after an
error, and always propagate the error code.
Acked-by: Hans Verkuil
Signed-off-by
Start list of actual chips compatible with "lvds-encoder".
Reviewed-by: Laurent Pinchart
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings
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.
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 53 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c |
On 04/06/2018 09:57 PM, Dongwon Kim wrote:
On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
Hi,
I fail to see any common ground for xen-zcopy and udmabuf ...
Does the above mean you can assume that xen-zcopy and udmabuf
On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. The vla in reg_write_range is based on the length of data
> passed. The one use of a non-constant size for this range is bounded by
> the size b
On 04/09/2018 11:51 AM, Daniel Vetter wrote:
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
On 04/05/2018 06:44 PM, Daniel Vetter wrote:
There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trø
From: Fengguang Wu
PTR_ERR should normally access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 742243a44a73 ("drm: xlnx: pl_disp: Use xlnx pipeline calls")
CC: Hyun Kwon
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
---
tree: h
Add the 3 optional power supplies using the exact description
found in the document named
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/sii902x.c | 39 +++
1 file changed, 35 insertions(
This patchset adds the 3 optional power supplies to the sii902x
drm bridge driver.
Philippe Cornu (2):
dt-bindings/display/bridge: sii902x: add optional power supplies
drm/bridge: sii902x: add optional power supplies
.../devicetree/bindings/display/bridge/sii902x.txt | 3 ++
drivers/gpu/drm
Add the 3 optional power supplies using the exact description
found in the document named
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
Signed-off-by: Philippe Cornu
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
1 file changed, 3 insertions(+)
diff -
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 5d404d3139a4624892a12683240abfae931ee849
commit: 2852a36199784540a872f42fa6dc7d8d51eee0d8 [43/120] drm/amd/display: Add
vline IRQ programming for DCN
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 24110c70630998dc83da23cae910a9538f54ef64
commit: 0547606296e739e875a294d786233bf2e6680421 [12/33] drm/amd/display:
Refactor FreeSync module
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3
On 2018-04-08 09:36, Archit Taneja wrote:
Hi Abhinav,
Thanks for posting this driver. Some comments below.
On Saturday 07 April 2018 12:36 PM, Abhinav Kumar wrote:
From: Archit Taneja
Add support for truly dual DSI video mode panel
panel used in MSM reference platforms >
Signed-off-by: Archi
Boris Brezillon writes:
> Hello,
>
> This is an attempt at simplifying the async page flip handling in VC4
> in order to get rid of vc4_queue_seqno_cb() and its dependencies and
> rely on fences instead.
>
> The reason I'm sending this as an RFC is because I'm pretty sure we can
> put some of the
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 5d404d3139a4624892a12683240abfae931ee849
commit: 9c1f5ab7dcce1b9ddb9321b328c5445238450671 [95/120] drm/amd/display: add
delay between panel pwr off to on.
config: i386-allyesconfig (attached as .config)
compiler: gcc-7
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm283x.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9d293decf8d3..869bf350d42
The GPU subsystem node was a workaround to have a central device to
bind V3D and display to. Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf94d139..2
https://bugs.freedesktop.org/show_bug.cgi?id=104216
--- Comment #23 from Germano Massullo ---
Trying to get some answers from Mozilla developers
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c17
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c18
--
You are receiving this mail bec
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
>
> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> > === What is adaptive sync and VRR? ===
> >
> > Adapti
On Tue, Apr 03, 2018 at 03:29:19PM +0200, Maxime Ripard wrote:
> The MBUS clock is used by the MBUS controller, so let's export it so that
> we can use it in our DT node.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/clk/sunxi-ng/ccu-sun5i.h | 4
> include/dt-bindings/clock/sun5i-cc
On Tue, Apr 03, 2018 at 12:15:25PM +0200, Lukasz Majewski wrote:
> This commit adds support for AUO's 7.0" display.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../bindings/display/panel/auo,g070vvn01 | 30 +
.txt
> drivers/gpu/drm/panel/panel-simple.c
On 2018-04-09 08:28, Jordan Crouse wrote:
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise it leads to silent timeouts increasing display
turn ON time.
Signed-off-by: Abhinav Kumar
---
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to t
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
This was a little hard to figure out but I think 32 should be a
c
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms. Switch to a constant size array
instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
d
Signed-off-by: Eric Anholt
Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace")
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..7c95ed5c5cac 100644
--- a/dr
https://bugs.freedesktop.org/show_bug.cgi?id=104597
Timothy Arceri changed:
What|Removed |Added
CC||c...@fuckyouprius.com
--- Comment #17
On Fri, Mar 30, 2018 at 07:18:19PM +0200, Sebastian Reichel wrote:
> Merge "rotation" property description into common panel
> binding.
>
> Suggested-by: Rob Herring
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/display/panel/panel-common.txt | 12
>
> D
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #19 from MirceaKitsune ---
(In reply to Alex Deucher from comment #18)
> Those parameters are not used on your chip.
That would be quite something, since after setting them I've clearly seen an
enormous difference. I will investigat
Daniel J Blueman writes:
> Hi Eric et al,
>
> In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B
> on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4,
> tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y
> < 0) [1], which therefore seems false
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #18 from Alex Deucher ---
(In reply to MirceaKitsune from comment #17)
> I will continue trying different values and seeing how tweaking them changes
> the issue. Please let me know what you think.
Those parameters are not used on y
Adding dri-devel, which I should've included from the start.
On 2018-04-09 03:56 PM, Harry Wentland wrote:
> === What is adaptive sync and VRR? ===
>
> Adaptive sync has been part of the DisplayPort spec for a while now and
> allows graphics adapters to drive displays with varying frame timings.
Daniel J Blueman writes:
> During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
> freed leading to leaking many 128B allocations. Fix the memory leak by
> releasing it at teardown time.
Reviewed, added a Fixes tag, and pushed to drm-misc-fixes. Thanks!
signature.asc
Descri
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #17 from MirceaKitsune ---
I have a very important preliminary result: Today I tested the last amdgpu
parameters on the list, and seem to have found a set that greatly mitigates the
problem. Those parameters have given me up to 144 m
On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
> If the bridge changes the bus format, allow this to be described in
> the bridge, instead of providing false information about the bus
> format of the connector or panel.
I guess this is dead, but I'll comment here anyway because this
On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen wrote:
> Hi Rob,
>
> On 23/03/18 03:23, Rob Herring wrote:
>
>>> Ok, I think the description was a bit unclear. So, the driver can do
>>> this just fine, it can reserve hw planes dynamically when needed. The
>>> problem is the userspace.
>>>
>>> When
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clip
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0
https://bugzilla.kernel.org/show_bug.cgi?id=199319
zxvfxwing (zxvfxw...@protonmail.com) changed:
What|Removed |Added
CC||zxvfxw...@protonmai
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
>
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dsi/dsi
This patch clarifies the adjusted_mode documentation
for bridges.
Signed-off-by: Philippe Cornu
Signed-off-by: Laurent Pinchart
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge:
On 04/05/2018 10:44 AM, Daniel Vetter wrote:
There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trø
Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
1 file changed, 29 insertions(+), 213 deletions(-)
diff --git
Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 15 +++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 --
drivers/gpu/drm/msm/dsi/dsi_host.c | 218 ++
This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now replaced with the corresponding
helper function.
V3:
Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #7 from Zach Tibbitts ---
This issue is also persisting with the latest update to Civ VI, including the
Rise and Fall expansion.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #80 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #79)
> Hi Jerome
>
> Not really, I am waiting for some feedback from Andrey.
>
>
> With the env. variable:
>
> GALLIUM_DDEBUG=flu
On Monday 09 April 2018 04:28 PM, Daniel Mack wrote:
Hi Archit,
Thanks a lot for your reply.
On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:
On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very s
Hi Peter,
On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
> On 2018-04-04 14:35, Peter Rosin wrote:
> > On 2018-04-04 11:07, Laurent Pinchart wrote:
> >> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> >>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
> On
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Sergey Kondakov (virtuous...@gmail.com) changed:
What|Removed |Added
CC||virtuous...@gmai
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #6 from Jason Playne ---
Can Confirm that this problem still persists on Kernel 4.16.1 and Mesa 18
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
On 9 April 2018 at 11:24, Emil Velikov wrote:
> On 9 April 2018 at 09:26, Daniel Vetter wrote:
>
>>> - point drm_device::dev to the parent of the virtio_device
>>> The biggest hack imaginable, if even possible.
>>
>> What would/could break if we do this? Why is this a hack?
>
> It _feels_ very h
https://bugzilla.kernel.org/show_bug.cgi?id=199319
--- Comment #10 from Mike Lothian (m...@fireburn.co.uk) ---
I should add this is 4.16-rc7 (agd5f's 4.18-wip branch) Qt 5.10, KDE frameworks
5.44, Plasma 5.12.4, Xorg 1.19.5 using the modesetting DDX (I'll try the Intel
& AMDGPU DDXs tonight.
--
https://bugzilla.kernel.org/show_bug.cgi?id=199319
Mike Lothian (m...@fireburn.co.uk) changed:
What|Removed |Added
CC||m...@fireburn.co.uk
https://bugs.freedesktop.org/show_bug.cgi?id=105950
--- Comment #2 from Bas Vermeulen ---
Created attachment 138698
--> https://bugs.freedesktop.org/attachment.cgi?id=138698&action=edit
Patch for dispatch_packet endianness fix
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=105950
--- Comment #1 from Bas Vermeulen ---
Created attachment 138697
--> https://bugs.freedesktop.org/attachment.cgi?id=138697&action=edit
Patch for si_vgt_param_key endian fix
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105589
Marta Löfstedt changed:
What|Removed |Added
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@
https://bugs.freedesktop.org/show_bug.cgi?id=105950
Bug ID: 105950
Summary: radeonsi: OpenCL not working correctly on a big endian
machine
Product: Mesa
Version: 17.3
Hardware: PowerPC
OS: Linux (All)
On 9 April 2018 at 09:26, Daniel Vetter wrote:
>> - point drm_device::dev to the parent of the virtio_device
>> The biggest hack imaginable, if even possible.
>
> What would/could break if we do this? Why is this a hack?
It _feels_ very hacky to reach/store the parent of the _parent_ device giv
On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote:
> On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote:
> > Same on the mandatory/optional VCC supply thing. Let's try to make
> > next version the final one. If the optional property with the dummy
> > regulator doesn't satisfy
Hi Daniel,
On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> >> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> >>> The mode and ajusted
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'
https://bugzilla.kernel.org/show_bug.cgi?id=199319
--- Comment #8 from m...@rainer-finke.de ---
The random flickering every 30 seconds is the same from my point of view. What
is different on my setup is that Plasma-Wayland with night shift enabled with a
changed color flickers with every mouse mov
Hi Rob,
On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote:
> On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > no
On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > > should never be modif
On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> > > Hi Daniel, all,
>
> [snip]
>
> > > Ok it was quite some time ago so I forgot about th
1 - 100 of 141 matches
Mail list logo
