rm_device *dev = node->minor->dev;
> struct radeon_device *rdev = dev->dev_private;
> + struct drm_device *ddev = rdev->ddev;
>
> - if (rdev->pm.dpm_enabled) {
> + if ((rdev->flags & RADEON_IS_PX) &&
> + (ddev->switch_power_state != DRM_SWITCH_POWER_ON)) {
> + seq_printf(m, "PX asic powered off\n");
> + } else if (rdev->pm.dpm_enabled) {
> mutex_lock(&rdev->pm.mutex);
> if (rdev->asic->dpm.debugfs_print_current_performance_level)
>
> radeon_dpm_debugfs_print_current_performance_level(rdev, m);
--
Ben Hutchings
Life would be so much easier if we could look at the source code.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/48eac60b/attachment.sig>
Hi Daniel
Thank you for comments.
On 05/20/2014 07:02 PM, Daniel Kurtz wrote:
> On Wed, May 14, 2014 at 2:26 PM, YoungJun Cho wrote:
>>
>> There could be the case that the page flip operation isn't finished correctly
>> with some abnormal condition such as panel reset. So this patch replaces
>>
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/dr
Hey,
So this set is pretty close to what I think we should be merging initially,
Since the last set, it makes fbcon and suspend/resume work a lot better,
I've also fixed a couple of bugs in -intel that make things work a lot
better.
I've bashed on this a bit using kms-flip from intel-gpu-tools,
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 10
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
From: Dave Airlie
This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h |
From: Dave Airlie
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files chang
From: Dave Airlie
This is the initial import of the helper for displayport multistream.
It consists of a topology manager, init/destroy/set mst state
It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs
connector detect and edid retrieval interface.
It supports i2c device over
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drive
From: Dave Airlie
This adds DP 1.2 MST support on Haswell systems.
Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.
b) it introduces a new MST output type.
c) it
From: Dave Airlie
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/
From: Dave Airlie
use the mst helper code to dump the topology in debugfs.
v0.2: drop is_mst check - as we want to dump other info
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i9
Hi Bjorn,
On 21 May 2014 04:50, Bjorn Helgaas wrote:
> On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
>> Update some descriptions for API arguments and descriptions.
>>
>> Signed-off-by: Gioh Kim
>
> I applied this to my "dma-api" branch for v3.16, thanks!
As always, I would queue thi
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
Hi,
This series is for the Exynos DRM driver to support MIPI DSI command mode
display and based on exynos-drm-next branch.
The previous patches,
RFC: http://www.spinics.net/lists/dri-devel/msg58898.html
V1: http://www.spinics.net/lists/dri-devel/msg59291.html
Changelog v2:
- Rebases for latest e
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
And clears exynos_crtc->pending_flip in exynos_drm_crtc
This patch adds relevant to exynos5 compatible for exynos5 SoCs.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/arm/samsung/sysreg.txt |1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/sy
This patch adds helper functions to convert cmdmode
to drm_display_mode
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_modes.c | 59 +++
include/drm/drm_modes.h | 12 +
2 files changed, 71 i
This patch adds sysreg property to fimd device node which is required
to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm
This patch adds relevant to exynos5420 compatible for exynos5420 SoC support.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/video/exynos_dsim.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/de
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
in
To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_d
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 568 +
This patch adds DT bindings for command mode display timing.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../bindings/video/cmdmode-display-timing.txt | 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree
This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_disp
To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
In case of using MIPI command mode interface panel,
the relevant registers should be set.
So this patch adds relevant DT bindings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/video/samsung-fimd.txt |2 ++
1 file changed, 2 insertio
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45
1 file changed
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-
To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
page flip request, and implements T
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/bo
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
ind
On 21 May 2014 01:17, Alex Deucher wrote:
> + val = RREG32(HDMI_CONTROL + offset);
> + val &= ~HDMI_DEEP_COLOR_ENABLE;
> + val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
> +
> + switch (bpc) {
> (...)
> + }
> +
> + WREG32(HDMI_CONTROL + offset, val);
What about using hel
On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho wrote:
> There could be the case that the page flip operation isn't finished correctly
> with some abnormal condition such as panel reset. So this patch replaces
> wait_event() with wait_event_timeout() to avoid waiting for page flip
> completion
> i
Hi Daniel
On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho
> wrote:
>> There could be the case that the page flip operation isn't finished correctly
>> with some abnormal condition such as panel reset. So this patch replaces
>> wait_event() with wait_e
On Wed, May 21, 2014 at 2:28 PM, YoungJun Cho wrote:
> Hi Daniel
>
>
> On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
>>
>> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho
>> wrote:
>>>
>>> There could be the case that the page flip operation isn't finished
>>> correctly
>>> with some abnormal condit
On Tue, May 20, 2014 at 03:25:34PM -0700, Jesse Barnes wrote:
> In some cases, the callers of this function may not need the return
> value and delaying the uevent is ok. So add an async version of the
> function for use in those cases.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/dr
On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> Gets the detect code (which may take awhile) out of the resume path,
> speeding things up a bit.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On Tue, May 20, 2014 at 03:25:33PM -0700, Jesse Barnes wrote:
> We really just want to go detect displays again and fire off a hotplug
> event if things have changed, not go through full hotplug processing.
>
> Requested-by: Daniel Vetter
> Signed-off-by: Jesse Barnes
Yeah, still can't remember
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/10ee9825/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/1d919520/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/2abe4d04/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/f1a23892/attachment.html>
On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrj?l? wrote:
> For everything but the reset_vblank_counter() thing:
> Reviewed-by: Ville Syrj?l?
>
> And another caveat: I only glanced at the crtc_helper stuff. It looks
> sane but I didn't go reading through the drivers to figure out if they
> w
For everything but the reset_vblank_counter() thing:
Reviewed-by: Ville Syrj?l?
And another caveat: I only glanced at the crtc_helper stuff. It looks
sane but I didn't go reading through the drivers to figure out if they
would fall over or work.
About the reset_vblank_counter(), I think we might
ice do
you always get the same fence value? Or is this random?
--
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/20140521/42da6b33/attachment.html>
On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrj?l? wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrj?l?
> >
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> >
On Tue, May 20, 2014 at 07:31:33PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > If a pipe is already active when we init/resume there might not be a
> > full modeset afterwards so drm_vblank_on()
Hi Inki, Tomasz,
Any comment on this patch?
Regards,
Rahul Sharma
On 20 May 2014 10:36, Rahul Sharma wrote:
> Exynos drm hdmi driver used to get dummy hdmiphy clock to
> control the PMU bit for hdmiphy. This bit needs to be set
> before setting any resolution to hdmi hardware. This was
> handle
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/96600a25/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140521/03ba0088/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140521/94cc22c0/attachment.html>
Hi Daniel,
On 05/21/2014 03:45 PM, Daniel Kurtz wrote:
> On Wed, May 21, 2014 at 2:28 PM, YoungJun Cho wrote:
>> Hi Daniel
>>
>>
>> On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
>>>
>>> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho
>>> wrote:
There could be the case that the page flip o
quick scan through the DSI specification.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/ce672608/attachment.sig>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/9631ba16/attachment-0001.sig>
Hi Rahul,
On 2014? 05? 07? 20:25, Rahul Sharma wrote:
> From: Rahul Sharma
>
> In case of exynos, setting dma-burst to 16Word causes permanent
> tearing for very small buffers, e.g. cursor buffer. Burst Mode
> switching, which is based on overlay size is not recommended as
> overlay size varies
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/6f0a88e7/attachment.sig>
VBLANK off?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/612c72fa/attachment.sig>
t attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/c6a60c92/attachment.sig>
ivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
Perhaps split off the i915 changes into a separate patch?
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/646a0b7f/attachment.sig>
Hi Therry
On 05/21/2014 08:02 PM, Thierry Reding wrote:
> On Wed, May 21, 2014 at 01:42:56PM +0900, YoungJun Cho wrote:
>> This patch is based on videomode and display_timing relevant codes.
>> To support command mode panel, it does not need to guide its timing
>> information to the display contro
;
> - drm_vblank_post_modeset(dev, pipe);
> -
> if (ret != 0)
Nit: There's now a blank line between ret = ... and if (...).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/d921c4cf/attachment.sig>
vel/attachments/20140521/e171c45b/attachment.html>
On Wed, May 21, 2014 at 01:17:49PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:04PM +0200, Daniel Vetter wrote:
> > From: Ville Syrj?l?
> >
> > Currently there's one per-device vblank disable timer, and it gets
> > reset wheneven the vblank refcount for any crtc drops to zero. Th
On Wed, May 21, 2014 at 01:32:35PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> > From: Ville Syrj?l?
> >
> > drm_vblank_off() will turn off vblank interrupts, but as long as the
> > refcount is elevated drm_vblank_get() will not re-enable them.
The shmem subsystem supports relocating pages on swap-in in case it was
loaded into the wrong zone. This was implemented 2 years ago in:
commit bde05d1ccd512696b09db9dd2e5f33ad19152605
Author: Hugh Dickins
Date: Tue May 29 15:06:38 2012 -0700
shmem: replace page if mapping
on the counters. At
least that would be my expectation.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/e32b4d52/attachment-0001.sig>
d, 6 insertions(+)
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/a554a5fa/attachment.sig>
ion/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/a01e85c6/attachment.sig>
application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/abe0b572/attachment.sig>
On Wed, May 21, 2014 at 02:53:00PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> > If we want to use this functionality in generic helpers to make
> > sure that all drivers have somewhat sane vblank handling across
> > modesets/dpms, we need to make
On Wed, May 21, 2014 at 02:16:26PM +0200, David Herrmann wrote:
> The shmem subsystem supports relocating pages on swap-in in case it was
> loaded into the wrong zone. This was implemented 2 years ago in:
>
> commit bde05d1ccd512696b09db9dd2e5f33ad19152605
> Author: Hugh Dickins
> Dat
On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki wrote:
> On 21 May 2014 01:17, Alex Deucher wrote:
>> + val = RREG32(HDMI_CONTROL + offset);
>> + val &= ~HDMI_DEEP_COLOR_ENABLE;
>> + val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
>> +
>
>> + switch (bpc) {
>> (...)
>> + }
>> +
>
On 21 May 2014 15:51, Alex Deucher wrote:
> On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki wrote:
>> What about using helper:
>>
>> WREG32_P(HDMI_CONTROL + offset,
>> val,
>> ~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));
>
> We could. I don't think it really makes much difference one
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the fin
When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by addi
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will us
Hello Everyone,
On 14 May 2014 17:09, Naveen Krishna Chatradhi wrote:
> exynos_drm_init() does probing of various drivers like dp_panel,
> hdmi, fimd, mixer, etc in an order and finally binds them together.
>
> Some of the drm devices (Eg: dp_panel) try to do regulator_get()
> and enable few supp
Tetsuo Handa wrote:
> From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker
> functions.
>
> I can observe that RHEL7 environment stalls with 100%
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/7c88724d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/948df6f7/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/b31b3250/attachment-0001.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/d3f7bb41/attachment.html>
reedesktop.org/archives/dri-devel/attachments/20140521/3c85e774/attachment.html>
<--[hv]sync_start-
> + * <--[hv]sync_end---> <--[hv]sync_end---
> + * <--[hv]total> <--[hv]total--
> + */
> +
> +/*
> + * sti_vtg_get_line_number
> + *
> + * @mode: display mod
Hi All,
I know it has not been that long since the last send of this series, but
it has been very quiet, and I would like to see some discussion on it
(or it being applied at once, that is fine too :)
This patch-set adds backlight device (un)registration notification and
makes acpi-video listen t
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering
backlight"
is also needed.
https://bugzilla.
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140521/57802969/attachment.html>
e here.
--
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/20140521/02e8b5ff/attachment.html>
On Wed, 21 May 2014 08:52:34 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > Gets the detect code (which may take awhile) out of the resume path,
> > speeding things up a bit.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i9
On Wed, May 21, 2014 at 08:00:22AM -0700, Jesse Barnes wrote:
> On Wed, 21 May 2014 08:52:34 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > > Gets the detect code (which may take awhile) out of the resume path,
> > > speeding things up a bit.
eiving 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/20140521/4cf7e204/attachment-0001.html>
0x000A
> +#define VTAC_6_PPP 0x000C
> +#define VTAC_13_PPP 0x001A
> +#define VTAC_14_PPP 0x001C
> +#define VTAC_15_PPP 0x001E
> +#define VTAC_16_PPP 0x0020
> +#define VTAC_17_PPP 0x0022
> +#define VTAC_18_PPP 0x0024
> +
> +/* enable bits */
> +#define EVEN_PARITY (1 << 13)
> +#define ODD_PARITY (1 << 12)
> +#define SW_RST_AUTOC (1 << 1)
> +#define ENABLE (1 << 0)
These could probably use a VTAC_ prefix for consistency.
> +
> +/*
> + * VTAC mode structure
> + *
> + * @type: main, aux or dvo device
> + * @vid_in_width: Video Data Resolution
These are probably obvious if you know the hardware or can look at the
datasheet, but I have no idea what this field for example means. I had
initially thought that it would contain some number of pixels, but the
table of modes below taught me better. Having some explanation of the
fields in this structure could be useful.
> + * @phyts_width: Width of phyt buses(phyt low and phyt high).
> + * @phyts_per_pixel: Number of phyts sent per pixel
> + */
> +struct sti_vtac_mode {
> + int type;
> + int vid_in_width;
> + int phyts_width;
> + int phyts_per_pixel;
> +};
> +
> +static struct sti_vtac_mode vtac_modes[] = {
> + {VTAC_MAIN, 0x2, 0x2, VTAC_5_PPP}, /* Main RGB 12 */
> + {VTAC_AUX, 0x1, 0x0, VTAC_17_PPP}, /* Aux 10 */
> +};
This doesn't really belong in a header. If you manage to unify both VTAC
Tx and Rx you can simply move this into the VTAC driver source file and
not expose it beyond that at all.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/288efcf0/attachment.sig>
ame: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/29d3f98d/attachment.sig>
t aware of anybody working on this currently, hence I think this
is an appropriate fix in the meantime:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/92cc54e9/attachment.sig>
(HDMI_TIMEOUT_PLL_LOCK));
> +
> + if ((readl(hdmi->regs + HDMI_STA) & HDMI_STA_DLL_LCK) == 0) {
> + DRM_ERROR("hdmi phy pll not locked\n");
> + goto err;
> + }
There doesn't seem to be a need for this to be strictly interrupt
driven. A simple timed loop would do equally well.
> + DRM_DEBUG_DRIVER("got PHY PLL Lock\n");
> +
> + /*
> + * To configure the source termination and pre-emphasis appropriately
> + * for different high speed TMDS clock frequencies a phy configuration
> + * table must be provided, tailored to the SoC and board combination.
> + */
> + for (i = 0; i < NB_HDMI_PHY_CONFIG; i++) {
> + if ((hdmiphy_config[i].min_tmds_freq <= tmdsck) &&
> + (hdmiphy_config[i].max_tmds_freq >= tmdsck)) {
> + val = hdmiphy_config[i].config[0];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_1);
> + val = hdmiphy_config[i].config[1];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_2);
> + val = hdmiphy_config[i].config[2];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_3);
> + val = hdmiphy_config[i].config[3];
> + val |= HDMI_SRZ_CTRL_EXTERNAL_DATA_EN;
> + val &= ~HDMI_SRZ_CTRL_POWER_DOWN;
> + writel(val, hdmi->regs + HDMI_SRZ_CTRL);
> +
> + DRM_DEBUG_DRIVER("serializer cfg 0x%x 0x%x 0x%x 0x%x\n",
> + hdmiphy_config[i].config[0],
> + hdmiphy_config[i].config[1],
> + hdmiphy_config[i].config[2],
> + hdmiphy_config[i].config[3]);
> + return 0;
> + }
> + }
> +
> + /*
> + * Default, power up the serializer with no pre-emphasis or source
> + * termination.
> + */
Should this case produce a warning?
> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_1);
> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_2);
> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_3);
> + writel(HDMI_SRZ_CTRL_EXTERNAL_DATA_EN, hdmi->regs + HDMI_SRZ_CTRL);
> +
> + return 0;
> +
> +err:
> + disable_pll_rejection(hdmi);
> +
> + return -1;
> +}
[...]
> +/*
> + * Debugfs
> + */
> +#define HDMI_DBG_DUMP(reg) seq_printf(m, "\n %-25s 0x%08X", #reg, \
> + readl(hdmi->regs + reg))
> +void sti_hdmi_tx3g0c55phy_show(struct sti_hdmi *hdmi, struct seq_file *m)
> +{
> + HDMI_DBG_DUMP(HDMI_SRZ_PLL_CFG);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_1);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_2);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_3);
> + HDMI_DBG_DUMP(HDMI_SRZ_CTRL);
> + seq_puts(m, "\n");
Why the empty line? Is this supposed to be used as part of a larger
file? I'd recommend against doing that and rather have one debugfs entry
for each device's register file.
> diff --git a/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
> b/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
[...]
Mostly the same comments apply here as for the other PHY.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/608f6680/attachment-0001.sig>
..
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/16303d7d/attachment.sig>
> +};
> +
> +module_platform_driver(sti_hda_driver);
> +
> +MODULE_LICENSE("GPL");
Same comments here as for all previous patches.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/9aabf2da/attachment.sig>
1 - 100 of 113 matches
Mail list logo
