Hi Philipp,
A bunch of review comments inline.
On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel wrote:
> From: CK Hu
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sink
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/a8a280bf/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/57ef90c3/attachment.html>
On 4 November 2015 at 00:23, Vincent ABRIOU wrote:
> Hello Dave,
>
> This serie of patches is a bunch of pending patches related with sti/drm
> driver.
>
This breaks my build as the patches it relies on aren't upstream yet.
It relies on platform_register_drivers which I'm sure will be merged in
On Mon, 2015-11-02 at 12:09 +0100, Philipp Zabel wrote:
> Hi Jitao,
>
> Am Montag, den 02.11.2015, 11:53 +0800 schrieb jitao shi:
> [...]
> > > +Example:
> > > + edp-bridge at 18 {
> > > + compatible = "parade,ps8640";
> > > + reg = <0x18>;
> > > + sleep-gpios = <&pio 116 G
Hi Philipp
I'll fixed those comments on V3.
Thank you very much.
Best Regards.
On Mon, 2015-11-02 at 12:34 +0100, Philipp Zabel wrote:
> Hi Jitao,
>
> a few comments below.
>
> Am Montag, den 02.11.2015, 11:54 +0800 schrieb jitao shi:
> [...]
> > > +static int ps8640_check_valid_id(struct ps8
On 10/31/2015 04:04 AM, Bjorn Andersson wrote:
> From: Werner Johansson
>
> This adds support for the Sharp panel found on the Qualcomm
> Snapdragon 800 Dragonboard (APQ8074)
>
> Signed-off-by: Werner Johansson
> Signed-off-by: Bjorn Andersson
Reviewed-by: Archit Taneja
> ---
>
> Change sin
https://bugzilla.kernel.org/show_bug.cgi?id=106901
Aaron Lu changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
Component|Power-Video
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/af1b708d/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/aef74678/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/41816549/attachment-0001.html>
From: Michel Dänzer
I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
out was using a write-combined CPU mapping.
Instead of BUGging out, just set the caching mode to what's needed.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
1 file changed,
From: Michel Dänzer
No use bothering users about this for whom we disable write-combining for
other reasons anyway.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_o
From: Michel Dänzer
Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/
From: Michel Dänzer
They reportedly cause random GPU hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gp
Hi, Michel,
On 11/05/2015 09:08 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
> out was using a write-combined CPU mapping.
>
> Instead of BUGging out, just set the caching mode to what's needed.
>
> Signed-off-by: Mi
Hi Jitao,
some things I missed before.
Am Montag, den 02.11.2015, 10:09 +0800 schrieb Jitao Shi:
[...]
> +static int ps8640_regr(struct i2c_client *client, u16 i2c_addr,
> +u8 reg, u8 *value)
> +{
> + int ret;
> +
> + client->addr = i2c_addr;
I think i2c_new_dummy sho
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/d3afd7ab/attachment.html>
On 05.11.2015 09:25, Michel Dänzer wrote:
> From: Michel Dänzer
>
> They reportedly cause random GPU hangs.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer
For this series Reviewed-by: Christian König
> ---
>
On 04.11.2015 23:13, Alex Deucher wrote:
> On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek wrote:
>> Hi!
>>
>>> index dac78ad..b86f06a 100644
>>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>>> @@ -569,6 +569,8 @@ static u32 atombios_a
On Wed, 23 Sep 2015, Ville Syrjälä wrote:
> On Wed, Sep 23, 2015 at 10:10:31AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> __u64 should be used instead of u64.
>>
>> Feature originally added in:
>>
>> commit e3eb3250d84ef97b766312345774367b6a310db8
>> Author: Rob Clark
>> Dat
Hi Daniel,
Am Donnerstag, den 05.11.2015, 02:49 +0800 schrieb Daniel Kurtz:
> Hi Philipp,
>
> A bunch of review comments inline.
A bunch indeed. Thank you for the feedback.
> On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel
> wrote:
[...]
> > +struct mtk_drm_crtc {
> > + struct drm_crtc
Am Mittwoch, den 04.11.2015, 21:28 -0600 schrieb Rob Herring:
> On Wed, Nov 04, 2015 at 12:44:58PM +0100, Philipp Zabel wrote:
> > From: CK Hu
> >
> > Add device tree binding documentation for the display subsystem in
> > Mediatek MT8173 SoCs.
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Phi
Disable planes if they are on to be blanked CRTC and enable them when
the CRTC is turned back on by DMPS.
This is desirable on HW that loses its context on blanking. When
planes are enabled and disabled with the associated CRTCs, there is no
need to restore the plane context in runtime_resume call
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/f0758961/attachment.html>
On Thu, Nov 5, 2015 at 5:41 AM, Christian König
wrote:
> On 05.11.2015 09:25, Michel Dänzer wrote:
>>
>> From: Michel Dänzer
>>
>> They reportedly cause random GPU hangs.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: M
Hi!
> >> The flickering would vanish completely if that's the reason for the issue
> >> you are seeing.
> >
> >> Try setting ref_div_min and ref_div_max to 2 in
> >> radeon_compute_pll_avivo().
> >
> > Ok, I did this, but no luck, still flickers. But the flicker only
> > happens when something ch
> RADEON_PLL_PREFER_MINM_OVER_MAXP).
> >>>The flickering would vanish completely if that's the reason for the issue
> >>>you are seeing.
> >>>Try setting ref_div_min and ref_div_max to 2 in
> >>> radeon_compute_pll_avivo().
> >>Ok, I did this, but no luck, still flickers. But the flicker onl
On Thu, Nov 5, 2015 at 7:51 AM, Jani Nikula
wrote:
> On Wed, 23 Sep 2015, Ville Syrjälä wrote:
>> On Wed, Sep 23, 2015 at 10:10:31AM +0100, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> __u64 should be used instead of u64.
>>>
>>> Feature originally added in:
>>>
>>> commit e3eb3250d
=no, active=unknown
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151105/40409906/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151105/503a5144/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151105/985f2c32/attachment.html>
On Mon, Nov 02, 2015 at 10:09:25AM +0800, Jitao Shi wrote:
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/display/bridge/ps8640.txt | 43
>
> 1 file chan
ARCH_TEGRA selects RESET_CONTROLLER.
The dependency "depends on RESET_CONTROLLER" is already met.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/tegra/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..a188
On Thursday 05 November 2015 20:15:21 Masahiro Yamada wrote:
> When I was implementing a new reset controller for my SoCs,
> I struggled to make my sub-menu shown under the reset
> controller menu.
> I noticed the Kconfig in reset sub-system are screwed up due to two
> config options (ARCH_HAS_RESE
When I was implementing a new reset controller for my SoCs,
I struggled to make my sub-menu shown under the reset
controller menu.
I noticed the Kconfig in reset sub-system are screwed up due to two
config options (ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER).
I think only the former should be
The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtouint.
Signed-off-by: LABBE Corentin
---
drivers/gpu/drm/drm_modes.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
in
RESET_CONTROLLER should be select'ed by SoCs that support reset
controllers. Use "depends on RESET_CONTROLLER" to describe dependency
between two drivers.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/sti/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
ARCH_ROCKCHIP selects RESET_CONTROLLER.
The dependency "depends on RESET_CONTROLLER" is already met.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/rockchip/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 3
Hi,
A few updates:
On Tue, Nov 03, 2015 at 05:13:48PM -0800, Brian Norris wrote:
> On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> > On 11/03/2015 12:38 PM, Brian Norris wrote:
> > >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> > >(FYI, I came across this by inspecti
The VM default page (used when a VM translation fails) is allocated in
system memory. The VM is misconfigured to interpret the physical address
as referencing a VRAM physical page.
Route default page accesses to system memory.
Signed-off-by: Jay Cornwall
Cc: # v4.2+
---
drivers/gpu/drm/amd/amd
41 matches
Mail list logo
