* Re: [PATCH 9/9] simplefb: Remove impossible check for of_clk_get_parent_count() < 0
From: Tomi Valkeinen @ 2016-02-26 11:35 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette
Cc: linux-kernel, linux-clk, Hans de Goede,
Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <1456174487-28397-10-git-send-email-sboyd@codeaurora.org>
[-- Attachment #1.1: Type: text/plain, Size: 673 bytes --]
On 22/02/16 22:54, Stephen Boyd wrote:
> The check for < 0 is impossible now that
> of_clk_get_parent_count() returns an unsigned int. Simplify the
> code and update the types.
>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: <linux-fbdev@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Please ack so this can go through clk tree along with patch 1.
>
> drivers/video/fbdev/simplefb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- 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: Uwe Kleine-König @ 2016-02-26 12:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-4-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
Cc += Liam Girdwood, Mark Brown
On Fri, Feb 26, 2016 at 12:13:07PM +0200, Tomi Valkeinen wrote:
> On 16/02/16 15:48, Uwe Kleine-König wrote:
> > Hello Tomi,
> >
> > On Tue, Feb 16, 2016 at 03:00:00PM +0200, Tomi Valkeinen wrote:
> >> On 20/12/15 13:13, Uwe Kleine-König wrote:
> >>> @@ -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()?
> >
> > That would make the specification of a vcc supply obligatory IIUC. (Yes,
> > the semantic difference between regulator_get vs. regulator_get_optional
> > is reversed when comparing to gpio_get vs. gpio_get_optional.)
>
> This is a bit confusing...
>
> So, is regulator_get_optional() meant for cases where the device can
> truly function without the supply in question? And regulator_get()
> should be used when the device needs the supply, even if the supply
> cannot be controlled via SW, and thus we may not even have the supply
> visible in the SW side (leading to using dummy regulator)?
Yeah, I think this is the right picture.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v2 3/3] fbdev: omap2: panel-dpi: implement support for a vcc regulator
From: Mark Brown @ 2016-02-26 12:22 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: 1145 bytes --]
On Fri, Feb 26, 2016 at 01:10:08PM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 26, 2016 at 12:13:07PM +0200, Tomi Valkeinen wrote:
> > > That would make the specification of a vcc supply obligatory IIUC. (Yes,
> > > the semantic difference between regulator_get vs. regulator_get_optional
> > > is reversed when comparing to gpio_get vs. gpio_get_optional.)
Not really, in both cases the _optional() case is for the case where the
requested resource may reasonably be absent.
> > So, is regulator_get_optional() meant for cases where the device can
> > truly function without the supply in question? And regulator_get()
> > should be used when the device needs the supply, even if the supply
> > cannot be controlled via SW, and thus we may not even have the supply
> > visible in the SW side (leading to using dummy regulator)?
> Yeah, I think this is the right picture.
Yes, exactly. Even in cases where supplies could potentially be
software controlled frequently system constraints make it impossible to
actually change their state so the consumer should not normally assume
that a disable will actually happen.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH v2] video: exynos: fix modular build
From: Arnd Bergmann @ 2016-02-26 12:38 UTC (permalink / raw)
To: linux-arm-kernel
The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
which can be configured as a loadable module, so we have to
make the driver a tristate symbol as well, to avoid this error:
drivers/built-in.o: In function `s6e8ax0_probe':
:(.text+0x23a48): undefined reference to `devm_backlight_device_register'
This also means we get another error from a missing export, which
this fixes as well:
ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
The drivers are all written to be loadable modules already,
except the Kconfig options for that are missing, which makes
the patch really easy.
Finally, the EXYNOS_VIDEO option is turned into tristate as well
for good measure, as all framebuffer drivers should be configurable
as modules, though this change is not strictly necessary.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
drivers/video/fbdev/exynos/Kconfig | 6 +++---
drivers/video/fbdev/exynos/Makefile | 6 ++++--
drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 1 +
3 files changed, 8 insertions(+), 5 deletions(-)
v2: improved changelog after feedback from Paul Bolle
diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig
index 1f16b4678c71..d916bef94f25 100644
--- a/drivers/video/fbdev/exynos/Kconfig
+++ b/drivers/video/fbdev/exynos/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig EXYNOS_VIDEO
- bool "Exynos Video driver support"
+ tristate "Exynos Video driver support"
depends on ARCH_S5PV210 || ARCH_EXYNOS
help
This enables support for EXYNOS Video device.
@@ -15,13 +15,13 @@ if EXYNOS_VIDEO
#
config EXYNOS_MIPI_DSI
- bool "EXYNOS MIPI DSI driver support."
+ tristate "EXYNOS MIPI DSI driver support."
select GENERIC_PHY
help
This enables support for MIPI-DSI device.
config EXYNOS_LCD_S6E8AX0
- bool "S6E8AX0 MIPI AMOLED LCD Driver"
+ tristate "S6E8AX0 MIPI AMOLED LCD Driver"
depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
depends on (LCD_CLASS_DEVICE = y)
default n
diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
index b5b1bd228abb..02d8dc522fea 100644
--- a/drivers/video/fbdev/exynos/Makefile
+++ b/drivers/video/fbdev/exynos/Makefile
@@ -2,6 +2,8 @@
# Makefile for the exynos video drivers.
#
-obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
- exynos_mipi_dsi_lowlevel.o
+obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos-mipi-dsi-mod.o
+
+exynos-mipi-dsi-mod-objs += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
+ exynos_mipi_dsi_lowlevel.o
obj-$(CONFIG_EXYNOS_LCD_S6E8AX0) += s6e8ax0.o
diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
index 951b592794e3..92e4af3caaf8 100644
--- a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
@@ -263,6 +263,7 @@ int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv)
return 0;
}
+EXPORT_SYMBOL_GPL(exynos_mipi_dsi_register_lcd_driver);
static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(
struct mipi_dsim_device *dsim,
--
2.7.0
^ permalink raw reply related
* Re: [PATCH v2 0/3] fbdev: omap2: panel-dpi: support reset-gpios and vcc regulator
From: Tomi Valkeinen @ 2016-02-26 12:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]
On 20/12/15 13:13, 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
>
> .../bindings/display/panel/panel-dpi.txt | 2 ++
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 23 ++++++++++++++++++++++
> 2 files changed, 25 insertions(+)
I think these look fine. However...
omapfb is now in maintenance state, and all new development should be
done for omapdrm. In v4.5 omapdss and all the panels were copied to
drivers/gpu/drm/omapdrm/.
So please send these to dri-devel list, with the path fixed (git-am does
that automatically), and subject prefix changed, and you can add my
reviewed-by.
If you really want these for omapfb, you need to convince me that they
are really needed for the legacy driver =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
From: Paul Gortmaker @ 2016-02-26 13:58 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-kernel, David S. Miller, Jean-Christophe Plagniol-Villard,
linux-fbdev, sparclinux
In-Reply-To: <56D02FB8.90803@ti.com>
[Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code] On 26/02/2016 (Fri 12:58) Tomi Valkeinen wrote:
>
>
> On 22/02/16 05:13, Paul Gortmaker wrote:
> > This series of commits is a part of a larger project to ensure
> > people don't reference modular support functions in non-modular
> > code. Overall there was roughly 5k lines of dead code in the
> > kernel due to this. So far we've fixed several areas, like tty,
> > x86, net, ... and we continue to work on other areas.
> >
> > There are several reasons to not use module support for code that
> > can never be built as a module, but the big ones are:
> >
> > (1) it is easy to accidentally write unused module_exit and remove code
> > (2) it can be misleading when reading the source, thinking it can be
> > modular when the Makefile and/or Kconfig prohibit it
> > (3) it requires the include of the module.h header file which in turn
> > includes nearly everything else, thus adding to CPP overhead.
> > (4) it gets copied/replicated into other code and spreads like weeds.
>
> I think all the "normal" drivers should be compilable as modules. If
> they can't, it should be fixed. However, we have lots of old drivers for
> which it may be difficult to get anyone to fix them or test them.
A counter point would be that if an old driver has remained non-modular
for all these years, then clearly there is no demand for adding a new
modular implementation at this point in time.
>
> Then again, with that kind of drivers it may be better to just let them
> be, if there's no big reason to start cleaning them up. In other words,
> if the driver is old and not actively developed/maintained, compiles
> fine, presumably works fine, doesn't obstruct any other development,
> then why touch it at all...
The main reason is listed as #4 above -- if we keep drivers around that
reflect a disconnect between Kconfig and code, the same mistake gets
copied into more and more new drivers as they are created.
If the argument was to not go in and rewrite core code for legacy
drivers, I'd agree with that, but that isn't what is happening here.
In a lot of these type changes, where the only change is to replace
module_init with device initcall, the object files are identical.
> While doing this, did you just go forward removing the module support,
> or did you check if it would be trivial to make the driver build as a
> module? I wouldn't be surprised if in some cases all that would need to
> be done is change the Kconfig's bool to tristate.
In some cases, where people have explicitly asked for it, indicating
that they (as author) intended it to be tristate, and support it as
such, yes.
But overall, with the number and diversity of the drivers involved, I
did not want to just go around enabling new functionality here and there
on hardware I don't know intimately. So instead the changes are like
what you see here: the runtime and functionality remains faithful to
what it was, while resolving issues #1 through #4 above.
If subsystem maintainers would rather have blanket tristate coversions
and whatever changes are required to make it compile and modpost, and
are OK to assume things will just work, then that could be an option...
Paul.
--
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc
From: David Miller @ 2016-02-26 17:21 UTC (permalink / raw)
To: tomi.valkeinen
Cc: paul.gortmaker, linux-kernel, plagnioj, linux-fbdev, sparclinux
In-Reply-To: <56D02FB8.90803@ti.com>
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Fri, 26 Feb 2016 12:58:00 +0200
> While doing this, did you just go forward removing the module support,
> or did you check if it would be trivial to make the driver build as a
> module? I wouldn't be surprised if in some cases all that would need to
> be done is change the Kconfig's bool to tristate.
I think what he is doing is reasonable, and none of these sparc drivers
have any reason to be built modular. You need them to have any bootup
console whatsoever, so they have to be built in statically to be
usable at all.
I plan to apply this patch series to my sparc tree as-is.
^ permalink raw reply
* [PATCH 0/5] goldfish: bring the framebuffer in sync with upstream
From: Alan @ 2016-02-26 18:41 UTC (permalink / raw)
To: linux-fbdev
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
.../devicetree/bindings/goldfish/audio.txt | 17 +++
.../devicetree/bindings/goldfish/battery.txt | 17 +++
.../devicetree/bindings/goldfish/events.txt | 17 +++
Documentation/devicetree/bindings/goldfish/fb.txt | 17 +++
Documentation/devicetree/bindings/goldfish/tty.txt | 17 +++
drivers/input/keyboard/goldfish_events.c | 15 +++
drivers/power/goldfish_battery.c | 17 +++
drivers/staging/goldfish/goldfish_audio.c | 10 ++
drivers/tty/goldfish.c | 10 ++
drivers/video/fbdev/goldfishfb.c | 107 +++++++++++++++++---
10 files changed, 223 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/goldfish/audio.txt
create mode 100644 Documentation/devicetree/bindings/goldfish/battery.txt
create mode 100644 Documentation/devicetree/bindings/goldfish/events.txt
create mode 100644 Documentation/devicetree/bindings/goldfish/fb.txt
create mode 100644 Documentation/devicetree/bindings/goldfish/tty.txt
--
#include <witty.h>
^ permalink raw reply
* [PATCH 1/5] Subject: video: goldfishfb: add devicetree bindings
From: Alan @ 2016-02-26 18:41 UTC (permalink / raw)
To: linux-fbdev
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
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.
+
+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,
}
};
^ permalink raw reply related
* [PATCH 2/5] Subject: goldfish: Enable ACPI-based enumeration for goldfish framebuffer
From: Alan @ 2016-02-26 18:41 UTC (permalink / raw)
To: linux-fbdev
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 },
+ { },
+};
+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),
}
};
^ permalink raw reply related
* [PATCH 3/5] Subject: goldfish_fb: Set pixclock = 0
From: Alan @ 2016-02-26 18:42 UTC (permalink / raw)
To: linux-fbdev
From: Christoffer Dall <christoffer.dall@linaro.org>
User space Android code identifies pixclock = 0 as a sign for
emulation and will set the frame rate to 60 fps when reading
this value, which is the desired outcome.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jin Qian <jinqian@android.com>
Signed-off-by: Alan <alan@linux.intel.com>
---
drivers/video/fbdev/goldfishfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 58b33e4..131fee0 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -235,7 +235,7 @@ static int goldfish_fb_probe(struct platform_device *pdev)
fb->fb.var.activate = FB_ACTIVATE_NOW;
fb->fb.var.height = readl(fb->reg_base + FB_GET_PHYS_HEIGHT);
fb->fb.var.width = readl(fb->reg_base + FB_GET_PHYS_WIDTH);
- fb->fb.var.pixclock = 10000;
+ fb->fb.var.pixclock = 0;
fb->fb.var.red.offset = 11;
fb->fb.var.red.length = 5;
^ permalink raw reply related
* [PATCH 4/5] Subject: goldfish: 32 bit framebuffer support
From: Alan @ 2016-02-26 18:42 UTC (permalink / raw)
To: linux-fbdev
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(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 131fee0..cddc91d 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -38,11 +38,56 @@ enum {
FB_SET_BLANK = 0x18,
FB_GET_PHYS_WIDTH = 0x1c,
FB_GET_PHYS_HEIGHT = 0x20,
+ FB_GET_FORMAT = 0x24,
FB_INT_VSYNC = 1U << 0,
FB_INT_BASE_UPDATE_DONE = 1U << 1
};
+/* These values *must* match the platform definitions found under
+ * <system/graphics.h> in the Goldfish emulator.
+ */
+enum {
+ HAL_PIXEL_FORMAT_RGBA_8888 = 1,
+ HAL_PIXEL_FORMAT_RGBX_8888 = 2,
+ HAL_PIXEL_FORMAT_RGB_888 = 3,
+ HAL_PIXEL_FORMAT_RGB_565 = 4,
+ HAL_PIXEL_FORMAT_BGRA_8888 = 5,
+ HAL_PIXEL_FORMAT_RGBA_5551 = 6,
+ HAL_PIXEL_FORMAT_RGBA_4444 = 7,
+};
+
+struct framebuffer_config {
+ u8 format;
+ u8 bytes_per_pixel;
+ u8 transp_offset;
+ u8 transp_length;
+ u8 red_offset;
+ u8 red_length;
+ u8 green_offset;
+ u8 green_length;
+ u8 blue_offset;
+ u8 blue_length;
+};
+
+static const struct framebuffer_config *get_fb_config_from_format(int format)
+{
+ /* Only configurations supported by the emulator. */
+ static const struct framebuffer_config fb_configs[] = {
+ { HAL_PIXEL_FORMAT_RGB_565, 2, 0, 0, 11, 5, 5, 6, 0, 5 },
+ { HAL_PIXEL_FORMAT_RGBX_8888, 4, 0, 0, 16, 8, 8, 8, 0, 8 },
+ { HAL_PIXEL_FORMAT_RGBA_8888, 4, 24, 8, 16, 8, 8, 8, 0, 8 },
+ };
+ const int fb_configs_size = ARRAY_SIZE(fb_configs);
+ int n;
+
+ for (n = 0; n < fb_configs_size; ++n) {
+ if (format = fb_configs[n].format)
+ return &fb_configs[n];
+ }
+ return &fb_configs[0]; /* default to RGB565 */
+}
+
struct goldfish_fb {
void __iomem *reg_base;
int irq;
@@ -126,7 +171,8 @@ static int goldfish_fb_set_par(struct fb_info *info)
{
struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
if (fb->rotation != fb->fb.var.rotate) {
- info->fix.line_length = info->var.xres * 2;
+ info->fix.line_length = info->var.xres *
+ (fb->fb.var.bits_per_pixel / 8);
fb->rotation = fb->fb.var.rotate;
writel(fb->rotation, fb->reg_base + FB_SET_ROTATION);
}
@@ -143,8 +189,10 @@ static int goldfish_fb_pan_display(struct fb_var_screeninfo *var,
spin_lock_irqsave(&fb->lock, irq_flags);
base_update_count = fb->base_update_count;
- writel(fb->fb.fix.smem_start + fb->fb.var.xres * 2 * var->yoffset,
- fb->reg_base + FB_SET_BASE);
+ writel(fb->fb.fix.smem_start +
+ fb->fb.var.xres * (
+ fb->fb.var.bits_per_pixel / 8) * var->yoffset,
+ fb->reg_base + FB_SET_BASE);
spin_unlock_irqrestore(&fb->lock, irq_flags);
wait_event_timeout(fb->wait,
fb->base_update_count != base_update_count, HZ / 15);
@@ -186,8 +234,10 @@ static int goldfish_fb_probe(struct platform_device *pdev)
struct resource *r;
struct goldfish_fb *fb;
size_t framesize;
- u32 width, height;
+ u32 width, height, format;
+ int bytes_per_pixel;
dma_addr_t fbpaddr;
+ const struct framebuffer_config *fb_config;
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (fb = NULL) {
@@ -217,13 +267,20 @@ static int goldfish_fb_probe(struct platform_device *pdev)
width = readl(fb->reg_base + FB_GET_WIDTH);
height = readl(fb->reg_base + FB_GET_HEIGHT);
+ format = readl(fb->reg_base + FB_GET_FORMAT);
+ fb_config = get_fb_config_from_format(format);
+ if (!fb_config) {
+ ret = -EINVAL;
+ goto err_no_irq;
+ }
+ bytes_per_pixel = fb_config->bytes_per_pixel;
fb->fb.fbops = &goldfish_fb_ops;
fb->fb.flags = FBINFO_FLAG_DEFAULT;
fb->fb.pseudo_palette = fb->cmap;
fb->fb.fix.type = FB_TYPE_PACKED_PIXELS;
fb->fb.fix.visual = FB_VISUAL_TRUECOLOR;
- fb->fb.fix.line_length = width * 2;
+ fb->fb.fix.line_length = width * bytes_per_pixel;
fb->fb.fix.accel = FB_ACCEL_NONE;
fb->fb.fix.ypanstep = 1;
@@ -231,20 +288,22 @@ static int goldfish_fb_probe(struct platform_device *pdev)
fb->fb.var.yres = height;
fb->fb.var.xres_virtual = width;
fb->fb.var.yres_virtual = height * 2;
- fb->fb.var.bits_per_pixel = 16;
+ fb->fb.var.bits_per_pixel = bytes_per_pixel * 8;
fb->fb.var.activate = FB_ACTIVATE_NOW;
fb->fb.var.height = readl(fb->reg_base + FB_GET_PHYS_HEIGHT);
fb->fb.var.width = readl(fb->reg_base + FB_GET_PHYS_WIDTH);
fb->fb.var.pixclock = 0;
- fb->fb.var.red.offset = 11;
- fb->fb.var.red.length = 5;
- fb->fb.var.green.offset = 5;
- fb->fb.var.green.length = 6;
- fb->fb.var.blue.offset = 0;
- fb->fb.var.blue.length = 5;
+ fb->fb.var.red.offset = fb_config->red_offset;
+ fb->fb.var.red.length = fb_config->red_length;
+ fb->fb.var.green.offset = fb_config->green_offset;
+ fb->fb.var.green.length = fb_config->green_length;
+ fb->fb.var.blue.offset = fb_config->blue_offset;
+ fb->fb.var.blue.length = fb_config->blue_length;
+ fb->fb.var.transp.offset = fb_config->transp_offset;
+ fb->fb.var.transp.length = fb_config->transp_length;
- framesize = width * height * 2 * 2;
+ framesize = width * height * 2 * bytes_per_pixel;
fb->fb.screen_base = (char __force __iomem *)dma_alloc_coherent(
&pdev->dev, framesize,
&fbpaddr, GFP_KERNEL);
@@ -295,7 +354,8 @@ static int goldfish_fb_remove(struct platform_device *pdev)
size_t framesize;
struct goldfish_fb *fb = platform_get_drvdata(pdev);
- framesize = fb->fb.var.xres_virtual * fb->fb.var.yres_virtual * 2;
+ framesize = fb->fb.var.xres_virtual * fb->fb.var.yres_virtual *
+ (fb->fb.var.bits_per_pixel / 8);
unregister_framebuffer(&fb->fb);
free_irq(fb->irq, fb);
^ permalink raw reply related
* [PATCH 5/5] Subject: goldfishfb: simplify framebuffer format selection.
From: Alan @ 2016-02-26 18:42 UTC (permalink / raw)
To: linux-fbdev
From: Nicolas Capens <capn@google.com>
Signed-off-by: Nicolas Capens <capn@google.com>
Signed-off-by: Jin Qian <jinqian@android.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/video/fbdev/goldfishfb.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index cddc91d..2a5fe71 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -53,39 +53,35 @@ enum {
HAL_PIXEL_FORMAT_RGB_888 = 3,
HAL_PIXEL_FORMAT_RGB_565 = 4,
HAL_PIXEL_FORMAT_BGRA_8888 = 5,
- HAL_PIXEL_FORMAT_RGBA_5551 = 6,
- HAL_PIXEL_FORMAT_RGBA_4444 = 7,
};
struct framebuffer_config {
- u8 format;
u8 bytes_per_pixel;
- u8 transp_offset;
- u8 transp_length;
u8 red_offset;
u8 red_length;
u8 green_offset;
u8 green_length;
u8 blue_offset;
u8 blue_length;
+ u8 transp_offset;
+ u8 transp_length;
+};
+
+static const struct framebuffer_config fb_configs[] = {
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* Invalid, assume RGB_565 */
+ { 4, 0, 8, 8, 8, 16, 8, 24, 8 }, /* HAL_PIXEL_FORMAT_RGBA_8888 */
+ { 4, 0, 8, 8, 8, 16, 8, 0, 0 }, /* HAL_PIXEL_FORMAT_RGBX_8888 */
+ { 3, 0, 8, 8, 8, 16, 8, 0, 0 }, /* HAL_PIXEL_FORMAT_RGB_888 */
+ { 2, 11, 5, 5, 6, 0, 5, 0, 0 }, /* HAL_PIXEL_FORMAT_RGB_565 */
+ { 4, 16, 8, 8, 8, 0, 8, 24, 8 }, /* HAL_PIXEL_FORMAT_BGRA_8888 */
};
static const struct framebuffer_config *get_fb_config_from_format(int format)
{
- /* Only configurations supported by the emulator. */
- static const struct framebuffer_config fb_configs[] = {
- { HAL_PIXEL_FORMAT_RGB_565, 2, 0, 0, 11, 5, 5, 6, 0, 5 },
- { HAL_PIXEL_FORMAT_RGBX_8888, 4, 0, 0, 16, 8, 8, 8, 0, 8 },
- { HAL_PIXEL_FORMAT_RGBA_8888, 4, 24, 8, 16, 8, 8, 8, 0, 8 },
- };
- const int fb_configs_size = ARRAY_SIZE(fb_configs);
- int n;
-
- for (n = 0; n < fb_configs_size; ++n) {
- if (format = fb_configs[n].format)
- return &fb_configs[n];
- }
- return &fb_configs[0]; /* default to RGB565 */
+ if (format > 0 && format < ARRAY_SIZE(fb_configs))
+ return &fb_configs[format];
+
+ return &fb_configs[HAL_PIXEL_FORMAT_RGB_565]; /* legacy default */
}
struct goldfish_fb {
^ permalink raw reply related
* Re: [PATCH 0/7] PMAG-AA frame buffer driver rework
From: Maciej W. Rozycki @ 2016-02-27 22:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Ralf Baechle, Jean-Christophe Plagniol-Villard,
Geert Uytterhoeven, linux-fbdev, linux-kernel
In-Reply-To: <56D033EB.7010506@ti.com>
Hi Tomi,
> > This is an update to the PMAG-AA frame buffer driver to adapt it to our
> > current APIs, which I promised a while ago (too much of a while, which I
> > apologise for).
>
> Interesting hardware. I like the names of these things. "Monolithic CMOS
> 64 x 64 Pixel Cursor Generator", "TURBOchannel Color Frame Buffer".
Indeed, it sounds so 1980s, doesn't it? It took me a while too to figure
out how to wire it to a monitor as the adapter has a TNC connector for its
output (the colour adapters from the line have a DA-3W3 connector each
instead). Fortunately at least video signalling is standard -- EIA-343A
-- so a modern VGA monitor can be used as long as it does sync-on-green.
> Also interesting to see the git history of a file going almost directly
> to the initial git commit.
FYI, for anything beyond you'd have to get at LMO's GIT history, e.g.:
$ git blame 66f0a432564b -- drivers/video/fbdev/pmag-aa-fb.c
on a checkout from <git://git.linux-mips.org/pub/scm/ralf/linux>.
Ralf had been running his MIPS tree in CVS since forever and consequently
had a slightly more detailed history of changes than Linus had with his
master copy. When the move from BitKeeper to GIT was made Ralf was kind
enough to go through the pain and converted his CVS repository to GIT
before merging with Linus.
There are older branches there as well, namely: linux-2.4, linux-2.2, and
linux-2.0 (anything beyond these is linear on master). Most operations on
the master branch are cut through at the initial Linus's commit though,
you need to name a commit preceding that point -- such as one immediately
before, which I referred to above -- to go past.
> Thanks, queued for 4.6.
Thanks.
I've since noticed blanking will need an update to interpret VESA modes
correctly, i.e. return errors for the unsupported ones. This is a minor
issue, so I'll group it with blanking support for the other two boards
which is missing for the Bt459 RAMDAC they use. The Bt459 can switch sync
generation off, so the full powerdown mode can be supported too in
addition to plain screen blanking (obviously you can't switch individual
sync signals in a composite signal).
Cursor support for the Bt459 would be good to have too; noted as a future
enhancement possibility.
Maciej
^ permalink raw reply
* INFORMAÇÃO IMPORTANTE RE: Consultoria de Investime =?utf-8?q?nto_em_sua_Loc
From: Mr. DOUGLAS @ 2016-02-28 12:37 UTC (permalink / raw)
To: linux-fbdev
Oi,
Temos planejado investir alguns fundos no seu país.
Responder se você estiver interessado.
Saudações,
Sir Henry Neville Lindley Keswick
Presidente da Jardine Matheson Holdings Ltd
https://en.wikipedia.org/wiki/Keswick_family
=========================
Hi friend,
Our family is interested in investing funds in your locality.
More information for you interest .
Greetings,
Sir Henry Neville Lindley Keswick
Chairman of Jardine Matheson Holdings Ltd
https://en.wikipedia.org/wiki/Keswick_family
^ permalink raw reply
* INFORMAÇÃO IMPORTANTE RE: Consultoria de Investime =?utf-8?q?nto_em_sua_Loc
From: Alecssandro @ 2016-02-28 12:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20160228133600.041758FAEA5@webmail.cefet-rj.br>
Oi Amigo,
INFORMAÇÃO IMPORTANTE
Nossa família está interessada em investir fundos em sua localidade.
Mais informações para você se interessou.
Saudações,
Sir Henry Neville Lindley Keswick
Presidente da Jardine Matheson Holdings Ltd
https://en.wikipedia.org/wiki/Keswick_family
^ permalink raw reply
* Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
From: Tomi Valkeinen @ 2016-02-29 8:44 UTC (permalink / raw)
To: Paul Gortmaker
Cc: linux-kernel, David S. Miller, Jean-Christophe Plagniol-Villard,
linux-fbdev, sparclinux
In-Reply-To: <20160226135813.GD15454@windriver.com>
[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]
On 26/02/16 15:58, Paul Gortmaker wrote:
> A counter point would be that if an old driver has remained non-modular
> for all these years, then clearly there is no demand for adding a new
> modular implementation at this point in time.
True. Then again, I think fbdev drivers are almost always used as
built-in to get the console up and running early. For fbdev I see the
module support mostly as a way to improve the code quality and to
simplify development and testing.
> The main reason is listed as #4 above -- if we keep drivers around that
> reflect a disconnect between Kconfig and code, the same mistake gets
> copied into more and more new drivers as they are created.
Yep, but the same could be said about having drivers without module
support too =).
In any case, I don't accept new fbdev drivers except in special cases,
so fbdev drivers' value as examples is not that much.
> If the argument was to not go in and rewrite core code for legacy
> drivers, I'd agree with that, but that isn't what is happening here.
> In a lot of these type changes, where the only change is to replace
> module_init with device initcall, the object files are identical.
Yes, the patches look simple enough. Ensuring they would work as modules
would be riskier.
> If subsystem maintainers would rather have blanket tristate coversions
> and whatever changes are required to make it compile and modpost, and
> are OK to assume things will just work, then that could be an option...
Nope, I think these are fine. I'll queue them up for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code,Re: [PATCH 0/3] video/fbde
From: Tomi Valkeinen @ 2016-02-29 8:51 UTC (permalink / raw)
To: David Miller
Cc: paul.gortmaker, linux-kernel, plagnioj, linux-fbdev, sparclinux
In-Reply-To: <20160226.122112.1169840448330570848.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]
On 26/02/16 19:21, David Miller wrote:
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Fri, 26 Feb 2016 12:58:00 +0200
>
>> While doing this, did you just go forward removing the module support,
>> or did you check if it would be trivial to make the driver build as a
>> module? I wouldn't be surprised if in some cases all that would need to
>> be done is change the Kconfig's bool to tristate.
>
> I think what he is doing is reasonable, and none of these sparc drivers
> have any reason to be built modular. You need them to have any bootup
> console whatsoever, so they have to be built in statically to be
> usable at all.
I disagree. Having drivers buildable as modules is always good, even if
the normal use case would be to have them as built-in.
> I plan to apply this patch series to my sparc tree as-is.
They are fbdev patches without any dependency to sparc afaics. So let's
apply them via fbdev tree.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: da8xx-fb: fix videomodes of lcd panels
From: Sushaanth Srirangapathi @ 2016-02-29 13:24 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Sekhar Nori, linux-fbdev, linux-kernel, linux-omap,
Sushaanth Srirangapathi
Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
forgot to update known_lcd_panels[] which had sync values
according to old logic. This breaks LCD at least on DA850 EVM.
This patch fixes this issue and I have tested this for panel
"Sharp_LK043T1DG01" using DA850 EVM board.
Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
hsync/vsync pulse")
Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
---
drivers/video/fbdev/da8xx-fb.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 6b2a06d..d8d583d 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -209,8 +209,7 @@ static struct fb_videomode known_lcd_panels[] = {
.lower_margin = 2,
.hsync_len = 0,
.vsync_len = 0,
- .sync = FB_SYNC_CLK_INVERT |
- FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .sync = FB_SYNC_CLK_INVERT,
},
/* Sharp LK043T1DG01 */
[1] = {
@@ -224,7 +223,7 @@ static struct fb_videomode known_lcd_panels[] = {
.lower_margin = 2,
.hsync_len = 41,
.vsync_len = 10,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .sync = 0,
.flag = 0,
},
[2] = {
@@ -239,7 +238,7 @@ static struct fb_videomode known_lcd_panels[] = {
.lower_margin = 10,
.hsync_len = 10,
.vsync_len = 10,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .sync = 0,
.flag = 0,
},
[3] = {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] video: exynos: fix modular build
From: Tomi Valkeinen @ 2016-02-29 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1456490307-823812-1-git-send-email-arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 1696 bytes --]
Hi,
On 26/02/16 14:38, Arnd Bergmann wrote:
> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
> which can be configured as a loadable module, so we have to
> make the driver a tristate symbol as well, to avoid this error:
>
> drivers/built-in.o: In function `s6e8ax0_probe':
> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
built-in?
> This also means we get another error from a missing export, which
> this fixes as well:
>
> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>
> The drivers are all written to be loadable modules already,
> except the Kconfig options for that are missing, which makes
> the patch really easy.
Looks and sound fine, except doesn't this tell that the drivers have
never been tested as modules? Did you or someone else actually test these?
> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
> index b5b1bd228abb..02d8dc522fea 100644
> --- a/drivers/video/fbdev/exynos/Makefile
> +++ b/drivers/video/fbdev/exynos/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for the exynos video drivers.
> #
>
> -obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> - exynos_mipi_dsi_lowlevel.o
> +obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos-mipi-dsi-mod.o
> +
> +exynos-mipi-dsi-mod-objs += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> + exynos_mipi_dsi_lowlevel.o
Hmm, why is this makefile change needed?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: da8xx-fb: fix videomodes of lcd panels
From: Tomi Valkeinen @ 2016-02-29 16:30 UTC (permalink / raw)
To: Sushaanth Srirangapathi, Jean-Christophe Plagniol-Villard
Cc: Sekhar Nori, linux-fbdev, linux-kernel, linux-omap
In-Reply-To: <1456751539-19298-1-git-send-email-sushaanth.s@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 734 bytes --]
On 29/02/16 15:12, Sushaanth Srirangapathi wrote:
> Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
> hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
> forgot to update known_lcd_panels[] which had sync values
> according to old logic. This breaks LCD at least on DA850 EVM.
>
> This patch fixes this issue and I have tested this for panel
> "Sharp_LK043T1DG01" using DA850 EVM board.
>
> Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
> hsync/vsync pulse")
> Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
> ---
> drivers/video/fbdev/da8xx-fb.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video: exynos: fix modular build
From: Arnd Bergmann @ 2016-02-29 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56D46DFD.6090706@ti.com>
On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
> Hi,
>
> On 26/02/16 14:38, Arnd Bergmann wrote:
> > The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
> > which can be configured as a loadable module, so we have to
> > make the driver a tristate symbol as well, to avoid this error:
> >
> > drivers/built-in.o: In function `s6e8ax0_probe':
> > :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>
> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
> built-in?
No, that's not how Kconfig interprets it. There are many bool option
that depend on tristate options but can be enabled if the dependency
is built-in.
Take this one for example:
config FIRMWARE_EDID
bool "Enable firmware EDID"
depends on FB
We clearly want to be able to turn this on even for FB=m.
> > This also means we get another error from a missing export, which
> > this fixes as well:
> >
> > ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
> >
> > The drivers are all written to be loadable modules already,
> > except the Kconfig options for that are missing, which makes
> > the patch really easy.
>
> Looks and sound fine, except doesn't this tell that the drivers have
> never been tested as modules? Did you or someone else actually test these?
No, this is not runtime tested. Generally there is very little that
can go wrong here though.
An alternative would be to change the dependency to
depends on BACKLIGHT_CLASS_DEVICE=y
which doesn't allow the driver to be turned on for the =m case.
However, no other framebuffer driver does this.
> > diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
> > index b5b1bd228abb..02d8dc522fea 100644
> > --- a/drivers/video/fbdev/exynos/Makefile
> > +++ b/drivers/video/fbdev/exynos/Makefile
> > @@ -2,6 +2,8 @@
> > # Makefile for the exynos video drivers.
> > #
> >
> > -obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> > - exynos_mipi_dsi_lowlevel.o
> > +obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos-mipi-dsi-mod.o
> > +
> > +exynos-mipi-dsi-mod-objs += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> > + exynos_mipi_dsi_lowlevel.o
>
> Hmm, why is this makefile change needed?
The original Makefile would link each file into a separate module, but that
cannot work, because they reference symbols from each other that are not
exported to other modules.
With my change, all the files get linked into a single module.
Arnd
^ permalink raw reply
* Re: [PATCH v2] video: exynos: fix modular build
From: Tomi Valkeinen @ 2016-02-29 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6291541.7IMAnfX0g2@wuerfel>
[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]
On 29/02/16 18:39, Arnd Bergmann wrote:
> On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/02/16 14:38, Arnd Bergmann wrote:
>>> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
>>> which can be configured as a loadable module, so we have to
>>> make the driver a tristate symbol as well, to avoid this error:
>>>
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>>
>> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
>> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
>> built-in?
>
> No, that's not how Kconfig interprets it. There are many bool option
> that depend on tristate options but can be enabled if the dependency
> is built-in.
>
> Take this one for example:
>
> config FIRMWARE_EDID
> bool "Enable firmware EDID"
> depends on FB
>
> We clearly want to be able to turn this on even for FB=m.
Right.
>>> This also means we get another error from a missing export, which
>>> this fixes as well:
>>>
>>> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>>>
>>> The drivers are all written to be loadable modules already,
>>> except the Kconfig options for that are missing, which makes
>>> the patch really easy.
>>
>> Looks and sound fine, except doesn't this tell that the drivers have
>> never been tested as modules? Did you or someone else actually test these?
>
> No, this is not runtime tested. Generally there is very little that
> can go wrong here though.
>
> An alternative would be to change the dependency to
>
> depends on BACKLIGHT_CLASS_DEVICE=y
>
> which doesn't allow the driver to be turned on for the =m case.
> However, no other framebuffer driver does this.
No, I think it's clearly better to make them tristate. I think all
drivers should be buildable as modules. It just makes me a bit
uncomfortable to enable code that has never been ran.
>>> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
>>> index b5b1bd228abb..02d8dc522fea 100644
>>> --- a/drivers/video/fbdev/exynos/Makefile
>>> +++ b/drivers/video/fbdev/exynos/Makefile
>>> @@ -2,6 +2,8 @@
>>> # Makefile for the exynos video drivers.
>>> #
>>>
>>> -obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> - exynos_mipi_dsi_lowlevel.o
>>> +obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos-mipi-dsi-mod.o
>>> +
>>> +exynos-mipi-dsi-mod-objs += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> + exynos_mipi_dsi_lowlevel.o
>>
>> Hmm, why is this makefile change needed?
>
> The original Makefile would link each file into a separate module, but that
> cannot work, because they reference symbols from each other that are not
> exported to other modules.
>
> With my change, all the files get linked into a single module.
Yes, of course.
Thanks, I'll queue this up for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] video: fbdev: sis: remove unused variable
From: Sudip Mukherjee @ 2016-02-29 18:14 UTC (permalink / raw)
To: Thomas Winischhofer, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen
Cc: linux-kernel, linux-fbdev, Sudip Mukherjee
In-Reply-To: <1421940699-20670-1-git-send-email-sudipm.mukherjee@gmail.com>
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(-)
diff --git a/drivers/video/fbdev/sis/init301.c b/drivers/video/fbdev/sis/init301.c
index 295e0de..20f7234 100644
--- a/drivers/video/fbdev/sis/init301.c
+++ b/drivers/video/fbdev/sis/init301.c
@@ -2151,17 +2151,15 @@ SiS_GetVCLK2Ptr(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned shor
unsigned short RefreshRateTableIndex)
{
unsigned short CRT2Index, VCLKIndex = 0, VCLKIndexGEN = 0, VCLKIndexGENCRT = 0;
- unsigned short modeflag, resinfo, tempbx;
+ unsigned short resinfo, tempbx;
const unsigned char *CHTVVCLKPtr = NULL;
if(ModeNo <= 0x13) {
- modeflag = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ModeFlag;
resinfo = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_ResInfo;
CRT2Index = SiS_Pr->SiS_SModeIDTable[ModeIdIndex].St_CRT2CRTC;
VCLKIndexGEN = (SiS_GetRegByte((SiS_Pr->SiS_P3ca+0x02)) >> 2) & 0x03;
VCLKIndexGENCRT = VCLKIndexGEN;
} else {
- modeflag = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_ModeFlag;
resinfo = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO;
CRT2Index = SiS_Pr->SiS_RefIndex[RefreshRateTableIndex].Ext_CRT2CRTC;
VCLKIndexGEN = SiS_Pr->SiS_RefIndex[RefreshRateTableIndex].Ext_CRTVCLK;
@@ -7270,7 +7268,7 @@ SiS_ShiftXPos(struct SiS_Private *SiS_Pr, int shift)
static void
SiS_SetGroup4_C_ELV(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned short ModeIdIndex)
{
- unsigned short temp, temp1, resinfo = 0;
+ unsigned short temp, temp1;
unsigned char *ROMAddr = SiS_Pr->VirtualRomBase;
if(!(SiS_Pr->SiS_VBType & VB_SIS30xCLV)) return;
@@ -7282,10 +7280,6 @@ SiS_SetGroup4_C_ELV(struct SiS_Private *SiS_Pr, unsigned short ModeNo, unsigned
if(!(ROMAddr[0x61] & 0x04)) return;
}
- if(ModeNo > 0x13) {
- resinfo = SiS_Pr->SiS_EModeIDTable[ModeIdIndex].Ext_RESINFO;
- }
-
SiS_SetRegOR(SiS_Pr->SiS_Part4Port,0x3a,0x08);
temp = SiS_GetReg(SiS_Pr->SiS_Part4Port,0x3a);
if(!(temp & 0x01)) {
--
1.9.1
^ permalink raw reply related
* [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