[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
ping. On Thu, May 15, 2014 at 5:10 PM, Ajay kumar wrote: > On Thu, May 15, 2014 at 1:43 PM, Thierry Reding > wrote: >> On Wed, May 14, 2014 at 11:39:30PM +0530, Ajay kumar wrote: >> [...] >>> >> >> diff --git >>> >> >> a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt >>> >> >> b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt >>> >> > [...] >>> >> >> + -led-en-gpio: >>> >> >> + eDP panel LED enable GPIO. >>> >> >> + Indicates which GPIO needs to be powered up as >>> >> >> output >>> >> >> + to enable the backlight. >>> >> > >>> >> > Since this is used to control a backlight, then this should really be a >>> >> > separate node to describe the backlight device (and use the >>> >> > corresponding backlight driver) rather than duplicating a subset of >>> >> > that >>> >> > functionality. >>> >> I am stressing this point again! >>> >> Backlight should ideally be enabled only after: >>> >> 1) Panel is powered up (LCD_VDD) >>> >> 2) HPD is thrown. >>> >> 3) Valid data starts coming from the encoder(DP in our case) >>> >> All the above 3 are controlled inside drm, but pwm-backlight is >>> >> independent of drm. So, we let the pwm_config happen in pwm-backlight >>> >> driver >>> >> and enable backlight GPIO(BL_EN) inside drm, after valid video data >>> >> starts >>> >> coming out of the encoder. >>> > >>> > But that's completely the wrong way around. Why can't you simply control >>> > the backlight from within DRM and only enable it at the right time? >>> I am trying to reuse existing code as much as possible. pwm-backlight driver >>> takes care of generating proper pwm signals for the given backlight value, >>> so I am reusing that part of it. Even though it also provides a way to >>> handle >>> "backlight enable" pin(which is ofcourse optional) I wish to control it in >>> the >>> panel drvier, because generally all panel datasheets say you should control >>> backlight enable along with panel controls. >> >> I still don't see how controlling the enable GPIO from the panel will be >> in any way better, or different for that matter, from simply enabling >> the backlight and let the backlight driver handle the enable GPIO. Have >> you tried to do that and found that it doesn't work? > It works, but it gives me glitch when I try to configure video. > This is because backlight_on(pwm-backlight) happens much before > I configure video(inside drm), and while configuring video there would > be a glitch, > and that glitch would be visible to the user since backlight is already > enabled. > > On the other hand, if I choose to delay enabling backlight till I am sure > enough > that video is properly configured, then even though the glitch comes up, the > user cannot make it out since backlight if off - a better user experience! > >>> >> As you said, we can get this GPIO from a backlight device node, but since >>> >> this GPIO is related to panel also, I think conceptually its not wrong >>> >> to have this >>> >> GPIO binding defined in a panel node. >>> > >>> > It's not related to the panel. It's an enable for the backlight. >>> > Backlight could be considered part of the panel, therefore it makes >>> > sense to control the backlight from the panel driver. >>> Ok. This GPIO goes from my AP to the backlight unit of the panel. >>> Basically, a board related GPIO which exists on all the boards. >>> Where should I be handling this? >> >> In the driver that handles the backlight unit. That is: pwm-backlight. >> >>> >> > What are panel_VCC or video_enable? >>> >> It is the time taken for the panel to throw a valid HPD from the point >>> >> we enabled LCD_VCC. >>> >> After HPD is thrown, we can start sending video data. >>> > >>> > What does "throw a valid HPD" mean? Is it an actual signal that can be >>> > captured via software (GPIO, interrupt, ...)? If so then it would be >>> > preferable to not use a delay at all but rather rely on that mechanism >>> > to determine when it's safe to send a video signal. >>> Right, your explanation holds good, but only for the case of eDP panels. >>> But, when we use eDP-LVDS bridges(ps8622), its a different case! >>> the bridge takes care of sending HPD, so the encoder gets HPD interrupt >>> and tries to read edid from the panel, but the panel might not have powered >>> up >>> enough to read edid. In such cases we would need delay. >>> So, having a delay field here would be really useful. >> >> Okay. >> >>> May be, while describing this particular DT binding I should elaborate more. >> >> Yes, something like the above explanation would be good to have in the >> binding. > Ok, will do that. > >>> >> >> diff --git a/drivers/gpu/drm/bridge/bridge_panel.c >>> >> >> b/drivers/gpu/drm/bridge/bridge_panel.c >>> >> > [...] >>> >> > >>> >> > This duplicates much of the functionality that panels should provide. I >>> >> > think a better solution would be to properly integrate panels with >>> >> > bridges.
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #20 from darkbasic --- > Have you tested with the patch attached to this bug? Still not because I was late and llvm takes a long time to compile, but I will test it tomorrow. -- 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/20140518/4544163f/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Tom Stellard changed: What|Removed |Added Attachment #99187|0 |1 is obsolete|| --- Comment #21 from Tom Stellard --- Created attachment 99254 --> https://bugs.freedesktop.org/attachment.cgi?id=99254&action=edit VGPR Spill Work Around v4 with possible antichamber crash fix Can you try this patch? It should fix the antichamber crash. -- 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/20140518/e316de74/attachment.html>
[PATCH] drm/radeon: avoid segfault on device open when accel is not working.
Hello Christian, no one has picked this. http://lists.freedesktop.org/archives/dri-devel/2014-May/059189.html Even Alex ACKed it. http://lists.freedesktop.org/archives/dri-devel/2014-May/059191.html Greetings, Dieter
[PATCH 1/2] fb: default NvMemExec to on, turning it off is used for debugging only
Signed-off-by: Ilia Mirkin --- Hope I understood you correctly wrt the mem exec stuff. nvkm/subdev/fb/ramnv50.c | 2 +- nvkm/subdev/fb/ramnva3.c | 2 +- nvkm/subdev/fb/ramnvc0.c | 2 +- nvkm/subdev/fb/ramnve0.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/nvkm/subdev/fb/ramnv50.c b/nvkm/subdev/fb/ramnv50.c index ef91b6e..e5d12c2 100644 --- a/nvkm/subdev/fb/ramnv50.c +++ b/nvkm/subdev/fb/ramnv50.c @@ -211,7 +211,7 @@ nv50_ram_prog(struct nouveau_fb *pfb) struct nv50_ram *ram = (void *)pfb->ram; struct nv50_ramseq *hwsq = &ram->hwsq; - ram_exec(hwsq, nouveau_boolopt(device->cfgopt, "NvMemExec", false)); + ram_exec(hwsq, nouveau_boolopt(device->cfgopt, "NvMemExec", true)); return 0; } diff --git a/nvkm/subdev/fb/ramnva3.c b/nvkm/subdev/fb/ramnva3.c index 6eb97f1..8076fb1 100644 --- a/nvkm/subdev/fb/ramnva3.c +++ b/nvkm/subdev/fb/ramnva3.c @@ -309,7 +309,7 @@ nva3_ram_prog(struct nouveau_fb *pfb) struct nouveau_device *device = nv_device(pfb); struct nva3_ram *ram = (void *)pfb->ram; struct nva3_ramfuc *fuc = &ram->fuc; - ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", false)); + ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", true)); return 0; } diff --git a/nvkm/subdev/fb/ramnvc0.c b/nvkm/subdev/fb/ramnvc0.c index 8edc922..5a6a502 100644 --- a/nvkm/subdev/fb/ramnvc0.c +++ b/nvkm/subdev/fb/ramnvc0.c @@ -408,7 +408,7 @@ nvc0_ram_prog(struct nouveau_fb *pfb) struct nouveau_device *device = nv_device(pfb); struct nvc0_ram *ram = (void *)pfb->ram; struct nvc0_ramfuc *fuc = &ram->fuc; - ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", false)); + ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", true)); return 0; } diff --git a/nvkm/subdev/fb/ramnve0.c b/nvkm/subdev/fb/ramnve0.c index 1675219..84c7efb 100644 --- a/nvkm/subdev/fb/ramnve0.c +++ b/nvkm/subdev/fb/ramnve0.c @@ -,7 +,7 @@ nve0_ram_prog(struct nouveau_fb *pfb) struct nouveau_device *device = nv_device(pfb); struct nve0_ram *ram = (void *)pfb->ram; struct nve0_ramfuc *fuc = &ram->fuc; - ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", false)); + ram_exec(fuc, nouveau_boolopt(device->cfgopt, "NvMemExec", true)); return (ram->base.next == &ram->base.xition); } -- 1.8.5.5
[PATCH 2/2] clk: allow end-user reclocking for nv40, nvaa, and nve0 clock types
Use with caution.
Signed-off-by: Ilia Mirkin
---
Same patch as before, but adds nv40 and nve0 as on by default, and removes end
user ability to turn it on for nv50/nva3/nvc0.
I finally found the nv50-related stuff you nuked, and yeah, the current code
definitely can't work as-is. Oh well. I'll play around with reinstating it in
one way or another.
nvkm/include/subdev/clock.h | 8 +---
nvkm/subdev/clock/base.c| 7 +--
nvkm/subdev/clock/nv04.c| 3 ++-
nvkm/subdev/clock/nv40.c| 3 ++-
nvkm/subdev/clock/nv50.c| 2 +-
nvkm/subdev/clock/nva3.c| 3 ++-
nvkm/subdev/clock/nvaa.c| 3 ++-
nvkm/subdev/clock/nvc0.c| 3 ++-
nvkm/subdev/clock/nve0.c| 3 ++-
9 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/nvkm/include/subdev/clock.h b/nvkm/include/subdev/clock.h
index 8f4ced7..c01e29c 100644
--- a/nvkm/include/subdev/clock.h
+++ b/nvkm/include/subdev/clock.h
@@ -77,6 +77,8 @@ struct nouveau_clock {
int tstate; /* thermal adjustment (max-) */
int dstate; /* display adjustment (min+) */
+ bool allow_reclock;
+
int (*read)(struct nouveau_clock *, enum nv_clk_src);
int (*calc)(struct nouveau_clock *, struct nouveau_cstate *);
int (*prog)(struct nouveau_clock *);
@@ -106,8 +108,8 @@ struct nouveau_clocks {
int mdiv;
};
-#define nouveau_clock_create(p,e,o,i,d)
\
- nouveau_clock_create_((p), (e), (o), (i), sizeof(**d), (void **)d)
+#define nouveau_clock_create(p,e,o,i,r,d)
\
+ nouveau_clock_create_((p), (e), (o), (i), (r), sizeof(**d), (void **)d)
#define nouveau_clock_destroy(p) ({
\
struct nouveau_clock *clk = (p); \
_nouveau_clock_dtor(nv_object(clk)); \
@@ -121,7 +123,7 @@ struct nouveau_clocks {
int nouveau_clock_create_(struct nouveau_object *, struct nouveau_object *,
struct nouveau_oclass *,
- struct nouveau_clocks *, int, void **);
+ struct nouveau_clocks *, bool, int, void **);
void _nouveau_clock_dtor(struct nouveau_object *);
int _nouveau_clock_init(struct nouveau_object *);
#define _nouveau_clock_fini _nouveau_subdev_fini
diff --git a/nvkm/subdev/clock/base.c b/nvkm/subdev/clock/base.c
index dd62bae..22351f5 100644
--- a/nvkm/subdev/clock/base.c
+++ b/nvkm/subdev/clock/base.c
@@ -346,8 +346,8 @@ nouveau_clock_ustate_update(struct nouveau_clock *clk, int
req)
struct nouveau_pstate *pstate;
int i = 0;
- /* YKW repellant */
- return -ENOSYS;
+ if (!clk->allow_reclock)
+ return -ENOSYS;
if (req != -1 && req != -2) {
list_for_each_entry(pstate, &clk->states, head) {
@@ -456,6 +456,7 @@ nouveau_clock_create_(struct nouveau_object *parent,
struct nouveau_object *engine,
struct nouveau_oclass *oclass,
struct nouveau_clocks *clocks,
+ bool allow_reclock,
int length, void **object)
{
struct nouveau_device *device = nv_device(parent);
@@ -478,6 +479,8 @@ nouveau_clock_create_(struct nouveau_object *parent,
ret = nouveau_pstate_new(clk, idx++);
} while (ret == 0);
+ clk->allow_reclock = allow_reclock;
+
mode = nouveau_stropt(device->cfgopt, "NvClkMode", &arglen);
if (mode) {
if (!strncasecmpz(mode, "disabled", arglen)) {
diff --git a/nvkm/subdev/clock/nv04.c b/nvkm/subdev/clock/nv04.c
index b74db6c..eb2d442 100644
--- a/nvkm/subdev/clock/nv04.c
+++ b/nvkm/subdev/clock/nv04.c
@@ -82,7 +82,8 @@ nv04_clock_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
struct nv04_clock_priv *priv;
int ret;
- ret = nouveau_clock_create(parent, engine, oclass, nv04_domain, &priv);
+ ret = nouveau_clock_create(parent, engine, oclass, nv04_domain, false,
+ &priv);
*pobject = nv_object(priv);
if (ret)
return ret;
diff --git a/nvkm/subdev/clock/nv40.c b/nvkm/subdev/clock/nv40.c
index db7346f..8a9e168 100644
--- a/nvkm/subdev/clock/nv40.c
+++ b/nvkm/subdev/clock/nv40.c
@@ -213,7 +213,8 @@ nv40_clock_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
struct nv40_clock_priv *priv;
int ret;
- ret = nouveau_clock_create(parent, engine, oclass, nv40_domain, &priv);
+ ret = nouveau_clock_create(parent, engine, oclass, nv40_domain, true,
+ &priv);
*pobject = nv_object(priv);
if (ret)
return ret;
diff --git a/nvkm/subdev/clock/nv50.c b/nvkm/subdev/clock/nv50.c
index 250a6d9..8c13277 100644
--- a/nvkm/subdev/clock/nv50.c
+++ b/nvkm/subdev/clock/nv50.c
@@ -507,7 +507,7 @
[Bug 75917] backlight switches off when starting X - since kernel-3.13
https://bugs.freedesktop.org/show_bug.cgi?id=75917 nl at gnuffy.net changed: What|Removed |Added Summary|backlight switches of when |backlight switches off when |starting X since|starting X - since |kernel-3.13 |kernel-3.13 -- 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/20140518/3c1695b3/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #230 from lockheed --- (In reply to comment #229) > Just wanted to add that after I started using linux-3.14.x my issues with > DPM are gone when using my Mobility Radeon 3650 (rv635/M86). Everything is > just working fine. > Once again, thanks for all the hard work. Francisco, were your problems related to random video crashes while using your system, or related to boot? What laptop are you using, if I may ask? -- 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/20140518/9c755c9e/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #22 from farmboy0+freedesktop at googlemail.com --- Patch v4 fixes the crash in Antichamber: LLVM triggered Diagnostic Handler: SIInstrInfo::storeRegToStackSlot - Can't spill VGPR! LLVM triggered Diagnostic Handler: SIInstrInfo::loadRegToStackSlot - Can't retrieve spilled VGPR! radeon_llvm_compile: Processing Diag Flag LLVM failed to compile shader EE si_state.c:2133 si_shader_select - Failed to build shader variant (type=1) 1 -- 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/20140518/0fa5de9d/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #231 from Francisco Pina Martins --- @lockheed: During initial testing (linux 3.11-rcX - 3.11.X) I used to have booting problems. During 3.12 - 3.13, I had the "frosting" screen problem during usage. Since 3.14 I am not experiencing any of them. Also note that this is no longer my main machine, and as such I don't use it as often nowadays. However, I could very easily reproduce the frosting screen by using enlightenment18 for a few minutes, and this frosting no longer happens even after hours of usage. My laptop is a Compal IFL90 (http://www.notebookcheck.net/Review-Compal-FL90-Notebook.4209.0.html), with a T7500 CPU, and I have replaced the stock nVidia 8600M GT (broken) with a Mobility Radeon HD 3650 (256Mb DDR3 RAM - there is a slower variant of this card with 512Mb DDR2 RAM). The card I am now using comes with the ACER VBios. On the software side, I have a fully up-to-date (as of today) Arch Linux x86_64 (testing repositories disabled - only "stable" stuff). -- 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/20140518/9699bece/attachment.html>
[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black
https://bugs.freedesktop.org/show_bug.cgi?id=77785 --- Comment #18 from smoki --- So i disabled it like in this commit, array size undefined and remove it: http://cgit.freedesktop.org/mesa/mesa/commit/?id=75b7e1df139676f2456fea4d3a57cf0044d8409e For PTTM and ATH games that does not help, but looks very similar to be format issue... it just needs alpha there but not got that :). -- 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/20140518/59dfd872/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #32 from vincent --- Is it likely that the firmware may cause this regression ? I have the firmware from fedora 20, I think they are newer than what was used for initial hawaii bring up and I'm not sure there is any other component that might be involved. -- 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/20140518/e6a4d323/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #232 from lockheed --- @Francisco, Thanks for the clarification. This ?frosting? screne problem ? does it freeze the screen apart from scrambling, and forces you to reboot? I found that on 3.13 I was able to use my laptop sometimes for hours, or even a day, without this happening. But it eventually always happened. I am on a Thinkpad W500 now with two GPUs. I switched to Intel for the moment and everything is fine. I will try again switching back to rv635 to try open drivers. Maybe soon, as you report no problems. However, I came to appreciate the temperature drop, battery life increase, and better Flash performance on the Intel 4500 chip. And I am on arch, too. Which Mesa version are you using? Have you tried this? https://aur.archlinux.org/packages/mesa-r300-r600-radeonsi-git/ -- 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/20140518/8c2d4a24/attachment-0001.html>
[Bug 75401] vgaswitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class)
https://bugzilla.kernel.org/show_bug.cgi?id=75401
--- Comment #12 from Pali Roh?r ---
@Alex Deucher: Why is this bug while loop needed?
static bool radeon_atrm_get_bios(struct radeon_device *rdev)
{
...
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) != NULL) {
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
continue;
status = acpi_get_handle(dhandle, "ATRM", &atrm_handle);
if (!ACPI_FAILURE(status)) {
found = true;
break;
}
}
...
Is not correct to use ACPI_HANDLE directly, something like this (without while
loop)?
static bool radeon_atrm_get_bios(struct radeon_device *rdev)
{
...
if (rdev->pdev)
dhandle = ACPI_HANDLE(&rdev->pdev->dev);
...
This could also eliminate using PCI_CLASS_DISPLAY_VGA.
If I understood correctly, ATRM method is specific for AMD cards so searching
for ATRM method in all avalilable pci devices (which match class) is not
necessary.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[PATCH] drivers/gpu/drm/i915/intel_display: coding style fixes
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b9256aa..ff21924 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -962,7 +962,7 @@ bool ibx_digital_port_connected(struct drm_i915_private
*dev_priv,
u32 bit;
if (HAS_PCH_IBX(dev_priv->dev)) {
- switch(port->port) {
+ switch (port->port) {
case PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
@@ -976,7 +976,7 @@ bool ibx_digital_port_connected(struct drm_i915_private
*dev_priv,
return true;
}
} else {
- switch(port->port) {
+ switch (port->port) {
case PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
@@ -3221,9 +3221,8 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
udelay(100);
/* Ironlake workaround, disable clock pointer after downing FDI */
- if (HAS_PCH_IBX(dev)) {
+ if (HAS_PCH_IBX(dev))
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
- }
/* still set train pattern 1 */
reg = FDI_TX_CTL(pipe);
@@ -5844,7 +5843,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
} else {
i9xx_update_pll(intel_crtc,
has_reduced_clock ? &reduced_clock : NULL,
-num_connectors);
+ num_connectors);
}
skip_dpll:
@@ -6220,8 +6219,7 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
if (intel_panel_use_ssc(dev_priv) && can_ssc) {
DRM_DEBUG_KMS("Using SSC on eDP\n");
val |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
- }
- else
+ } else
val |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
} else
val |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
@@ -8844,7 +8842,7 @@ void intel_prepare_page_flip(struct drm_device *dev, int
plane)
spin_unlock_irqrestore(&dev->event_lock, flags);
}
-inline static void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
+static inline void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
{
/* Ensure that the work item is consistent when activating it ... */
smp_wmb();
@@ -9054,7 +9052,7 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
if (ret)
goto err;
- switch(intel_crtc->plane) {
+ switch (intel_crtc->plane) {
case PLANE_A:
plane_bit = MI_DISPLAY_FLIP_IVB_PLANE_A;
break;
@@ -9333,7 +9331,7 @@ static void intel_modeset_commit_output_state(struct
drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector * connector,
+connected_sink_compute_bpp(struct intel_connector *connector,
struct intel_crtc_config *pipe_config)
{
int bpp = pipe_config->pipe_bpp;
--
1.9.0
[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
On Sun, May 18, 2014 at 2:44 AM, Thierry Reding wrote: > On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote: >> On Thu, May 15, 2014 at 1:43 PM, Thierry Reding > gmail.com> wrote: > [...] >> > I still don't see how controlling the enable GPIO from the panel will be >> > in any way better, or different for that matter, from simply enabling >> > the backlight and let the backlight driver handle the enable GPIO. Have >> > you tried to do that and found that it doesn't work? >> It works, but it gives me glitch when I try to configure video. >> This is because backlight_on(pwm-backlight) happens much before >> I configure video(inside drm), and while configuring video there would >> be a glitch, >> and that glitch would be visible to the user since backlight is already >> enabled. > > Okay, so this means that your backlight is turned on too early. Instead > of working around that problem by moving control of the backlight enable > GPIO from the backlight driver into the panel driver, the correct way to > fix it is to make sure the backlight stays off until video is ready. Ok. Please suggest an idea how to do the same! I have already suggested a simple idea which conforms to a valid spec. Just because enable_gpio is already a part of pwm_bl.c, I somewhat feel like we are forcing people to handle enable_gpio inside pwm_bl.c. Note that, pwm_bl can still work properly without enabling the backlight GPIO. And, I did point out to a valid datasheet from AUO, which clearly indicates why backlight enable GPIO should be a part of panel driver and not pwm_bl driver. I am not trying to say we should remove enable_gpio from pwm_bl. Provided that its already an optional property, and if someone wants to control it in a panel driver, what is wrong in doing so? Regards, Ajay
