Hi,
On 10/18/2017 05:13 AM, Jingoo Han wrote:
On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:
From: Tomasz Figa
The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. M
On 10/18/2017 02:13 AM, Dan Carpenter wrote:
We free "edid", then use it again on the next line.
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Dan Carpenter
Thanks for the fix. I've queued this to drm-misc-next.
Archit
diff --git a/drivers/gpu/drm/bridge/a
On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote:
> On 17.10.2017 16:09, Ville Syrjälä wrote:
> > On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> >>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
>
2017년 10월 17일 17:04에 Andrzej Hajda 이(가) 쓴 글:
> On 17.10.2017 09:38, Inki Dae wrote:
>>
>> 2017년 09월 29일 19:05에 Andrzej Hajda 이(가) 쓴 글:
>>> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
>>> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
>>> can be enabled by manipu
On Tue, Oct 17, 2017 at 6:36 PM, wrote:
> From: Frank Rowand
>
> I have found the device tree overlay code to be difficult to read and
> maintain. This patch series attempts to improve that situation.
>
> The cleanup includes some changes visible to users of overlays. The
> only in kernel user
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #54 from Alex Deucher ---
Please see comment 37. We support both snooped and unsnooped access to system
memory. When we use unsnooped, we always use uncached memory. Does i915
always assume dma_bufs are cached?
--
You are receiv
On Fri, Oct 13, 2017 at 07:01:27PM +0200, Lucas Stach wrote:
> Only exposes a single mode and not a complete display timing, as
> the datasheet is rather vague about the minimum/maximum values.
>
> Signed-off-by: Lucas Stach
> ---
> .../display/panel/toshiba,lt089ac29000.txt | 8 +++
On Wed, Oct 18, 2017 at 2:10 AM, Maxime Ripard
wrote:
> On Tue, Oct 17, 2017 at 10:38:45PM +0800, Chen-Yu Tsai wrote:
>> > diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> > b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
>> > index 2d1b4329f54a..e39ec9beef75 100644
>> > --- a/arch
The patch
ASoC: AMD: DMA driver changes for Stoney Platform
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
drm/amdgpu Moving amdgpu asic types to a separate file
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: AMD: Add machine driver for cz rt5650
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Lin
The patch
ASoC: AMD: disabling memory gating in stoney platform
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and s
The patch
ASoC: AMD: Audio buffer related changes for Stoney
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
Hi Daniel,
>> Initially I wondered if this info printk could be moved into
>> vga_arbiter_check_bridge_sharing(), but it's been separated out since
>> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
>> possible."), and upon closer examination, it seems you can't be sure a
>> devic
Boris Brezillon writes:
> This ioctl will allow us to purge inactive userspace buffers when the
> system is running out of contiguous memory.
>
> For now, the purge logic is rather dumb in that it does not try to
> release only the amount of BO needed to meet the last CMA alloc request
> but inst
On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:
>
> From: Tomasz Figa
>
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointer
On Tuesday, October 17, 2017 4:09 AM, Jeffy Chen wrote:
>
> From: Tomasz Figa
>
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointer
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #16 from Harry Wentland ---
That's interesting. No picture needed anymore. I get it now.
This is really weird behavior. Do you have the actual TV model by any chance?
If I get a chance I'd love to see if I can find something similar
https://bugs.freedesktop.org/show_bug.cgi?id=103320
Bug ID: 103320
Summary: Build error with 1.20 release
Product: DRI
Version: XOrg git
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #15 from dwagner ---
(In reply to Harry Wentland from comment #10)
> As for the behavior you're seeing with the modelines removed, I don't fully
> understand what you're seeing. Mind posting a picture? It sounds like we
> should be d
Hi Sebastian,
On Wednesday, 18 October 2017 01:29:56 EEST Sebastian Reichel wrote:
> On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote:
> > This patch series merges the omapdrm and omapdss drivers into a single
> > driver called omapdrm. The split in two drivers was historical, in o
Hi Sebastian,
On Wednesday, 18 October 2017 01:16:53 EEST Sebastian Reichel wrote:
> Hi,
>
> On Fri, Oct 13, 2017 at 05:59:43PM +0300, Laurent Pinchart wrote:
> > As part of an effort to remove the usage of global variables in the
> > driver, store the debugfs root directory in the dss_device str
Hi Laurent,
On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote:
> This patch series merges the omapdrm and omapdss drivers into a single driver
> called omapdrm. The split in two drivers was historical, in order to support
> the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver suppo
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #14 from dwagner ---
(In reply to Alex Deucher from comment #13)
> It's pretty vague unfortunately regarding HDMI:
> It does not explicitly say 4K@60 on HDMI. The high refresh rates may only
> be available on DP.
Well then, if you
Hi,
On Fri, Oct 13, 2017 at 05:59:05PM +0300, Laurent Pinchart wrote:
> The number of function declarations in the omap_drv.h degrades
> readability. To fix it, create new header files for each part of the
> driver and move the related functions.
>
> Signed-off-by: Laurent Pinchart
> ---
Review
Hi,
On Fri, Oct 13, 2017 at 05:59:44PM +0300, Laurent Pinchart wrote:
> As part of an effort to remove the usage of global variables in the
> driver, store the registered plls array in the dss_device structure
> instead of a global variable.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by
Hi,
On Fri, Oct 13, 2017 at 05:59:43PM +0300, Laurent Pinchart wrote:
> As part of an effort to remove the usage of global variables in the
> driver, store the debugfs root directory in the dss_device structure
> instead of a global variable.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/
Hi,
On Fri, Oct 13, 2017 at 05:59:42PM +0300, Laurent Pinchart wrote:
> The dispc private data structure is currently stored as a global
> variable. While no platform with multiple DISPC currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be fixed.
Quoting Thierry Reding (2017-10-12 14:29:39)
> diff --git a/lib/igt_x86.h b/lib/igt_x86.h
> index d6dcfa108331..27b7f0fd5837 100644
> --- a/lib/igt_x86.h
> +++ b/lib/igt_x86.h
> @@ -40,7 +40,7 @@
> #define AVX0x80
> #define AVX2 0x100
>
> -#if defined(__x86_64__)
> +#if defined(__x86_64__
Hi Sebastian,
On Wednesday, 18 October 2017 00:24:54 EEST Sebastian Reichel wrote:
> Hi,
>
> On Fri, Oct 13, 2017 at 05:59:41PM +0300, Laurent Pinchart wrote:
> > This removes the need to access the global DISPC private data in those
> > functions (both for the current accesses and the future one
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #53 from Chris Wilson ---
Created attachment 134897
--> https://bugs.freedesktop.org/attachment.cgi?id=134897&action=edit
Shotgun attempt to stop pulling external images into the L3 (mesa/i965)
--
You are receiving this mail beca
Hi,
On Fri, Oct 13, 2017 at 05:59:41PM +0300, Laurent Pinchart wrote:
> This removes the need to access the global DISPC private data in those
> functions (both for the current accesses and the future ones that will
> be introduced when allocating the DISPC private data dynamically).
>
> Signed-o
Hi,
On Fri, Oct 13, 2017 at 05:59:40PM +0300, Laurent Pinchart wrote:
> This removes the need to access the global DISPC private data in those
> functions (both for the current accesses and the future ones that will
> be introduced when allocating the DISPC private data dynamically).
>
> In order
Hi,
On Fri, Oct 13, 2017 at 05:59:39PM +0300, Laurent Pinchart wrote:
> The dss_mgr_ops operations implemented by the omapdrm side have to look
> up the omap_crtc objects from global variables as they are only passed a
> channel number. In order to remove global variables pass the
> omap_drm_priva
https://bugs.freedesktop.org/show_bug.cgi?id=103304
--- Comment #2 from Nicolai Hähnle ---
Oh wow, now that I've actually looked at the issue in more detail, I'm pretty
amazed that you actually managed to hit this issue! Congratulations! :)
The true analysis is a bit different, I would say. The
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sei
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-simple.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-in
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-
They're not necessary for atomic drivers, and drm_panel will WARN if
the calls are unbalanced.
Signed-off-by: Sean Paul
---
No changes since v1
.../gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/panel/pan
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-
I noticed while removing the enabled flag that backlight update checks
prepared in such a way that could race with hardware turning on/off.
This patch adds a mutex to ensure these races don't happen.
In addition to the lock, this patch also renames prepared to initialized
to better reflect what it
A number of panel drivers track enabled/prepared state (I suspect to protect
regulator refcounts). However, the atomic framework already ensures that
prepare/unprepare and enable/disable calls are balanced. This series removes all
independent tracking from the drivers and adds a WARNING to the core
It's not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-orisetec
In preparation for state tracking in drm_panel, move the panel functions
into drm_panel.c so we beef them up in later patches.
Signed-off-by: Sean Paul
---
New in v3
drivers/gpu/drm/drm_panel.c | 77
include/drm/drm_panel.h | 78 +++--
This patch adds state tracking to the drm_panel functions which keep
track of enabled and prepared. If the calls are unbalanced, a WARNING is
issued.
The motivation for this change is that a number of panel drivers
(including panel-simple) all do this to protect their regulator
refcounts. The atom
They're not necessary for atomic drivers, and drm_panel will
WARN if the calls are unbalanced.
Signed-off-by: Sean Paul
---
No changes since v1
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel
Signed-off-by: Sean Paul
---
New in v3
include/drm/drm_panel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 14ac240a1f64..ab59d71a24c3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -96,7 +96,7
https://bugs.freedesktop.org/show_bug.cgi?id=103234
--- Comment #5 from Nicolai Hähnle ---
Thank you for the report!
Can you try with Mesa from git master?
The issue is that in Mesa 17.2.2 (which you have according to glxinfo),
si_state_draw.c:1305 corresponds to
1304
https://bugs.freedesktop.org/show_bug.cgi?id=101691
--- Comment #52 from Daniel Vetter ---
Reassigning to amdgpu.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
https://bugs.freedesktop.org/show_bug.cgi?id=101691
Daniel Vetter changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
We free "edid", then use it again on the next line.
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 31ca883bda83..0e14f1572d05 100644
--- a/d
Hi,
On Fri, Oct 13, 2017 at 05:59:38PM +0300, Laurent Pinchart wrote:
> The omap_dss_register_driver(), omap_dss_unregister_driver() and
> dispc_enable_gamma_table() functions don't exist anymore, remove their
> prototypes.
>
> Signed-off-by: Laurent Pinchart
> ---
Yeah, I also found the ones f
https://bugs.freedesktop.org/show_bug.cgi?id=103130
--- Comment #7 from Nicolai Hähnle ---
Thanks for the report!
The error message is benign. The only possible way in which it cause issues is
if the application itself is also trying to use LLVM.
If you could provide a backtrace with debug symb
https://bugs.freedesktop.org/show_bug.cgi?id=103304
--- Comment #1 from Nicolai Hähnle ---
Do you have a simple test application you can share that reproduces this
reliably?
--
You are receiving this mail because:
You are the assignee for the bug.___
On Tue, Oct 17, 2017 at 4:16 PM, Eric Anholt wrote:
> Rob Clark writes:
>
>> Bootloader enabled display, when the driver is built-in (rather than a
>> module loaded after CCF/genpd disable "unused" clocks/powerdomains)
>> causes problems since the driver thinks the clocks are off, but in fact
>>
Hi,
On Fri, Oct 13, 2017 at 05:59:37PM +0300, Laurent Pinchart wrote:
> The dss_mgr_*() functions take a channel argument to identify the
> channel they operate on. This prevents the functions from accessing
> driver data structures without resorting to global variables. In an
> effort to remove g
Rob Clark writes:
> Bootloader enabled display, when the driver is built-in (rather than a
> module loaded after CCF/genpd disable "unused" clocks/powerdomains)
> causes problems since the driver thinks the clocks are off, but in fact
> they are on. This causes (for example) clk_set_rate() to fa
Hi,
On Fri, Oct 13, 2017 at 05:59:36PM +0300, Laurent Pinchart wrote:
> The dsi_display_init_dispc() and dsi_display_uninit_dispc() functions
> take a channel argument that is reduntant as it is always identical to
> the dsi->output.dispc_channel. Remove the argument and use the field
> directly i
Hi,
On Fri, Oct 13, 2017 at 05:59:35PM +0300, Laurent Pinchart wrote:
> The dsi_data structure stores a pointer to a struct platform_device. The
> driver only uses the dev member of the platform device structure. Store
> the struct device pointer instead and use it directly.
>
> Signed-off-by: La
Hi,
On Fri, Oct 13, 2017 at 05:59:34PM +0300, Laurent Pinchart wrote:
> The dsi_bind() function receives a pointer to a struct device that it
> casts to a struct platform_device, only to use the platform device's dev
> field through the code. Use the dev pointer directly.
>
> While at it rename t
Hi,
On Fri, Oct 13, 2017 at 05:59:33PM +0300, Laurent Pinchart wrote:
> The dsi_get_dsidrv_data() and dsi_get_dsidev_from_dssdev() inline
> functions convert a struct omap_dss_device pointer to the corresponding
> struct platform_device, and a struct platform_device pointer to the
> corresponding
Hi,
On Fri, Oct 13, 2017 at 05:59:32PM +0300, Laurent Pinchart wrote:
> Internal dsi functions take a pointer to the DSI platform_device and
> then cast it to a dsi_data pointer. That's pointless as the caller
> already has the dsi_data pointer. Pass it directly instead of the
> platform_device po
On Tue, Oct 17, 2017 at 02:43:38AM -0600, Haneen Mohammed wrote:
> This patch extract DRM_* debug macros from drmP.h to drm_print.h and
> move printing related functions used by these macros from drm_drv.[hc]
> to drm_print.[hc].
>
> Signed-off-by: Haneen Mohammed
> ---
> Changes in v3:
> - Move
On Wed, Oct 11, 2017 at 01:23:37PM +0200, Lothar Waßmann wrote:
> Signed-off-by: Lothar Waßmann
> ---
> .../bindings/display/panel/edt,et0350g0dh6.txt| 7 +++
Please split bindings to separate patch.
> drivers/gpu/drm/panel/panel-simple.c | 19
> ++
Hi,
On Tue, Oct 17, 2017 at 10:09:46PM +1100, Jonathan Liu wrote:
> Dithering is supported on TCON channel 0 which is used for LCD panels.
Expanding a bit the commit log would be great. What is dithering, why
is this needed in the first place, what is it trying to fix, etc.
> Signed-off-by: Jona
https://bugs.freedesktop.org/show_bug.cgi?id=103317
--- Comment #1 from Torsten Kessler ---
Created attachment 134889
--> https://bugs.freedesktop.org/attachment.cgi?id=134889&action=edit
Dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=103317
Bug ID: 103317
Summary: Tearing in WQHD, but not in FHD
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=103234
--- Comment #4 from Dennis Schridde ---
I now also have this card plugged into the system:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Baffin [Radeon RX 560] (rev cf) (prog-if 00 [VGA controller])
Subsystem
Hi,
On Fri, Oct 13, 2017 at 05:59:31PM +0300, Laurent Pinchart wrote:
> The wait_for_bit_change() function returns the value of the bit it
> polls. This requires the caller to compare the return value to the
> expected bit value. As all the existing callers need is to check whether
> the bit has r
https://bugs.freedesktop.org/show_bug.cgi?id=103234
--- Comment #3 from Dennis Schridde ---
It just happened again:
Application: KWin (kwin_x11), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc355251d00 (LWP 3241))]
Threa
Hi,
On Fri, Oct 13, 2017 at 05:59:30PM +0300, Laurent Pinchart wrote:
> The sdi private data structure is currently stored as a global
> variable. While no platform with multiple SDI encoders currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be f
On 17.10.2017 19:16, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote:
On 17/10/17 05:04 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
On 17/10/17 02:22 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 12:28:17PM +0200, Miche
On 17.10.2017 16:09, Ville Syrjälä wrote:
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
On 17/10/17 02:22 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
Common sense suggests that there nee
Hi,
On Fri, Oct 13, 2017 at 05:59:29PM +0300, Laurent Pinchart wrote:
> The venc private data structure is currently stored as a global
> variable. While no platform with multiple VENC encoders currently exists
> nor is planned, this doesn't comply with the kernel device model and
> should thus be
Hi,
On Fri, Oct 13, 2017 at 05:59:28PM +0300, Laurent Pinchart wrote:
> The omap_hdmi private data structure is currently stored as a global
> variable. While no platform with multiple HDMI5 encoders currently
> exists nor is planned, this doesn't comply with the kernel device model
> and should t
https://bugs.freedesktop.org/show_bug.cgi?id=103316
Bug ID: 103316
Summary: [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632
at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548
ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
Prod
On Tue, Oct 17, 2017 at 06:16:24PM +0800, Jeffy Chen wrote:
> Since we are trying to access components' resources in the master's
> suspend/resume PM callbacks(e.g. panel), add device links to correct
> the suspend/resume and shutdown ordering.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in
On 10/18/2017 04:06 AM, Pavel Roskin wrote:
> Ben, David,
>
> I would hate if Linux 4.14 is released without this fix, as it would
> be a regression for my machine. As I mentioned, Linux 4.13 registers
> nouveaufb even without the dock, but Linux 4.14 doesn't. And that
> would cause an oops even i
On Tue, Oct 17, 2017 at 06:16:22PM +0800, Jeffy Chen wrote:
> From: Tomasz Figa
>
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
> owned by its driver struct. Moreover, storing two different pointe
On Tue, Oct 17, 2017 at 06:16:21PM +0800, Jeffy Chen wrote:
> Add missing error handling in bind().
>
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/gpu
On Tue, Oct 17, 2017 at 06:16:20PM +0800, Jeffy Chen wrote:
> Add missing clk_disable_unprepare() in bind()'s error handling path.
This also isn't disabled in unbind(), is that intentional?
>
> Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
> Signed-off-by: Jeffy Chen
On Tue, Oct 17, 2017 at 10:38:45PM +0800, Chen-Yu Tsai wrote:
> > diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > index 2d1b4329f54a..e39ec9beef75 100644
> > --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> > +++ b/arch/arm
On Tue, Oct 17, 2017 at 06:16:19PM +0800, Jeffy Chen wrote:
> Add missing pm_runtime_disable() in bind()'s error handling path.
>
> Also cleanup encoder & connector in unbind().
>
> Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
> Signed-off-by: Jeffy Chen
> ---
>
>
On Tue, Oct 17, 2017 at 06:16:18PM +0800, Jeffy Chen wrote:
> Add missing error handling in rockchip_dp_bind().
>
> Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
On Tue, Oct 17, 2017 at 01:47:36PM -0400, Sean Paul wrote:
> On Tue, Oct 17, 2017 at 04:59:39PM +0200, Daniel Vetter wrote:
> > At least when they have vblank support they need to call this, or the
> > vblank core will happily call into their crtc->enable_vblank callback
> > even when the crtc is o
On Tue, Oct 17, 2017 at 04:59:39PM +0200, Daniel Vetter wrote:
> At least when they have vblank support they need to call this, or the
> vblank core will happily call into their crtc->enable_vblank callback
> even when the crtc is off. Which leads to a boom when the clocks are
> off on most hardwar
https://bugzilla.kernel.org/show_bug.cgi?id=60857
mirh (m...@protonmail.ch) changed:
What|Removed |Added
CC||m...@protonmail.ch
--- Comment
Hey Adrian,
This looks good to me. Pushed!
Sorry about the late reply, I was under the weather for a bit.
Would you be interested in commit rights to this project?
Rob.
On Mon, 2017-10-02 at 11:31 -0700, Adrian Salido wrote:
> There are instances where the primary plane may have been disabled,
https://bugs.freedesktop.org/show_bug.cgi?id=37696
mirh changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote:
> On 17/10/17 05:04 PM, Daniel Vetter wrote:
>> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> On 17/10/17
On Tue, Oct 17, 2017 at 06:29:18PM +0200, Daniel Vetter wrote:
> Inspired by discussions with Keith and Ville.
>
> Cc: Ville Syrjälä
> Cc: Keith Packard
> Signed-off-by: Daniel Vetter
Acked-by: Sean Paul
> ---
> Documentation/gpu/todo.rst | 12
> 1 file changed, 12 insertions(+
On Tue, Oct 17, 2017 at 7:56 AM, Thierry Reding
wrote:
> On Tue, Oct 17, 2017 at 02:44:23PM +0200, Lothar Waßmann wrote:
>> Hi,
>>
>> On Tue, 17 Oct 2017 14:12:40 +0200 Thierry Reding wrote:
>> > On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote:
>> > > The baseboards for the Ka-Ro el
Hi,
On Tue, Oct 17, 2017 at 04:13:55PM +0800, Jeffy Chen wrote:
> On 10/17/2017 07:57 AM, Brian Norris wrote:
> >This is going to be a*lot* of churn throughout the tree, if we expect
> >all resource consumers to do this. I think we'd want some kind of
> >agreement from the PM maintainers and (lar
Hi Ulrich,
(CC'ing Matthias Brugger and Daniel Kurtz)
On Monday, 16 October 2017 18:31:32 EEST Ulrich Hecht wrote:
> Hi!
>
> This is a new revision of the Acer Chromebook R13 support series. It does
> not offer anything new in terms of functionality, but eliminates three out
> of four ugly hacks
Inspired by discussions with Keith and Ville.
Cc: Ville Syrjälä
Cc: Keith Packard
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 92ee2f982572..96f8ec7dbe
Hi,
Sorry for being slow to reply, I've been a bit overwhelmed with
other stuff lately.
On 10/02/2017 10:01 AM, Daniel Vetter wrote:
On Sun, Oct 01, 2017 at 05:33:14PM +0200, Hans de Goede wrote:
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot
https://bugzilla.kernel.org/show_bug.cgi?id=197103
--- Comment #4 from Igor Gnatenko (i.gnatenko.br...@gmail.com) ---
(In reply to Thorsten Leemhuis from comment #2)
> Did you try to bring this to the nouveau developer list? Not sure if the
> drivers developers look here. Did you consider to bisec
On Tue, Oct 17, 2017 at 12:33:09PM +0200, Matthias Brugger wrote:
> Hi Ulrich,
>
> On 10/16/2017 05:31 PM, Ulrich Hecht wrote:
> > Hi!
> >
> > This is a new revision of the Acer Chromebook R13 support series. It does
> > not offer anything new in terms of functionality, but eliminates three out
>
On Mon, Oct 09, 2017 at 04:07:04PM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
>
> Documentation/devicetree/bindings/display/panel/panel-rgb.txt
>
> Signed-off-by: San
1 - 100 of 298 matches
Mail list logo
