* Re: [PATCH v2 2/3] fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
From: Tomi Valkeinen @ 2016-02-16 13:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-3-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On 16/02/16 15:31, Uwe Kleine-König wrote:
> On Tue, Feb 16, 2016 at 03:01:55PM +0200, Tomi Valkeinen wrote:
>>
>> On 20/12/15 13:13, Uwe Kleine-König wrote:
>>> Some displays have a reset input. To assert that the display is
>>> functional the reset gpio must be deasserted.
>>>
>>> Teach the driver to get and drive such a gpio accordingly.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> --
>>> Changes since (implicit) v1, sent with
>>> Message-Id: 1449753107-11410-4-git-send-email-uwe@kleine-koenig.org :
>>>
>>> - never assert reset because there are too many different panels with
>>> too many different needs for their reset.
>>> - split out dt binding changes
>>> - reword commit log
>>
>> Please add these extra texts below the --- line below. Otherwise they
>> end up in the commit description.
>
> This was an accident. Should I resend for that one?
If there are other changes to other patches, resend the series. If there
are no other changes, I can just snip it out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
From: Uwe Kleine-König @ 2016-02-16 13:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-3-git-send-email-u.kleine-koenig@pengutronix.de>
On Tue, Feb 16, 2016 at 03:01:55PM +0200, Tomi Valkeinen wrote:
>
> On 20/12/15 13:13, Uwe Kleine-König wrote:
> > Some displays have a reset input. To assert that the display is
> > functional the reset gpio must be deasserted.
> >
> > Teach the driver to get and drive such a gpio accordingly.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > --
> > Changes since (implicit) v1, sent with
> > Message-Id: 1449753107-11410-4-git-send-email-uwe@kleine-koenig.org :
> >
> > - never assert reset because there are too many different panels with
> > too many different needs for their reset.
> > - split out dt binding changes
> > - reword commit log
>
> Please add these extra texts below the --- line below. Otherwise they
> end up in the commit description.
This was an accident. Should I resend for that one?
Best regards
Uwe
^ permalink raw reply
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
From: Tomi Valkeinen @ 2016-02-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda=mgcF8RRymbe0AAKpfCWGZSw_YZP5_6JW2g-mKEt16g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
On 16/02/16 01:34, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> Eventually I would like to have patches 1 thru 8 (those with
>> patches to CLCD or the DT bindings) applied through the FBDEV
>> subsystem,
>
> If there are no comments, would the fbdev people consider
> patches 1 thru 8?
Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
not sent as a reply to this thread, making it a bit unclear.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH resend] video: Use bool instead int pointer for get_opt_bool() argument
From: Tomi Valkeinen @ 2016-02-16 13:14 UTC (permalink / raw)
To: Daniel Wagner, Maik Broemme
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <1455009512-26806-1-git-send-email-daniel.wagner@bmw-carit.de>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On 09/02/16 11:18, Daniel Wagner wrote:
> As the function name already indicates that get_opt_bool() parses
> for a bool. It is not a surprise that compiler is complaining
> about it when -Werror=incompatible-pointer-types is used:
>
> drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’:
> drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> if (get_opt_bool(this_opt, "accel", &accel))
>
> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> [resend because Maik's emial address bounced last try]
>
> Hi,
>
> In the 'simple wait queue support' series is a patch
> which turns on -Werror=incompatible-pointer-types which will
> result in a compile error for intelfb.
>
> https://lkml.org/lkml/2016/1/28/462
>
> Even if that patch wont make it, this one makes sense (at least
> for me :))
>
> I'll prepend this patch to the next version of the series in order
> to see if I got rid of all incompatible pointer types errors caught
> by the kbuild test robot.
The patch looks good to me, but I didn't quite catch the above. So do
you want me to apply this to fbdev tree, or do you need to take this via
some other tree? If the latter, you have my ack.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Tomi Valkeinen @ 2016-02-16 13:06 UTC (permalink / raw)
To: Rob Herring, Uwe Kleine-König
Cc: Jean-Christophe Plagniol-Villard,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20151229205458.GA31241@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
On 29/12/15 22:54, Rob Herring wrote:
> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>> Some displays have a reset input and/or need a regulator to function
>> properly. Allow to specify them for panel-dpi devices.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> index 216c894d4f99..b52ac52757df 100644
>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> @@ -7,6 +7,8 @@ Required properties:
>> Optional properties:
>> - label: a symbolic name for the panel
>> - enable-gpios: panel enable gpio
>> +- reset-gpios: GPIO to control the RESET pin
>
> The problem with this in a generic binding is what if the panel has
> ordering requirements like enable gpio has to be inactive when reset
> is deasserted?
>
>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>
> What if there are 2 supplies?
Yes, I think it's an impossible task to create a really generic driver
wrt. gpios and supplies. There may be a bunch of them, and a particular
sequence to enable/disable needed, and even particular delays required
in between.
So I think the best we can do is to support (hopefully) most of the
panels by defining one sequence panel-dpi uses. If a particular panel
falls outside that, a separate driver is needed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
From: Tomi Valkeinen @ 2016-02-16 13:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-3-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
On 20/12/15 13:13, Uwe Kleine-König wrote:
> Some displays have a reset input. To assert that the display is
> functional the reset gpio must be deasserted.
>
> Teach the driver to get and drive such a gpio accordingly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> --
> Changes since (implicit) v1, sent with
> Message-Id: 1449753107-11410-4-git-send-email-uwe@kleine-koenig.org :
>
> - never assert reset because there are too many different panels with
> too many different needs for their reset.
> - split out dt binding changes
> - reword commit log
Please add these extra texts below the --- line below. Otherwise they
end up in the commit description.
> ---
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index e780fd4f8b46..201a1c1a6f42 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -213,6 +213,16 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
>
> ddata->enable_gpio = gpio;
>
> + /*
> + * Many different panels are supported by this driver and there are
> + * probably very different needs for their reset pins in regards to
> + * timing and order relative to the enable gpio. So for now it's just
> + * ensured that the reset line isn't active.
> + */
> + gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(gpio))
> + return PTR_ERR(gpio);
> +
> ddata->backlight_gpio = -ENOENT;
>
> r = of_get_display_timing(node, "panel-timing", &timing);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] fbdev: omap2: panel-dpi: implement support for a vcc regulator
From: Tomi Valkeinen @ 2016-02-16 13:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-4-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]
On 20/12/15 13:13, Uwe Kleine-König wrote:
> To allow supporting displays that need some logic to enable power to the
> display try to get a vcc-supply property from the device tree and drive
> the resulting regulator accordingly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since (implicit) v1, sent with
> Message-Id: 1449753107-11410-5-git-send-email-uwe@kleine-koenig.org:
>
> - split out dt binding changes
> - reword commit log
> ---
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 201a1c1a6f42..8c3f31ebff00 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -15,6 +15,7 @@
> #include <linux/slab.h>
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> +#include <linux/regulator/consumer.h>
>
> #include <video/omapdss.h>
> #include <video/omap-panel-data.h>
> @@ -32,6 +33,7 @@ struct panel_drv_data {
> int backlight_gpio;
>
> struct gpio_desc *enable_gpio;
> + struct regulator *vcc_supply;
> };
>
> #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -83,6 +85,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> if (r)
> return r;
>
> + r = regulator_enable(ddata->vcc_supply);
> + if (r) {
> + in->ops.dpi->disable(in);
> + return r;
> + }
> +
> gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>
> if (gpio_is_valid(ddata->backlight_gpio))
> @@ -105,6 +113,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
> gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>
> gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + regulator_disable(ddata->vcc_supply);
>
> in->ops.dpi->disable(in);
>
> @@ -223,6 +232,10 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> if (IS_ERR(gpio))
> return PTR_ERR(gpio);
>
> + ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
> + if (IS_ERR(ddata->vcc_supply))
> + return PTR_ERR(ddata->vcc_supply);
devm_regulator_get_optional()?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] video: fbdev: metronomefb: two harmless off by one bugs
From: Tomi Valkeinen @ 2016-02-16 12:53 UTC (permalink / raw)
To: Dan Carpenter, Jean-Christophe Plagniol-Villard, Jaya Kumar
Cc: linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <20160130144432.GF3462@mwanda>
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
On 30/01/16 16:44, Dan Carpenter wrote:
> par->metromem_cmd->args[] is an array of 31 elements of size u16. Here
> we have initialized the first "i" elements and want to set the rest to
> zero.
>
> The issue here is that ARRAY_SIZE(par->metromem_cmd->args) is 31 and not
> 32 as in the original code. It means that we set ->csum to zero, but
> that is harmless because we immediately set it to the correct value on
> the next line.
>
> Still, the buffer overflow upsets static checkers so let's correct the
> math.
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Stefano Stabellini @ 2016-02-16 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2801550.oZPkqjv8nW@wuerfel>
On Tue, 16 Feb 2016, Arnd Bergmann wrote:
> On Monday 15 February 2016 16:51:08 Stefano Stabellini wrote:
> > >
> > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > > index 8ea45a5cd806..fd3d6fd290a9 100644
> > > --- a/drivers/video/fbdev/Kconfig
> > > +++ b/drivers/video/fbdev/Kconfig
> > > @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> > > config XEN_FBDEV_FRONTEND
> > > tristate "Xen virtual frame buffer support"
> > > depends on FB && XEN
> > > + depends on INPUT || !INPUT_MISC
> > > select FB_SYS_FILLRECT
> > > select FB_SYS_COPYAREA
> > > select FB_SYS_IMAGEBLIT
> >
> > This looks very hackish. Couldn't we just do the following?
> >
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5..3c15f6d 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> > select FB_SYS_IMAGEBLIT
> > select FB_SYS_FOPS
> > select FB_DEFERRED_IO
> > - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> > + select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> > select XEN_XENBUS_FRONTEND
> > default y
> > help
> >
>
> No, that doesn't solve the problem:
>
> If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
> get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.
>
> INPUT_MISC already depends on INPUT, so your change has no effect
> at all.
Please correct me if I am wrong, but the difference is that with this
change if INPUT=m, then the build system would ask the user whether she
wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.
However it is true that if the users chooses
INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
Maybe we also need:
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1f2337a..303df24 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -721,7 +721,7 @@ config INPUT_CMA3000_I2C
config INPUT_XEN_KBDDEV_FRONTEND
tristate "Xen virtual keyboard and mouse support"
- depends on XEN
+ depends on XEN && INPUT
default y
select XEN_XENBUS_FRONTEND
help
Do you have a kernel config with INPUT=m that I can use to test with?
^ permalink raw reply related
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Arnd Bergmann @ 2016-02-16 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
On Monday 15 February 2016 16:51:08 Stefano Stabellini wrote:
> >
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5cd806..fd3d6fd290a9 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> > config XEN_FBDEV_FRONTEND
> > tristate "Xen virtual frame buffer support"
> > depends on FB && XEN
> > + depends on INPUT || !INPUT_MISC
> > select FB_SYS_FILLRECT
> > select FB_SYS_COPYAREA
> > select FB_SYS_IMAGEBLIT
>
> This looks very hackish. Couldn't we just do the following?
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5..3c15f6d 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> select FB_DEFERRED_IO
> - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> + select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> select XEN_XENBUS_FRONTEND
> default y
> help
>
No, that doesn't solve the problem:
If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.
INPUT_MISC already depends on INPUT, so your change has no effect
at all.
Arnd
^ permalink raw reply
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
From: Linus Walleij @ 2016-02-15 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Eventually I would like to have patches 1 thru 8 (those with
> patches to CLCD or the DT bindings) applied through the FBDEV
> subsystem,
If there are no comments, would the fbdev people consider
patches 1 thru 8?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] fbcon: set a default value to blink interval
From: Scot Doyle @ 2016-02-15 21:12 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: linux-fbdev, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Greg Kroah-Hartman, Pavel Machek, Thierry Reding, stable
In-Reply-To: <1455561693-28615-1-git-send-email-jean-philippe.brucker@arm.com>
On Mon, 15 Feb 2016, Jean-Philippe Brucker wrote:
> Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
> fbcon: use the cursor blink interval provided by vt
>
> two attempts have been made at fixing a possible hang caused by
> cursor_timer_handler. That function registers a timer to be triggered at
> "jiffies + fbcon_ops.cur_blink_jiffies".
...
> Instead of patching all possible paths that lead to this case one at a
> time, fix the issue at the source and initialise cur_blink_jiffies to
> 200ms when allocating fbcon_ops. This was its default value before
> aforesaid commit. fbcon_cursor or fbcon_init will refine this value
> downstream.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> Cc: <stable@vger.kernel.org> # v4.2
I agree with the approach and the patch works on my x86_64.
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
^ permalink raw reply
* [PATCH] fbcon: set a default value to blink interval
From: Jean-Philippe Brucker @ 2016-02-15 18:41 UTC (permalink / raw)
To: linux-fbdev
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Scot Doyle,
Greg Kroah-Hartman, Pavel Machek, Thierry Reding, stable
Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
fbcon: use the cursor blink interval provided by vt
two attempts have been made at fixing a possible hang caused by
cursor_timer_handler. That function registers a timer to be triggered at
"jiffies + fbcon_ops.cur_blink_jiffies".
A new case had been encountered during initialisation of clcd-pl11x:
fbcon_fb_registered
do_fbcon_takeover
-> do_register_con_driver
fbcon_startup
(A) add_cursor_timer (with cur_blink_jiffies = 0)
-> do_bind_con_driver
visual_init
fbcon_init
(B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
If we take an softirq anywhere between A and B (and we do),
cursor_timer_handler executes indefinitely.
Instead of patching all possible paths that lead to this case one at a
time, fix the issue at the source and initialise cur_blink_jiffies to
200ms when allocating fbcon_ops. This was its default value before
aforesaid commit. fbcon_cursor or fbcon_init will refine this value
downstream.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: <stable@vger.kernel.org> # v4.2
---
drivers/video/console/fbcon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 92f3949..6e92917 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -709,6 +709,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
}
if (!err) {
+ ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
if (vc)
@@ -956,6 +957,7 @@ static const char *fbcon_startup(void)
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
+ ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
p->con_rotate = initial_rotation;
set_blitting_type(vc, info);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Stefano Stabellini @ 2016-02-15 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C20552.8030305@citrix.com>
On Mon, 15 Feb 2016, David Vrabel wrote:
> On 15/02/16 16:51, Stefano Stabellini wrote:
> > CC'ing a few others.
> >
> > On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> >> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> >> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> >> is a loadable module, this configuration cannot work. On mainline kernels,
> >> the symbol will be enabled but not used, while in combination with
> >> a patch I have to detect such useless configurations, we get the
> >> expected link failure:
> >>
> >> drivers/input/built-in.o: In function `xenkbd_remove':
> >> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> >> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> >>
> >> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> >> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> >> in the broken select.
> >>
> >> As usual, we would be much better off without the 'select', but removing
> >> it now would likely break existing user configurations that depend on
> >> it, so this adds another hack on top to get it working.
>
> I would remove the select.
>
> Existing configurations with both XEN_FBDEV_FRONTEND and
> XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
> already enabled removing the select won't turn it off).
I am happy with that too.
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> >> ---
> >> drivers/video/fbdev/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> >> index 8ea45a5cd806..fd3d6fd290a9 100644
> >> --- a/drivers/video/fbdev/Kconfig
> >> +++ b/drivers/video/fbdev/Kconfig
> >> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> >> config XEN_FBDEV_FRONTEND
> >> tristate "Xen virtual frame buffer support"
> >> depends on FB && XEN
> >> + depends on INPUT || !INPUT_MISC
> >> select FB_SYS_FILLRECT
> >> select FB_SYS_COPYAREA
> >> select FB_SYS_IMAGEBLIT
> >
> > This looks very hackish. Couldn't we just do the following?
> >
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5..3c15f6d 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> > select FB_SYS_IMAGEBLIT
> > select FB_SYS_FOPS
> > select FB_DEFERRED_IO
> > - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> > + select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> > select XEN_XENBUS_FRONTEND
> > default y
> > help
> >
>
^ permalink raw reply
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: David Vrabel @ 2016-02-15 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
On 15/02/16 16:51, Stefano Stabellini wrote:
> CC'ing a few others.
>
> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
>> The Xen framebuffer driver selects the xen keyboard driver, so the latter
>> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
>> is a loadable module, this configuration cannot work. On mainline kernels,
>> the symbol will be enabled but not used, while in combination with
>> a patch I have to detect such useless configurations, we get the
>> expected link failure:
>>
>> drivers/input/built-in.o: In function `xenkbd_remove':
>> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
>> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>>
>> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
>> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
>> in the broken select.
>>
>> As usual, we would be much better off without the 'select', but removing
>> it now would likely break existing user configurations that depend on
>> it, so this adds another hack on top to get it working.
I would remove the select.
Existing configurations with both XEN_FBDEV_FRONTEND and
XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
already enabled removing the select won't turn it off).
David
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
>> ---
>> drivers/video/fbdev/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 8ea45a5cd806..fd3d6fd290a9 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
>> config XEN_FBDEV_FRONTEND
>> tristate "Xen virtual frame buffer support"
>> depends on FB && XEN
>> + depends on INPUT || !INPUT_MISC
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> select FB_SYS_IMAGEBLIT
>
> This looks very hackish. Couldn't we just do the following?
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5..3c15f6d 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> select FB_DEFERRED_IO
> - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> + select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> select XEN_XENBUS_FRONTEND
> default y
> help
>
^ permalink raw reply
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Stefano Stabellini @ 2016-02-15 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
CC'ing a few others.
On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
>
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>
> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> in the broken select.
>
> As usual, we would be much better off without the 'select', but removing
> it now would likely break existing user configurations that depend on
> it, so this adds another hack on top to get it working.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> ---
> drivers/video/fbdev/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..fd3d6fd290a9 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> config XEN_FBDEV_FRONTEND
> tristate "Xen virtual frame buffer support"
> depends on FB && XEN
> + depends on INPUT || !INPUT_MISC
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
This looks very hackish. Couldn't we just do the following?
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5..3c15f6d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
- select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
+ select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
select XEN_XENBUS_FRONTEND
default y
help
^ permalink raw reply related
* [PATCH 6/7] fbdev: exynos: fix IS_ERR_VALUE usage
From: Andrzej Hajda @ 2016-02-15 14:35 UTC (permalink / raw)
To: linux-kernel
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Donghwa Lee, Kyungmin Park,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-samsung-soc
In-Reply-To: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
IS_ERR_VALUE macro should be used only with unsigned long type.
For signed types comparison 'ret < 0' should be used.
The patch follows conclusion from discussion on LKML [1][2].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
index b527fe4..951b592 100644
--- a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
@@ -402,12 +402,12 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
goto error;
}
- dsim->irq = platform_get_irq(pdev, 0);
- if (IS_ERR_VALUE(dsim->irq)) {
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0) {
dev_err(&pdev->dev, "failed to request dsim irq resource\n");
- ret = -EINVAL;
goto error;
}
+ dsim->irq = ret;
init_completion(&dsim_wr_comp);
init_completion(&dsim_rd_comp);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/7] fix IS_ERR_VALUE usage
From: Andrzej Hajda @ 2016-02-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This small set of independent patches tries to fix incorrect
IS_ERR_VALUE macro usage. It fixes most usages leading to errors
as described in [1]. It also follows conclusion from the discussion
[1][2] - IS_ERR_VALUE should be used only with unsigned long type,
signed types should use comparison 'ret < 0'.
The patchset does not fix errors present in net/ethernet/freescale
and soc/fsq/qe drivers - these drivers mixes different types:
dma_addr_t, u32, unsigned long, fixing it properly seems to me more
challenging, maybe maintainers or brave volunteers can look it.
The list of missing fixes:
drivers/net/ethernet/freescale/fs_enet/mac-scc.c:149:36-37: WARNING: incorrect argument type in IS_ERR_VALUE(fep -> ring_mem_addr)
drivers/net/ethernet/freescale/ucc_geth.c:2237:48-49: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2314:48-49: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2524:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2544:45-46: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> thread_dat_tx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2571:46-47: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> send_q_mem_reg_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2612:42-43: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> scheduler_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2659:54-55: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2696:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2715:45-46: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> thread_dat_rx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2736:54-55: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2756:53-54: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_irq_coalescing_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2822:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_bd_qs_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2908:47-48: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> exf_glbl_param_offset)
drivers/net/ethernet/freescale/ucc_geth.c:292:36-37: WARNING: incorrect argument type in IS_ERR_VALUE(init_enet_offset)
drivers/net/ethernet/freescale/ucc_geth.c:3042:39-40: WARNING: incorrect argument type in IS_ERR_VALUE(init_enet_pram_offset)
drivers/soc/fsl/qe/ucc_fast.c:271:60-61: WARNING: incorrect argument type in IS_ERR_VALUE(uccf -> ucc_fast_tx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_fast.c:284:60-61: WARNING: incorrect argument type in IS_ERR_VALUE(uccf -> ucc_fast_rx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:186:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> us_pram_offset)
drivers/soc/fsl/qe/ucc_slow.c:213:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> rx_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:224:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> tx_base_offset)
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c:110:35-36: WARNING: unknown argument type in IS_ERR_VALUE(fpi -> dpram_offset)
[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581
Regards
Andrzej
Andrzej Hajda (7):
netfilter: fix IS_ERR_VALUE usage
MIPS: module: fix incorrect IS_ERR_VALUE macro usages
drivers: char: mem: fix IS_ERROR_VALUE usage
atmel-isi: fix IS_ERR_VALUE usage
serial: clps711x: fix IS_ERR_VALUE usage
fbdev: exynos: fix IS_ERR_VALUE usage
usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage
arch/mips/kernel/module-rela.c | 2 +-
arch/mips/kernel/module.c | 2 +-
drivers/char/mem.c | 2 +-
drivers/media/platform/soc_camera/atmel-isi.c | 4 ++--
drivers/tty/serial/clps711x.c | 14 ++++++++------
drivers/usb/gadget/udc/fsl_qe_udc.c | 2 +-
drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 6 +++---
include/linux/netfilter/x_tables.h | 6 +++---
net/ipv4/netfilter/arp_tables.c | 11 +++++++----
net/ipv4/netfilter/ip_tables.c | 12 ++++++++----
net/ipv6/netfilter/ip6_tables.c | 13 +++++++++----
11 files changed, 44 insertions(+), 30 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Linus Walleij @ 2016-02-15 13:25 UTC (permalink / raw)
To: Ray Jui
Cc: Arun Ramamurthy, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Russell King,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui, bcm-kernel-feedback-list
In-Reply-To: <a005c107-0b15-65ec-eede-a713ee1a8bd9-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Feb 10, 2016 at 6:48 PM, Ray Jui <ray.jui@broadcom.com> wrote:
> Could you please add me to the email thread and I can review it there (I
> won't have time to test, but I can help to review the code and find time to
> test later)?
OK I will add you to subsequent postings, if any.
> This may be a dumb question, is there any way for me to directly reply to
> the thread here?
Not easily, I guess it is possible to conjure an SMTP mail
with the right in-reply-to message ID but that is so complex
hacking that I have no clue how to do it, just ever reached
the limit of "a little knowledge is dangerous".
Yours,
Linus Walleij
^ permalink raw reply
* RADEON/4.3.0 sets non-native screen resolution for the console
From: Lars Dölle @ 2016-02-14 15:59 UTC (permalink / raw)
To: linux-fbdev
Hi All,
since quite a while, the RADEON frame buffer driver does not longer initially
sets the native screen resolution for the console, which is 1920x1200 here,
but decides on 1024x768 instead. The display uses a display-port connector,
which might be the particularity.
As you see, this is a stock debian kernel, but I have the same effect with
locally compiled kernels. Earlier kernels up to late 3.x worked well in this
respect, so do drivers for other hardware. Thus I assume that the effect is
unwanted. I can not work around the problem, since mode setting is not longer
available.
I'm not sure what information you'd need beside the ones included below, but
I would gladly provide them on request and/or could try out a patch if
necessary.
Kind regards
Lars
-- ---
$ lspci
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.[AMD/ATI] RV620
GL [FirePro 2260]
$ journalctl -b | grep radeon|drm|fbcon
: Linux version 4.3.0-1-amd64 (debian-kernel@lists.debian.org)
: [drm] Initialized drm 1.1.0 20060810
: [drm] radeon kernel modesetting enabled.
: [drm] initializing kernel modesetting (RV620 0x1002:0x95CF 0x1002:0x2143).
: [drm] register mmio base: 0xE0200000
: [drm] register mmio size: 65536
: radeon 0000:01:00.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF
(256M used)
: radeon 0000:01:00.0: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF
: [drm] Detected VRAM RAM%6M, BAR%6M
: [drm] RAM width 64bits DDR
: [drm] radeon: 256M of VRAM memory ready
: [drm] radeon: 512M of GTT memory ready.
: [drm] Loading RV620 Microcode
: radeon 0000:01:00.0: firmware: direct-loading firmware radeon/RV620_pfp.bin
: radeon 0000:01:00.0: firmware: direct-loading firmware radeon/RV620_me.bin
: radeon 0000:01:00.0: firmware: direct-loading firmware radeon/R600_rlc.bin
: [drm] Internal thermal controller with fan control
: [drm] radeon: power management initialized
: radeon 0000:01:00.0: firmware: direct-loading firmware radeon/R600_uvd.bin
: [drm] GART: num cpu pages 131072, num gpu pages 131072
: [drm] PCIE GART of 512M enabled (table at 0x0000000000254000).
: radeon 0000:01:00.0: WB enabled
: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00
and cpu addr 0xffff8800c9c81c00
: radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x00000000000521d0
and cpu addr 0xffffc900010121d0
: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
: [drm] Driver supports precise vblank timestamp query.
: radeon 0000:01:00.0: radeon: MSI limited to 32-bit
: radeon 0000:01:00.0: radeon: using MSI.
: [drm] radeon: irq initialized.
: [drm] ring test on 0 succeeded in 1 usecs
: [drm] ring test on 5 succeeded in 1 usecs
: [drm] UVD initialized successfully.
: [drm] ib test on ring 0 succeeded in 0 usecs
: [drm] ib test on ring 5 succeeded
: [drm] Radeon Display Connectors
: [drm] Connector 0:
: [drm] DP-1
: [drm] HPD2
: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
: [drm] Encoders:
: [drm] DFP1: INTERNAL_UNIPHY
: [drm] Connector 1:
: [drm] DP-2
: [drm] HPD4
: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
: [drm] Encoders:
: [drm] DFP2: INTERNAL_UNIPHY
: [drm] fb mappable at 0xD0355000
: [drm] vram apper at 0xD0000000
: [drm] size 3145728
: [drm] fb depth is 24
: [drm] pitch is 4096
: fbcon: radeondrmfb (fb0) is primary device
: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
: [drm] Initialized radeon 2.43.0 20080528 for 0000:01:00.0 on minor 0
^ permalink raw reply
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Andrew Jones @ 2016-02-12 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
On Fri, Feb 12, 2016 at 01:04:40PM +0100, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
>
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>
> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> in the broken select.
>
> As usual, we would be much better off without the 'select', but removing
> it now would likely break existing user configurations that depend on
> it, so this adds another hack on top to get it working.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> ---
> drivers/video/fbdev/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..fd3d6fd290a9 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> config XEN_FBDEV_FRONTEND
> tristate "Xen virtual frame buffer support"
> depends on FB && XEN
> + depends on INPUT || !INPUT_MISC
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> --
> 2.7.0
>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Thanks,
drew
^ permalink raw reply
* [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Arnd Bergmann @ 2016-02-12 12:04 UTC (permalink / raw)
To: linux-arm-kernel
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..fd3d6fd290a9 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2241,6 +2241,7 @@ config FB_VIRTUAL
config XEN_FBDEV_FRONTEND
tristate "Xen virtual frame buffer support"
depends on FB && XEN
+ depends on INPUT || !INPUT_MISC
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
--
2.7.0
^ permalink raw reply related
* [GIT PULL] fbdev fixes for 4.5
From: Tomi Valkeinen @ 2016-02-12 11:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
Hi Linus,
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -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 b82fe6ddd782f847332aeabf8cab980852f61629:
video: fbdev: imxfb: Provide a reset mechanism (2016-01-29 14:20:16 +0200)
----------------------------------------------------------------
fbdev fixes for v4.5
* fix omap2plus_defconfig to enable omapfb as it was in v4.4
* ocfb: fix timings for margins
* s6e8ax0, da8xx-fb: fix compile warnings
* mmp: fix build failure caused by bad printk parameters
* imxfb: fix clock issue which kept the display off
----------------------------------------------------------------
Andrea Merello (1):
ocfb: fix tgdel and tvdel timing parameters
Arnd Bergmann (3):
fbdev: s6e8ax0: avoid unused function warnings
fbdev: da8xx-fb: remove incorrect type cast
fbdev: mmp: print IRQ resource using %pR format string
Fabio Estevam (1):
video: fbdev: imxfb: Provide a reset mechanism
Tomi Valkeinen (1):
ARM: omap2plus_defconfig: update display configs
arch/arm/configs/omap2plus_defconfig | 33 ++++++++++++++++-----------------
drivers/video/fbdev/da8xx-fb.c | 6 +++---
drivers/video/fbdev/exynos/s6e8ax0.c | 13 ++++---------
drivers/video/fbdev/imxfb.c | 15 +++++++++++++++
drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 3 +--
drivers/video/fbdev/ocfb.c | 4 ++--
6 files changed, 41 insertions(+), 33 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: imxfb: Provide a reset mechanism
From: Tomi Valkeinen @ 2016-02-12 7:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1453209057-16444-1-git-send-email-festevam@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
On 10/02/16 21:52, Fabio Estevam wrote:
> Hi Tomi,
>
> On Fri, Jan 29, 2016 at 10:20 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>>
>> On 19/01/16 15:10, Fabio Estevam wrote:
>>> From: Fabio Estevam <fabio.estevam@nxp.com>
>>>
>>> Currently when we boot the kernel on a mx25pdk the LCDC controller
>>> does not show the Linux logo on boot.
>>>
>>> This problem is well explained by Sascha Hauer:
>>>
>>> "Unfortunately this LCD controller does not have an enable bit. The
>>> controller starts directly when the clocks are enabled. If the clocks
>>> are enabled when the controller is not yet programmed with proper
>>> register values then it just goes into some undefined state. What I
>>> suspect is that the clocks already were enabled before driver probe,
>>> presumably by the bootloader, so the controller is already in undefined
>>> state when entering Linux. Now by dis/enabling the ipg clock you
>>> effectively reset the controller. Since you have programmed it with
>>> valid register values in the mean time it starts working after this
>>> reset."
>>>
>>> So do as suggested and force a reset of the LCDC hardware by
>>> enabling and disabling the IPG clock.
>>>
>>> With this change the Linux logo can be seen on boot on a mx25pdk.
>>>
>>> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
>>> ---
>>> drivers/video/fbdev/imxfb.c | 15 +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>
>> Thanks. Queued for 4.5 fixes.
>
> Still don't see this one applied in Linus nor linux-next tree yet.
I've been a bit preoccupied, but I hope I get to send the pull request
today.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] fbdev: omap2: panel-dpi: support reset-gpios and vcc regulator
From: Tomi Valkeinen @ 2016-02-12 7:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
On 01/02/16 12:07, Uwe Kleine-König wrote:
> Hello Tomi,
>
> On Sun, Dec 20, 2015 at 12:13:19PM +0100, Uwe Kleine-König wrote:
>> Hello,
>>
>> these patches are what is remaining from my previous series sent
>> starting with
>> Message-Id: 1449753107-11410-1-git-send-email-uwe@kleine-koenig.org .
>>
>> I split out the changes to
>> Documentation/devicetree/bindings/video/panel-dpi.txt in a (single)
>> separate patch. Also I changed the behaviour of the reset gpio to never
>> assert it because there are too many different needs.
>>
>> Have fun
>> Uwe
>>
>> Uwe Kleine-König (3):
>> devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
>> fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
>> fbdev: omap2: panel-dpi: implement support for a vcc regulator
>
> you didn't comment these patches, do you have them still on your radar?
Sorry, my mainline radar has been suspended for a while. I'll get back
to fbdev next week.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
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