Hello!
On 17.01.2019 4:49, Laurent Pinchart wrote:
On the D3 and E3 SoCs the LVDS encoder has an extended internal PLL and
supplies a clock to the DU. That clock is used not only for the LVDS
outputs but also for the DPAD output. The LVDS encoder thus needs to be
available to the DU even when i
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #104 from Michel Dänzer ---
(In reply to Hans D from comment #103)
> With the latest xf86 DDX driver 3d works better in amdgpu.dc=0, but still
> lags, even though a built-in counter is showing high fps. Does amdgpu.dc=1
> improve 3d
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
---
drivers/gpu/drm/drm_crtc_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_hel
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 somewhat curious case with one HDMI/DVI screen that fails
> > > > to initial
This patchset improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
and 8QXP):
1. Add support for drm_bridge
On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
display connector, where an LCD panel can be attached, but instead it is
connected to DSI controller. Since t
Hi Maxime,
On 09/01/19 3:03 PM, 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 Ripard
Currently, the vblank support is not correctly implemented in MXSFB_DRM
driver. The call to drm_vblank_init is made with mode_config.num_crtc
which at that time is 0. Because of this, vblank is not activated, so
there won't be any vblank event submitted.
Signed-off-by: Robert Chiras
---
drivers/
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 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > > Currently M
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 AM, Liam Mark wrote:
> > On Fri, 11 J
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.
Signed-off-by: Alexander Shiyan
---
drivers/video/backlight/pwm_bl.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
dif
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 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> > > Currently MP clocks don't consider adjusting parent rate even if they
> > > are allowed
Because of stability issues, we may want to limit the maximum resolution
supported by the MXSFB (eLCDIF) driver.
This patch add support for a new property which we can use to impose such
limitation.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 12 ++--
1 file chan
Add new optional property 'max-res', to limit the maximum supported
resolution by the MXSFB_DRM driver.
Signed-off-by: Robert Chiras
---
Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mxsfb.t
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 wrote:
> On Tue, 15 Jan 2019, Andre
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
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 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
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
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
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
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
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
---
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 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 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
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 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
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
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
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!
> ---
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
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
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 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 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, 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
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 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
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
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 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 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 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 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
https://bugs.freedesktop.org/show_bug.cgi?id=108940
H.Habighorst changed:
What|Removed |Added
Attachment #143140|0 |1
is obsolete|
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
--- 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 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:
> > >
> > > -
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 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 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 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 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 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 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 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: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 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
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
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
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 #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 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 +
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
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 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
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 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 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 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 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 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 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 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 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 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 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
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 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
> ---
>
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.
>
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 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:
> > > >
> > > >
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
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
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
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
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
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
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
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:
1 - 100 of 115 matches
Mail list logo
