On 11.01.2019 16:19, Peter Rosin wrote:
> Optionally power down the LVDS-encoder when it is not in use.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:/
On 11.01.2019 16:19, Peter Rosin wrote:
> Make the code easier to read and modify.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/m
Hi Linus,
This is a separate pull req for -fixes that just contains the patch to
enable TU102 GPUs with nouveau (RTX 2080 Ti).
It seems small enough to go in now rather than wait for merge.
Dave.
drm-fixes-2019-01-18-1:
drm/nouveau: add TU102 support
The following changes since commit df0219b4f
The pull request you sent on Fri, 18 Jan 2019 10:43:13 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1092a94fcbcde03a8c2cc554f305af48c95d5d58
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Fri, Jan 18, 2019 at 12:43 PM Dave Airlie wrote:
>
> Going to be at LCA next week in Christchurch, but should be fine for
> normal pulls.
.. hey, me too.
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18
Pulled,
Linus
_
Hi all,
In commit
dddce8b49005 ("drm/amd/display: Only get the connector state for VRR when
toggled")
Fixes tag
Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
has these problem(s):
- Target SHA1 does not exist
--
Cheers,
Stephen Rothwell
pgpNdzvp9M
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #22 from bmil...@gmail.com ---
(In reply to mikhail.v.gavrilov from comment #21)
> Forgot to ask: when it will be merged in Linus tree?
https://github.com/torvalds/linux/commit/6d060fa39035d5ff6bb3e720a8119aeb50453e3b
Can confirm my
The following changes since commit a5176a4cb85bb6213daadf691097cf411da35df2:
drm/nouveau/falcon: avoid touching registers if engine is off
(2019-01-11 16:25:54 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-4.21
for you to fetch changes up to 7ebec5f4313
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #21 from mikhail.v.gavri...@gmail.com ---
Forgot to ask: when it will be merged in Linus tree?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #20 from mikhail.v.gavri...@gmail.com ---
Michel, thanks.
I tested this patch https://patchwork.codeaurora.org/patch/699617/ for several
days and confirm that it fix the problem.
--
You are receiving this mail because:
You are the a
On 1/17/19 9:15 PM, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 10:57 AM Hoegeun Kwon
> wrote:
>>
>> On 1/17/19 6:20 PM, Daniel Vetter wrote:
>>> On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
There is a problem in crtc_helper that property value is not updated
when dp
Hi, Frank:
On Thu, 2019-01-17 at 15:14 +0100, Frank Wunderlich wrote:
> Hi,
>
> this Patchset does not hang on Bananapi R2, but does not show anything on
> FB-Console...seems anything is missing
>
> https://github.com/frank-w/BPI-R2-4.14/tree/4.20-fbdev
>
> dmesg | grep 'fb\|framebuffer'
> [
Hi Linus,
Going to be at LCA next week in Christchurch, but should be fine for
normal pulls.
The rc3 fixes are a bit scattered:
meson, sun4i and rockchip all had missing of_node_put
qxl and virtio both were advertising dma-buf to userspace when they
really shouldn't have.
Otherwise:
meson:
- mo
Kuo-Hsin Yang writes:
> The gem drivers use shmemfs to allocate backing storage for gem objects.
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
> to pin a lot of pages, breaking the page reclaim mechanism and
Hi,
On Wed, Jan 16, 2019 at 10:03 AM Jordan Crouse wrote:
> + gpu@500 {
> + compatible = "qcom,adreno-630.2", "qcom,adreno";
> + #stream-id-cells = <16>;
> +
> + reg = <0x500 0x4>, <0x509e000 0x10>;
This
On 01/17/2019 10:29 AM, Koenig, Christian wrote:
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On Thursday, January 17, 2019 6:26:25 PM CET Russell King - ARM Linux admin
wrote:
> On Tue, Jan 15, 2019 at 11:47:00PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] driver core: Fix adding device links to probing suppliers
> >
> > Currently, it is not valid to
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #56 from l...@protonmail.ch ---
Also, forgot to mention, but the new GPU recovery thing doesn't work, and it
would make the following error in dmesg:
jan 16 16:43:26 las kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring
sdma0 t
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #55 from l...@protonmail.ch ---
I have a very similar problem, although the few differences is that my entire
screen becomes one single color, which doesn't seem to be entirely random. Some
times it is grey, other times a blueish tint
Add a few __printf attribute specifiers to routines that
could use them.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/msm/msm_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9f51be5a637c..927e5d86f7c1 100644
--- a
On Thu, Jan 17, 2019 at 7:26 AM Daniel Vetter wrote:
>
> On Thu, Jan 17, 2019 at 2:04 PM Tomi Valkeinen wrote:
> >
> > On 17/01/19 14:33, Daniel Vetter wrote:
> > > On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
> > >> The DRM device minor numbers are allocated according to the r
Tomi Valkeinen writes:
> The DRM device minor numbers are allocated according to the registration
> order. This causes confusion in cases where the registration order can
> change, or when, say, a modesetting capable device is preferred to be
> card0, and a rendering device is preferred to be car
Stéphane Marchesin writes:
> I don't have strong feelings for against this approach, but if we do this,
> I think we should ensure we keep providing the original EDID to user space.
> The contents of EDIDs have so many implications that even the kernel isn't
> always in the best position to decid
On Mon, Jan 7, 2019, 09:07 Brian Starkey On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter writes:
> >
> > > Best to pull in some other compositor people and get them to agree.
> From a
> > > kernel pov I'm fine with whatever userspace preferes.
> >
> > Hrm. It woul
On Thu, Jan 17, 2019 at 8:59 PM Alex Deucher wrote:
>
> On Wed, Jan 16, 2019 at 1:35 PM Pekka Paalanen wrote:
> >
> > On Mon, 7 Jan 2019 17:07:09 +
> > Brian Starkey wrote:
> >
> > > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > > > Daniel Vetter writes:
> > > >
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #9 from Raman Gupta ---
(In reply to Harry Wentland from comment #7)
> If you didn't say you tried swapping monitors and cables I'd say it was a
> cable issue.
>
> Are those high refresh rate displays (120Hz+)? If so you might want
On Wed, Jan 16, 2019 at 1:35 PM Pekka Paalanen wrote:
>
> On Mon, 7 Jan 2019 17:07:09 +
> Brian Starkey wrote:
>
> > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > > Daniel Vetter writes:
> > >
> > > > Best to pull in some other compositor people and get them to agree.
>
On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> Range setting makes sense for YCbCr and RGB buffers. Current
> drm_color_range enum labels suggest use with YCbCr buffers.
> Create enum labels without colorspace specification.
>
> Signed-off-by: Christoph Manszewski
> ---
>
Daniel Vetter writes:
> Connector properties are documented here:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
Cool. Seems like we might want a bit more organization here to make it
clear which of these are derived from the connected monitor.
It would
On Wed, Jan 16, 2019 at 08:35:16PM +, Priit Laes wrote:
> On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> > Hi Priit,
> >
> > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote:
> > > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > > > > I have a some
On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
> The DRM device minor numbers are allocated according to the registration
> order. This causes confusion in cases where the registration order can
> change, or when, say, a modesetting capable device is preferred to be
> card0, and a
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > > v5: Actually try to sort them, and while at it, sort all the ones I
> > > touch.
> >
> > Applied this variant on top of drm-misc and did a build
On Tue, Jan 15, 2019 at 11:47:00PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: [PATCH] driver core: Fix adding device links to probing suppliers
>
> Currently, it is not valid to add a device link from a consumer
> driver ->probe() callback to a supplier that is still pro
On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > v5: Actually try to sort them, and while at it, sort all the ones I
> > touch.
>
> Applied this variant on top of drm-misc and did a build test.
> Looked good for ia64, x86 and alpha.
>
> Took a closer look at the c
On 1/16/19 4:54 PM, Liam Mark wrote:
> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>> Hi :-)
>>>
>>> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark
On 01/17/2019 10:29 AM, Koenig, Christian wrote:
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On Thu, Jan 17, 2019 at 04:33:35PM +0300, Alexander Shiyan wrote:
> We have two *_CLASS_DEVICE kernel config options (LCD_CLASS_DEVICE
> and BACKLIGHT_LCD_DEVICE) that do the same job.
> The patch removes useless BACKLIGHT_LCD_SUPPORT option
> and converts LCD_CLASS_DEVICE into a menu.
>
> Signed-
On Thu, Jan 17, 2019 at 04:33:36PM +0300, Alexander Shiyan wrote:
> This patch removes dependencies on BACKLIGHT_CLASS_DEVICE for items
> that are already placed under #if BACKLIGHT_CLASS_DEVICE.
Why the # before the if (in Kconfig its just "if" right?).
>
> Signed-off-by: Alexander Shiyan
Any
On Wed, Jan 16, 2019 at 04:38:17PM +0300, Alexander Shiyan wrote:
> Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
> As a side effect, removing #ifdef CONFIG_PM_SLEEP will improve
> compilation coverage.
Adopting SIMPLE_DEV_PM_OPS() results in the suspend/resume functions
being
On 1/16/19 4:48 PM, Liam Mark wrote:
> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13
On Thu, Jan 17, 2019 at 3:54 PM Liviu Dudau wrote:
>
> On Thu, Jan 17, 2019 at 01:32:15PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
> > >
> > > On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> > > > On Thu, Jan 17, 2019 at 12:38 PM Liviu Du
On Thu, Jan 17, 2019 at 04:03:45PM +0100, Lubomir Rintel wrote:
> On Thu, 2019-01-17 at 10:55 +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote:
> > > here are patches that make the Armada DRM work on an OLPC XO-1.75.
> > > They build
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On
On Thu, Jan 17, 2019 at 01:32:15PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
> >
> > On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> > > >
> > > > On Wed, Jan 16, 2019 at 05:39:03PM +
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #4 from Ryan Bair ---
I can confirm the attached patch does fix the issue for i440FX.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
On 01/17/2019 02:40 PM, Peter Rosin wrote:
> On 2019-01-16 17:45, Bartlomiej Zolnierkiewicz wrote:
>> On 01/07/2019 11:35 AM, Peter Rosin wrote:
>>> Right. So, here's an update...
>>>
>>> Again, it would probably be best if this went in before 5.0 is released.
>>>
>>> Changes since v1:
>>> - renam
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #3 from Ryan Bair ---
Thank you both for the responses.
I can confirm using the Q35 machine type does not see this issue.
I'm rebuilding a kernel today to test the patch and will report back.
--
You are receiving this mail beca
Hi Julia,
On Sun, 2019-01-13 at 09:47 +0100, Julia Lawall wrote:
> The device node iterators perform an of_node_get on each
> iteration, so a jump out of the loop requires an of_node_put.
>
> Move the initialization channel->child = child; down to just
> before the call to imx_ldb_register so tha
On 17/01/19 15:26, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 2:04 PM Tomi Valkeinen wrote:
>>
>> On 17/01/19 14:33, Daniel Vetter wrote:
>>> On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
The DRM device minor numbers are allocated according to the registration
order
On Wed, Jan 09, 2019 at 10:33:26AM +0100, Maxime Ripard wrote:
> Now that we have everything we need in the phy framework to allow to tune
> the phy parameters, let's convert the Cadence DSI bridge to that API
> instead of creating a ad-hoc driver for its phy.
>
> Signed-off-by: Maxime Ripard
As
On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
>
> Only the DSI driver has an ad-hoc driver for that phy at the moment, while
> the v4l2 d
On Wed, Jan 09, 2019 at 10:33:23AM +0100, Maxime Ripard wrote:
> The current configuration of the DSI bridge and its associated D-PHY is
> intertwined. In order to ease the future conversion to the phy framework
> for the D-PHY part, let's split the configuration in two.
>
> Signed-off-by: Maxime
On Thu, Jan 17, 2019 at 2:04 PM Tomi Valkeinen wrote:
>
> On 17/01/19 14:33, Daniel Vetter wrote:
> > On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
> >> The DRM device minor numbers are allocated according to the registration
> >> order. This causes confusion in cases where the r
On 17/01/19 14:33, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
>> The DRM device minor numbers are allocated according to the registration
>> order. This causes confusion in cases where the registration order can
>> change, or when, say, a modesetting capa
On Wed, Jan 16, 2019 at 03:52:52PM +0800, Jitao Shi wrote:
> Use the mtk_pwm_data struction to define different registers
> and add MT8183 specific register operations, such as MT8183
> have commit register, needs to enable double buffer
> before writing register, and needs to select commit mode
>
On Wed, Jan 16, 2019 at 11:49 AM Thomas Hellstrom wrote:
>
> Hi,
>
> On Wed, 2019-01-16 at 09:24 -0500, Rob Clark wrote:
> > So, I guess this is to do w/ the magic of merge commits, but it looks
> > like the hunk changing the crtc_ww_class got lost:
>
> So what happened here is that this commit ch
On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
> The DRM device minor numbers are allocated according to the registration
> order. This causes confusion in cases where the registration order can
> change, or when, say, a modesetting capable device is preferred to be
> card0, and a
On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
>
> On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> > >
> > > On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> > > > Compared to the RFC[1] no changes to the
On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> >
> > On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> > > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > > forward a lot:
> > >
> > > -
https://bugs.freedesktop.org/show_bug.cgi?id=108940
--- Comment #16 from H.Habighorst ---
Created attachment 143146
--> https://bugs.freedesktop.org/attachment.cgi?id=143146&action=edit
dmesg from ~agd5f/linux, branch drm-next-5.1-wip, drm.debug=0x06, commit
e7498c5ed98802940cb21e4fb18c9c440b64
On Wed, Jan 16, 2019 at 11:44 PM Rafael J. Wysocki wrote:
>
> On Wednesday, January 16, 2019 7:42:45 PM CET Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 11:47 PM Rafael J. Wysocki
> > wrote:
> > >
> > > [CC Greg]
> > >
> > > On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote
https://bugs.freedesktop.org/show_bug.cgi?id=108940
H.Habighorst changed:
What|Removed |Added
Attachment #143140|0 |1
is obsolete|
On Thu, Jan 17, 2019 at 10:57 AM Hoegeun Kwon wrote:
>
>
> On 1/17/19 6:20 PM, Daniel Vetter wrote:
> > On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
> >> There is a problem in crtc_helper that property value is not updated
> >> when dpms is turned on or off. So modify the property
On Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
>
> On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > forward a lot:
> >
> > - gitlab CI builds with: reduced configs/libraries, arm cross build
> > and a
On Wed, Jan 16, 2019 at 11:41 PM Eric Anholt wrote:
>
> Daniel Vetter writes:
>
> > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > forward a lot:
> >
> > - gitlab CI builds with: reduced configs/libraries, arm cross build
> > and a sysroot build (should address all the
On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> co
The DRM device minor numbers are allocated according to the registration
order. This causes confusion in cases where the registration order can
change, or when, say, a modesetting capable device is preferred to be
card0, and a rendering device is preferred to be card1.
This patch adds similar func
On Tue, Jan 15, 2019 at 10:15:44AM +, Liviu Dudau wrote:
> The initial series is only introducing the basic components and not
> implementing IRQ handling. Remove the left over code that touches
> IRQs until the proper implementation is introduced in a later series.
>
> Signed-off-by: Liviu Du
On Thu, Jan 17, 2019 at 01:01:00PM +0200, Arkadiusz Hiler wrote:
> On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > forward a lot:
> >
> > - gitlab CI builds with: reduced configs/libraries, arm cross build
On Tue, Dec 18, 2018 at 04:37:40PM +0100, Lubomir Rintel wrote:
> It needs to be enabled (at least on MMP2) in order for the register
> writes to LCDC to work.
Dove also has an AXI clock input to the LCDC, but it isn't clear
whether that is necessary for register access or not. From a quick
searc
drm-misc-fixes-2019-01-17:
drm-misc-fixes for v5.0-rc3:
- Add missing calls to of_node_put to sun4i, meson, and rockchip.
- Drop unimplemented prime callbacks in virtio and qxl, so support
for prime is not advertised on those drivers.
- Fix mode switching regression in meson.
The following chang
On Tue, Jan 15, 2019 at 10:15:44AM +, Liviu Dudau wrote:
> The initial series is only introducing the basic components and not
> implementing IRQ handling. Remove the left over code that touches
> IRQs until the proper implementation is introduced in a later series.
>
> Signed-off-by: Liviu Dud
On Wed, Jan 16, 2019 at 05:39:03PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> co
On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote:
> here are patches that make the Armada DRM work on an OLPC XO-1.75.
> They build on patches previously submitted by Russel King (included here for
> completeness as well).
Hi,
Would it be possible for you to re-post patches 1 throug
On Tue, Jan 15, 2019 at 10:15:44AM +, Liviu Dudau wrote:
> The initial series is only introducing the basic components and not
> implementing IRQ handling. Remove the left over code that touches
> IRQs until the proper implementation is introduced in a later series.
>
> Signed-off-by: Liviu Dud
On Thu, 2019-01-17 at 10:30 +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required
> > to
> > do the cache flushing o
Hi Dave and Daniel -
Just gvt this week, quoting Zhenyu:
> This contains one cmd parser failure fix to allow cmd access for one
> register, and fix region cleanup properly in vGPU destroy, and another
> fix for critical mmap size check mistake.
I didn't wait for CI results after pushing, becaus
Hi Laurent,
On Thu, Jan 17, 2019 at 3:07 AM Laurent Pinchart
wrote:
> The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> output when the LVDS0 encoder is used. Enable it despite its output not
> being connected.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
> ---
Den 15.01.2019 05.36, skrev Noralf Trønnes:
> David discovered a bug which gave memory corruption because the tx_buf
> was written past its end for st7586 which has a smaller tx_buf. The
> problem was that mipi_dbi_enable_flush() now calls directly into
> mipi_dbi_fb_dirty() instead of going via
Den 14.01.2019 13.10, skrev Noralf Trønnes:
> CMA helper drivers have been converted to drm_fbdev_generic_setup()
> so the fbdev code can be removed.
>
> v3: Remove CMA specific conditional in the generic fbdev client
>
> v2: Clean up the includes some more (Laurent)
>
> Cc: Laurent Pinchart
On 1/17/19 6:20 PM, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
>> There is a problem in crtc_helper that property value is not updated
>> when dpms is turned on or off. So modify the property value when dpms
>> is on.
>>
>> Signed-off-by: Hoegeun Kwon
> T
Hi,
18. 12. 14. 오후 9:10에 Christoph Manszewski 이(가) 쓴 글:
> Range setting makes sense for YCbCr and RGB buffers. Current
> drm_color_range enum labels suggest use with YCbCr buffers.
> Create enum labels without colorspace specification.
>
> Signed-off-by: Christoph Manszewski
> ---
> include/drm
On Wed, Jan 16, 2019 at 12:32:58PM -0800, Keith Packard wrote:
> Adam Jackson writes:
>
> > If the kernel wanted to expose its quirks db somehow the library could
> > certainly be taught to use it. However there are likely to be quirks
> > relevant only to userspace (see below), making the kernel
On Thu, Jan 17, 2019 at 05:50:44PM +0900, Hoegeun Kwon wrote:
> There is a problem in crtc_helper that property value is not updated
> when dpms is turned on or off. So modify the property value when dpms
> is on.
>
> Signed-off-by: Hoegeun Kwon
This is fixed with atomic, and exynos is atomic. W
On Wed, Jan 16, 2019 at 03:34:36PM -0700, Jonathan Corbet wrote:
> The kerneldoc comment for struct dma_fence_array lacks a description
> of the "work" member, leading to this docs-build warning:
>
> ./include/linux/dma-fence-array.h:54: warning: Function parameter or member
> 'work' not descri
On Tue, Jan 15, 2019 at 04:02:31PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 10:17:09AM +0530, Nishad Kamdar wrote:
> > This switches the fbtft driver to use GPIO descriptors
> > rather than numerical gpios:
> >
> > Utilize the GPIO library's intrinsic handling of OF GPIOs
> > and
Bit 21 can alter the CTRL2_OUTSTANDING_REQS value right after the eLCDIF
is enabled, since it comes up with default value of 1 (this behaviour
has been seen on some imx8 platforms).
In order to fix this, clear CTRL2_OUTSTANDING_REQS bits before setting
its value.
Signed-off-by: Robert Chiras
---
Hi,
On 09/01/19 3:03 PM, Maxime Ripard wrote:
> Now that we have everything we need in the phy framework to allow to tune
> the phy parameters, let's convert the Cadence DSI bridge to that API
> instead of creating a ad-hoc driver for its phy.
>
> Signed-off-by: Maxime Ripard
For this too, need
From: Mirela Rabulea
Add support for the following pixel formats:
16 bpp: RG16 ,BG16, XR15, XB15, AR15, AB15
Set the bus format based on input from the user and panel capabilities.
Save the bus format in crtc->mode.private_flags, the DSI will use it.
Use drm_get_format_name instead of loc
Since version 4 of eLCDIF, there are some registers that can do
transformations on the input data, like re-arranging the pixel
components. By doing that, we can support more pixel formats.
This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
is not supported by eLCDIF, the alpha
On Wed, Jan 16, 2019 at 05:11:34PM +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 02:25:01PM -0700, Jason Gunthorpe wrote:
> > RDMA needs something similar as well, in this case drivers take a
> > struct page * from get_user_pages() and need to have the DMA map fail
> > if the platform can't D
On 16/01/2019 08:52, Jitao Shi wrote:
> Use the mtk_pwm_data struction to define different registers
> and add MT8183 specific register operations, such as MT8183
> have commit register, needs to enable double buffer
has_commit is set to false, so I suppose you mean that MT8183 does not have a
c
Move the pm_runtime_enable call at the end of probbe, since it was made too
early, causing issues to DRM enable routines.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mxs
The eLCDIF controller has control pin for the external LCD reset pin.
Add support for it and assert this pin in enable and de-assert it in
disable.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 10 --
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
2 files changed, 9 i
This switches the fbtft driver to use GPIO descriptors
rather than numerical gpios:
Utilize the GPIO library's intrinsic handling of OF GPIOs
and polarity. If the line is flagged active low, gpiolib
will deal with this.
Remove gpios from platform device structure. Neither assign
statically number
Currently, the MXSFB DRM driver only supports a panel. But, its output
display signal can also be redirected to another encoder, like a DSI
controller. In this case, that DSI controller may act like a drm_bridge.
In order support this use-case too, this patch adds support for
drm_bridge in mxsfb.
From: Mirela Rabulea
Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
This will trigger the execution of disable/enable on
a modeset with different bpp than the current one.
Signed-off-by: Mirela Rabulea
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c
On Thu, 17 Jan 2019 at 07:07, Benjamin Herrenschmidt
wrote:
>
> On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote:
> > > As far as I know on x86 it doesn't, so when you have an un-cached page
> > > you can still access it with a snooping DMA read/write operation and
> > > don't cause trouble
On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a):
> > > > On Sun, Nov
1 - 100 of 115 matches
Mail list logo
