On 12/07/16 16:46, Daniel Vetter wrote:
>> > This implementation is a hack in the first place. The code will be
>> > removed when DRM has a proper generic connector support.
> Hm, what's this generic drm connector thing you talk about? What's it for?
> Asking since I haven't seen that yet nor heard
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/f1657934/attachment.html>
On 12/07/2016 09:53 PM, Dave Airlie wrote:
Yeah, already done.
>>>
>>> Just tried to build drm-next/mxsfb I get:
>>>
>>> drivers/built-in.o: In function `mxsfb_probe':
>>> core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
>>> core.c:(.text+0x9cff0): undefined reference to `drm_
Select DRM_PANEL, since the MXSFB driver depends on it. Otherwise,
we get the following error when compiling:
drivers/built-in.o: In function `mxsfb_probe':
core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
drivers/b
Currently the reference for the dmabuf->obj is incremented for the
dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
interface), but is released in drm_gem_dmabuf_release() (the lowlevel
handler). Improve the symmetry of the dmabuf->obj ownership by acquiring
the reference in drm_
Hi Dave, first set of fixes for drm-next/v4.10-rc1.
BR,
Jani.
The following changes since commit e9cbc4bd0140e1d4e0172e2fe8fe07ba278e5980:
drm/i915: Update DRIVER_DATE to 20161121 (2016-11-21 09:45:03 +0100)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-int
On Wednesday, December 7, 2016 4:19:52 PM CET Benjamin Gaignard wrote:
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> +
Hi Eric,
On Wednesday 07 Dec 2016 11:16:32 Eric Anholt wrote:
> Maxime Ripard writes:
> > [ Unknown signature status ]
> >
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers
On 12/07/2016 08:22 PM, Stefan Agner wrote:
> On 2016-12-06 04:36, Marek Vasut wrote:
>> On 12/06/2016 08:53 AM, Daniel Vetter wrote:
>>> On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote:
On 2 December 2016 at 04:02, Marek Vasut wrote:
> Hi,
>
> as asked by Daniel, I co
On Tue, 06 Dec 2016, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote:
>> > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
>> > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel
We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In
order to avoid a flag day the plan is to only support uGPU initially and
transition to older ASICs gradually.
The DC component has received extensive testing
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ab5fcbbc/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/0407df2c/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161207/b9b4e43a/attachment.html>
nts/20161207/74dc0fa3/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/e22b1e1e/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/521adfc8/attachment.html>
On Thu, Dec 01, 2016 at 09:29:09PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
>
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: stable at vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off
On Fri, Dec 02, 2016 at 04:01:28PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>
> Until commit b1cb1bd29189 ("drm/i915/dsi: update re
On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy wrote:
> By comparison, the same use-cases (fbcon and fb-test) under the same
> big-endian kernel do *not* show the same problem with nouveau driving a
> PCIe 7600GT card, which led me to believe it was HDLCD-specific.
Just to randomly insert info her
DEFAULT_RATELIMIT_BURST); \
> > if (__ratelimit(&_rs)) \
> > - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ ## level, \
> > -__func__, "", fmt, ##args); \
> > + _DRM_DEBUG(DRM_UT_ ## category, fmt, ##args); \
> > })
> >
> > /**
> > @@ -268,21 +313,24 @@ struct dma_buf_attachment;
> > * \param arg arguments
> > */
> > #define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, args...) \
> > - DEV__DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> > #define DRM_DEBUG_RATELIMITED(fmt, args...) \
> > - DRM_DEV_DEBUG_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRIVER, fmt, ##args)
> > #define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...) \
> > - DRM_DEV_DEBUG_DRIVER_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, KMS, fmt, ##args)
> > #define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
> \
> > - DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, PRIME, fmt, ##args)
> > #define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...)\
> > - DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
> >
> > /* Format strings and argument splitters to simplify printing
> > * various "complex" objects
>
> Since I brought up some changes for the debug stuff itself, would it make
> sense to split that from the general macro rework for all the non-debug
> output, and merge that first?
>
> Another thing to look into: I think it'd be good to move all the print
> definitions into drm_print.[hc], since drmP.h is a mess, and drm_drv.c not
> really the right place. That would then also allow us to easily document
> all the variants, and put something like the intro message for this commit
> into the overview DOC: section.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ff4a879d/attachment-0001.html>
On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>> software limitation, not a hardware one though.
>>
>> L
On 07/12/16 06:39 PM, Alexandre Courbot wrote:
> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>> software limitation, not a hardware one though.
>
> Looking at the trace I wonder - is the limitation in Nouveau o
On Wed, Dec 07, 2016 at 04:57:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> > Under a big-endian kernel, colours on the framebuffer all come out a
> > delightful shade of wrong, since we fail to take the reversed byte
> > order into account. Fort
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
> That's right -- nouveau currently requires 4k page sizes to work. This is a
> software limitation, not a hardware one though.
Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>
>
> On Dec 1, 2016 5:13 PM, "Jeremy Linton
This is still missing corresponding documentation changes, and I haven't
moved anything to drm_print.h yet, as suggested.
Sending out with a few functional improvements first to get agreement
before documenting anything (changes summarised in v2: section below)
In particular, affecting the output
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/3596769f/attachment.html>
On Wed, Dec 07, 2016 at 04:54:40PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > > On Wed, Dec 07, 2016 at 12
t.h Daniel Vetter 2016-08-29 68 *
@count: number of valid properties, must be less than or equal to
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29 69 *
DRM_OBJECT_MAX_PROPERTY.
:: The code at line 61 was first introduced by commit
:: 7520a277d97be6e8a8ec038bb5ed01f40d4f9aeb drm: Extract
drm_framebuffer.[hc]
:: TO: Daniel Vetter
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/92bb6381/attachment.gz>
-)
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/4fb87cc8/attachment-0001.html>
On 2016-12-07 16:59, Stefan Agner wrote:
> On 2016-12-07 16:49, Marek Vasut wrote:
>> On 12/08/2016 01:27 AM, Stefan Agner wrote:
>>> The DRM subsystem specifies the pixel clock polarity from a
>>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>>> the controller drives the data on pix
Hi Benjamin,
On Wednesday 07 Dec 2016 15:57:49 Benjamin Gaignard wrote:
> 2016-12-07 15:35 GMT+01:00 Laurent Pinchart:
> > On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> >> Allow generic frame-buffer to provide a default
> >> get_fb_unmapped_area function if specific devices need it.
On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > The check to reject combinations of multiple rotation angles is overly
> > > restrictive and has th
On 2016-12-07 16:49, Marek Vasut wrote:
> On 12/08/2016 01:27 AM, Stefan Agner wrote:
>> The DRM subsystem specifies the pixel clock polarity from a
>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>> the controller drives the data on pixel clocks falling edge.
>> That is the controll
Hi Dave,
I did not rebase it, but it should still merge fine. This time with a
tag...
Some fixes and cleanup, mainly around fbdev emulation. It also adds a
new module parameter which allows to specify the color depth/bpp for
the fbdev emulation (like the IMX DRM driver).
There have been some fix
Adds IPU client devices for the SMFC and IC task units.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-common.c | 87 +++--
include/video/imx-ipu-v3.h | 3 ++
2 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/
To allow for IPU clients containing multiple ports, they are no longer
a single port node name, but have a name of the format
"ipu_". So we can no longer use of_graph_get_port_by_id()
to lookup the client node.
Create the function of_get_ipu_client_node() that looks up the client
node by node name
Adds an enumeration of the major IPUv3 subunits. Provide that info
in struct ipu_client_platformdata to more easily determine the IPU
client type.
Signed-off-by: Steve Longerbeam
---
include/video/imx-ipu-v3.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/video/
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.
On the sabreauto, two analog video inputs are routed to the ADV7180,
composite on Ain1, and composite on Ain3. Those inputs are defined
via inputs and input-names under the ADV7180 node. The AD
Add pinctrl groups for both GPT input capture channels.
Signed-off-by: Steve Longerbeam
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 944a4f
The reset pin to the port expander chip (MAX7310) is controlled by a gpio,
so define a reset-gpios property to control it. There are three MAX7310's
on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for
their reset. Since all can't acquire the same pin, assign it to max7310_b,
tha
The sabreauto uses a steering pin to select between the SDA signal on
i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control
this steering pin. Idle state of the i2cmux selects SPI NOR. This is not
a classic way to use i2cmux, since one side of the mux selects something
other than a
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Until the OV5652 sen
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI C
From: Philipp Zabel
This patch adds the IPU subunit devices involved in video capture and
image conversion, and defines all the possible hardware connections
between them via OF graphs.
External to the IPU:
Video input multiplexers are defined that multiplex inputs from camera
sensors and the M
To allow for IPU client devices that are composed of more than one
port for input and output (SMFC and IC), change the nodes from being
a single port node to nodes that can contain multiple ports. Rename
the nodes to use the following format: "ipu_".
The IPUv3 driver will then need to lookup the c
Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.
Signed-off-by: Steve Longerbeam
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..e01e5d5 1
Hi Philipp, Sascha, Shawn, et al,
I've been working for the past few months on a media driver for i.MX.
In addition to the media entities for the IPU-external units involved
with video capture (video mux and MIPI CSI-2 receiver), I've created
media entities for the IPU CSI, SMFC, and IC subunits.
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong, since we fail to take the reversed byte
> order into account. Fortunately, the HDLCD has a control bit to make it
> automatically byteswa
On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > > The check to reject combin
On 07/12/16 16:42, Robin Murphy wrote:
> On 07/12/16 15:57, Daniel Vetter wrote:
>> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>>> Under a big-endian kernel, colours on the framebuffer all come out a
>>> delightful shade of wrong, since we fail to take the reversed byte
>>> order
On 6 December 2016 at 05:12, Jonathan Gray wrote:
> On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote:
>> On 1 December 2016 at 04:18, Jonathan Gray wrote:
>> > DRI devices on OpenBSD are not in their own directory. They reside in
>> > /dev with a large number of statically generated
On 07/12/16 15:57, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>> Under a big-endian kernel, colours on the framebuffer all come out a
>> delightful shade of wrong, since we fail to take the reversed byte
>> order into account. Fortunately, the HDLCD has a c
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> Allow generic frame-buffer to provide a default
> get_fb_unmapped_area function if specific devices need it.
>
> Usually this function is defined in architecture directories but
> define it here ma
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:50 Benjamin Gaignard wrote:
> drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU.
> Use a new DRM_VM to define when drm_vm.c in needed.
>
> stub drm_legacy_vma_flush() to avoid compilation issues
>
> version 4:
>
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove
Hi Thomas,
in commit 59bd00c8 (Blackfin: fix framebuffer mmap bug for nommu) you
have introduce
get_fb_unmapped_area() for blackfin architecture.
I'm proposing a patch to have a default function in fbmem which
slightly does the same.
Do you think is new function could also fit with blackfin arch
The DRM subsystem specifies the pixel clock polarity from a
controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
the controller drives the data on pixel clocks falling edge.
That is the controllers DOTCLK_POL=0 (Default is data launched
at negative edge).
Also change the data enable logic t
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
> Add the vga-bridge node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Go
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:45:11 Bartosz Golaszewski wrote:
> 2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required t
On 12/06/16 15:28, Dan Carpenter wrote:
> Hello Jyri Sarha,
>
> The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> driver" from Oct 31, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc()
> warn
Some SoC without MMU have display driver where a drm/kms driver
could be implemented.
Before doing such kind of thing drm/kms must allow to use mmuless devices.
This patch propose to remove MMU configuration flag and add a cma helper
function to help implementing mmuless display driver
version 4:
On Wednesday, 2016-12-07 16:19:52 +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add a
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
>
> Fix this by relaxing the check to ignore values
On Mon, 5 Dec 2016 17:50:13 -0800
Florian Fainelli wrote:
> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
> >
> > Signed-off-by: Boris Brezillon
> > ---
>
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/d
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong,
So you are saying that wrong is only a 1 bit value?
> since we fail to take the reversed byte
> order into account. Fortunately, the
2016-12-07 15:35 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
>> Allow generic frame-buffer to provide a default
>> get_fb_unmapped_area function if specific devices need it.
>>
>> Usually this function is de
On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
>
>
> å¾æç iPad å³é
>
> > Thierry Reding æ¼ 2016å¹´12æ6æ¥
> > ä¸å11:46 寫éï¼
> >
> >> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> >> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> >> s
On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > The check to reject combinations of multiple rotation angles is overly
> > restrictive and has the side-effect of also failing any rotation value
> > which consists onl
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.
v2. Make it build. Oops.
Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
non-KMS driver")
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off
On Wed, Dec 07, 2016 at 04:32:44PM +0200, Laurent Pinchart wrote:
> Hi Benjamin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> > Some SoC without MMU have display driver where a drm/kms driver
> > could be implemented.
> >
> > Before doing such kin
On Wed, Dec 07, 2016 at 04:20:34PM +0200, Jyri Sarha wrote:
> On 12/06/16 15:28, Dan Carpenter wrote:
> > Hello Jyri Sarha,
> >
> > The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> > driver" from Oct 31, 2016, leads to the following static checker
> > warning:
> >
> > driv
Under a big-endian kernel, colours on the framebuffer all come out a
delightful shade of wrong, since we fail to take the reversed byte
order into account. Fortunately, the HDLCD has a control bit to make it
automatically byteswap big-endian data; let's use it as appropriate.
Signed-off-by: Robin
2016-12-07 15:25 GMT+01:00 Laurent Pinchart :
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>>
On Wed, Dec 07, 2016 at 07:25:51AM +0100, Johannes Berg wrote:
> On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
>
> > It seems that there should be a better way to do it,
> > but this works too.
>
> In some cases there might be:
>
> > --- a/drivers/s390/virtio/Makefile
> > +++ b/dr
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin
>>> wrote:
That's right -- nouveau currently requires 4k page sizes to work. T
On Wed, Dec 07, 2016 at 04:12:07PM +0200, Ville Syrjälä wrote:
>On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
>> The check to reject combinations of multiple rotation angles is overly
>> restrictive and has the side-effect of also failing any rotation value
>> which consists only
Exposing rb swapped (or other swizzled) formats for rendering would
involve swizzing in the pixel shader. This is not the case at the
moment, so reject requests for creating such surfaces.
(GPUs that need an extra resolve step anyway due to multiple pixel
pipes, such as gc2000, might also do this
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.
Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
non-KMS driver")
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
---
--
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/d7e15474/attachment.sig>
On 05.12.2016 21:13, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:40PM +0200, Mikko Perttunen wrote:
>> From: Arto Merilainen
>>
>> Add a set of falcon helper routines for use by the tegradrm client drivers
>> of the various falcon-based engines.
>>
>> The falcon is a microcontroller th
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
>
> Fix this by relaxing the check to ignore values
On 2016å¹´12æ06æ¥ 23:41, Michael S. Tsirkin wrote:
> __CHECK_ENDIAN__ isn't on by default presumably because
> it triggers too many sparse warnings for correct code.
> But virtio is now clean of these warnings, and
> we want to keep it this way - enable this for
> sparse builds.
>
> Signed-off
On Wed, Dec 07, 2016 at 02:13:23PM +0100, Daniel Vetter wrote:
> vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> fare similarly.
>
> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
> non-KMS driver")
> Cc: Michel Dänzer
> Cc: Alex Deucher
> Cc
https://bugzilla.kernel.org/show_bug.cgi?id=189451
--- Comment #4 from Raffaele ---
Created attachment 247081
--> https://bugzilla.kernel.org/attachment.cgi?id=247081&action=edit
Second error message with 4.8.10
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=189451
--- Comment #3 from Raffaele ---
I have a new kernel and a new error message
Kernel 4.8.10-300.fc25.x86_64
New error message. This time UVD seems to be initialized fine, but there is
another error afterwards
[ 20.447459] [drm:uvd_v1_0_start
On 7 December 2016 at 11:51, Stefan Agner wrote:
> Hi Dave,
>
> On 2016-11-28 18:55, Stefan Agner wrote:
>> Hi Dave,
>>
>> Some fixes and cleanup, mainly around fbdev emulation. It also adds a
>> new module parameter which allows to specify the color depth/bpp for
>> the fbdev emulation (like the
The check to reject combinations of multiple rotation angles is overly
restrictive and has the side-effect of also failing any rotation value
which consists only of reflections.
Fix this by relaxing the check to ignore values which contain no
rotation flags.
Fixes: 6e0c7c3358d4 ("drm/atomic: Reje
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
> releases and acquires this lock. This causes a sparse warning. Add
> appropriate annotations for sparse context checking.
>
> Signed-off-by: Michael S. Tsirkin
> -
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> When virtio_gpu_free_vbufs exits due to list empty, it does not
> drop the free_vbufs lock that it took.
> list empty is not expected to happen anyway, but it can't hurt to fix
> this and drop the lock.
>
> Signed-off-by: Michael S. Tsirkin
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_cmd_transfer_to_host_2d expects x and y
> parameters in LE, but virtio_gpu_primary_plane_update
> passes in the CPU format instead.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
>
Acked-by: Benjamin Gaignard
2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> Do not process update requests with unmodified parameters.
>
> Since the HQVDP command queue is limited to 2, we shall take care of
> not posting unneeded commands, which would abusively fill the command
> queue leading to
Acked-by: Benjamin Gaignard
2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> When a plane is enabled, after having been disabled, do not reload XP70
> firmware again, but only register VTG again
>
> Signed-off-by: Fabien Dessenne
> ---
> drivers/gpu/drm/sti/sti_hqvdp.c | 8 ++--
> 1 file chan
2016-12-07 Daniel Vetter :
> On Tue, Dec 06, 2016 at 03:47:17PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Instead of dealing with crtc details inside drm_atomic.c we should
> > just export a function that creates a new crtc fence for us and
> > use that.
> >
> > Suggested-
Hi Dave,
If it's not too late, one last regression fix for amdgpu.
The following changes since commit ab7cd8d83e5dba13027de66f1b008b08b30b71a4:
Merge tag 'drm-intel-fixes-2016-12-01' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-04 06:31:26
+1000)
are available in t
Hi Rob,
On Tuesday 06 Dec 2016 15:15:50 Rob Herring wrote:
> On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> > Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> > tree binding by itself but is meant to be referenced by platform device
> > tree bindings, a
Hello,
On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or relia
2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> THS8135 is a configurable video DAC. Add DT bindings for this chip and
> use the dumb-vga-dac driver for now as no configuration is required to
> make it work.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> .../bindings/display/bridge/ti,ths8135.
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.ph
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 67
1 file changed
1 - 100 of 130 matches
Mail list logo
