On Tue, Nov 14, 2017 at 08:32:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to provide a device wide .mode_valid() hook in addition to
> the already existing crtc/encoder/bridge/connector hooks. This can be
> used to validate device/driver wide constraings without havin
On Tue, Nov 14, 2017 at 08:32:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We never support certain mode flags etc. Reject those early on in the
> mode_config.mode_valid() hook. That allows us to remove some duplicated
> checks from the connector .mode_valid() hooks, and it guarante
On Mon, Nov 20, 2017 at 09:01:07AM +0100, Daniel Vetter wrote:
> On Tue, Nov 14, 2017 at 08:32:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We never support certain mode flags etc. Reject those early on in the
> > mode_config.mode_valid() hook. That allows us to remove some du
On Tue, Nov 14, 2017 at 11:05:55PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 14, 2017 at 02:31:11PM -0500, Alex Deucher wrote:
> > On Tue, Nov 14, 2017 at 2:10 PM, Ville Syrjala
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add the missing kerneldoc for modifiers and modifier_count.
> > >
> >
From: Thierry Reding
kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it doesn't
actually do that. Instead, drivers are supposed to explicitly call the
drm_atomic_normalize_zpos() function. Change the kerneldoc comm
Hi Noralf,
On Thu, 2017-11-16 at 21:11 +0100, Noralf Trønnes wrote:
> Den 16.11.2017 09.14, skrev Shawn Guo:
> >
> > On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote:
> > >
> > > This patchset adds drm_fb_cma_fbdev_init/fini() functions that replaces
> > > drm_fbdev_cma_init/fini()
platform_get_irq_byname() can fail here and we must check its return
value.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/sti/sti_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 30f02d2..adabd41 100644
--- a/
Hi,
I'm trying to get Android graphics working on i.MX6 using upstream
versions:
Kernel 4.14
Mesa: mesa-17.3.0-rc2
Libdrm: libdrm-2.4.88
drm_hwcomposer (git head)
gbm_gralloc (git head from git://github.com/robherring)
I want to run on Android 5, which only has HWC1, the code for that i
Quoting Harry Wentland :
On 2017-11-10 05:31 PM, Gustavo A. R. Silva wrote:
Make use of the swap macro instead of _manually_ swapping values
and remove unnecessary variable swap.
This makes the code easier to read and maintain.
This code was detected with the help of Coccinelle.
Signed-off-
Hi Thierry,
> On Sat, Oct 21, 2017 at 12:06:09AM +0200, Lukasz Majewski wrote:
> > This commit adds support for Mitsubishi aa070mc01 TFT panel working
> > with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - P
On Fri, Nov 17, 2017 at 3:16 PM, Greg Kroah-Hartman
wrote:
> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
>
> This allows tools that check that the module license matches the source
> code license to work properly, as
Hi Thierry,
> On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > Signed-off-by: Lukasz Majewski
> >
> > ---
> > Changes for v2:
> > - Provide more
> > detailed ./Documentation/devicetree/bindings/display/panel entry to
> > describe this panel device. ---
> > .../bindings/displ
Dear All,
> On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > Signed-off-by: Lukasz Majewski
> >
> > ---
> > Changes for v2:
> > - Provide more
> > detailed ./Documentation/devicetree/bindings/display/panel entry to
> > describe this panel device. ---
> > .../bindings/display
On Fri, 17 Nov 2017 13:27:13 +0100
Thierry Reding wrote:
> On Fri, Nov 17, 2017 at 01:17:12PM +0100, Lukasz Majewski wrote:
> > Hi Thierry,
> >
> > > On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> > > > Dear All,
> > > >
> > > > > On Tue, Nov 07, 2017 at 04:30:58PM +
Dear All,
> On Fri, Oct 20, 2017 at 5:18 PM, Lukasz Majewski
> wrote:
> > This commit adds support for Mitsubishi aa070mc01 TFT panel working
> > with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Place the
Hi Thierry,
> On Fri, Nov 17, 2017 at 11:02:47AM +0100, Lukasz Majewski wrote:
> > Dear All,
> >
> > > On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> > > > Signed-off-by: Lukasz Majewski
> > > >
> > > > ---
> > > > Changes for v2:
> > > > - Provide more
> > > > detailed
Greg KH wrote:
> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
Greg KH wrote:
> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>> Hi!
>>
>> Hopefully the right
On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
>I still have no idea how this autoselect picks up patches that do *not*
>have cc: stable nor Fixes: from us. What information do you have that we
>don't for making that call?
I think there's a difference in views about the stable tag he
Hi Andrew,
> Am 16.11.2017 um 19:56 schrieb H. Nikolaus Schaller :
>
> Hi Andrew,
>
>> Am 16.11.2017 um 19:32 schrieb Andrew F. Davis :
>>
>> On 11/16/2017 12:18 PM, H. Nikolaus Schaller wrote:
>>>
Am 16.11.2017 um 18:08 schrieb Andrew F. Davis :
On 11/16/2017 10:10 AM, H. Niko
On Sun, 19 Nov 2017, Greg KH wrote:
> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>> > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>> >> Greg KH wrote:
>> >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
>> Greg KH wrot
On 11/16/2017 09:25 PM, Dave Airlie wrote:
> gmail for some reason ate my email formatting, apparantly preediting
> in gedit, then pasting in here doesn't work so well.
>
> Dave.
That's the usual case when using the gmail web interface.
If you care about formatting, use a real mail client to gmai
On 20.11.2017 08:54, Daniel Vetter wrote:
> On Tue, Nov 14, 2017 at 03:34:19PM +0100, Andrzej Hajda wrote:
>> On 05.04.2017 14:04, Thierry Reding wrote:
>>> On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
Hi Rob,
Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herri
I believe the intention of the commit 2c9fc9bf45f8
("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
like omap4460.
By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
same way as it would tr
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #83 from Samuel Pitoiset ---
I do agree with Jozef, it's really a different issue that the one initially
filled here. Thanks again for fixing this!
--
You are receiving this mail because:
You are the assignee for the bug.__
On Mon, Nov 20, 2017 at 08:53:05AM +0100, Andrzej Hajda wrote:
> On 18.11.2017 02:16, Eric Anholt wrote:
> > Andrzej Hajda writes:
> >
> >> On 16.11.2017 21:27, Eric Anholt wrote:
> >>> Andrzej Hajda writes:
> >>>
> On 15.11.2017 21:26, Eric Anholt wrote:
> > I'm happy to have the DSI pa
The new omapdss API is HW independent and cleans up some of the
DSS5 specific hacks from the omapdrm side and get rid off the
DSS2 IRQ register bits and replace them with HW independent
struct. This new generic struct makes it more straight forward to
implement IRQ code for the future DSS versions
On Fri, Nov 17, 2017 at 11:49:28AM +0100, Christian König wrote:
> Give moving a BO into place an operation context to work with.
>
> v2: rebased
>
> Signed-off-by: Christian König
> Reviewed-by: Michel Dänzer
> ---
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> in
On Fri, Nov 17, 2017 at 03:50:25PM +0100, Philippe Ombredanne wrote:
> On Fri, Nov 17, 2017 at 3:16 PM, Greg Kroah-Hartman
> wrote:
> > There is no need to #define the license of the driver, just put it in
> > the MODULE_LICENSE() line directly as a text string.
> >
> > This allows tools that chec
On Sat, Nov 18, 2017 at 01:23:28AM +0100, Stefan Agner wrote:
> Hi Daniel,
What am I supposed to do with this pull request? drm-misc doesn't take
pull requests, and I'm not the drm top-level tree maintainer ...
/me confused
Cheers, Daniel
>
> Some cleanup/fixes, some noticed during testing of
On Mon, Nov 20, 2017 at 09:16:39AM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> will automatically calculate the normalized zpos values, but it doesn't
> actually do that. Instead, drivers are supposed to explicitl
https://bugs.freedesktop.org/show_bug.cgi?id=101731
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #84 from Christian
Hi all,
Since I'm going slightly off-topic, I've tweaked the subject line and
trimmed some of the conversation.
I believe everyone in the CC list might be interested in the
following, yet feel free to adjust.
Above all, I'd kindly ask everyone to skim through and draw their conclusions.
If the id
Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> Jani Nikula wrote:
>> On Sun, 19 Nov 2017, Greg KH wrote:
>>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
Greg KH wrote:
> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sat,
On 20/11/17 10:45, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed.
Fixes: 59eb2b5e57ea ("d
On 20/11/17 10:45, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed,
while the child backligh
On 20/11/17 10:45, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
This would only cause trouble if the child node is missing while there
is an unrelated node na
On 19 November 2017 at 09:49, Wladimir J. van der Laan wrote:
> This patch series adds support for printing the properties of all DRM mode
> objects. This is subsequently used to parse the IN_FORMATS blob to be able to
> print the available modifiers and their formats.
>
> Wladimir J. van der Laan
On 20/11/17 10:45, Johan Hovold wrote:
Two framebuffer device-node names were looked up during probe, but were
only used as flags to indicate the presence of two framebuffer device.
Drop the unused framebuffer name along with a likewise unused device
pointer from the driver data, and update the
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the p
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the 4.14 mainline release but applies
as well to drm-next.
This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to
HDMI adapter and a Club 3D DisplayPort MST Hub + modi
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
From: Hans Verkuil
Document the Display Port CEC helper functions.
Signed-off-by: Hans Verkuil
---
No changes since v4.
---
Documentation/gpu/drm-kms-helpers.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-help
Op 20-11-17 om 12:38 schreef Rainer Fiebig:
> Maarten Lankhorst wrote:
>> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
>>> Jani Nikula wrote:
On Sun, 19 Nov 2017, Greg KH wrote:
> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sun, Nov 19, 2
On 2017-11-20 11:18, Daniel Vetter wrote:
> On Sat, Nov 18, 2017 at 01:23:28AM +0100, Stefan Agner wrote:
>> Hi Daniel,
>
> What am I supposed to do with this pull request? drm-misc doesn't take
> pull requests, and I'm not the drm top-level tree maintainer ...
>
> /me confused
Hm, I see, wasn't
I didn't see this merged for 4.15, is it too late to include this?
All other changes needed to get CEC to work on rk3288 and rk3399 are all merged.
Regards,
Hans
On 10/26/2017 08:19 PM, Pierre-Hugues Husson wrote:
> The documentation already mentions "cec" optional clock, but
> currently
On Mon, Nov 20, 2017 at 01:25:23PM +0100, Stefan Agner wrote:
> On 2017-11-20 11:18, Daniel Vetter wrote:
> > On Sat, Nov 18, 2017 at 01:23:28AM +0100, Stefan Agner wrote:
> >> Hi Daniel,
> >
> > What am I supposed to do with this pull request? drm-misc doesn't take
> > pull requests, and I'm not
On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> Hi all,
>
> Since I'm going slightly off-topic, I've tweaked the subject line and
> trimmed some of the conversation.
> I believe everyone in the CC list might be interested in the
> following, yet feel free to adjust.
>
> Above all,
On Mon, 20 Nov 2017, Johan Hovold wrote:
> On Wed, Nov 15, 2017 at 03:39:09PM +0100, Johan Hovold wrote:
> > On Wed, Nov 15, 2017 at 02:32:11PM +, Lee Jones wrote:
> > > On Wed, 15 Nov 2017, Johan Hovold wrote:
> > >
> > > > On Tue, Nov 14, 2017 at 07:48:09PM +, Daniel Thompson wrote:
> >
On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> > Hi all,
> >
> > Since I'm going slightly off-topic, I've tweaked the subject line and
> > trimmed some of the conversation.
> > I believe everyone in the CC list might
Hi Dave,
Please pull the removal of DRM_TILCDC_SLAVE_COMPAT, the backward
compatibility option for the obsolete "ti,tilcdc,slave"-binding. The dts
code used in the option causes lot of trouble to device/of development.
Best regards and thanks,
Jyri
The following changes since commit 44cd3939c111b
On 11/13/2017 06:04 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-b
From: Martin Bugge
Audio channel count should start from 2.
Reference: CEA-861-F Table 27.
Cc: Hans Verkuil
Reported-by: Ahung Cheng
Signed-off-by: Martin Bugge
---
drivers/video/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/
From: Hans Verkuil
Some devices (Windows Intel driver!) send a Vendor InfoFrame that
uses a payload length of 0x1b instead of the length of 5 or 6
that the unpack code expects. The InfoFrame is padded with 0 by
the source.
The current code thinks anything other than 5 or 6 is an error,
but large
From: Hans Verkuil
Ville, can you add these two to your "drm/edid: Infoframe cleanups and fixes"
patch series? These two have been in our queue for some time now and were
never upstreamed, so this is a good opportunity to finally kick them out.
Once all this is merged I really should sit down an
Hi Linus,
Please pull fbdev changes for v4.15. There is nothing really major here
(though removal of the dead igafb driver stands out in diffstat), please
see the signed tag description for details.
Test merge revealed a small merge conflict in include/video/iga.h caused
by SPDX tags addition (
On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Some devices (Windows Intel driver!) send a Vendor InfoFrame that
> uses a payload length of 0x1b instead of the length of 5 or 6
> that the unpack code expects. The InfoFrame is padded with 0 by
> the source.
On Mon, Nov 20, 2017 at 02:36:20PM +0100, Hans Verkuil wrote:
> On 11/13/2017 06:04 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> > @@ -1163,7 +1176,7 @@ static int hdmi_audio_infoframe_unpack(struct
> > hdmi_audio_infoframe *frame,
> > */
> > static int
> > hdmi_vendor_any_infoframe_un
On 11/20/2017 03:51 PM, Ville Syrjälä wrote:
> On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Some devices (Windows Intel driver!) send a Vendor InfoFrame that
>> uses a payload length of 0x1b instead of the length of 5 or 6
>> that the unpack code expect
On 11/17/2017 09:43 AM, Hans Verkuil wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
>
> There is no need to have adv7511_probe() fail if the CEC initia
On 11/20/2017 04:05 PM, Hans Verkuil wrote:
> On 11/17/2017 09:43 AM, Hans Verkuil wrote:
>> If the device tree for a board did not specify a cec clock, then
>> adv7511_cec_init would return an error, which would cause adv7511_probe()
>> to fail and thus there is no HDMI output.
>>
>> There is no n
From: Thierry Reding
kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it doesn't
actually do that anymore since commit 38d868e41c4b ("drm: Don't force
all planes to be added to the state due to zpos"). Instead, driv
Hi Dave,
drm-misc-fixes-2017-11-20:
4.15 merge window fixes 1
-fixes pull instead of -next-fixes because we haven't scripted our
flowchart for where people should apply their -misc bugfixes yet :-)
Cheers, Daniel
The following changes since commit 44419ce7d77e03692ed8fe799688d8dc43f9266e:
d
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #33 from Alex Deucher ---
(In reply to Michel Dänzer from comment #27)
> Thanks for bisecting, but I don't think that commit can be directly
> responsible for a GPU hang. Before that commit, the DRI3 code in Mesa would
> only use one
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #34 from Alex Deucher ---
The following commits are relevant:
abb2e3c1ce64c8bba678973800c34ea1dc97c42c
6458bd4dfd9414cba5804eb9907fe2a824278c34
ef736d394e85b1bf1fd65ba5e5257b85f6c82325
4e6e98b1e48c9474aed7ce03025ec319b941e26e
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #35 from Alex Deucher ---
Does reverting a628392cf03e0eef21b345afbb192cbade041741 fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mai
Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:
On 10/18/2017 09:58 AM, Christian König wrote:
From: Christian König
Most BIOS don't enable this because of compatibility reasons.
Manually enable a 64bit BAR of 64GB size so that we have
enough room for PCI devices.
v2: style cleanups, increas
https://bugs.freedesktop.org/show_bug.cgi?id=103808
--- Comment #1 from Marek Olšák ---
Can you upload an apitrace?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
Hi All,
I tested the latest Git kernel version [1] on my Varisys Nemo board with
a 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne
X1000) [2] today. Unfortunately hardware 3D acceleration doesn't work
anymore. It works without any problems with the kernel 4.14.0 [3].
Error
Hi Dave,
Some cleanup/fixes, some noticed during testing of Noralf Trønnes
rework of the suspend/resume helper. His changes will conflict with
this fixes, but he will rebase the patchset ontop of this changes.
I did base this on drm-fixes, hope that is fine.
--
Stefan
The following changes sinc
On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote:
> On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote:
> > > Sorry this took so long.
> >
> > No worries.
> >
> > >
> > > The vmwgfx part: Reviewed-by: Sinc
On Mon, Nov 20, 2017 at 09:32:56AM -0800, Sinclair Yeh wrote:
> On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote:
> > > > Sorry this took so long.
> >
I think this patch is not correct. The EOP-mem is not associated with
the queue size. The EOP buffer is a separate buffer used by the firmware
to handle command completion. As I understand it, this allows more
concurrency, while still making it look like all commands in the queue
are completing in
On Fri, Nov 17, 2017 at 12:43 AM, Hans Verkuil wrote:
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 3a33075dbb22..56a6a1fa 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/
On Wed, Nov 15, 2017 at 2:26 PM, Eric Anholt wrote:
> I'm happy to have the DSI panel finally working on VC4 (just waiting on
> https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
> but now I've got another problem to solve. It would be great if I could
> include the DSI p
Daniel Vetter writes:
> On Mon, Nov 20, 2017 at 08:53:05AM +0100, Andrzej Hajda wrote:
>> On 18.11.2017 02:16, Eric Anholt wrote:
>> > Andrzej Hajda writes:
>> >
>> >> On 16.11.2017 21:27, Eric Anholt wrote:
>> >>> Andrzej Hajda writes:
>> >>>
>> On 15.11.2017 21:26, Eric Anholt wrote:
>>
If the device tree for a board did not specify a cec clock, then
adv7511_cec_init would return an error, which would cause adv7511_probe()
to fail and thus there is no HDMI output.
There is no need to have adv7511_probe() fail if the CEC initialization
fails, so just change adv7511_cec_init() to a
On Mon, Nov 20, 2017 at 8:13 AM, Daniel Vetter wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of
On Sun, Nov 19, 2017 at 02:12:05PM -0600, David Lechner wrote:
> This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK).
>
> This prefix is already used several places and I will be adding more.
>
> Signed-off-by: David Lechner
> ---
>
> v2 changes:
> * New patch in v2
>
>
On Sun, Nov 19, 2017 at 02:12:06PM -0600, David Lechner wrote:
> This adds a new binding for display panels that use an Ilitek ILI9225
> controller.
>
> The "ilitek,ili9225-2.2in-176x220" device listed has no identification
> markings whatsoever and an hour of googling turned up nothing, hence the
On 20 November 2017 at 23:13, Daniel Vetter wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> > Hi all,
>> >
>> > Since I'm going slightly off-topic, I've tweaked the subject line and
>> > trimmed some of the
https://bugs.freedesktop.org/show_bug.cgi?id=103808
--- Comment #2 from Chris Rankin ---
Created attachment 135620
--> https://bugs.freedesktop.org/attachment.cgi?id=135620&action=edit
apitrace for WoW
--
You are receiving this mail because:
You are the assignee for the bug.__
I got your point . I can push follow up patch with document change and code
update as discussed here.
Keeping that I think this patch should be ok to land?
Thanks,
Deepak
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Thursday, November 16, 2017 7:40 AM
T
https://bugs.freedesktop.org/show_bug.cgi?id=103808
--- Comment #3 from Chris Rankin ---
There's some initial chaos when you start replaying this trace, but I think the
most relevant artifacts (from this bug's perspective) occur right at the end.
--
You are receiving this mail because:
You are
On Sun, Oct 8, 2017 at 10:31 PM, Dieter Nützel wrote:
> OK, got it but can't revert the commit clean.
>
> amdgpu-pci-0100
> Adapter: PCI adapter
> fan1: 873 RPM
> temp1:+26.0°C (crit = +0.0°C, hyst = +0.0°C)
>
> SOURCE/amd-staging-drm-next> git bisect good
> 0944c350c8eddf4064e7
On Mon, Nov 20, 2017 at 12:57 PM, Hans Verkuil wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
>
> There is no need to have adv7511_probe() fail if the
Dave Stevenson writes:
> These are relatively trivial patches that just expand the
> list of formats that the vc4 DRM driver will accept.
> RGB888, BGR888, NV21, and NV61 tested with the modetest app from the libdrm
> repo. YUV422 and YVU422 can't be as they aren't supported.
It worked in my tes
Den 17.11.2017 10.10, skrev Alexey Brodkin:
Hi Noralf,
On Thu, 2017-11-16 at 21:11 +0100, Noralf Trønnes wrote:
Den 16.11.2017 09.14, skrev Shawn Guo:
On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote:
This patchset adds drm_fb_cma_fbdev_init/fini() functions that replaces
drm_f
That did it.
a716d5540346 (HEAD -> amd-staging-drm-next) drm/amdgpu: don't skip
attributes when powerplay is enabled
9f896d936c9d (origin/amd-staging-drm-next) drm/amdgpu: fix VCE buffer
placement restrictions v2
ca9b5d953735 drm/amdgpu: align GTT start to 4GB v2
52364b9f0226 drm/amdgpu: remov
Hello Christian,
your latest 'amd-staging-drm-next' commit
drm/amdgpu: fix VCE buffer placement restrictions v2
#9f896d936c9d4ea936a02d52eaeb14fdd209193b
static int amdgpu_vce_validate_bo(struct amdgpu_cs_parser *p, uint32_t
ib_idx,
int lo, int hi, unsigned si
Tested on nouveau with the CRTC only (no planes).
Signed-off-by: Ilia Mirkin
---
v1 -> v2: always set a flat gamma ramp for non-indexed modes
tests/modetest/buffers.c | 2 ++
tests/modetest/modetest.c | 24
tests/util/format.c | 2 ++
tests/util/pattern.c | 73 ++
On Mon, Nov 20, 2017 at 1:08 PM, Christian Zigotzky
wrote:
> Hi All,
>
> I tested the latest Git kernel version [1] on my Varisys Nemo board with a
> 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne X1000)
> [2] today. Unfortunately hardware 3D acceleration doesn't work anymore.
Hi Hans,
Thank you for the patch.
On Monday, 20 November 2017 22:57:34 EET Hans Verkuil wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
>
> There is n
https://bugzilla.kernel.org/show_bug.cgi?id=60371
mirh (m...@protonmail.ch) changed:
What|Removed |Added
CC||m...@protonmail.ch
--- Comment
Hi Peter,
Thank you for the patch.
On Monday, 20 November 2017 11:51:40 EET Peter Ujfalusi wrote:
> I believe the intention of the commit 2c9fc9bf45f8
> ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
> was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
> like o
get_modes() callback might be called asynchronously from the DRM core and
it is not synchronized with bridge_enable(), which sets proper runtime PM
state of the main DP device. Fix this by calling pm_runtime_get_sync()
before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
analogi
On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> Of course our CI is open, so if someone is supremely bored and wants to
> backport more stuff for drm/i915, they could do that. But atm it doesn't
> happen, and then having to deal with the fallout is not really great (like
> I said,
96 matches
Mail list logo
