On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
> wrote:
>
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches
>
> Ah there it is :D
> Reviewed-by: Linus Walleij
>
> PS: why
Use GPIO descriptors instead of relying on the old method.
Signed-off-by: Ludovic Desroches
Acked-by: Nicolas Ferre
Reviewed-by: Linus Walleij
Reviewed-by: Andy Shevchenko
---
Changes
- V2:
- remove of_gpio.h.
- move gpiod declaration to preserve reversed tree style.
- use devm_gpiod_get
https://bugs.freedesktop.org/show_bug.cgi?id=104963
Bug ID: 104963
Summary: MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba
HD7560D) Boot loop without radeon.dpm=0
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
Hi,
On Sun, Feb 04, 2018 at 10:31:04PM +0100, Philippe Cornu wrote:
> This patch adds the DCS/GENERIC DSI read feature.
>
> Signed-off-by: Philippe Cornu
> ---
> Extra notes:
> DSI read tests have been performed with DCS & GENERIC, short & long
> commands, on two different panels.
> The maximum
On Fri, Feb 02, 2018 at 10:19:15PM +, Philippe CORNU wrote:
> Hi Archit, Andrzej, Laurent & Brian,
>
> What is your opinion regarding this patch? Do you have any advice for
> handling hw versions?
>
> Do not hesitate to comment.
I'll admit, I don't really have the bandwidth to handle this.
On Thu, 2018-02-01 at 13:31 +0100, Hans de Goede wrote:
> Hi All,
>
> As you may have heard I've recently been working on improving
> Linux laptop battery life, specifically the OOTB experience
> without tweaking any options such as e.g. powertop --auto-tune
> would do, see:
>
> https://fedorap
On Mon, Feb 05, 2018 at 11:54:04PM +, Andy Lutomirski wrote:
>
>
> > On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote:
> >
> >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM,
2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글:
> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
>
> Signed-off-by: Wolfram Sang
> ---
> Only build tested. To be applied individually per subsystem.
>
> drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
> 1 file changed, 1
2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
>
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. ti
> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote:
>
>> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
>>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>
On Tue, Feb 6, 2018 at 9:35 AM, Danilo Krummrich
wrote:
> Hi Ben,
>
> still _assuming_ it's an issue of the card I thought about why it
> works with the NVIDIA binary driver.
>
> And I can image they're just trying to do an identity-mapping first
> and if that doesn't work (e.g. the particular SOR
Rodrigo Vivi writes:
> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?
Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add
explicit casts where the compiler would already introduce equivalent
implicit c
Hi Ben,
still _assuming_ it's an issue of the card I thought about why it
works with the NVIDIA binary driver.
And I can image they're just trying to do an identity-mapping first
and if that doesn't work (e.g. the particular SOR is already in use
by another macro link) they just pick the next sui
With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar
routing should be possible, such that any SOR sublink can drive
any macro link. Therefore, if crossbar routing is available,
the first suitable SOR was picked.
Unfortunately, there's at least one card where some SORs being
being conn
Hi Hans,
On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote:
> Hi,
>
> On 01-02-18 13:31, Hans de Goede wrote:
> > Hi All,
> >
> > As you may have heard I've recently been working on improving
> > Linux laptop battery life, specifically the OOTB experience
> > without tweaking any op
On Thu, Feb 01, 2018 at 05:43:56PM +, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote:
> > Hi-
> >
> > As requested in your blog post, I tested PSR. I see something like
> > 2.69W with PSR off and 2.17W with PSR on. Screen blanking,
> > suspend/resume, and the
On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> >> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
> >> wrote:
> >>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
On Mon, Feb 05, 2018 at 08:35:25PM +, Andy Lutomirski wrote:
Andy, first of all thank you very much for those findings.
> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
> wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 P
On Thu, Feb 01, 2018 at 08:33:29PM +, Chris Wilson wrote:
> Quoting Kristian Høgsberg (2018-02-01 20:22:40)
> > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson
> > wrote:
> >
> > > Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > > > *However*, I do see one unfortunate side effect of turning on
The current PSR code has a two call sites that each schedule delayed
work to activate PSR. As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.
The call sites are:
- intel_psr_enable(), which explicitly states in a com
https://bugzilla.kernel.org/show_bug.cgi?id=198669
--- Comment #4 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk)
---
Well it moved the problem. It crashed somewhere else in the driver with some
message about scratch. Sorry I cannot tell you what is was because I screwed up
the sav
On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran
wrote:
>
> On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
>> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>> wrote:
>> >
>> >
>> >
>> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> >> On Sat, Feb 3, 2018 at 5:
On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
> wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
> >> > On Sat, Feb 3, 2018 at 5:20 AM, P
On Mon, 2018-02-05 at 12:49 -0800, Rodrigo Vivi wrote:
> On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> > On 6 February 2018 at 06:32, Rodrigo Vivi wrote:
> > > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> > >> Dhinakaran Pandiyan writes:
> > >>
> > >> > From:
On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> On 6 February 2018 at 06:32, Rodrigo Vivi wrote:
> > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> >> Dhinakaran Pandiyan writes:
> >>
> >> > From: "Pandiyan, Dhinakaran"
> >> >
> >> > drm_vblank_count() has an u32
Quoting Chris Wilson (2018-02-05 16:04:25)
> Quoting Michal Srb (2018-02-05 15:17:45)
> > The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> > possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> > In that case check_cmd will read bits from the fo
On 6 February 2018 at 06:32, Rodrigo Vivi wrote:
> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
>> Dhinakaran Pandiyan writes:
>>
>> > From: "Pandiyan, Dhinakaran"
>> >
>> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
>> > The effect of this is w
On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
wrote:
>
>
>
> On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
>> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> > wrote:
>> >>
>> >> On Fri, 2018-02-02 at 19:18 +0
On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> Dhinakaran Pandiyan writes:
>
> > From: "Pandiyan, Dhinakaran"
> >
> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > s
From: Thierry Reding
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_d
From: Thierry Reding
This helper chooses an appropriate configuration, according to the
bitrate requirements of the video mode and the capabilities of the
DisplayPort sink.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 55 +
include
From: Thierry Reding
If the sink is eDP and supports the alternate scrambler reset, enable
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 82
From: Thierry Reding
If the sink supports eDP, read the eDP revision from it's DPCD.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16 +++-
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
From: Thierry Reding
Use microsecond sleeps for the clock recovery and channel equalization
delays during link training. The duration of these delays can be from
100 us up to 16 ms. It is rude to busy-loop for that amount of time.
While at it, also convert to standard coding style by putting the
From: Thierry Reding
If the transmitter supports pre-emphasis post cursor2 the sink will
request adjustments in a similar way to how it requests adjustments to
the voltage swing and pre-emphasis settings.
Add a helper to extract these adjustments on a per-lane basis from the
DPCD link status.
S
From: Thierry Reding
Parse from the sink capabilities whether or not the eDP alternate
scrambler reset value of 0xfffe is supported.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 9 +
2 files changed, 14 insertions(+)
di
From: Thierry Reding
Store the AUX read interval from DPCD, so that it can be used to wait
for the durations given in the specification during link training.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
include/drm/drm_dp_helper.h | 18 ++
2 f
From: Thierry Reding
Make use of the newly added drm_dp_aux_rd_interval() helper in existing
DP link training helpers and add comments about minimum required delays
mandated by the DP specification.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 20
1
From: Thierry Reding
Parse from the sink capabilities whether or not it supports ANSI 8B/10B
channel coding as specified in ANSI X3.230-1994, clause 11.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
include/drm/drm_dp_helper.h | 9 +
2 files changed, 12
From: Thierry Reding
The TPS3 capability can be exposed by DP 1.2 and later sinks if they
support the alternative training pattern for channel equalization.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 5 ins
From: Thierry Reding
While probing the DisplayPort link, query the fast training capability.
If supported, drivers can use the fast link training sequence instead of
the more involved full link training sequence.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
includ
From: Thierry Reding
Hi,
this set of patches is based on work that I had done some 2-3 years ago
to enable DP support on Pixel C. I never really got that to work, but I
recently got my hands on newer hardware with DP connectivity, so I went
to revive these patches.
I think this takes into accou
From: Thierry Reding
Use existing parsing helpers to probe a DisplayPort link.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 29 ++---
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/
From: Thierry Reding
Store capabilities in max_* fields and add separate fields for the
currently selected settings.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/bridge/tc358767.c | 14 +++---
drivers/gpu/drm/drm_dp_helper.c| 16 +++-
drivers/gpu/drm/msm/e
From: Thierry Reding
Rather than storing capabilities as flags in an integer, use a separate
boolean per capability. This simplifies the code that checks for these
capabilities.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/bridge/tc358767.c | 6 +++---
drivers/gpu/drm/drm_dp_helper.c
From: Thierry Reding
Subsequent patches will add non-volatile fields to struct drm_dp_link,
so introduce a function to zero out only the volatile fields.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff
From: Thierry Reding
The drm_dp_link structure tracks capabilities on the DP link. Add some
kerneldoc to explain what each of its fields means.
Signed-off-by: Thierry Reding
---
include/drm/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b
The ARM reference designs "Versatile AB" and "Versatile PB"
contain panel connectors with autodetection of the connected
panel type. This adds a small driver utilizing the MFD syscon
look-up to read the autodetection register and set up the
corresponding panel appropriately.
In the source file the
Hi Philippe,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15 next-20180205]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
This adds a pretty simple set of device tree bindings for
ARM Versatile panels appearing as child nodes of a system
controller.
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Collect Rob's ACK.
---
.../display/panel/arm,versatile-tft
On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> > wrote:
> >>
> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >>> I updated to 4.15, and the situation
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head: a5592a6df4f45a018b48f252ad1c498e683e9b9d
commit: 30de3c24e044a36ad8738faddb8986fe4e3a2319 [59/249] drm/amd/display:
Implement interface for CRC on CRTC
config: x86_64-randconfig-a0-02052326 (attached as .config)
compil
On Sat, Feb 3, 2018 at 12:12 AM, Dhinakaran Pandiyan
wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference
https://bugs.freedesktop.org/show_bug.cgi?id=104216
--- Comment #14 from Germano Massullo ---
(In reply to Emil Velikov from comment #13)
> (In reply to Germano Massullo from comment #12)
> > Is there anything else I can do to retrieve useful informations?
> > Thank you
>
>
> You can track (git
On Mon, Feb 05, 2018 at 06:39:05PM +0100, Lucas Stach wrote:
> Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
> > On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > > On Wed, Apr 05, 2017 at 10:
Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
constant and adds missing HDMI_I2S_SEL_DATA0. There is no functional
change.
Signed-off-by: Sylwester Nawrocki
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
dr
Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
> On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > > Hi Rob,
> > > >
> > > > Am
On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> On Wed, Apr 05, 2017 at 02:04:31PM +0200, 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 Herring:
> > > > On Mon,
On Mon, Feb 05, 2018 at 05:29:09PM +0100, Lucas Stach wrote:
> Am Montag, den 05.02.2018, 17:11 +0100 schrieb Thierry Reding:
> > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > > Hi Rob,
> > > >
> > > > Am Mi
On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:
> Hello,
>
>
> I have a DRM driver which implements display protocol for Xen [1]
> and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
> tells the other end that some display buffer needs to be displayed,
> e
Am Montag, den 05.02.2018, 17:11 +0100 schrieb Thierry Reding:
> On Wed, Apr 05, 2017 at 02:04:31PM +0200, 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 Herring:
> > > > On Mon,
https://bugs.freedesktop.org/show_bug.cgi?id=104216
--- Comment #13 from Emil Velikov ---
(In reply to Germano Massullo from comment #12)
> Is there anything else I can do to retrieve useful informations?
> Thank you
You can track (git bisect) which version of Mesa, ideally which commit, caused
On Wed, Apr 05, 2017 at 02:04:31PM +0200, 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 Herring:
> > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > wrote:
> > > > On Fri, Jan
Quoting Michal Srb (2018-02-05 15:17:45)
> The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> In that case check_cmd will read bits from the following command, or even past
> the end of the buff
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
> >Hi,
> >
> > > > Why not use virtio-vsock to run the wayland protocol? I don't like
> > > > the idea to duplicate something with very simliar functionality in
> > > > virtio-gpu.
> >
Hello,
I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the form
On Mon, Feb 05, 2018 at 03:06:33PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
> wrote:
> > Use GPIO descriptors instead of relying on the old method.
>
> Reviewed-by: Andy Shevchenko
>
> Though few nitpicks below.
>
>
> > --- a/drivers/video/fbdev/atmel
On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.
If the offset ends up outside of the command
On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
'D' (pad macro 1, link 2) causes failures:
[6.712111] nouveau :01:00.0: bus: MMIO read of FAULT at 61c880
[ IBUS ]
[6.724888] nouveau :01:00.0: disp: intr24 8000
[8.716668] nouveau :01:00.0: D
With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar
routing should be possible, such that any SOR sublink can drive
any macro link.
Unfortunately, there's at least one card where some SOR sublinks
being connected to a particular macro link are causing failures.
To work around this is
Taken from NVIDIA binary driver (Linux 64-bit, revision 390.25)
from README.txt.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 41
1 file changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
b/
On 1 February 2018 at 14:59, Rob Herring wrote:
> On Wed, Jan 31, 2018 at 12:46 PM, John Stultz wrote:
>> On Wed, Jan 31, 2018 at 8:01 AM, Emil Velikov
>> wrote:
>>> On 30 January 2018 at 05:42, John Stultz wrote:
On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov
wrote:
> Hi all,
Hi Andrzej,
And many thanks for your good comments
On 02/05/2018 02:03 PM, Andrzej Hajda wrote:
> On 22.01.2018 16:08, Philippe Cornu wrote:
>> From: Philippe CORNU
>>
>> Add support for the Synopsys DesignWare MIPI DSI version 1.31
>> Two registers need to be updated/added for supporting 1.31:
Op 05-02-18 om 15:16 schreef Ville Syrjälä:
> On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
>> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
>>> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
This will make it possible for userspace to know whether readin
Quoting Michal Srb (2018-02-05 14:29:16)
> The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> In that case check_cmd will read bits from the following command, or even past
> the end of the buff
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.
The reason for abandoning that approach was the type of objects that
could be shared via virtio
On Mon, Feb 05, 2018 at 12:55:50PM +0530, Aishwarya Pant wrote:
> On Thu, Feb 01, 2018 at 11:36:04AM +, Daniel Thompson wrote:
> > On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote:
> > > On Wed, 31 Jan 2018, Daniel Thompson wrote:
> > > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Ai
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct. As the chip-data that occupies the phy_data
pointer initially gets assigned to the rockchip_hdmi struct we can not
re-use this phy_data pointer to hold the reference to the rockchip_hdmi
struct, similar
From: Zheng Yang
The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
Signed-off-by: Zheng Yang
Signed-off-by: Heiko Stuebner
---
.../bindings/phy/phy-rockchip-inno-hdmi.txt| 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentati
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general
mmio, so allow these to be referenced via the regular phy interfaces
and therefore add optional phy-related properties to the binding.
Signed-off-by: Heiko Stuebner
---
Documentation/devicetree/bindings/display/rockchip/dw_
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that now output-switch
From: Zheng Yang
Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
and rk3328 socs from Rockchip.
Signed-off-by: Zheng Yang
Signed-off-by: Heiko Stuebner
---
drivers/phy/rockchip/Kconfig |7 +
drivers/phy/rockchip/Makefile |1 +
drivers/p
In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
phy from Innosilicon but still report the HDMI20_TX type.
So allow the glue driver to force a specific type, like the vendor-phy
for these cases.
Signed-of
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1 file changed, 10 insertio
From: Algea Cao
External phys may not provide their own hotplug-related
routines but instead rely on the dw-hdmi ones.
Export these functions so that external hdmi-phys can
use them if necessary.
Signed-off-by: Algea Cao
[export all 3 hotplug-related functions]
Signed-off-by: Heiko Stuebner
--
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy
from Innosilicon that resides completely separate from the dw-hdmi block
and gets accessed via mmio.
Additionally the rk3328 dw-hdmi does not report the vendor-phy type
but a different one instead, so add the possibility to ove
The rk3328 uses an external hdmi phy from Innosilicon which uses
the generic phy framework for access. Add the necessary data
and the compatible for it.
Signed-off-by: Heiko Stuebner
---
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.
In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as M
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.
Similarly to how registers are checked - if
Hi,
I have tried to extract the intel_engine_cmd_parser into a user-space binary
and run libFuzzer on it. It found two ways to cause undefined behavior.
I am not completely sure if the same issues can be triggered in the driver, or
if something would prevent them from happening. Still I thought i
On Thu, Feb 01, 2018 at 05:09:33PM +0100, Giulio Benetti wrote:
> Il 01/02/2018 11:14, Maxime Ripard ha scritto:
> > On Sat, Jan 27, 2018 at 11:07:09PM +0100, Giulio Benetti wrote:
> > > > > > > I don't really know what the polarity of D0 would be just by
> > > > > > > judging at that capture, but
On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
> > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
> >> This will make it possible for userspace to know whether reading
> >> will block, without blocking on the fd.
On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
wrote:
> On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
>> Nouveau only exposes support for XBGR2101010. Prior to the atomic
>> conversion, drm would pass in the wrong format in the framebuffer, but
>> it was always ignored -- both usersp
On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
> Nouveau only exposes support for XBGR2101010. Prior to the atomic
> conversion, drm would pass in the wrong format in the framebuffer, but
> it was always ignored -- both userspace (xf86-video-nouveau) and the
> kernel driver agreed on
Attached is a patch for umr{master} which should in theory support both
iova and iomem.
I can add the write method if you want since ya it should be fairly
simple to copy/pasta that up.
Cheers,
Tom
On 05/02/18 07:07 AM, Christian König wrote:
Well adding write support is trivial.
What I'm
On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
wrote:
> Use GPIO descriptors instead of relying on the old method.
Reviewed-by: Andy Shevchenko
Though few nitpicks below.
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -18,6 +18,7 @@
> #include
>
On 22.01.2018 16:08, Philippe Cornu wrote:
> From: Philippe CORNU
>
> Add support for the Synopsys DesignWare MIPI DSI version 1.31
> Two registers need to be updated/added for supporting 1.31:
> * PHY_TMR_CFG 0x9c (updated)
> 1.30 [31:24] phy_hs2lp_time
>[23:16] phy_lp2hs_time
>
Op 02-02-18 om 15:46 schreef Ville Syrjälä:
> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
>> This will make it possible for userspace to know whether reading
>> will block, without blocking on the fd. This makes it possible to
>> drain all queued CRC's in blocking mode, witho
Hi Andrzej,
And many thanks
Philippe :-)
On 02/05/2018 11:07 AM, Andrzej Hajda wrote:
> On 04.02.2018 22:31, Philippe Cornu wrote:
>> This patch adds the DCS/GENERIC DSI read feature.
>>
>> Signed-off-by: Philippe Cornu
>
> Reviewed-by: Andrzej Hajda
>
> If there will be no objections I will
1 - 100 of 130 matches
Mail list logo
