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
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
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
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.
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
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
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
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
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
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
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:
-
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
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 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
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:
>>> -
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
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
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
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
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
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
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
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
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
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=edit
dmesg from ~agd5f/linux, branch drm-next-5.1-wip, drm.debug=0x06, commit
e7498c5ed98802940cb21e4fb18c9c440b646e6a
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
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
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
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
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
>
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
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
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
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
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
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
>
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
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
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
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,
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
>
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
> ---
>
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
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.
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
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
> >
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,
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
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
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
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
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 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
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
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
Currently, the enable of the axi clock return status is ignored, causing
issues when the enable fails then we try to disable it. Therefore, it is
better to check the return status and disable it only when enable
succeeded.
Also, remove the helper functions around clk_axi, since we can directly
use
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
1 - 100 of 115 matches
Mail list logo
