* Re: [PATCH 2/2] staging: sm750fb: add spaces around operator
From: Dan Carpenter @ 2015-11-08 6:35 UTC (permalink / raw)
To: Othmar Pasteka
Cc: sudipm.mukherjee, teddy.wang, sudip, greg, devel, linux-fbdev,
linux-kernel
In-Reply-To: <dff05f0aaa83ddedafd5f061548dc2ba75486fd3.1446942955.git.pasteka@kabsi.at>
If it's a one line fix then just send it as a single patch.
regards,
dan carpenter
^ permalink raw reply
* [PATCH 2/2] staging: sm750fb: add spaces around operator
From: Othmar Pasteka @ 2015-11-08 0:43 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, sudip, greg
Cc: devel, linux-fbdev, linux-kernel, Othmar Pasteka
In-Reply-To: <e426148688caace0a5083b379c1eaab85e424c74.1446942955.git.pasteka@kabsi.at>
checkpatch.pl says: CHECK: spaces preferred around that '+' (ctx:VxV)
Signed-off-by: Othmar Pasteka <pasteka@kabsi.at>
---
drivers/staging/sm750fb/sm750_cursor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index cab891c..0a41585 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -143,7 +143,7 @@ void hw_cursor_setData(struct lynx_cursor *cursor,
iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
- if ((i+1) % pitch = 0) {
+ if ((i + 1) % pitch = 0) {
/* need a return */
pstart += offset;
pbuffer = pstart;
--
2.5.3
^ permalink raw reply related
* [PATCH 1/2] staging: sm750fb: move opening brace to previous line
From: Othmar Pasteka @ 2015-11-08 0:43 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, sudip, greg
Cc: devel, linux-fbdev, linux-kernel, Othmar Pasteka
Fixes the checkpatch.pl error:
ERROR: that open brace { should be on the previous line
Signed-off-by: Othmar Pasteka <pasteka@kabsi.at>
---
drivers/staging/sm750fb/sm750_cursor.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index 3b7ce92..cab891c 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -143,8 +143,7 @@ void hw_cursor_setData(struct lynx_cursor *cursor,
iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
- if ((i+1) % pitch = 0)
- {
+ if ((i+1) % pitch = 0) {
/* need a return */
pstart += offset;
pbuffer = pstart;
--
2.5.3
^ permalink raw reply related
* Re: [PATCH v3 01/12] pwm: introduce default period and polarity concepts
From: Alexandre Belloni @ 2015-11-07 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1442828009-6241-2-git-send-email-boris.brezillon@free-electrons.com>
On 21/09/2015 at 11:33:18 +0200, Boris Brezillon wrote :
> When requested by a user, the PWM is assigned a default period and polarity
> extracted from the DT, the platform data or statically set by the driver.
> Those default values are currently stored in the period and polarity
> fields of the pwm_device struct, but they will be stored somewhere else
> once we have introduced the architecture allowing for hardware state
> retrieval.
>
> The pwm_set_default_polarity and pwm_set_default_period should only be
> used by PWM drivers or the PWM core infrastructure to specify the
> default period and polarity values.
>
> PWM users might call the pwm_get_default_period to query the default
> period value. There is currently no helper to query the default
> polarity, but it might be added later on if there is a need for it.
>
> This patch also modifies all the places where the default helpers should
> be used in place of the standard ones.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
For pwm-sun4i:
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-06 12:45 UTC (permalink / raw)
To: Michel Dänzer
Cc: linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Deucher, Alexander,
Christian König
In-Reply-To: <563C0F85.8070204@daenzer.net>
On Fri 2015-11-06 11:25:09, Michel Dänzer wrote:
> On 06.11.2015 05:23, Pavel Machek wrote:
> > 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 changes on screen, like dragging a big
> >>> window. Is that consistent with wrong PLL timings?
> >>
> >> Does it go away with radeon.dpm=0? Sounds more like either memory
> >> reclocking happening outside of vblank, or underflow to the display
> >> controllers.
> >
> > No, it does not:
> >
> > pavel@half:~$ cat /proc/cmdline
> > BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> > resume=/dev/sda1 radeon.dpm=0
> >
> > ..and same issue. And yes, it looks like an underflow to me. How can I
> > debug reclocking / underflows?
>
> Does radeon.disp_priority=2 help?
Tried this, and no change, still flickers.
pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
pavel@half:~$
I searched for some more config options, and tried:
pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
radeon.amdgpu_runtime_pm=0 radeon.bapm=0 radeon.sched_hw_submission=0
radeon.enable_semaphores=0
pavel@half:~$
..still flickers.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: YH Huang @ 2015-11-06 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1446716430.3894.12.camel@pengutronix.de>
On Thu, 2015-11-05 at 10:40 +0100, Philipp Zabel wrote:
> >
> > Based on this, could we disable it initially and update in the
> > backlight_update_status function?
> >
> > Like this,
> >
> > if (pb->enable_gpio) {
> > if (phandle &&
> > gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
> > gpiod_get_value(pb->enable_gpio) = 1)
> > gpiod_direction_output(pb->enable_gpio, 1);
>
> The gpiod_direction_output call is a no-op, since the direction is
> already output and the value is already 1.
> Also, I propose to set initial blanking to FB_BLANK_POWERDOWN in this
> case, and wait for the panel driver to enable the backlight at the
> appropriate time.
Thanks your kindly reply.
Your patch looks good to me.
Regards,
YH Huang
^ permalink raw reply
* [PATCH V2] goldfish: add goldfish match node for dt driver probe
From: yalin wang @ 2015-11-06 7:12 UTC (permalink / raw)
To: dmitry.torokhov, sre, dbaryshkov, dwmw2, gregkh, jslaby, plagnioj,
tomi.valkeinen, yalin.wang2010, peter.senna, dan.carpenter, joe,
alan, somyaanand214, ricardo.ribalda, mahfouz.saif.elyazal,
ravi2j, linux-input, linux-kernel, linux-pm, devel, linux-fbdev
qemu use device tree to bootup linux kernel,
we need add device node match table to plaftorm driver,
so that can probe the goldfish driver correctly.
test by this qemu:
git clone https://android.googlesource.com/platform/external/qemu
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/input/keyboard/goldfish_events.c | 9 +++++++++
drivers/platform/goldfish/goldfish_pipe.c | 11 ++++++++++-
drivers/power/goldfish_battery.c | 11 ++++++++++-
drivers/staging/goldfish/goldfish_audio.c | 11 ++++++++++-
drivers/staging/goldfish/goldfish_nand.c | 11 ++++++++++-
drivers/tty/goldfish.c | 11 ++++++++++-
drivers/video/fbdev/goldfishfb.c | 10 +++++++++-
7 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/goldfish_events.c b/drivers/input/keyboard/goldfish_events.c
index 907e4e2..7b99ab8 100644
--- a/drivers/input/keyboard/goldfish_events.c
+++ b/drivers/input/keyboard/goldfish_events.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <linux/input.h>
#include <linux/kernel.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/irq.h>
@@ -178,10 +179,18 @@ static int events_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_events_match[] = {
+ { .compatible = "generic,goldfish-events-keypad" },
+ { },
+};
+#endif
+
static struct platform_driver events_driver = {
.probe = events_probe,
.driver = {
.name = "goldfish_events",
+ .of_match_table = of_match_ptr(goldfish_events_match),
},
};
diff --git a/drivers/platform/goldfish/goldfish_pipe.c b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..55b6d7c 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -50,6 +50,7 @@
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/miscdevice.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/poll.h>
#include <linux/sched.h>
@@ -615,11 +616,19 @@ static int goldfish_pipe_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_pipe_match[] = {
+ { .compatible = "generic,android-pipe" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_pipe = {
.probe = goldfish_pipe_probe,
.remove = goldfish_pipe_remove,
.driver = {
- .name = "goldfish_pipe"
+ .name = "goldfish_pipe",
+ .of_match_table = of_match_ptr(goldfish_pipe_match),
}
};
diff --git a/drivers/power/goldfish_battery.c b/drivers/power/goldfish_battery.c
index a50bb98..48b057d 100644
--- a/drivers/power/goldfish_battery.c
+++ b/drivers/power/goldfish_battery.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/types.h>
@@ -227,11 +228,19 @@ static int goldfish_battery_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_battery_match[] = {
+ { .compatible = "generic,goldfish-battery" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_battery_device = {
.probe = goldfish_battery_probe,
.remove = goldfish_battery_remove,
.driver = {
- .name = "goldfish-battery"
+ .name = "goldfish-battery",
+ .of_match_table = of_match_ptr(goldfish_battery_match),
}
};
module_platform_driver(goldfish_battery_device);
diff --git a/drivers/staging/goldfish/goldfish_audio.c b/drivers/staging/goldfish/goldfish_audio.c
index b0927e4..f0c5118 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/miscdevice.h>
#include <linux/fs.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/types.h>
#include <linux/pci.h>
@@ -344,11 +345,19 @@ static int goldfish_audio_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_audio_match[] = {
+ { .compatible = "generic,goldfish-audio" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_audio_driver = {
.probe = goldfish_audio_probe,
.remove = goldfish_audio_remove,
.driver = {
- .name = "goldfish_audio"
+ .name = "goldfish_audio",
+ .of_match_table = of_match_ptr(goldfish_audio_match),
}
};
diff --git a/drivers/staging/goldfish/goldfish_nand.c b/drivers/staging/goldfish/goldfish_nand.c
index 623353db5..d4c4285 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -23,6 +23,7 @@
#include <linux/ioport.h>
#include <linux/vmalloc.h>
#include <linux/mtd/mtd.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/goldfish.h>
@@ -430,11 +431,19 @@ static int goldfish_nand_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_nand_match[] = {
+ { .compatible = "generic,goldfish-nand" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_nand_driver = {
.probe = goldfish_nand_probe,
.remove = goldfish_nand_remove,
.driver = {
- .name = "goldfish_nand"
+ .name = "goldfish_nand",
+ .of_match_table = of_match_ptr(goldfish_nand_match),
}
};
diff --git a/drivers/tty/goldfish.c b/drivers/tty/goldfish.c
index 0f82c0b..a49f4a2 100644
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
@@ -324,11 +325,19 @@ static int goldfish_tty_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_tty_match[] = {
+ { .compatible = "generic,goldfish-tty" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_tty_platform_driver = {
.probe = goldfish_tty_probe,
.remove = goldfish_tty_remove,
.driver = {
- .name = "goldfish_tty"
+ .name = "goldfish_tty",
+ .of_match_table = of_match_ptr(goldfish_tty_match),
}
};
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6..809c502 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
enum {
@@ -304,12 +305,19 @@ static int goldfish_fb_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_fb_match[] = {
+ { .compatible = "generic,goldfish-fb" },
+ { },
+};
+#endif
static struct platform_driver goldfish_fb_driver = {
.probe = goldfish_fb_probe,
.remove = goldfish_fb_remove,
.driver = {
- .name = "goldfish_fb"
+ .name = "goldfish_fb",
+ .of_match_table = of_match_ptr(goldfish_fb_match),
}
};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] goldfish: add goldfish match node for dt driver probe
From: kbuild test robot @ 2015-11-06 5:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1446787441-18846-1-git-send-email-yalin.wang2010@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Hi yalin,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.3 next-20151105]
url: https://github.com/0day-ci/linux/commits/yalin-wang/goldfish-add-goldfish-match-node-for-dt-driver-probe/20151106-132647
config: x86_64-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/staging/goldfish/goldfish_nand.c:446:3: error: request for member 'of_match_table' in something not a structure or union
.of_match_table = of_match_ptr(goldfish_nand_match),
^
vim +/of_match_table +446 drivers/staging/goldfish/goldfish_nand.c
440
441 static struct platform_driver goldfish_nand_driver = {
442 .probe = goldfish_nand_probe,
443 .remove = goldfish_nand_remove,
444 .driver = {
445 .name = "goldfish_nand"
> 446 .of_match_table = of_match_ptr(goldfish_nand_match),
447 }
448 };
449
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 50533 bytes --]
^ permalink raw reply
* [PATCH] goldfish: add goldfish match node for dt driver probe
From: yalin wang @ 2015-11-06 5:24 UTC (permalink / raw)
To: dmitry.torokhov, sre, dbaryshkov, dwmw2, gregkh, jslaby, plagnioj,
tomi.valkeinen, yalin.wang2010, peter.senna, joe, dan.carpenter,
alan, somyaanand214, mahfouz.saif.elyazal, ricardo.ribalda,
ravi2j, linux-input, linux-kernel, linux-pm, devel, linux-fbdev
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/input/keyboard/goldfish_events.c | 9 +++++++++
drivers/platform/goldfish/goldfish_pipe.c | 11 ++++++++++-
drivers/power/goldfish_battery.c | 11 ++++++++++-
drivers/staging/goldfish/goldfish_audio.c | 11 ++++++++++-
drivers/staging/goldfish/goldfish_nand.c | 9 +++++++++
drivers/tty/goldfish.c | 11 ++++++++++-
drivers/video/fbdev/goldfishfb.c | 10 +++++++++-
7 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/goldfish_events.c b/drivers/input/keyboard/goldfish_events.c
index 907e4e2..7b99ab8 100644
--- a/drivers/input/keyboard/goldfish_events.c
+++ b/drivers/input/keyboard/goldfish_events.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <linux/input.h>
#include <linux/kernel.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/irq.h>
@@ -178,10 +179,18 @@ static int events_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_events_match[] = {
+ { .compatible = "generic,goldfish-events-keypad" },
+ { },
+};
+#endif
+
static struct platform_driver events_driver = {
.probe = events_probe,
.driver = {
.name = "goldfish_events",
+ .of_match_table = of_match_ptr(goldfish_events_match),
},
};
diff --git a/drivers/platform/goldfish/goldfish_pipe.c b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..55b6d7c 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -50,6 +50,7 @@
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/miscdevice.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/poll.h>
#include <linux/sched.h>
@@ -615,11 +616,19 @@ static int goldfish_pipe_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_pipe_match[] = {
+ { .compatible = "generic,android-pipe" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_pipe = {
.probe = goldfish_pipe_probe,
.remove = goldfish_pipe_remove,
.driver = {
- .name = "goldfish_pipe"
+ .name = "goldfish_pipe",
+ .of_match_table = of_match_ptr(goldfish_pipe_match),
}
};
diff --git a/drivers/power/goldfish_battery.c b/drivers/power/goldfish_battery.c
index a50bb98..48b057d 100644
--- a/drivers/power/goldfish_battery.c
+++ b/drivers/power/goldfish_battery.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/types.h>
@@ -227,11 +228,19 @@ static int goldfish_battery_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_battery_match[] = {
+ { .compatible = "generic,goldfish-battery" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_battery_device = {
.probe = goldfish_battery_probe,
.remove = goldfish_battery_remove,
.driver = {
- .name = "goldfish-battery"
+ .name = "goldfish-battery",
+ .of_match_table = of_match_ptr(goldfish_battery_match),
}
};
module_platform_driver(goldfish_battery_device);
diff --git a/drivers/staging/goldfish/goldfish_audio.c b/drivers/staging/goldfish/goldfish_audio.c
index b0927e4..f0c5118 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/miscdevice.h>
#include <linux/fs.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/types.h>
#include <linux/pci.h>
@@ -344,11 +345,19 @@ static int goldfish_audio_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_audio_match[] = {
+ { .compatible = "generic,goldfish-audio" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_audio_driver = {
.probe = goldfish_audio_probe,
.remove = goldfish_audio_remove,
.driver = {
- .name = "goldfish_audio"
+ .name = "goldfish_audio",
+ .of_match_table = of_match_ptr(goldfish_audio_match),
}
};
diff --git a/drivers/staging/goldfish/goldfish_nand.c b/drivers/staging/goldfish/goldfish_nand.c
index 623353db5..f26de0f 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -23,6 +23,7 @@
#include <linux/ioport.h>
#include <linux/vmalloc.h>
#include <linux/mtd/mtd.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/goldfish.h>
@@ -430,11 +431,19 @@ static int goldfish_nand_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_nand_match[] = {
+ { .compatible = "generic,goldfish-nand" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_nand_driver = {
.probe = goldfish_nand_probe,
.remove = goldfish_nand_remove,
.driver = {
.name = "goldfish_nand"
+ .of_match_table = of_match_ptr(goldfish_nand_match),
}
};
diff --git a/drivers/tty/goldfish.c b/drivers/tty/goldfish.c
index 0f82c0b..a49f4a2 100644
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
@@ -324,11 +325,19 @@ static int goldfish_tty_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_tty_match[] = {
+ { .compatible = "generic,goldfish-tty" },
+ { },
+};
+#endif
+
static struct platform_driver goldfish_tty_platform_driver = {
.probe = goldfish_tty_probe,
.remove = goldfish_tty_remove,
.driver = {
- .name = "goldfish_tty"
+ .name = "goldfish_tty",
+ .of_match_table = of_match_ptr(goldfish_tty_match),
}
};
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6..809c502 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
enum {
@@ -304,12 +305,19 @@ static int goldfish_fb_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id goldfish_fb_match[] = {
+ { .compatible = "generic,goldfish-fb" },
+ { },
+};
+#endif
static struct platform_driver goldfish_fb_driver = {
.probe = goldfish_fb_probe,
.remove = goldfish_fb_remove,
.driver = {
- .name = "goldfish_fb"
+ .name = "goldfish_fb",
+ .of_match_table = of_match_ptr(goldfish_fb_match),
}
};
--
1.9.1
^ permalink raw reply related
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Michel Dänzer @ 2015-11-06 2:25 UTC (permalink / raw)
To: Pavel Machek, Alex Deucher
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Christian König
In-Reply-To: <20151105202301.GA3624@amd>
On 06.11.2015 05:23, Pavel Machek wrote:
> 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 changes on screen, like dragging a big
>>> window. Is that consistent with wrong PLL timings?
>>
>> Does it go away with radeon.dpm=0? Sounds more like either memory
>> reclocking happening outside of vblank, or underflow to the display
>> controllers.
>
> No, it does not:
>
> pavel@half:~$ cat /proc/cmdline
> BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> resume=/dev/sda1 radeon.dpm=0
>
> ..and same issue. And yes, it looks like an underflow to me. How can I
> debug reclocking / underflows?
Does radeon.disp_priority=2 help?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-05 20:26 UTC (permalink / raw)
To: Christian König
Cc: linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Deucher, Alexander,
Christian König
In-Reply-To: <563B32C7.3080202@vodafone.de>
> >>>>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 only
> >>happens when something changes on screen, like dragging a big
> >>window. Is that consistent with wrong PLL timings?
> >Does it go away with radeon.dpm=0? Sounds more like either memory
> >reclocking happening outside of vblank, or underflow to the display
> >controllers.
>
> Sounds like my suspicion was right, that doesn't seem to be a PLL issue
> after all.
>
> Just to rule out the obvious your system works fine with windows and you
> don't have a extra long cable for the monitor or something like
>this?
Cable is something like 2 meters. It does not seem to be EMI, because
it only happens when the display is being updated.
The system had some thermal issues before, but a) there's big fan
cooling it now and b) it does not get worse with more usage. I don't
think its heat.
I don't have Windows for a test, sorry.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-05 20:23 UTC (permalink / raw)
To: Alex Deucher
Cc: linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Deucher, Alexander,
Christian König
In-Reply-To: <CADnq5_OwDpgTKuS66dBSeFEMqkxi=1mie_xONZsnYj8su4Z_xw@mail.gmail.com>
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 changes on screen, like dragging a big
> > window. Is that consistent with wrong PLL timings?
>
> Does it go away with radeon.dpm=0? Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.
No, it does not:
pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0
..and same issue. And yes, it looks like an underflow to me. How can I
debug reclocking / underflows?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Christian König @ 2015-11-05 10:43 UTC (permalink / raw)
To: Alex Deucher, Pavel Machek
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <CADnq5_OwDpgTKuS66dBSeFEMqkxi=1mie_xONZsnYj8su4Z_xw@mail.gmail.com>
On 04.11.2015 23:13, Alex Deucher wrote:
> On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek <pavel@ucw.cz> 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_adjust_pll(struct drm_crtc *crtc,
>>>>>>> radeon_crtc->pll_flags = 0;
>>>>>>>
>>>>>>> if (ASIC_IS_AVIVO(rdev)) {
>>>>>>> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>>>>>>> +
>>>>>>> if ((rdev->family = CHIP_RS600) ||
>>>>>>> (rdev->family = CHIP_RS690) ||
>>>>>>> (rdev->family = CHIP_RS740))
>>>>>>>
>>>>>> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>>>>>> issue completely.
>>>>> You could also try the old pll algorithm:
>>>> I reverted the patch above, and switched to the old algorithm.
>>>>
>>>> The flicker is still there. (But maybe its less horrible, like with
>>>> 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 only
>> happens when something changes on screen, like dragging a big
>> window. Is that consistent with wrong PLL timings?
> Does it go away with radeon.dpm=0? Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.
Sounds like my suspicion was right, that doesn't seem to be a PLL issue
after all.
Just to rule out the obvious your system works fine with windows and you
don't have a extra long cable for the monitor or something like this?
Regards,
Christian.
>
> Alex
>
>> diff --git a/config.32 b/config.32
>> index 00e5dd2..4734158 100644
>> --- a/config.32
>> +++ b/config.32
>> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>> CONFIG_PREVENT_FIRMWARE_BUILD=y
>> CONFIG_FW_LOADER=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
>> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>> # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
>> CONFIG_ALLOW_DEV_COREDUMP=y
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index dac78ad..dcc4f4d 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>> radeon_crtc->pll_flags = 0;
>>
>> if (ASIC_IS_AVIVO(rdev)) {
>> + //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> +
>> if ((rdev->family = CHIP_RS600) ||
>> (rdev->family = CHIP_RS690) ||
>> (rdev->family = CHIP_RS740))
>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
>> index 6743174..bebaf4f 100644
>> --- a/drivers/gpu/drm/radeon/radeon_display.c
>> +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>> fb_div_max = pll->max_feedback_div;
>>
>> if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
>> + printk("radeon: fractional divider\n");
>> fb_div_min *= 10;
>> fb_div_max *= 10;
>> }
>> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>> else
>> ref_div_max = pll->max_ref_div;
>>
>> + ref_div_min = 2;
>> + ref_div_max = 2;
>> +
>> /* determine allowed post divider range */
>> if (pll->flags & RADEON_PLL_USE_POST_DIV) {
>> post_div_min = pll->post_div;
>> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>> diff = abs(target_clock - (pll->reference_freq * fb_div) /
>> (ref_div * post_div));
>>
>> + printk("post_div = %d, diff = %d\n", post_div, diff);
>> +
>> if (diff < diff_best || (diff = diff_best &&
>> !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
>>
>> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>> }
>> }
>> post_div = post_div_best;
>> + printk("Selected post_div = %d\n", post_div);
>>
>> /* get the feedback and reference divider for the optimal value */
>> avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
>> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>> *ref_div_p = ref_div;
>> *post_div_p = post_div;
>>
>> - DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
>> + printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
>> freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
>> ref_div, post_div);
>> }
>>
>>
>>> But I'm not 100% convinced that this is actually a PLL problem, try to
>>> compile the firmware it complains about into the kernel as well.
>> Did that, too.
>>
>> Best regards,
>> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: Philipp Zabel @ 2015-11-05 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1446601656.15340.11.camel@mtksdaap41>
Am Mittwoch, den 04.11.2015, 09:47 +0800 schrieb YH Huang:
> On Tue, 2015-11-03 at 12:08 +0100, Philipp Zabel wrote:
> > Hi YH,
> >
> > Am Dienstag, den 03.11.2015, 16:11 +0800 schrieb YH Huang:
> > > > The reasoning is that devices where there is no phandle link pointing to
> > > > the backlight (for example from a simple-panel node), we should keep the
> > > > current default behaviour (enable during probe).
> > >
> > > I have a little problem for the current default behaviour.
> > > Should we enable during probe?
> >
> > Here I mean enabling the backlight (at the end of the probe function),
> > not enabling the GPIO already when requesting it.
> >
> > > Before this patch ( http://patchwork.ozlabs.org/patch/324690/ ),
> > > we disable "enable-gpio" in the probe function.
> >
> > While before this patch the GPIO would be initialized in the disabled
> > state, the call to backlight_update_status at the end of the probe
> > function would still enable the backlight afterwards.
>
> Based on this, could we disable it initially and update in the
> backlight_update_status function?
>
> Like this,
>
> if (pb->enable_gpio) {
> if (phandle &&
> gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
> gpiod_get_value(pb->enable_gpio) = 1)
> gpiod_direction_output(pb->enable_gpio, 1);
The gpiod_direction_output call is a no-op, since the direction is
already output and the value is already 1.
Also, I propose to set initial blanking to FB_BLANK_POWERDOWN in this
case, and wait for the panel driver to enable the backlight at the
appropriate time.
regards
Philipp
^ permalink raw reply
* RE: [PATCH] video: fbdev: fsl: Split DIU initialization entry
From: Wang Dongsheng @ 2015-11-05 1:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444709355-8905-1-git-send-email-dongsheng.wang@freescale.com>
SGkgVGltdXIsDQoNCj4gT24gTW9uLCBPY3QgMTIsIDIwMTUgYXQgMTE6MDkgUE0sIERvbmdzaGVu
ZyBXYW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2NhbGUuY29tPg0KPiB3cm90ZToNCj4gPiArICAg
ICAgIHJldCA9IGZzbF9kaXVfcGVycGFyZSgpOw0KPiA+ICsgICAgICAgaWYgKHJldCkNCj4gPiAr
ICAgICAgICAgICAgICAgZ290byBvdXRfZGl1X3BlcnBhcmU7DQo+IA0KPiBJIHRoaW5rIHlvdSBt
ZWFuICJwcmVwYXJlIg0KPiANCj4gVGhhbmtzIGZvciBwb3N0aW5nIHRoaXMgcGF0Y2guICBJIHdp
bGwgdHJ5IHRvIHJldmlldyBpdCBtb3JlIHRob3JvdWdobHkgbGF0ZXIuDQoNCkRvIHlvdSBoYXZl
IGFueSBvdGhlciBjb21tZW50cyBhYm91dCB0aGlzIHBhdGNoPyBUaGFua3MgZm9yIHlvdXIgcmV2
aWV3Lg0KDQpSZWdhcmRzLA0KLURvbmdzaGVuZw0K
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Alex Deucher @ 2015-11-04 22:13 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Deucher, Alexander,
Christian König
In-Reply-To: <20151104221000.GA3608@amd>
On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek <pavel@ucw.cz> 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_adjust_pll(struct drm_crtc *crtc,
>> >>>> radeon_crtc->pll_flags = 0;
>> >>>>
>> >>>> if (ASIC_IS_AVIVO(rdev)) {
>> >>>>+ radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> >>>>+
>> >>>> if ((rdev->family = CHIP_RS600) ||
>> >>>> (rdev->family = CHIP_RS690) ||
>> >>>> (rdev->family = CHIP_RS740))
>> >>>>
>> >>>Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>> >>>issue completely.
>> >>You could also try the old pll algorithm:
>> >I reverted the patch above, and switched to the old algorithm.
>> >
>> >The flicker is still there. (But maybe its less horrible, like with
>> >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 only
> happens when something changes on screen, like dragging a big
> window. Is that consistent with wrong PLL timings?
Does it go away with radeon.dpm=0? Sounds more like either memory
reclocking happening outside of vblank, or underflow to the display
controllers.
Alex
>
> diff --git a/config.32 b/config.32
> index 00e5dd2..4734158 100644
> --- a/config.32
> +++ b/config.32
> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
> CONFIG_ALLOW_DEV_COREDUMP=y
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
> index dac78ad..dcc4f4d 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> radeon_crtc->pll_flags = 0;
>
> if (ASIC_IS_AVIVO(rdev)) {
> + //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> +
> if ((rdev->family = CHIP_RS600) ||
> (rdev->family = CHIP_RS690) ||
> (rdev->family = CHIP_RS740))
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
> index 6743174..bebaf4f 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> fb_div_max = pll->max_feedback_div;
>
> if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
> + printk("radeon: fractional divider\n");
> fb_div_min *= 10;
> fb_div_max *= 10;
> }
> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> else
> ref_div_max = pll->max_ref_div;
>
> + ref_div_min = 2;
> + ref_div_max = 2;
> +
> /* determine allowed post divider range */
> if (pll->flags & RADEON_PLL_USE_POST_DIV) {
> post_div_min = pll->post_div;
> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> diff = abs(target_clock - (pll->reference_freq * fb_div) /
> (ref_div * post_div));
>
> + printk("post_div = %d, diff = %d\n", post_div, diff);
> +
> if (diff < diff_best || (diff = diff_best &&
> !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
>
> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> }
> }
> post_div = post_div_best;
> + printk("Selected post_div = %d\n", post_div);
>
> /* get the feedback and reference divider for the optimal value */
> avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> *ref_div_p = ref_div;
> *post_div_p = post_div;
>
> - DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> + printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
> ref_div, post_div);
> }
>
>
>> But I'm not 100% convinced that this is actually a PLL problem, try to
>> compile the firmware it complains about into the kernel as well.
>
> Did that, too.
>
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-04 22:10 UTC (permalink / raw)
To: Christian König
Cc: linux-fbdev@vger.kernel.org, kernel list,
Maling list - DRI developers, Deucher, Alexander,
Christian König
In-Reply-To: <5639B580.1050409@vodafone.de>
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_adjust_pll(struct drm_crtc *crtc,
> >>>> radeon_crtc->pll_flags = 0;
> >>>>
> >>>> if (ASIC_IS_AVIVO(rdev)) {
> >>>>+ radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> >>>>+
> >>>> if ((rdev->family = CHIP_RS600) ||
> >>>> (rdev->family = CHIP_RS690) ||
> >>>> (rdev->family = CHIP_RS740))
> >>>>
> >>>Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
> >>>issue completely.
> >>You could also try the old pll algorithm:
> >I reverted the patch above, and switched to the old algorithm.
> >
> >The flicker is still there. (But maybe its less horrible, like with
> >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 only
happens when something changes on screen, like dragging a big
window. Is that consistent with wrong PLL timings?
diff --git a/config.32 b/config.32
index 00e5dd2..4734158 100644
--- a/config.32
+++ b/config.32
@@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
+CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
CONFIG_ALLOW_DEV_COREDUMP=y
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..dcc4f4d 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
radeon_crtc->pll_flags = 0;
if (ASIC_IS_AVIVO(rdev)) {
+ //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
if ((rdev->family = CHIP_RS600) ||
(rdev->family = CHIP_RS690) ||
(rdev->family = CHIP_RS740))
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 6743174..bebaf4f 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
fb_div_max = pll->max_feedback_div;
if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+ printk("radeon: fractional divider\n");
fb_div_min *= 10;
fb_div_max *= 10;
}
@@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
else
ref_div_max = pll->max_ref_div;
+ ref_div_min = 2;
+ ref_div_max = 2;
+
/* determine allowed post divider range */
if (pll->flags & RADEON_PLL_USE_POST_DIV) {
post_div_min = pll->post_div;
@@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
diff = abs(target_clock - (pll->reference_freq * fb_div) /
(ref_div * post_div));
+ printk("post_div = %d, diff = %d\n", post_div, diff);
+
if (diff < diff_best || (diff = diff_best &&
!(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
@@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
}
}
post_div = post_div_best;
+ printk("Selected post_div = %d\n", post_div);
/* get the feedback and reference divider for the optimal value */
avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
@@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
*ref_div_p = ref_div;
*post_div_p = post_div;
- DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+ printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
ref_div, post_div);
}
> But I'm not 100% convinced that this is actually a PLL problem, try to
> compile the firmware it complains about into the kernel as well.
Did that, too.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Christian König @ 2015-11-04 7:36 UTC (permalink / raw)
To: Pavel Machek, Alex Deucher
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <20151103230329.GA4167@amd>
On 04.11.2015 00:03, Pavel Machek wrote:
> Hi!
>
>
>>>>>>> Any ideas?
>>>>>> Alex probably knows more about this, but it sounds like problems with
>>>>>> switching the memory clocks on 3D load.
>>>>>> Try to disable power management completely with radeon.dpm=0 on the kernel
>>>>>> command line or nailing the hardware at a specific power level using
>>>>>> sysfs.
>>>>> I tried that, but it still flickers.
>>>> It's probably pll stability. There seem to be a number of regressions
>>>> since the pll code was rewritten to support matching the hdmi clocks
>>>> more closely. Does this patch help?
>>>>
>>>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
>>>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>>>> 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_adjust_pll(struct drm_crtc *crtc,
>>>> radeon_crtc->pll_flags = 0;
>>>>
>>>> if (ASIC_IS_AVIVO(rdev)) {
>>>> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>>>> +
>>>> if ((rdev->family = CHIP_RS600) ||
>>>> (rdev->family = CHIP_RS690) ||
>>>> (rdev->family = CHIP_RS740))
>>>>
>>> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>>> issue completely.
>> You could also try the old pll algorithm:
> I reverted the patch above, and switched to the old algorithm.
>
> The flicker is still there. (But maybe its less horrible, like with
> 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().
But I'm not 100% convinced that this is actually a PLL problem, try to
compile the firmware it complains about into the kernel as well.
Regards,
Christian.
>
> Thanks,
> Pavel
>
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: YH Huang @ 2015-11-04 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1446548924.3373.3.camel@pengutronix.de>
On Tue, 2015-11-03 at 12:08 +0100, Philipp Zabel wrote:
> Hi YH,
>
> Am Dienstag, den 03.11.2015, 16:11 +0800 schrieb YH Huang:
> > > The reasoning is that devices where there is no phandle link pointing to
> > > the backlight (for example from a simple-panel node), we should keep the
> > > current default behaviour (enable during probe).
> >
> > I have a little problem for the current default behaviour.
> > Should we enable during probe?
>
> Here I mean enabling the backlight (at the end of the probe function),
> not enabling the GPIO already when requesting it.
>
> > Before this patch ( http://patchwork.ozlabs.org/patch/324690/ ),
> > we disable "enable-gpio" in the probe function.
>
> While before this patch the GPIO would be initialized in the disabled
> state, the call to backlight_update_status at the end of the probe
> function would still enable the backlight afterwards.
Based on this, could we disable it initially and update in the
backlight_update_status function?
Like this,
if (pb->enable_gpio) {
if (phandle &&
gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
gpiod_get_value(pb->enable_gpio) = 1)
gpiod_direction_output(pb->enable_gpio, 1);
else
gpiod_direction_output(pb->enable_gpio, 0);
}
And then update with props.brightness in backlight_update_status.
I am not sure, maybe I miss something.
Regards,
YH Huang
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-03 23:15 UTC (permalink / raw)
To: Alex Deucher
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <CADnq5_P8TOQ14NiWKgV-YUy0_8P+K842pZ4h7WuU6XBu4o9fyQ@mail.gmail.com>
Hi!
> >> Unfortunately, it can't be applied as is because we had a similar
> >> patch which was reverted because it regressed a bunch of other
> >> systems. The actual pll limits probably need to be tweaked.
> >
> > Any ideas how to tweak the pll limits?
>
> Adjust the the algorithm in radeon_compute_pll_avivo() in radeon_display.c
Hmm. Two values have diff = 0, I guess that leaves little room for
improvement, as we already tried both with the PREFER_... setting.
[ 1.236229] Linux agpgart interface v0.103
[ 1.236829] [drm] Initialized drm 1.1.0 20060810
[ 1.237013] [drm] radeon kernel modesetting enabled.
[ 1.238284] [drm] initializing kernel modesetting (RV710
0x1002:0x9553 0x1025:0x0212)
.
[ 1.238362] [drm] register mmio base: 0xD6200000
[ 1.238417] [drm] register mmio size: 65536
[ 1.238622] ATOM BIOS: BR34582.001
[ 1.238789] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 -
0x000000001FFFFFFF (
512M used)
[ 1.238856] radeon 0000:01:00.0: GTT: 1024M 0x0000000020000000 -
0x000000005FFFFFFF
[ 1.238915] [drm] Detected VRAM RAMQ2M, BAR%6M
[ 1.238970] [drm] RAM width 64bits DDR
[ 1.239266] [TTM] Zone kernel: Available graphics memory: 431276
kiB
[ 1.239323] [TTM] Zone highmem: Available graphics memory: 1546602
kiB
[ 1.239380] [TTM] Initializing pool allocator
[ 1.240936] [TTM] Initializing DMA pool allocator
[ 1.241174] [drm] radeon: 512M of VRAM memory ready
[ 1.241231] [drm] radeon: 1024M of GTT memory ready.
[ 1.241345] [drm] Loading RV710 Microcode
[ 1.241483] radeon 0000:01:00.0: Direct firmware load for
radeon/RV710_smc.bin failed
with error -2
[ 1.241553] smc: error loading firmware "radeon/RV710_smc.bin"
[ 1.241638] [drm] radeon: power management initialized
[ 1.241754] radeon 0000:01:00.0: Direct firmware load for
radeon/RV710_uvd.bin failed
with error -2
[ 1.241823] radeon 0000:01:00.0: radeon_uvd: Can't load firmware
"radeon/RV710_uvd.bi
n"
[ 1.241885] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 1.257273] [drm] PCIE GART of 1024M enabled (table at
0x0000000000040000).
[ 1.257456] radeon 0000:01:00.0: WB enabled
[ 1.257514] radeon 0000:01:00.0: fence driver on ring 0 use gpu
addr 0x0000000020000c
00 and cpu addr 0xffc01c00
[ 1.257582] radeon 0000:01:00.0: fence driver on ring 3 use gpu
addr 0x0000000020000c0c and cpu addr 0xffc01c0c
[ 1.257655] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[ 1.257713] [drm] Driver supports precise vblank timestamp query.
[ 1.257770] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 1.257921] [drm] radeon: irq initialized.
[ 1.304343] [drm] ring test on 0 succeeded in 1 usecs
[ 1.304403] [drm] ring test on 3 succeeded in 2 usecs
[ 1.304835] [drm] ib test on ring 0 succeeded in 0 usecs
[ 1.304912] [drm] ib test on ring 3 succeeded in 0 usecs
[ 1.307453] [drm] Radeon Display Connectors
[ 1.307511] [drm] Connector 0:
[ 1.307565] [drm] VGA-1
[ 1.307619] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
0x7e4c 0x7e4c
[ 1.307677] [drm] Encoders:
[ 1.307730] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 1.336107] ACPI: Deprecated procfs I/F for battery is loaded,
please retry with CONFIG_ACPI_PROCFS_POWER cleared
[ 1.336209] ACPI: Battery Slot [BAT0] (battery absent)
[ 1.342090] [drm] fb mappable at 0xC0241000
[ 1.342146] [drm] vram apper at 0xC0000000
[ 1.342201] [drm] size 8294400
[ 1.342254] [drm] fb depth is 24
[ 1.342307] [drm] pitch is 7680
[ 1.342777] fbcon: radeondrmfb (fb0) is primary device
[ 1.344374] post_div = 5, diff = 270
[ 1.344375] post_div = 6, diff = 0
[ 1.344375] post_div = 7, diff = 192
[ 1.344376] post_div = 8, diff = 0
[ 1.344377] Selected post_div = 8
[ 1.344378] 148500 - 148500, pll dividers - fb: 88.0 ref: 2, post 8
[ 1.381561] Console: switching to colour frame buffer device 192x60
[ 1.391454] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer
device
[ 1.404499] [drm] Initialized radeon 2.43.0 20080528 for
0000:01:00.0 on minor 0
[ 1.404669] [drm] amdgpu kernel modesetting enabled.
[ 1.416219] loop: module loaded
[ 1.418413] nbd: registered device at major 43
The "error loading firmware" messages confuse me a bit, but I do have
some firmware built into kernel, and 3D acceleration seems to work.
pavel@half:/data/l/linux$ grep FIRMWARE .config
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_CYPRESS_FIRMWARE is not set
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_FIRMWARE_EDID=y
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_GOOGLE_FIRMWARE is not set
# CONFIG_TEST_FIRMWARE is not set
pavel@half:/data/l/linux$
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-03 23:03 UTC (permalink / raw)
To: Alex Deucher
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <CADnq5_P8TOQ14NiWKgV-YUy0_8P+K842pZ4h7WuU6XBu4o9fyQ@mail.gmail.com>
Hi!
> >> >> >Any ideas?
> >> >>
> >> >> Alex probably knows more about this, but it sounds like problems with
> >> >> switching the memory clocks on 3D load.
> >> >
> >> >> Try to disable power management completely with radeon.dpm=0 on the kernel
> >> >> command line or nailing the hardware at a specific power level using
> >> >> sysfs.
> >> >
> >> > I tried that, but it still flickers.
> >>
> >> It's probably pll stability. There seem to be a number of regressions
> >> since the pll code was rewritten to support matching the hdmi clocks
> >> more closely. Does this patch help?
> >>
> >> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> >> b/drivers/gpu/drm/radeon/atombios_crtc.c
> >> 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_adjust_pll(struct drm_crtc *crtc,
> >> radeon_crtc->pll_flags = 0;
> >>
> >> if (ASIC_IS_AVIVO(rdev)) {
> >> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> >> +
> >> if ((rdev->family = CHIP_RS600) ||
> >> (rdev->family = CHIP_RS690) ||
> >> (rdev->family = CHIP_RS740))
> >>
> >
> > Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
> > issue completely.
>
> You could also try the old pll algorithm:
I reverted the patch above, and switched to the old algorithm.
The flicker is still there. (But maybe its less horrible, like with
RADEON_PLL_PREFER_MINM_OVER_MAXP).
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Alex Deucher @ 2015-11-03 22:25 UTC (permalink / raw)
To: Pavel Machek
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <20151103220919.GA4824@amd>
On Tue, Nov 3, 2015 at 5:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> >4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
>> >> >my monitor is native 1920x1080, so that mode looks pretty ugly on
>> >> >screen. If I go to 1920x1080, I see colored horizontal lines (often
>> >> >black) as soon as there's graphics activity.
>> >> >
>> >> >pavel@half:~$ xrandr
>> >> >Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
>> >> >VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
>> >> >axis) 478mm x 268mm
>> >> > 1920x1080 60.00*+
>> >> > 1600x1200 60.00
>> >> > 1680x1050 59.95
>> >> > 1280x1024 75.02 60.02
>> >> > 1440x900 59.89
>> >> > 1024x768 75.08 60.00
>> >> > 800x600 75.00 60.32
>> >> > 640x480 75.00 60.00
>> >> > 720x400 70.08
>> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
>> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
>> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
>> >> >
>
>> >> >Any ideas?
>> >>
>> >> Alex probably knows more about this, but it sounds like problems with
>> >> switching the memory clocks on 3D load.
>> >
>> >> Try to disable power management completely with radeon.dpm=0 on the kernel
>> >> command line or nailing the hardware at a specific power level using
>> >> sysfs.
>> >
>> > I tried that, but it still flickers.
>>
>> It's probably pll stability. There seem to be a number of regressions
>> since the pll code was rewritten to support matching the hdmi clocks
>> more closely. Does this patch help?
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> 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_adjust_pll(struct drm_crtc *crtc,
>> radeon_crtc->pll_flags = 0;
>>
>> if (ASIC_IS_AVIVO(rdev)) {
>> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> +
>> if ((rdev->family = CHIP_RS600) ||
>> (rdev->family = CHIP_RS690) ||
>> (rdev->family = CHIP_RS740))
>>
>
> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
> issue completely.
You could also try the old pll algorithm:
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..8c6e8fa 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1094,8 +1094,8 @@ static void atombios_crtc_set_pll(struct
drm_crtc *crtc, struct drm_display_mode
radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,
&fb_div, &frac_fb_div,
&ref_div, &post_div);
else if (ASIC_IS_AVIVO(rdev))
- radeon_compute_pll_avivo(pll,
radeon_crtc->adjusted_clock, &pll_clock,
- &fb_div, &frac_fb_div,
&ref_div, &post_div);
+ radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,
+ &fb_div, &frac_fb_div,
&ref_div, &post_div);
else
radeon_compute_pll_legacy(pll,
radeon_crtc->adjusted_clock, &pll_clock,
&fb_div, &frac_fb_div,
&ref_div, &post_div);
>
>> Unfortunately, it can't be applied as is because we had a similar
>> patch which was reverted because it regressed a bunch of other
>> systems. The actual pll limits probably need to be tweaked.
>
> Any ideas how to tweak the pll limits?
Adjust the the algorithm in radeon_compute_pll_avivo() in radeon_display.c
Alex
^ permalink raw reply related
* HELLO
From: MSELLAGOLAN @ 2015-11-03 22:13 UTC (permalink / raw)
To: linux-fbdev
I am Mrs.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response, please reply to my personal
email: mrsellagolan@gmail.com
Faithfully,
Ms.Ella Golan
^ permalink raw reply
* Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080
From: Pavel Machek @ 2015-11-03 22:09 UTC (permalink / raw)
To: Alex Deucher
Cc: Deucher, Alexander, linux-fbdev@vger.kernel.org,
Christian König, Maling list - DRI developers, kernel list
In-Reply-To: <CADnq5_MoThbrDADBHBRXiEGWC8jukwOLyfjfX9-7d0fB0kbpMA@mail.gmail.com>
Hi!
> >> >4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But
> >> >my monitor is native 1920x1080, so that mode looks pretty ugly on
> >> >screen. If I go to 1920x1080, I see colored horizontal lines (often
> >> >black) as soon as there's graphics activity.
> >> >
> >> >pavel@half:~$ xrandr
> >> >Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> >> >VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y
> >> >axis) 478mm x 268mm
> >> > 1920x1080 60.00*+
> >> > 1600x1200 60.00
> >> > 1680x1050 59.95
> >> > 1280x1024 75.02 60.02
> >> > 1440x900 59.89
> >> > 1024x768 75.08 60.00
> >> > 800x600 75.00 60.32
> >> > 640x480 75.00 60.00
> >> > 720x400 70.08
> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080
> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200
> >> >
> >> >Any ideas?
> >>
> >> Alex probably knows more about this, but it sounds like problems with
> >> switching the memory clocks on 3D load.
> >
> >> Try to disable power management completely with radeon.dpm=0 on the kernel
> >> command line or nailing the hardware at a specific power level using
> >> sysfs.
> >
> > I tried that, but it still flickers.
>
> It's probably pll stability. There seem to be a number of regressions
> since the pll code was rewritten to support matching the hdmi clocks
> more closely. Does this patch help?
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> 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_adjust_pll(struct drm_crtc *crtc,
> radeon_crtc->pll_flags = 0;
>
> if (ASIC_IS_AVIVO(rdev)) {
> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> +
> if ((rdev->family = CHIP_RS600) ||
> (rdev->family = CHIP_RS690) ||
> (rdev->family = CHIP_RS740))
>
Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
issue completely.
> Unfortunately, it can't be applied as is because we had a similar
> patch which was reverted because it regressed a bunch of other
> systems. The actual pll limits probably need to be tweaked.
Any ideas how to tweak the pll limits?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 3/3] Hisilicon graphic driver: add 2d acceleration to hisilicon hi1710 graphic chip
From: Rongrong Zou @ 2015-11-03 13:54 UTC (permalink / raw)
To: linux-fbdev
From: Rongrong Zou <zourongrong@huawei.com>
This patch implements 2d acceleration.
Signed-off-by: Rongrong Zou <zourongrong@huawei.com>
---
drivers/video/fbdev/hisilicon/Makefile | 2 +-
drivers/video/fbdev/hisilicon/hisi_accel.c | 382 +++++++++++++++++++++++++++++
drivers/video/fbdev/hisilicon/hisi_accel.h | 62 +++++
drivers/video/fbdev/hisilicon/hisi_drv.c | 122 ++++++++-
drivers/video/fbdev/hisilicon/hisi_hw.c | 23 +-
5 files changed, 588 insertions(+), 3 deletions(-)
create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.c
create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.h
diff --git a/drivers/video/fbdev/hisilicon/Makefile b/drivers/video/fbdev/hisilicon/Makefile
index 5f478ed..1675edb 100644
--- a/drivers/video/fbdev/hisilicon/Makefile
+++ b/drivers/video/fbdev/hisilicon/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_FB_HISILICON) += hisiliconfb.o
-hisiliconfb-y := hisi_drv.o hisi_hw.o hisi_cursor.o hisi_chip.o
+hisiliconfb-y := hisi_drv.o hisi_hw.o hisi_accel.o hisi_cursor.o hisi_chip.o
hisiliconfb-y += hisi_mode.o hisi_power.o
hisiliconfb-objs := $(hisiliconfb-y)
diff --git a/drivers/video/fbdev/hisilicon/hisi_accel.c b/drivers/video/fbdev/hisilicon/hisi_accel.c
new file mode 100644
index 0000000..3666995
--- /dev/null
+++ b/drivers/video/fbdev/hisilicon/hisi_accel.c
@@ -0,0 +1,382 @@
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/pagemap.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/screen_info.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/vmalloc.h>
+#include "hisi_drv.h"
+#include "hisi_accel.h"
+#include "hisi_help.h"
+#include "hisi_reg.h"
+
+static inline void write_dpr(struct hisi_accel *accel, int offset, u32 value)
+{
+ writel(value, accel->dpr_base + offset);
+}
+
+static inline u32 read_dpr(struct hisi_accel *accel, int offset)
+{
+ return readl(accel->dpr_base + offset);
+}
+
+static inline void write_dpport(struct hisi_accel *accel, u32 data)
+{
+ writel(data, accel->dp_port_base);
+}
+
+int hw_de_init(struct hisi_accel *accel)
+{
+ /* setup 2d engine registers */
+ u32 reg;
+ u32 clr;
+
+ write_dpr(accel, DE_MASKS, 0xFFFFFFFF);
+ /* dpr1c */
+ reg = FIELD_SET(0, DE_STRETCH_FORMAT, PATTERN_XY, NORMAL) |
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, PATTERN_Y, 0) |
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, PATTERN_X, 0) |
+ FIELD_SET(0, DE_STRETCH_FORMAT, ADDRESSING, XY) |
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, SOURCE_HEIGHT, 3);
+
+ clr = FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_XY) &
+ FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_Y) &
+ FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_X) &
+ FIELD_CLEAR(DE_STRETCH_FORMAT, ADDRESSING) &
+ FIELD_CLEAR(DE_STRETCH_FORMAT, SOURCE_HEIGHT);
+
+ /* DE_STRETCH bpp format need be initilized in setMode routine */
+ write_dpr(accel, DE_STRETCH_FORMAT,
+ (read_dpr(accel, DE_STRETCH_FORMAT) & clr) | reg);
+
+ /* disable clipping and transparent */
+ write_dpr(accel, DE_CLIP_TL, 0);/*dpr2c*/
+ write_dpr(accel, DE_CLIP_BR, 0);/*dpr30*/
+
+ write_dpr(accel, DE_COLOR_COMPARE_MASK, 0);/*dpr24*/
+ write_dpr(accel, DE_COLOR_COMPARE, 0);
+
+ reg = FIELD_SET(0, DE_CONTROL, TRANSPARENCY, DISABLE) |
+ FIELD_SET(0, DE_CONTROL, TRANSPARENCY_MATCH, OPAQUE) |
+ FIELD_SET(0, DE_CONTROL, TRANSPARENCY_SELECT, SOURCE);
+
+ clr = FIELD_CLEAR(DE_CONTROL, TRANSPARENCY) &
+ FIELD_CLEAR(DE_CONTROL, TRANSPARENCY_MATCH) &
+ FIELD_CLEAR(DE_CONTROL, TRANSPARENCY_SELECT);
+
+ /* dpr0c */
+ write_dpr(accel, DE_CONTROL, (read_dpr(accel, DE_CONTROL) & clr) | reg);
+
+ return 0;
+}
+
+/* set2dformat only be called from setmode functions
+ * but if you need dual framebuffer driver,need call set2dformat
+ * every time you use 2d function
+ */
+void hw_set_2dformat(struct hisi_accel *accel, int fmt)
+{
+ u32 reg;
+ /* fmt=0,1,2 for 8,16,32 */
+ reg = read_dpr(accel, DE_STRETCH_FORMAT);
+ reg = FIELD_VALUE(reg, DE_STRETCH_FORMAT, PIXEL_FORMAT, fmt);
+ write_dpr(accel, DE_STRETCH_FORMAT, reg);
+}
+
+int hw_fillrect(
+ struct hisi_accel *accel, u32 base,
+ u32 pitch, u32 Bpp,
+ u32 x, u32 y, u32 width,
+ u32 height, u32 color, u32 rop)
+{
+ u32 deCtrl;
+
+ if (accel->de_wait() != 0) {
+ /* int time wait and always busy,seems hardware
+ * got something error
+ */
+ dbg_msg("%s:De engine always bussy\n", __func__);
+ return -1;
+ }
+
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base);/*dpr40*/
+ write_dpr(accel, DE_PITCH,
+ FIELD_VALUE(0, DE_PITCH, DESTINATION, pitch / Bpp) |
+ FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp));/*dpr10*/
+
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, pitch / Bpp) |
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch / Bpp));
+
+ write_dpr(accel, DE_FOREGROUND, color);/*DPR14*/
+
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_DESTINATION, X, x) |
+ FIELD_VALUE(0, DE_DESTINATION, Y, y));/*dpr4*/
+
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));/*dpr8*/
+
+ deCtrl = FIELD_SET(0, DE_CONTROL, STATUS, START) |
+ FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT) |
+ FIELD_SET(0, DE_CONTROL, LAST_PIXEL, ON) |
+ FIELD_SET(0, DE_CONTROL, COMMAND, RECTANGLE_FILL) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ FIELD_VALUE(0, DE_CONTROL, ROP, rop);/*dpr0xc*/
+
+ write_dpr(accel, DE_CONTROL, deCtrl);
+
+ return 0;
+}
+
+int hw_copyarea(
+ struct hisi_accel *accel,
+ unsigned int sbase, /* Address of source: offset in frame buffer */
+ unsigned int spitch, /* Pitch value of source surface in BYTE */
+ unsigned int sx,
+ unsigned int sy, /* Starting coordinate of source surface */
+ /* Address of destination: offset in frame buffer */
+ unsigned int dbase,
+ unsigned int dpitch, /* Pitch value of destination surface in BYTE */
+ unsigned int bpp, /* Color depth of destination surface */
+ unsigned int dx,
+ unsigned int dy, /* Starting coordinate of destination surface */
+ unsigned int width,
+ unsigned int height,
+ unsigned int rop2)
+{
+ unsigned int direction;
+ unsigned int de_ctrl;
+ int opsign;
+
+ direction = LEFT_TO_RIGHT;
+ /* Direction of ROP2 operation:
+ * 1 = Left to Right, (-1) = Right to Left
+ */
+ opsign = 1;
+ de_ctrl = 0;
+
+ /* If source and destination are the same surface,
+ * need to check for overlay cases
+ */
+ if (sbase = dbase && spitch = dpitch) {
+ /* Determine direction of operation */
+ if (sy < dy) {
+ direction = BOTTOM_TO_TOP;
+ } else if (sy > dy) {
+ direction = TOP_TO_BOTTOM;
+ } else {
+ /* sy = dy */
+ if (sx <= dx) {
+ direction = RIGHT_TO_LEFT;
+ } else {
+ /* sx > dx */
+ direction = LEFT_TO_RIGHT;
+ }
+ }
+ }
+
+ if ((direction = BOTTOM_TO_TOP) || (direction = RIGHT_TO_LEFT)) {
+ sx += width - 1;
+ sy += height - 1;
+ dx += width - 1;
+ dy += height - 1;
+ opsign = (-1);
+ }
+
+ /* Note:
+ * DE_FOREGROUND are DE_BACKGROUND are don't care.
+ * DE_COLOR_COMPARE and DE_COLOR_COMPARE_MAKS
+ * are set by set deSetTransparency().
+ */
+
+ /* 2D Source Base.
+ * It is an address offset (128 bit aligned) from the beginning
+ * of frame buffer.
+ */
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, sbase); /* dpr40 */
+
+ /* 2D Destination Base.
+ * It is an address offset (128 bit aligned) from the beginning
+ * of frame buffer.
+ */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dbase); /* dpr44 */
+
+ write_dpr(accel, DE_PITCH,
+ FIELD_VALUE(0, DE_PITCH, DESTINATION, (dpitch / bpp)) |
+ FIELD_VALUE(0, DE_PITCH, SOURCE, (spitch / bpp))); /* dpr10*/
+
+ /* Screen Window width in Pixels.
+ * 2D engine uses this value to calculate the linear address
+ * in frame buffer for a given point.
+ */
+ /* dpr3c */
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH,
+ DESTINATION, (dpitch / bpp)) |
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (spitch / bpp)));
+
+ if (accel->de_wait() != 0)
+ return -1;
+
+ write_dpr(accel, DE_SOURCE,
+ FIELD_SET(0, DE_SOURCE, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_SOURCE, X_K1, sx) |
+ FIELD_VALUE(0, DE_SOURCE, Y_K2, sy)); /* dpr0 */
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_DESTINATION, X, dx) |
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
+
+ de_ctrl = FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ FIELD_SET(0, DE_CONTROL, COMMAND, BITBLT) |
+ ((direction = RIGHT_TO_LEFT) ?
+ FIELD_SET(0, DE_CONTROL, DIRECTION, RIGHT_TO_LEFT)
+ : FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT)) |
+ FIELD_SET(0, DE_CONTROL, STATUS, START);
+ write_dpr(accel, DE_CONTROL, de_ctrl); /* dpr0c */
+
+ return 0;
+}
+
+static unsigned int de_get_transparency(struct hisi_accel *accel)
+{
+ unsigned int de_ctrl;
+
+ de_ctrl = read_dpr(accel, DE_CONTROL);
+
+ de_ctrl &= FIELD_MASK(DE_CONTROL_TRANSPARENCY_MATCH) |
+ FIELD_MASK(DE_CONTROL_TRANSPARENCY_SELECT) |
+ FIELD_MASK(DE_CONTROL_TRANSPARENCY);
+
+ return de_ctrl;
+}
+
+int hw_imageblit(
+ struct hisi_accel *accel,
+ /* pointer to start of source buffer in system memory */
+ const char *psrcbuf,
+ /* Pitch value (in bytes) of the source buffer,
+ * +ive means top down and -ive mean button up
+ */
+ u32 srcdelta,
+ /* Mono data can start at any bit in a byte,
+ * this value should be 0 to 7
+ */
+ u32 startbit,
+ u32 dbase, /* Address of destination: offset in frame buffer */
+ u32 dpitch, /* Pitch value of destination surface in BYTE */
+ u32 bytperpxl, /* Color depth of destination surface */
+ u32 dx,
+ u32 dy, /* Starting coordinate of destination surface */
+ u32 width,
+ u32 height, /* width and height of rectange in pixel value */
+ /* Foreground color (corresponding to a 1 in the monochrome data */
+ u32 fcolor,
+ /* Background color (corresponding to a 0 in the monochrome data */
+ u32 bcolor,
+ u32 rop2) /* ROP value */
+{
+ unsigned int bytes_per_scan;
+ unsigned int qbytes_per_scan;
+ unsigned int bytes_remain;
+ unsigned int de_ctrl = 0;
+ unsigned char ajRemain[4];
+ int i, j;
+
+ /* Just make sure the start bit is within legal range */
+ startbit &= 7;
+ bytes_per_scan = (width + startbit + 7) / 8;
+ qbytes_per_scan = bytes_per_scan & ~3;
+ bytes_remain = bytes_per_scan & 3;
+
+ if (accel->de_wait() != 0)
+ return -1;
+
+ /* 2D Source Base. Use 0 for HOST Blt.*/
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, 0);
+
+ /* 2D Destination Base.
+ * It is an address offset (128 bit aligned)
+ * from the beginning of frame buffer.
+ */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dbase);
+ /* dpr10 */
+ write_dpr(accel, DE_PITCH,
+ FIELD_VALUE(0, DE_PITCH, DESTINATION, dpitch / bytperpxl)|
+ FIELD_VALUE(0, DE_PITCH, SOURCE, dpitch / bytperpxl));
+
+ /* Screen Window width in Pixels.
+ * 2D engine uses this value to calculate
+ * the linear address in frame buffer
+ * for a given point.
+ */
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION,
+ (dpitch / bytperpxl)) |
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE,
+ (dpitch / bytperpxl))
+ );
+
+ /* Note: For 2D Source in Host Write, only X_K1_MONO
+ * field is needed, and Y_K2 field is not used.For mono bitmap,
+ * use startBit for X_K1.
+ */
+ write_dpr(accel, DE_SOURCE,
+ FIELD_SET(0, DE_SOURCE, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startbit)); /* dpr00 */
+
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_DESTINATION, X, dx) |
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
+
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
+
+ write_dpr(accel, DE_FOREGROUND, fcolor);
+ write_dpr(accel, DE_BACKGROUND, bcolor);
+
+ de_ctrl = FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ FIELD_SET(0, DE_CONTROL, COMMAND, HOST_WRITE) |
+ FIELD_SET(0, DE_CONTROL, HOST, MONO) |
+ FIELD_SET(0, DE_CONTROL, STATUS, START);
+
+ write_dpr(accel, DE_CONTROL,
+ de_ctrl | de_get_transparency(accel));
+
+ /* Write MONO data (line by line) to 2D Engine data port */
+ for (i = 0; i < height; i++) {
+ /* For each line, send the data in chunks of 4 bytes */
+ for (j = 0; j < (qbytes_per_scan/4); j++)
+ write_dpport(accel,
+ *(unsigned int *)(psrcbuf + (j * 4)));
+
+ if (bytes_remain) {
+ memcpy(ajRemain, psrcbuf+qbytes_per_scan,
+ bytes_remain);
+ write_dpport(accel, *(unsigned int *)ajRemain);
+ }
+
+ psrcbuf += srcdelta;
+ }
+
+ return 0;
+}
diff --git a/drivers/video/fbdev/hisilicon/hisi_accel.h b/drivers/video/fbdev/hisilicon/hisi_accel.h
new file mode 100644
index 0000000..3393b2e
--- /dev/null
+++ b/drivers/video/fbdev/hisilicon/hisi_accel.h
@@ -0,0 +1,62 @@
+#ifndef HISI_ACCEL_H__
+#define HISI_ACCEL_H__
+
+#define HW_ROP2_COPY 0xc
+#define HW_ROP2_XOR 0x6
+
+
+/* blt direction */
+#define TOP_TO_BOTTOM 0
+#define LEFT_TO_RIGHT 0
+#define BOTTOM_TO_TOP 1
+#define RIGHT_TO_LEFT 1
+
+void hw_set_2dformat(struct hisi_accel *accel, int fmt);
+int hw_de_init(struct hisi_accel *accel);
+int hw_fillrect(struct hisi_accel *accel, u32 base, u32 pitch, u32 bpp,
+ u32 x, u32 y, u32 width, u32 height, u32 color, u32 rop);
+
+int hw_copyarea(
+ struct hisi_accel *accel,
+ unsigned int sbase, /* Address of source: offset in frame buffer */
+ unsigned int spitch, /* Pitch value of source surface in BYTE */
+ unsigned int sx,
+ unsigned int sy, /* Starting coordinate of source surface */
+ /* Address of destination: offset in frame buffer */
+ unsigned int dbase,
+ unsigned int dpitch, /* Pitch value of destination surface in BYTE */
+ unsigned int bpp, /* Color depth of destination surface */
+ unsigned int dx,
+ unsigned int dy, /* Starting coordinate of destination surface */
+ unsigned int width,
+ unsigned int height,
+ unsigned int rop2
+);
+
+int hw_imageblit(
+ struct hisi_accel *accel,
+ /* pointer to start of source buffer in system memory */
+ const char *psrcbuf,
+ /* Pitch value (in bytes) of the source buffer,
+ * +ive means top down and -ive mean button up
+ */
+ u32 srcdelta,
+ /* Mono data can start at any bit in a byte, this value
+ * should be 0 to 7
+ */
+ u32 startbit,
+ u32 dbase, /* Address of destination: offset in frame buffer */
+ u32 dpitch, /* Pitch value of destination surface in BYTE */
+ u32 byteperpixel, /* Color depth of destination surface */
+ u32 dx,
+ u32 dy, /* Starting coordinate of destination surface */
+ u32 width,
+ u32 height, /* width and height of rectange in pixel value */
+ /* Foreground color (corresponding to a 1 in the monochrome data */
+ u32 fcolor,
+ /* Background color (corresponding to a 0 in the monochrome data */
+ u32 bcolor,
+ u32 rop2
+);
+
+#endif
diff --git a/drivers/video/fbdev/hisilicon/hisi_drv.c b/drivers/video/fbdev/hisilicon/hisi_drv.c
index 54231d3..e16f942 100644
--- a/drivers/video/fbdev/hisilicon/hisi_drv.c
+++ b/drivers/video/fbdev/hisilicon/hisi_drv.c
@@ -20,6 +20,7 @@
#include "hisi_drv.h"
#include "hisi_cursor.h"
#include "hisi_hw.h"
+#include "hisi_accel.h"
/* chip specific setup routine */
@@ -187,6 +188,103 @@ static int hisifb_ops_cursor(struct fb_info *info, struct fb_cursor *fbcursor)
return 0;
}
+static void hisifb_ops_fillrect(struct fb_info *info,
+ const struct fb_fillrect *region)
+{
+ struct hisifb_par *par;
+ struct hisi_share *share;
+ unsigned int base, pitch, Bpp, rop;
+ u32 color;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return;
+
+ par = info->par;
+ share = par->share;
+
+ /*
+ * each time 2d function begin to work,below three variable always need
+ * be set, seems we can put them together in some place
+ */
+ base = par->crtc.oscreen;
+ pitch = info->fix.line_length;
+ Bpp = info->var.bits_per_pixel >> 3;
+
+ color = (Bpp = 1) ? region->color :
+ ((u32 *)info->pseudo_palette)[region->color];
+ rop = (region->rop != ROP_COPY) ?
+ HW_ROP2_XOR : HW_ROP2_COPY;
+
+ share->accel.de_fillrect(&share->accel,
+ base, pitch, Bpp, region->dx,
+ region->dy, region->width,
+ region->height, color, rop);
+}
+
+static void hisifb_ops_copyarea(struct fb_info *info,
+ const struct fb_copyarea *region)
+{
+ struct hisifb_par *par;
+ struct hisi_share *share;
+ unsigned int base, pitch, Bpp;
+
+ par = info->par;
+ share = par->share;
+
+ /*
+ * each time 2d function begin to work,below three variable always need
+ * be set, seems we can put them together in some place
+ */
+ base = par->crtc.oscreen;
+ pitch = info->fix.line_length;
+ Bpp = info->var.bits_per_pixel >> 3;
+
+ share->accel.de_copyarea(&share->accel, base, pitch,
+ region->sx, region->sy, base,
+ pitch, Bpp, region->dx, region->dy,
+ region->width, region->height,
+ HW_ROP2_COPY);
+}
+
+static void hisifb_ops_imageblit(struct fb_info *info,
+ const struct fb_image *image)
+{
+ unsigned int base, pitch, Bpp;
+ unsigned int fgcol, bgcol;
+ struct hisifb_par *par;
+ struct hisi_share *share;
+
+ par = info->par;
+ share = par->share;
+ /*
+ * each time 2d function begin to work,below three variable always need
+ * be set, seems we can put them together in some place
+ */
+ base = par->crtc.oscreen;
+ pitch = info->fix.line_length;
+ Bpp = info->var.bits_per_pixel >> 3;
+
+ if (image->depth = 1) {
+ if (info->fix.visual = FB_VISUAL_TRUECOLOR ||
+ info->fix.visual = FB_VISUAL_DIRECTCOLOR) {
+ fgcol = ((u32 *)info->pseudo_palette)[image->fg_color];
+ bgcol = ((u32 *)info->pseudo_palette)[image->bg_color];
+ } else {
+ fgcol = image->fg_color;
+ bgcol = image->bg_color;
+ }
+ goto _do_work;
+ }
+ return;
+_do_work:
+ share->accel.de_imageblit(&share->accel,
+ image->data, image->width >> 3, 0,
+ base, pitch, Bpp,
+ image->dx, image->dy,
+ image->width, image->height,
+ fgcol, bgcol, HW_ROP2_COPY);
+}
+
static struct fb_ops hisifb_ops = {
.owner = THIS_MODULE,
.fb_check_var = hisifb_ops_check_var,
@@ -710,7 +808,12 @@ static int hisifb_set_fbinfo(struct fb_info *info, int index)
}
/* set info->fbops, must be set before fb_find_mode */
-
+ if (!share->accel_off) {
+ /* use 2d acceleration */
+ hisifb_ops.fb_fillrect = hisifb_ops_fillrect;
+ hisifb_ops.fb_copyarea = hisifb_ops_copyarea;
+ hisifb_ops.fb_imageblit = hisifb_ops_imageblit;
+ }
info->fbops = &hisifb_ops;
if (!g_fbmode[index]) {
@@ -880,6 +983,23 @@ static int hisifb_pci_probe(struct pci_dev *pdev,
share->accel_off = g_noaccel;
share->dual = g_dualview;
+
+ if (!share->accel_off) {
+ /*
+ * hook deInit and 2d routines, notes that below hw_xxx
+ * routine can work on most of hisi chips,if some chip need
+ * specific function,please hook it in smXXX_set_drv
+ * routine
+ */
+ share->accel.de_init = hw_de_init;
+ share->accel.de_fillrect = hw_fillrect;
+ share->accel.de_copyarea = hw_copyarea;
+ share->accel.de_imageblit = hw_imageblit;
+ inf_msg("enable 2d acceleration\n");
+ } else {
+ inf_msg("disable 2d acceleration\n");
+ }
+
/* call chip specific setup routine */
hisi_fb_setup(share, g_settings);
diff --git a/drivers/video/fbdev/hisilicon/hisi_hw.c b/drivers/video/fbdev/hisilicon/hisi_hw.c
index e993f25..22fa166 100644
--- a/drivers/video/fbdev/hisilicon/hisi_hw.c
+++ b/drivers/video/fbdev/hisilicon/hisi_hw.c
@@ -18,6 +18,7 @@
#include <linux/string.h>
#include <linux/vmalloc.h>
#include "hisi_drv.h"
+#include "hisi_accel.h"
#include "hisi_help.h"
#include "hisi_hw.h"
#include "hisi_mode.h"
@@ -138,14 +139,34 @@ int hw_hisi_crtc_setmode(struct hisifb_crtc *crtc,
struct fb_var_screeninfo *var,
struct fb_fix_screeninfo *fix)
{
- int ret;
+ int ret, fmt;
u32 reg;
struct mode_para modparm;
enum clock_type clock;
+ struct hisi_share *share;
struct hisifb_par *par;
ret = 0;
par = container_of(crtc, struct hisifb_par, crtc);
+ share = par->share;
+
+ if (!share->accel_off) {
+ /* set 2d engine pixel format according to mode bpp */
+ switch (var->bits_per_pixel) {
+ case 8:
+ fmt = 0;
+ break;
+ case 16:
+ fmt = 1;
+ break;
+ case 32:
+ default:
+ fmt = 2;
+ break;
+ }
+ hw_set_2dformat(&share->accel, fmt);
+ }
+
/* set timing */
modparm.pixel_clock = ps_to_hz(var->pixclock);
modparm.vsync_polarity --
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox