* [PATCH 3/3] video: fbdev: imxfb: add some error handling
From: Uwe Kleine-König @ 2016-03-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1457380425-20244-1-git-send-email-u.kleine-koenig@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/fbdev/imxfb.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index 3dd2824e6773..671b3719db56 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -473,8 +473,9 @@ static int imxfb_set_par(struct fb_info *info)
return 0;
}
-static void imxfb_enable_controller(struct imxfb_info *fbi)
+static int imxfb_enable_controller(struct imxfb_info *fbi)
{
+ int ret;
if (fbi->enabled)
return;
@@ -496,10 +497,27 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
*/
writel(RMCR_LCDC_EN_MX1, fbi->regs + LCDC_RMCR);
- clk_prepare_enable(fbi->clk_ipg);
- clk_prepare_enable(fbi->clk_ahb);
- clk_prepare_enable(fbi->clk_per);
+ ret = clk_prepare_enable(fbi->clk_ipg);
+ if (ret)
+ goto err_enable_ipg;
+
+ ret = clk_prepare_enable(fbi->clk_ahb);
+ if (ret)
+ goto err_enable_ahb;
+
+ ret = clk_prepare_enable(fbi->clk_per);
+ if (ret) {
+ clk_disable_unprepare(fbi->clk_ahb);
+err_enable_ahb:
+ clk_disable_unprepare(fbi->clk_ipg);
+err_enable_ipg:
+ writel(0, fbi->regs + LCDC_RMCR);
+
+ return ret;
+ }
+
fbi->enabled = true;
+ return 0;
}
static void imxfb_disable_controller(struct imxfb_info *fbi)
@@ -510,8 +528,8 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
pr_debug("Disabling LCD controller\n");
clk_disable_unprepare(fbi->clk_per);
- clk_disable_unprepare(fbi->clk_ipg);
clk_disable_unprepare(fbi->clk_ahb);
+ clk_disable_unprepare(fbi->clk_ipg);
fbi->enabled = false;
writel(0, fbi->regs + LCDC_RMCR);
@@ -520,6 +538,7 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
static int imxfb_blank(int blank, struct fb_info *info)
{
struct imxfb_info *fbi = info->par;
+ int ret = 0;;
pr_debug("imxfb_blank: blank=%d\n", blank);
@@ -532,10 +551,10 @@ static int imxfb_blank(int blank, struct fb_info *info)
break;
case FB_BLANK_UNBLANK:
- imxfb_enable_controller(fbi);
+ ret = imxfb_enable_controller(fbi);
break;
}
- return 0;
+ return ret;
}
static struct fb_ops imxfb_ops = {
--
2.7.0
^ permalink raw reply related
* [PATCH 2/3] video: fbdev: imxfb: enable lcd regulator in .probe
From: Uwe Kleine-König @ 2016-03-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1457380425-20244-1-git-send-email-u.kleine-koenig@pengutronix.de>
This asserts that the display is on after the driver is initialized.
Otherwise, depending on how the boot loader handled the display, it is
either disabled as the regulator doesn't seem in use, or it stays off.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/fbdev/imxfb.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index c5fcedde2a60..3dd2824e6773 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -979,8 +979,17 @@ static int imxfb_probe(struct platform_device *pdev)
imxfb_enable_controller(fbi);
fbi->pdev = pdev;
+ if (!IS_ERR(fbi->lcd_pwr)) {
+ ret = regulator_enable(fbi->lcd_pwr);
+ if (ret)
+ goto failed_regulator;
+ }
+
return 0;
+failed_regulator:
+ imxfb_disable_controller(fbi);
+
failed_lcd:
unregister_framebuffer(info);
--
2.7.0
^ permalink raw reply related
* [PATCH 1/3] video: fbdev: imxfb: fix semantic of .get_power and .set_power
From: Uwe Kleine-König @ 2016-03-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1457380425-20244-1-git-send-email-u.kleine-koenig@pengutronix.de>
.set_power gets passed an FB_BLANK_XXX value, not a bool. So 0 signals
on; and >1 means off. The same applies for return values of .get_power.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/fbdev/imxfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index cee88603efc9..c5fcedde2a60 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -759,9 +759,9 @@ static int imxfb_lcd_get_power(struct lcd_device *lcddev)
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
if (!IS_ERR(fbi->lcd_pwr))
- return regulator_is_enabled(fbi->lcd_pwr);
+ return !regulator_is_enabled(fbi->lcd_pwr);
- return 1;
+ return 0;
}
static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
@@ -769,7 +769,7 @@ static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
if (!IS_ERR(fbi->lcd_pwr)) {
- if (power)
+ if (!power)
return regulator_enable(fbi->lcd_pwr);
else
return regulator_disable(fbi->lcd_pwr);
--
2.7.0
^ permalink raw reply related
* [PATCH 0/3] video: fbdev: imxfb: make it work again
From: Uwe Kleine-König @ 2016-03-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
it seems the imxfb driver stopped working quite some time ago. Here come
some fixes to convince the driver to operate again. This is a cleanup of
the RFC patch "video: fbdev: imxfb: make the driver cooperate" I sent
last week (Message-Id:
1456829223-1526-1-git-send-email-u.kleine-koenig@pengutronix.de).
Best regards
Uwe
Uwe Kleine-König (3):
video: fbdev: imxfb: fix semantic of .get_power and .set_power
video: fbdev: imxfb: enable lcd regulator in .probe
video: fbdev: imxfb: add some error handling
drivers/video/fbdev/imxfb.c | 48 +++++++++++++++++++++++++++++++++++----------
1 file changed, 38 insertions(+), 10 deletions(-)
--
2.7.0
^ permalink raw reply
* Re: [PATCH 4/5] Subject: goldfish: 32 bit framebuffer support
From: Tomi Valkeinen @ 2016-03-07 18:40 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]
On 26/02/16 20:42, Alan wrote:
> From: bohu <bohu@google.com>
>
> Add support for display formats and allow the use of both 16-bit and
> 32-bit framebuffers in the emulator.
>
> Signed-off-by: Bo Hu <bohu@google.com>
> Signed-off-by: Jin Qian <jinqian@android.com>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
> drivers/video/fbdev/goldfishfb.c | 88 ++++++++++++++++++++++++++++++++------
> 1 file changed, 74 insertions(+), 14 deletions(-)
Lots of the added lines in this patch just end up removed in the next one...
I guess these patches were just taken from some google tree and dumped
to fbdev. I'd appreciate if someone would go through them first before
sending.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] Subject: goldfish: Enable ACPI-based enumeration for goldfish framebuffer
From: Tomi Valkeinen @ 2016-03-07 18:35 UTC (permalink / raw)
To: Alan, linux-fbdev, plagnioj, linux-acpi
In-Reply-To: <20160226184157.2731.30846.stgit@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1747 bytes --]
On 26/02/16 20:41, Alan wrote:
> From: Yu Ning <yu.ning@intel.com>
>
> Enable ACPI bindings for the Goldfish framebuffer device.
>
> Signed-off-by: Yu Ning <yu.ning@intel.com>
> Signed-off-by: Jin Qian <jinqian@android.com>
> Signed-off-by: Alan <alan@linux.intel.com>
> ---
> drivers/video/fbdev/goldfishfb.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
> index f0e651b..58b33e4 100644
> --- a/drivers/video/fbdev/goldfishfb.c
> +++ b/drivers/video/fbdev/goldfishfb.c
> @@ -26,6 +26,7 @@
> #include <linux/interrupt.h>
> #include <linux/ioport.h>
> #include <linux/platform_device.h>
> +#include <linux/acpi.h>
>
> enum {
> FB_GET_WIDTH = 0x00,
> @@ -310,6 +311,12 @@ static const struct of_device_id goldfish_fb_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
>
> +static const struct acpi_device_id goldfish_fb_acpi_match[] = {
> + { "GFSH0004", 0 },
I'm not familiar with ACPI, so I need to ask... Where does the ID come
from? Is it safe to use that one, and there's no chance for a clash with
some other device in the future?
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, goldfish_fb_acpi_match);
> +
> static struct platform_driver goldfish_fb_driver = {
> .probe = goldfish_fb_probe,
> .remove = goldfish_fb_remove,
> @@ -317,6 +324,7 @@ static struct platform_driver goldfish_fb_driver = {
> .name = "goldfish_fb",
> .owner = THIS_MODULE,
> .of_match_table = goldfish_fb_of_match,
> + .acpi_match_table = ACPI_PTR(goldfish_fb_acpi_match),
So does the emulator sometimes use devicetree and sometimes ACPI to
match the device?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] Subject: video: goldfishfb: add devicetree bindings
From: Tomi Valkeinen @ 2016-03-07 18:29 UTC (permalink / raw)
To: Alan, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
plagnioj-sclMFOaUSTBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20160226184146.2731.41848.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2208 bytes --]
On 26/02/16 20:41, Alan wrote:
> From: Greg Hackmann <ghackmann@google.com>
>
> Add device tree bindings to the Goldfish frame buffer interface.
>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Jin Qian <jinqian@android.com>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
> Documentation/devicetree/bindings/goldfish/fb.txt | 17 +++++++++++++++++
> drivers/video/fbdev/goldfishfb.c | 9 ++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/goldfish/fb.txt
Device tree bindings should also be sent to the devicetree mailing list.
> diff --git a/Documentation/devicetree/bindings/goldfish/fb.txt b/Documentation/devicetree/bindings/goldfish/fb.txt
> new file mode 100644
> index 0000000..c7d2d46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/goldfish/fb.txt
> @@ -0,0 +1,17 @@
> +Android Goldfish Framebuffer
> +
> +Andorid goldfish framebuffer device generated by android emulator.
Typo there in Android.
> +
> +Required properties:
> +
> +- compatible : should contain "google,goldfish-fb" to match emulator
> +- reg : <registers mapping>
> +- interrupts : <interrupt mapping>
> +
> +Example:
> +
> + goldfish_fb@9010000 {
> + compatible = "google,goldfish-fb";
> + reg = <0x9010000 0x100>;
> + interrupts = <0x2>;
> + };
> diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
> index 7f6c9e6..f0e651b 100644
> --- a/drivers/video/fbdev/goldfishfb.c
> +++ b/drivers/video/fbdev/goldfishfb.c
> @@ -304,12 +304,19 @@ static int goldfish_fb_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct of_device_id goldfish_fb_of_match[] = {
> + { .compatible = "google,goldfish-fb", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
>
> static struct platform_driver goldfish_fb_driver = {
> .probe = goldfish_fb_probe,
> .remove = goldfish_fb_remove,
> .driver = {
> - .name = "goldfish_fb"
> + .name = "goldfish_fb",
> + .owner = THIS_MODULE,
> + .of_match_table = goldfish_fb_of_match,
> }
> };
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] goldfish: bring the framebuffer in sync with upstream
From: Tomi Valkeinen @ 2016-03-07 18:26 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1.1: Type: text/plain, Size: 901 bytes --]
On 26/02/16 20:41, Alan wrote:
> The Android tree has changes to support Goldfish (Android virtual platform
> emulator) improvements. Pull those into upstream as part of the goal of
> making upstream run out of the box on Goldfish.
>
> ---
>
> Christoffer Dall (1):
> Subject: goldfish_fb: Set pixclock = 0
>
> Greg Hackmann (1):
> Subject: video: goldfishfb: add devicetree bindings
>
> Nicolas Capens (1):
> Subject: goldfishfb: simplify framebuffer format selection.
>
> Yu Ning (1):
> Subject: goldfish: Enable ACPI-based enumeration for goldfish framebuffer
>
> bohu (1):
> Subject: goldfish: 32 bit framebuffer support
"bohu" doesn't look like a real name. The emails should use the standard
format.
All the patches have "Subject: " in the subject... We know it's the
subject without saying that in the subject =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/12] pwm: add support for atomic update
From: Doug Anderson @ 2016-03-07 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VckTVD8b1g+f0G2kMeoTjvY0pAGhoDnWQN_dAmqSxBxg@mail.gmail.com>
Thierry,
On Thu, Feb 25, 2016 at 3:14 PM, Doug Anderson <dianders@google.com> wrote:
> So just to summarize:
>
> * Add pwm_get_state(), pwm_apply_state(), pwm_get_args().
> pwm_get_state() initially returns 0 for duty cycle if driver doesn't
> support readout.
>
> * Re-implement pwm_get_period() (and maybe other similar functions)
> atop pwm_get_state() as you describe earlier in the thread.
>
> * Document pwm_get_period() (and maybe other similar functions) as deprecated.
>
> * Fix drivers for all current 2 users of PWM regulator to support
> hardware readout.
>
> * Update PWM regulator as you described earlier in the thread (Feb 23).
>
> * If PWM regulator is ever used on a new board whose PWM doesn't
> support hardware readout, the voltage will change at probe time.
>
>
> Did I get all that right? Thanks!
Can you provide a "yes, you got that right" or a "no, you didn't
understand"? That will unblock Boris, I think.
-Doug
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Tomi Valkeinen @ 2016-03-07 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaJ1xzRp4gg1wLSoo_se+LEC9sUDZ-9L2iZ1g4GPj_dZw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1111 bytes --]
On 05/03/16 18:57, Linus Walleij wrote:
> On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Although one thing to consider is that if there is ever going to be a
>> DRM driver for CLCD, it would be good to have the device tree parts
>> correctly representing the hardware, so that the DRM driver could be
>> implemented in a cleaner, more generic way.
>
> OK so for the next kernel cycle I can work on that.
>
> The non-controversial patch set is essentially just using the DT bindings
Yes, I think the non-controversial series is fine. Will you be sending a
v2 of that series?
> that are already in the kernel and in widespread use. See:
> commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
> "video: ARM CLCD: Add DT support"
>
> They follow the example set by
> commit 478a4f81af4936c683a03488e15b087e28cb4f0d
> "ARM: vexpress: Add CLCD Device Tree properties"
This one not actually correct, as the panel node is inside the clcd
node. The child parent relationship should represent a control bus. But
that's a different topic...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7 v2] video: ARM CLCD: support DT signal inversion flags
From: Linus Walleij @ 2016-03-07 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56D02A3A.6010701@ti.com>
On Fri, Feb 26, 2016 at 5:34 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> + /* Set up some inversion flags */
>> + timnp = of_get_child_by_name(node, "panel-timing");
>> + if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
>
> Hmm, why are you poking in the videomode DT properties directly?
It is to provide
backward compatibility with already deployed device trees that
do not have this property set, so that they default to negative edge
rather than positive edge.
> If the
> pixelclk-active was not defined in the DT, you should see it in the
> videomode struct as neither DISPLAY_FLAGS_PIXDATA_POSEDGE nor
> DISPLAY_FLAGS_PIXDATA_NEGEDGE being set (I think, I didn't go through
> the code in detail).
OK I'll take a look!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-03-05 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56D02D28.9080109@ti.com>
On Fri, Feb 26, 2016 at 5:47 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Although one thing to consider is that if there is ever going to be a
> DRM driver for CLCD, it would be good to have the device tree parts
> correctly representing the hardware, so that the DRM driver could be
> implemented in a cleaner, more generic way.
OK so for the next kernel cycle I can work on that.
The non-controversial patch set is essentially just using the DT bindings
that are already in the kernel and in widespread use. See:
commit d10715be03bd8bad59ddc50236cb140c3bd73c7b
"video: ARM CLCD: Add DT support"
They follow the example set by
commit 478a4f81af4936c683a03488e15b087e28cb4f0d
"ARM: vexpress: Add CLCD Device Tree properties"
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Ingo Molnar @ 2016-03-05 11:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: paulmck, bp, tglx, hpa, toshi.kani, airlied, benh, mst,
vinod.koul, jgross, daniel.vetter, luto, davem, ben,
benjamin.poirier, linux-fbdev, linux-arch, linux-kernel, x86,
linux-doc, corbet
In-Reply-To: <1457131501-14855-1-git-send-email-mcgrof@kernel.org>
* Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> The current documentation refers to using set_memory_wc() as a
> possible hole strategy when you have overlapping ioremap() regions,
The whole explanation should talk about virtual aliases over the same physical
address, not some 'overlapping regions'.
I see where this talk about 'overlap' comes: the memtype rbtree in
arch/x86/mm/pat_rbtree.c indeed has memtype ranges that may overlap on the
physical side. But it is highly confusing to call this 'overlapping' on the driver
API documentation level without making it really clear what it's about.
Thanks,
Ingo
^ permalink raw reply
* RE: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Elliott, Robert (Persistent Memory) @ 2016-03-05 4:39 UTC (permalink / raw)
To: Luis R. Rodriguez, paulmck@linux.vnet.ibm.com, bp@alien8.de,
mingo@kernel.org, tglx@linutronix.de, hpa@zytor.com,
toshi.kani@hp.com
Cc: airlied@redhat.com, benh@kernel.crashing.org, mst@redhat.com,
vinod.koul@intel.com, jgross@suse.com, daniel.vetter@ffwll.ch,
luto@amacapital.net, davem@davemloft.net, ben@decadent.org.uk,
benjamin.poirier@gmail.com, linux-fbdev@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net
In-Reply-To: <1457131501-14855-1-git-send-email-mcgrof@kernel.org>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Friday, March 04, 2016 4:45 PM
> Subject: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on
> PAT / non-PAT systems"
...
> +MMIO and another PCI BAR for write-combing, if needed.
typo: combining
^ permalink raw reply
* Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Luis R. Rodriguez @ 2016-03-05 1:03 UTC (permalink / raw)
To: Paul E. McKenney, bp
Cc: Luis R. Rodriguez, mingo, tglx, hpa, toshi.kani, airlied, benh,
mst, vinod.koul, jgross, daniel.vetter, luto, davem, ben,
benjamin.poirier, linux-fbdev, linux-arch, linux-kernel, x86,
linux-doc, corbet
In-Reply-To: <20160305000304.GA3577@linux.vnet.ibm.com>
On Fri, Mar 04, 2016 at 04:03:04PM -0800, Paul E. McKenney wrote:
> On Fri, Mar 04, 2016 at 02:45:01PM -0800, Luis R. Rodriguez wrote:
> > The current documentation refers to using set_memory_wc() as a
> > possible hole strategy when you have overlapping ioremap() regions,
> > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > not IO memory. Using set_memory_wc() will not fail, that's a problem
> > which must be corrected in the future. This fixes that, and updates
> > the documention to *strongly* discourage overlapping ioremap() memory
> > uses, but also documents a possible solution should there really be
> > no other option to remain compatible on both PAT and MTRR memory
> > constarained systems. While at it, this provides some same guidlines
> > to system designers to remain sane and compatible on both PAT and
> > non-PAT systems.
> >
> > As per Toshi this also fixes the table for the effective memory type
> > when using MTRR WC on PAT UC- to WC.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>
> And I was really confused during my earlier reply. For some reason
> I read the filename as memory-barriers.txt.
>
> This one is not mine. Too much time in standards committee meetings,
> I guess. ;-)
Heh, OK yeah I was confused why you wanted to pick it up but played along.
Boris, can this go through you as its a follow up that previously went
through you ?
Luis
^ permalink raw reply
* Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Paul E. McKenney @ 2016-03-05 0:03 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: bp, mingo, tglx, hpa, toshi.kani, airlied, benh, mst, vinod.koul,
jgross, daniel.vetter, luto, davem, ben, benjamin.poirier,
linux-fbdev, linux-arch, linux-kernel, x86, linux-doc, corbet
In-Reply-To: <1457131501-14855-1-git-send-email-mcgrof@kernel.org>
On Fri, Mar 04, 2016 at 02:45:01PM -0800, Luis R. Rodriguez wrote:
> The current documentation refers to using set_memory_wc() as a
> possible hole strategy when you have overlapping ioremap() regions,
> that's incorrect as set_memory_*() helpers can only be used on RAM,
> not IO memory. Using set_memory_wc() will not fail, that's a problem
> which must be corrected in the future. This fixes that, and updates
> the documention to *strongly* discourage overlapping ioremap() memory
> uses, but also documents a possible solution should there really be
> no other option to remain compatible on both PAT and MTRR memory
> constarained systems. While at it, this provides some same guidlines
> to system designers to remain sane and compatible on both PAT and
> non-PAT systems.
>
> As per Toshi this also fixes the table for the effective memory type
> when using MTRR WC on PAT UC- to WC.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
And I was really confused during my earlier reply. For some reason
I read the filename as memory-barriers.txt.
This one is not mine. Too much time in standards committee meetings,
I guess. ;-)
Thanx, Paul
> ---
> Documentation/x86/pat.txt | 54 +++++++++++++++++++++++++++++++++++------------
> 1 file changed, 41 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index 54944c71b819..6323f24f3b59 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -112,19 +112,47 @@ before the page is freed to free pool.
> MTRR effects on PAT / non-PAT systems
> -------------------------------------
>
> +As of v4.3 mtrr_add() has been phased out in favor of arch_phys_wc_add(),
> +these calls are a no-op on PAT enabled systems but remain MTRR effective
> +on non-PAT systems. In order for this to work properly on both PAT and
> +non-PAT systems the region over which an arch_phys_wc_add() is made should be
> +ioremapped with WC attributes or PAT entries, using ioremap_wc().
> +
> +To enable simplifying device drivers, and to help support PAT and remain
> +compatible with non-PAT systems, PCI devices are encouraged to dedicate a full
> +PCI bar for different intended regions of IO, for instance one PCI BAR for
> +MMIO and another PCI BAR for write-combing, if needed.
> +
> +Firmware should always expose to the operating system where write-combining is
> +desirable, otherwise PAT cannot be supported, PAT systems need to know the
> +physical address of the area where write-combining is desirable.
> +
> +Devices which use a single PCI BAR to combine different areas of IO memory
> +must use separate ioremap() calls for each type of intended IO memory.
> +Physically overlapping ioremap calls are strongly discouraged and may soon be
> +disallowed. Devices that have one PCI BAR with an area of IO where
> +write-combining is desirable followed contiguously by an area of MMIO
> +should ioremap_wc() only on the area where write-combining is desired,
> +followed by a physically non-overlapping ioremap_uc() for MMIO. Since MTRR
> +calls are limited, and since MTRR calls must be done with orders of power of 2
> +on both the size and base address one may be constrained to use just one MTRR
> +call which will include the full MMIO range. In such cases, in order to remain
> +compatible with PAT and functional on non-PAT systems arch_phys_wc_add() can
> +be used to enable MTRR WC on the entire PCI BAR for all the combined IO range
> +(both write-combining and MMIO range). Using ioremap_uc() ensures that a
> +MTRR WC applied to it effectively yields UC, while using ioremap_wc()
> +white-lists the MTRR WC effects over its region. For an example of this
> +strategy refer to commit 3cc2dac5be ("drivers/video/fbdev/atyfb: Replace
> +MTRR UC hole with strong UC"). Such use is nevertheless heavily discouraged
> +as the effective memory type for the write-combined area on non-PAT is
> +technically considered implementation defined. This strategy should only be
> +used used as a last resort measure.
> +
> +You cannot use set_memory_*() helpers on ioremap'd regions (IO memory), even
> +though its use currently gives no hint of an error.
> +
> The following table provides the effects of using write-combining MTRRs when
> -using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> -mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
> -be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> -is made, should already have been ioremapped with WC attributes or PAT entries,
> -this can be done by using ioremap_wc() / set_memory_wc(). Devices which
> -combine areas of IO memory desired to remain uncacheable with areas where
> -write-combining is desirable should consider use of ioremap_uc() followed by
> -set_memory_wc() to white-list effective write-combined areas. Such use is
> -nevertheless discouraged as the effective memory type is considered
> -implementation defined, yet this strategy can be used as last resort on devices
> -with size-constrained regions where otherwise MTRR write-combining would
> -otherwise not be effective.
> +using ioremap*() calls on x86 for both non-PAT and PAT systems.
>
> ----------------------------------------------------------------------
> MTRR Non-PAT PAT Linux ioremap value Effective memory type
> @@ -136,7 +164,7 @@ MTRR Non-PAT PAT Linux ioremap value Effective memory type
> |||
> WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> -WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
> +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> ----------------------------------------------------------------------
>
> --
> 2.7.2
>
^ permalink raw reply
* [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Luis R. Rodriguez @ 2016-03-04 22:45 UTC (permalink / raw)
To: paulmck, bp, mingo, tglx, hpa, toshi.kani
Cc: airlied, benh, mst, vinod.koul, jgross, daniel.vetter, luto,
davem, ben, benjamin.poirier, linux-fbdev, linux-arch,
linux-kernel, x86, linux-doc, corbet, Luis R. Rodriguez
In-Reply-To: <20160304210900.GT3577@linux.vnet.ibm.com>
The current documentation refers to using set_memory_wc() as a
possible hole strategy when you have overlapping ioremap() regions,
that's incorrect as set_memory_*() helpers can only be used on RAM,
not IO memory. Using set_memory_wc() will not fail, that's a problem
which must be corrected in the future. This fixes that, and updates
the documention to *strongly* discourage overlapping ioremap() memory
uses, but also documents a possible solution should there really be
no other option to remain compatible on both PAT and MTRR memory
constarained systems. While at it, this provides some same guidlines
to system designers to remain sane and compatible on both PAT and
non-PAT systems.
As per Toshi this also fixes the table for the effective memory type
when using MTRR WC on PAT UC- to WC.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/x86/pat.txt | 54 +++++++++++++++++++++++++++++++++++------------
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c71b819..6323f24f3b59 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -112,19 +112,47 @@ before the page is freed to free pool.
MTRR effects on PAT / non-PAT systems
-------------------------------------
+As of v4.3 mtrr_add() has been phased out in favor of arch_phys_wc_add(),
+these calls are a no-op on PAT enabled systems but remain MTRR effective
+on non-PAT systems. In order for this to work properly on both PAT and
+non-PAT systems the region over which an arch_phys_wc_add() is made should be
+ioremapped with WC attributes or PAT entries, using ioremap_wc().
+
+To enable simplifying device drivers, and to help support PAT and remain
+compatible with non-PAT systems, PCI devices are encouraged to dedicate a full
+PCI bar for different intended regions of IO, for instance one PCI BAR for
+MMIO and another PCI BAR for write-combing, if needed.
+
+Firmware should always expose to the operating system where write-combining is
+desirable, otherwise PAT cannot be supported, PAT systems need to know the
+physical address of the area where write-combining is desirable.
+
+Devices which use a single PCI BAR to combine different areas of IO memory
+must use separate ioremap() calls for each type of intended IO memory.
+Physically overlapping ioremap calls are strongly discouraged and may soon be
+disallowed. Devices that have one PCI BAR with an area of IO where
+write-combining is desirable followed contiguously by an area of MMIO
+should ioremap_wc() only on the area where write-combining is desired,
+followed by a physically non-overlapping ioremap_uc() for MMIO. Since MTRR
+calls are limited, and since MTRR calls must be done with orders of power of 2
+on both the size and base address one may be constrained to use just one MTRR
+call which will include the full MMIO range. In such cases, in order to remain
+compatible with PAT and functional on non-PAT systems arch_phys_wc_add() can
+be used to enable MTRR WC on the entire PCI BAR for all the combined IO range
+(both write-combining and MMIO range). Using ioremap_uc() ensures that a
+MTRR WC applied to it effectively yields UC, while using ioremap_wc()
+white-lists the MTRR WC effects over its region. For an example of this
+strategy refer to commit 3cc2dac5be ("drivers/video/fbdev/atyfb: Replace
+MTRR UC hole with strong UC"). Such use is nevertheless heavily discouraged
+as the effective memory type for the write-combined area on non-PAT is
+technically considered implementation defined. This strategy should only be
+used used as a last resort measure.
+
+You cannot use set_memory_*() helpers on ioremap'd regions (IO memory), even
+though its use currently gives no hint of an error.
+
The following table provides the effects of using write-combining MTRRs when
-using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
-mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
-be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
-is made, should already have been ioremapped with WC attributes or PAT entries,
-this can be done by using ioremap_wc() / set_memory_wc(). Devices which
-combine areas of IO memory desired to remain uncacheable with areas where
-write-combining is desirable should consider use of ioremap_uc() followed by
-set_memory_wc() to white-list effective write-combined areas. Such use is
-nevertheless discouraged as the effective memory type is considered
-implementation defined, yet this strategy can be used as last resort on devices
-with size-constrained regions where otherwise MTRR write-combining would
-otherwise not be effective.
+using ioremap*() calls on x86 for both non-PAT and PAT systems.
----------------------------------------------------------------------
MTRR Non-PAT PAT Linux ioremap value Effective memory type
@@ -136,7 +164,7 @@ MTRR Non-PAT PAT Linux ioremap value Effective memory type
|||
WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
-WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
+WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
----------------------------------------------------------------------
--
2.7.2
^ permalink raw reply related
* Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation
From: Paul E. McKenney @ 2016-03-04 21:09 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: bp, mingo, tglx, hpa, toshi.kani, airlied, benh, mst, vinod.koul,
jgross, daniel.vetter, luto, linux-fbdev, linux-arch,
linux-kernel, x86, linux-doc, corbet
In-Reply-To: <20160304192326.GU25240@wotan.suse.de>
On Fri, Mar 04, 2016 at 08:23:26PM +0100, Luis R. Rodriguez wrote:
> On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> > > The current documentation refers to using set_memor_wc() as a
> > > possible hole strategy when you have overlapping ioremap() regions,
> > > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > > not IO memory. This fixes that, and updates the documention to
> > > *strongly* discourage overlapping ioremap() memory uses, but also
> > > documents a possible solution should there really be no other
> > > option.
> > >
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> >
> > Given an Acked-by or better from the guys on the TO line, I would be
> > happy to queue it.
>
> I'll need to respin as fortunately I ended up actually not needing
> to do an overlap on atyfb, and instead just let MTRR be effective
> over an entire range that included both write-combining and strong
> UC attributes. It was a bit fuzzy as this while ago, and since its
> also obscure, its more reason to document now.
>
> Will spin a v2.
Sounds good!
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation
From: Luis R. Rodriguez @ 2016-03-04 19:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Luis R. Rodriguez, bp, mingo, tglx, hpa, toshi.kani, airlied,
benh, mst, vinod.koul, jgross, daniel.vetter, luto, linux-fbdev,
linux-arch, linux-kernel, x86, linux-doc, corbet
In-Reply-To: <20160303214233.GN3577@linux.vnet.ibm.com>
On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote:
> On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> > The current documentation refers to using set_memor_wc() as a
> > possible hole strategy when you have overlapping ioremap() regions,
> > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > not IO memory. This fixes that, and updates the documention to
> > *strongly* discourage overlapping ioremap() memory uses, but also
> > documents a possible solution should there really be no other
> > option.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>
> Given an Acked-by or better from the guys on the TO line, I would be
> happy to queue it.
I'll need to respin as fortunately I ended up actually not needing
to do an overlap on atyfb, and instead just let MTRR be effective
over an entire range that included both write-combining and strong
UC attributes. It was a bit fuzzy as this while ago, and since its
also obscure, its more reason to document now.
Will spin a v2.
Luis
^ permalink raw reply
* [PATCH] video: AMBA CLCD: Remove duplicated include in amba-clcd.c
From: Wang Hongcheng @ 2016-03-04 2:10 UTC (permalink / raw)
To: Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel, Borislav Petkov, SPG_Linux_Kernel
Cc: Wang Hongcheng
The header file asm/sizes.h is unnecessary.
And it can also be compiled under X86 arch after the removal.
Signed-off-by: Wang Hongcheng <annie.wang@amd.com>
---
drivers/video/fbdev/amba-clcd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9362424..1a1ed80 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -34,8 +34,6 @@
#include <video/of_display_timing.h>
#include <video/videomode.h>
-#include <asm/sizes.h>
-
#define to_clcd(info) container_of(info, struct clcd_fb, fb)
/* This is limited to 16 characters when displayed by X startup */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation
From: Paul E. McKenney @ 2016-03-03 21:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: bp, mingo, tglx, hpa, toshi.kani, airlied, benh, mst, vinod.koul,
jgross, daniel.vetter, luto, linux-fbdev, linux-arch,
linux-kernel, x86, linux-doc, corbet
In-Reply-To: <1457040108-27358-1-git-send-email-mcgrof@kernel.org>
On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> The current documentation refers to using set_memor_wc() as a
> possible hole strategy when you have overlapping ioremap() regions,
> that's incorrect as set_memory_*() helpers can only be used on RAM,
> not IO memory. This fixes that, and updates the documention to
> *strongly* discourage overlapping ioremap() memory uses, but also
> documents a possible solution should there really be no other
> option.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Given an Acked-by or better from the guys on the TO line, I would be
happy to queue it.
Thanx, Paul
> ---
> Documentation/x86/pat.txt | 25 ++++++++++++++-----------
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index 54944c71b819..8a26b4cdccf6 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -113,18 +113,21 @@ MTRR effects on PAT / non-PAT systems
> -------------------------------------
>
> The following table provides the effects of using write-combining MTRRs when
> -using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> -mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
> -be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. As of v4.3
> +mtrr_add() has been phased out in favor of arch_phys_wc_add(), these calls are
> +a no-op on PAT enabled systems. The region over which an arch_phys_wc_add()
> is made, should already have been ioremapped with WC attributes or PAT entries,
> -this can be done by using ioremap_wc() / set_memory_wc(). Devices which
> -combine areas of IO memory desired to remain uncacheable with areas where
> -write-combining is desirable should consider use of ioremap_uc() followed by
> -set_memory_wc() to white-list effective write-combined areas. Such use is
> -nevertheless discouraged as the effective memory type is considered
> -implementation defined, yet this strategy can be used as last resort on devices
> -with size-constrained regions where otherwise MTRR write-combining would
> -otherwise not be effective.
> +this can be done by using ioremap_wc(). Devices which combine areas of IO
> +memory desired to remain uncacheable with areas where write-combining is
> +desirable should consider use of ioremap_wc() followed by an overlapping
> +ioremap_uc() "hole". For an example of this strategy refer to commit 3cc2dac5be
> +("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC").
> +Such use is nevertheless heavily discouraged as the effective memory type is
> +considered implementation defined. This strategy should only be used used as a
> +last resort measure.
> +
> +Note you cannot use set_memory_*() helpers on ioremap'd regions, even though
> +its use currently gives no hint of an error.
>
> ----------------------------------------------------------------------
> MTRR Non-PAT PAT Linux ioremap value Effective memory type
> --
> 2.7.2
>
^ permalink raw reply
* [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation
From: Luis R. Rodriguez @ 2016-03-03 21:21 UTC (permalink / raw)
To: bp, mingo, tglx, hpa
Cc: toshi.kani, paulmck, airlied, benh, mst, vinod.koul, jgross,
daniel.vetter, luto, linux-fbdev, linux-arch, linux-kernel, x86,
linux-doc, corbet, Luis R. Rodriguez
The current documentation refers to using set_memor_wc() as a
possible hole strategy when you have overlapping ioremap() regions,
that's incorrect as set_memory_*() helpers can only be used on RAM,
not IO memory. This fixes that, and updates the documention to
*strongly* discourage overlapping ioremap() memory uses, but also
documents a possible solution should there really be no other
option.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/x86/pat.txt | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c71b819..8a26b4cdccf6 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -113,18 +113,21 @@ MTRR effects on PAT / non-PAT systems
-------------------------------------
The following table provides the effects of using write-combining MTRRs when
-using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
-mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
-be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+using ioremap*() calls on x86 for both non-PAT and PAT systems. As of v4.3
+mtrr_add() has been phased out in favor of arch_phys_wc_add(), these calls are
+a no-op on PAT enabled systems. The region over which an arch_phys_wc_add()
is made, should already have been ioremapped with WC attributes or PAT entries,
-this can be done by using ioremap_wc() / set_memory_wc(). Devices which
-combine areas of IO memory desired to remain uncacheable with areas where
-write-combining is desirable should consider use of ioremap_uc() followed by
-set_memory_wc() to white-list effective write-combined areas. Such use is
-nevertheless discouraged as the effective memory type is considered
-implementation defined, yet this strategy can be used as last resort on devices
-with size-constrained regions where otherwise MTRR write-combining would
-otherwise not be effective.
+this can be done by using ioremap_wc(). Devices which combine areas of IO
+memory desired to remain uncacheable with areas where write-combining is
+desirable should consider use of ioremap_wc() followed by an overlapping
+ioremap_uc() "hole". For an example of this strategy refer to commit 3cc2dac5be
+("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC").
+Such use is nevertheless heavily discouraged as the effective memory type is
+considered implementation defined. This strategy should only be used used as a
+last resort measure.
+
+Note you cannot use set_memory_*() helpers on ioremap'd regions, even though
+its use currently gives no hint of an error.
----------------------------------------------------------------------
MTRR Non-PAT PAT Linux ioremap value Effective memory type
--
2.7.2
^ permalink raw reply related
* [GIT PULL] fbdev fixes for 4.5
From: Tomi Valkeinen @ 2016-03-03 11:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 784 bytes --]
Hi Linus,
The following changes since commit 81f70ba233d5f660e1ea5fe23260ee323af5d53a:
Linux 4.5-rc5 (2016-02-20 13:39:35 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-4.5
for you to fetch changes up to a1e533ec07d583d01349ef13c0c965b8633e1b91:
fbcon: set a default value to blink interval (2016-02-26 13:19:55 +0200)
----------------------------------------------------------------
fbdev fixes for v4.5
* fix hang caused by fbconsole blink timer
----------------------------------------------------------------
Jean-Philippe Brucker (1):
fbcon: set a default value to blink interval
drivers/video/console/fbcon.c | 2 ++
1 file changed, 2 insertions(+)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: sis: remove unused variable
From: Tomi Valkeinen @ 2016-03-03 11:40 UTC (permalink / raw)
To: Sudip Mukherjee, Thomas Winischhofer,
Jean-Christophe Plagniol-Villard
Cc: linux-kernel, linux-fbdev
In-Reply-To: <1456768949-27318-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]
On 29/02/16 20:02, Sudip Mukherjee wrote:
> The variables modeflag and resinfo were only assigned some value but
> were never used.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
> drivers/video/fbdev/sis/init301.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH RFC] video: fbdev: imxfb: make the driver cooperate
From: Uwe Kleine-König @ 2016-03-01 10:47 UTC (permalink / raw)
To: linux-arm-kernel
The .get_power and .set_power callbacks didn't adhere to the expected(?)
convention to enable the power when the power parameter is zero.
Moreover ensure that the regulator is enabled together with the lcd
controller.
Without these changes there is nothing visible after bootup because the
regulator is kept off (or disabled by the regulator core because it's not
used). The lcd regulator is enabled only after 10 minutes of idle when it
should really go off.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
this introduces a new warning because the return value of regulator_enable
isn't checked. If it's agreed that the patch is ok in general I can fix this
up, but I don't know if fbdev is already too dead even for fixes like this.
Best regards
Uwe
drivers/video/fbdev/imxfb.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index cee88603efc9..7d763164820c 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -499,6 +499,9 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
clk_prepare_enable(fbi->clk_ipg);
clk_prepare_enable(fbi->clk_ahb);
clk_prepare_enable(fbi->clk_per);
+ if (!IS_ERR(fbi->lcd_pwr))
+ regulator_enable(fbi->lcd_pwr);
+
fbi->enabled = true;
}
@@ -513,6 +516,8 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
clk_disable_unprepare(fbi->clk_ipg);
clk_disable_unprepare(fbi->clk_ahb);
fbi->enabled = false;
+ if (!IS_ERR(fbi->lcd_pwr))
+ regulator_disable(fbi->lcd_pwr);
writel(0, fbi->regs + LCDC_RMCR);
}
@@ -759,9 +764,9 @@ static int imxfb_lcd_get_power(struct lcd_device *lcddev)
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
if (!IS_ERR(fbi->lcd_pwr))
- return regulator_is_enabled(fbi->lcd_pwr);
+ return !regulator_is_enabled(fbi->lcd_pwr);
- return 1;
+ return 0;
}
static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
@@ -769,7 +774,7 @@ static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
if (!IS_ERR(fbi->lcd_pwr)) {
- if (power)
+ if (!power)
return regulator_enable(fbi->lcd_pwr);
else
return regulator_disable(fbi->lcd_pwr);
--
2.7.0
^ 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