* 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] fbdev: kill fb_rotate
From: Tomi Valkeinen @ 2016-02-26 11:30 UTC (permalink / raw)
To: Rasmus Villemoes, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel, linux-omap
In-Reply-To: <1455044172-17488-1-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1.1: Type: text/plain, Size: 934 bytes --]
On 09/02/16 20:56, Rasmus Villemoes wrote:
> The fb_rotate method in struct fb_ops is never actually invoked, and
> it's been that way in the entire history of git (in fact, the last
> occurrence of the string '->fb_rotate' vanished over 10 years ago,
> with b4d8aea6d6, and that merely tested whether the callback
> existed). So remove some dead code and make struct fb_obs a little
> smaller.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/video/fbdev/atafb.c | 3 ---
> drivers/video/fbdev/au1100fb.c | 22 ----------------------
> drivers/video/fbdev/bf537-lq035.c | 23 -----------------------
> drivers/video/fbdev/omap/omapfb_main.c | 22 ----------------------
> drivers/video/fbdev/skeletonfb.c | 17 -----------------
> include/linux/fb.h | 3 ---
> 6 files changed, 90 deletions(-)
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: set a default value to blink interval
From: Tomi Valkeinen @ 2016-02-26 11:21 UTC (permalink / raw)
To: Jean-Philippe Brucker, linux-fbdev
Cc: Jean-Christophe Plagniol-Villard, Scot Doyle, Greg Kroah-Hartman,
Pavel Machek, Thierry Reding, stable
In-Reply-To: <1455561693-28615-1-git-send-email-jean-philippe.brucker@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1423 bytes --]
On 15/02/16 20:41, 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".
>
> 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(+)
Thanks, queued for 4.5 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] PMAG-AA frame buffer driver rework
From: Tomi Valkeinen @ 2016-02-26 11:15 UTC (permalink / raw)
To: Maciej W. Rozycki, Jean-Christophe Plagniol-Villard,
Geert Uytterhoeven
Cc: linux-fbdev, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1602220110330.7431@eddie.linux-mips.org>
[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]
On 22/02/16 03:54, Maciej W. Rozycki wrote:
> Hi,
>
> 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".
Also interesting to see the git history of a file going almost directly
to the initial git commit.
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: pmag-ba-fb: Fix the lower margin size
From: Tomi Valkeinen @ 2016-02-26 11:04 UTC (permalink / raw)
To: Maciej W. Rozycki, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1602220109160.7431@eddie.linux-mips.org>
[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]
On 22/02/16 03:54, Maciej W. Rozycki wrote:
> According to the board specification[1] the width of the vertical sync
> front porch is 12 pixels or the same as the width of the horizontal sync
> front porch. This in turn means the size of the lower margin is 0,
> because the vertical sync starts as soon as the start of the horizontal
> sync terminates the last line.
>
> References:
>
> [1] "PMAG-BA TURBOchannel Color Frame Buffer Functional Specification",
> Revision 1.2, Workstation Systems Engineering, Digital Equipment
> Corporation, August 27, 1990, Table 3-5: "Video Timing"
>
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> linux-pmag-ba-lower.patch
> Index: linux-20150524-4maxp64/drivers/video/fbdev/pmag-ba-fb.c
> ===================================================================
> --- linux-20150524-4maxp64.orig/drivers/video/fbdev/pmag-ba-fb.c
> +++ linux-20150524-4maxp64/drivers/video/fbdev/pmag-ba-fb.c
> @@ -60,7 +60,7 @@ static struct fb_var_screeninfo pmagbafb
> .left_margin = 116,
> .right_margin = 12,
> .upper_margin = 34,
> - .lower_margin = 12,
> + .lower_margin = 0,
> .hsync_len = 128,
> .vsync_len = 3,
> .sync = FB_SYNC_ON_GREEN,
>
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdc: Use ARCH_RENESAS
From: Tomi Valkeinen @ 2016-02-26 11:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1456106391-10353-1-git-send-email-horms+renesas@verge.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]
On 22/02/16 03:59, Simon Horman wrote:
> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
>
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/video/fbdev/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Based on v4.5-rc1
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..936ebd4bcf73 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1985,7 +1985,7 @@ config FB_W100
>
> config FB_SH_MOBILE_LCDC
> tristate "SuperH Mobile LCDC framebuffer support"
> - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> + depends on FB && (SUPERH || ARCH_RENESAS) && HAVE_CLK
> depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
>
Thanks, queued 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
From: Tomi Valkeinen @ 2016-02-26 10:58 UTC (permalink / raw)
To: Paul Gortmaker, linux-kernel
Cc: David S. Miller, Jean-Christophe Plagniol-Villard, linux-fbdev,
sparclinux
In-Reply-To: <1456110792-21771-1-git-send-email-paul.gortmaker@windriver.com>
[-- Attachment #1.1: Type: text/plain, Size: 1741 bytes --]
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.
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...
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.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Tomi Valkeinen @ 2016-02-26 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYowXJinONTd2qREfCtEDCon+HSQtdd6t1QQA91f6PJdw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2417 bytes --]
On 25/02/16 21:30, Linus Walleij wrote:
> On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 25/02/16 16:04, Linus Walleij wrote:
>
>>> *All* the others
>>> will be very happy with *ONE* display defined as panel in the
>>> device tree, and off they go. Usually VGA. And that will look
>>
>> You keep mentioning VGA. So is there are VGA output? Or do you just mean
>> MIPI DPI panels, which happen to take the same video timings as VGA?
>
> Russell beat me to it, yes there is an external VGA encoder.
> It needs some bits set up through the "misc registers" system
> controller as indicated. From the CLCD hardware point of view
> it's no different than any other panel. So the DTS fragment looks
> like so:
>
> panel {
> compatible = "panel-dpi";
>
> port {
> clcd_panel: endpoint {
> remote-endpoint = <&clcd_pads>;
> };
> };
>
> /* Standard 640x480 VGA timings */
> panel-timing {
> clock-frequency = <25175000>;
> hactive = <640>;
> hback-porch = <48>;
> hfront-porch = <16>;
> hsync-len = <96>;
> vactive = <480>;
> vback-porch = <33>;
> vfront-porch = <10>;
> vsync-len = <2>;
> };
> };
>
>
> This is reported as the default display type if no LCD panel
> is connected.
>
> If a LCD panel is also connected, it take precedence.
Ok. Well... It's all wrong, but I don't know how much time we want to
spend on fixing that.
Although one thing to consider is that if there is ever going to be a
DRM driver for CLCD, it would be good to have the device tree parts
correctly representing the hardware, so that the DRM driver could be
implemented in a cleaner, more generic way.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7 v2] video: ARM CLCD: support DT signal inversion flags
From: Tomi Valkeinen @ 2016-02-26 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1456221704-5792-4-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 2644 bytes --]
On 23/02/16 12:01, Linus Walleij wrote:
> The device tree bindings from display-timing.txt allows us to
> specify if data enable, hsync, vsync or the pixed clock should be
> inverted on the way to the display. The driver does not currently
> handle this so add support for those flags as it is needed for
> the Versatile Sanyo LCD display.
>
> Note that the previous behaviour was to invert the pixel clock
> for all displays, so unless the pixel clock polarity is
> explicitly defined in the device tree (i.e. the timings node
> has the "pixelclk-active" property) we fall back to inverting
> the pixel clock. This needs some extra compatibility code.
>
> Since the timing flags have to be set up inside the struct
> clcd_panel, we need to refactor the code a bit to pass around
> the panel rather than just the mode.
>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - No changes. Just reposting.
> ---
> drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index c5d1e9ca81ab..8903a42c4122 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
>
> #ifdef CONFIG_OF
> static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct display_timing timing;
> + struct device_node *timnp;
> struct videomode video;
>
> err = of_get_display_timing(node, "panel-timing", &timing);
> @@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
>
> videomode_from_timing(&timing, &video);
>
> - err = fb_videomode_from_videomode(&video, mode);
> + err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
> if (err)
> return err;
>
> + /* Set up some inversion flags */
> + timnp = of_get_child_by_name(node, "panel-timing");
> + if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
Hmm, why are you poking in the videomode DT properties directly? If the
pixelclk-active was not defined in the DT, you should see it in the
videomode struct as neither DISPLAY_FLAGS_PIXDATA_POSEDGE nor
DISPLAY_FLAGS_PIXDATA_NEGEDGE being set (I think, I didn't go through
the code in detail).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] video: ARM CLCD: non-controversial parts
From: Tomi Valkeinen @ 2016-02-26 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbGDXTbenOY_bsiuGqS3oBP3CKyjsOJuMPStaMFi=u3hw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 471 bytes --]
On 25/02/16 21:35, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 11:01 AM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>
>> This is a redux version of the previous patch set that strips out
>> any attempts to auto-switch or rewrite the device tree to match
>> the CLCD Versatile panel.
>
> It seems patch #4 didn't make it out so I re-sent it.
Hmm, it was there in the series... Russell had comments to it, to which
you didn't reply.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: n411: check return value
From: Tomi Valkeinen @ 2016-02-26 10:18 UTC (permalink / raw)
To: Sudip Mukherjee, Jean-Christophe Plagniol-Villard
Cc: linux-kernel, linux-fbdev
In-Reply-To: <1456231457-20806-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 355 bytes --]
On 23/02/16 14:44, Sudip Mukherjee wrote:
> We were not checking the return value of platform_device_add_data()
> which can fail.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
> drivers/video/fbdev/n411.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 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 3/3] fbdev: omap2: panel-dpi: implement support for a vcc regulator
From: Tomi Valkeinen @ 2016-02-26 10:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-4-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]
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)?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/12] pwm: add support for atomic update
From: Doug Anderson @ 2016-02-25 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VM3cOQ0HqwLANBw9MVBCyFTrSyPe_dGzgPucuMUEWRKA@mail.gmail.com>
Thierry,
On Tue, Feb 23, 2016 at 10:42 AM, Doug Anderson <dianders@google.com> wrote:
> Thierry,
>
> On Tue, Feb 23, 2016 at 10:14 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>>> pwm_get_period(): get the period of the PWM; if the PWM has not yet
>>> been configured by software this gets the default period (possibly
>>> specified by the device tree).
>>
>> No. I think we'll need a different construct for the period defined by
>> DT or board files. pwm_get_period() is the legacy API to retrieve the
>> "current" period, even if it was lying a little before the atomic API.
>
> Ah, got it. I think I missed that you considered pwm_get_period()
> legacy and that you eventually wanted to get rid of it. OK, then what
> you say makes sense.
>
>
>>> That should work with one minor problem. If HW readout isn't
>>> supported then pwm_get_state() in probe will presumably return 0 for
>>> the duty cycle. That means it will change the voltage. That's in
>>> contrast to how I think things work today where the voltage isn't
>>> changed until the first set_voltage() call. At least the last time I
>>> tested things get_voltage() would simply report an incorrect value
>>> until the first set_voltage(). I think existing behavior (reporting
>>> the wrong value) is better than new behavior (change the value at
>>> probe).
>>
>> That's exactly the point. Reporting a wrong value isn't really a good
>> option. Changing the voltage on boot is the only way to make the logical
>> state match the hardware state on boot. Chances are that if you don't
>> have hardware readout support you probably don't care what state your
>> regulator will be in.
>>
>> Then again, if we don't support hardware readout, setting up the logical
>> state with data from DT (or board files) and defaulting the duty cycle
>> to 0, we end up with exactly what we had before, even with the atomic
>> API, right? Maybe that's okay, too.
>
> IMHO this is a change in behavior that will break existing users.
> Anyone using a PWM regulator will suddenly find their voltage changing
> at bootup. Certainly today all users of the PWM regulator don't seem
> to mind (apparently) the the voltage is reported incorrectly at bootup
> but I bet they'd mind if the voltage suddenly started changing for
> them at bootup.
>
> It seems better to preserve existing behavior and print a warning that
> the voltage will be reported incorrectly until HW Readout is
> supported.
>
> Of course, we're only talking about two real users in mainline here:
> Rockchip boards and the "stih407-family". If we just fix both of
> those to support HW Readout before landing the change then I'm fine
> with doing what you say.
>
>
>>> ...and if set_voltage() remains untouched then we can solve my probe
>>> problem by renaming pwm_get_state() to pwm_get_hw_state() and having
>>> it return an error if HW readout is not supported. Then we only call
>>> pwm_get_args() / pwm_apply_state() when we support HW readout.
>>
>> The problem is that we make the API clumsy to use. If we don't sync the
>> "initial" state (as defined by DT or board files) to hardware at any
>> point, then we need to add the pwm_args construct and always stick to
>> it. I think it weird to have to use the pwm_args.period instead of the
>> current period.
>>
>> So we're back to square one, really. That's exactly what Mark brought up
>> originally.
>
> I had missed the part where you wanted to deprecate pwm_get_period().
> Thus my points here aren't really valid.
>
> In my mind the old API was perfectly fine (and actually quite clean /
> simple to use) except in the special case of avoiding the PWM
> regulator glitches. With that mindset I think my previous email make
> sense. However, this is your subsystem to maintain and if you think
> moving everyone to a new atomic API makes more sense then you're in
> the best position to make that decision. :)
So just to summarize:
* Add pwm_get_state(), pwm_apply_state(), pwm_get_args().
pwm_get_state() initially returns 0 for duty cycle if driver doesn't
support readout.
* Re-implement pwm_get_period() (and maybe other similar functions)
atop pwm_get_state() as you describe earlier in the thread.
* Document pwm_get_period() (and maybe other similar functions) as deprecated.
* Fix drivers for all current 2 users of PWM regulator to support
hardware readout.
* Update PWM regulator as you described earlier in the thread (Feb 23).
* If PWM regulator is ever used on a new board whose PWM doesn't
support hardware readout, the voltage will change at probe time.
Did I get all that right? Thanks!
-Doug
^ permalink raw reply
* Re: [PATCH 0/7] video: ARM CLCD: non-controversial parts
From: Linus Walleij @ 2016-02-25 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
On Tue, Feb 23, 2016 at 11:01 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> This is a redux version of the previous patch set that strips out
> any attempts to auto-switch or rewrite the device tree to match
> the CLCD Versatile panel.
It seems patch #4 didn't make it out so I re-sent it.
Tell me if you want me to resend the entire v2 patch set.
This stuff would be really neat to get in as a starter.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/7 v2] video: ARM CLCD: support pads connected in reverse order
From: Linus Walleij @ 2016-02-25 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1456221704-5792-5-git-send-email-linus.walleij@linaro.org>
There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
drivers/video/fbdev/amba-clcd.c | 8 ++++++++
include/linux/amba/clcd.h | 31 ++++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
} panels[] = {
{ 0x110, 1, 7, 13, CLCD_CAP_5551 },
{ 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x110, 16, 8, 0, CLCD_CAP_888 },
{ 0x111, 4, 14, 20, CLCD_CAP_444 },
{ 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
{ 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
fb->panel->caps = panels[i].caps;
}
+ /*
+ * If we actually physically connected the R lines to B and
+ * vice versa
+ */
+ if (r0 != 0 && b0 = 0)
+ fb->panel->bgr_connection = true;
+
return fb->panel->caps ? 0 : -EINVAL;
}
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
grayscale:1;
unsigned int connector;
struct backlight_device *backlight;
+ /*
+ * If the B/R lines are switched between the CLCD
+ * and the panel we need to know this and not try to
+ * compensate with the BGR bit in the control register.
+ */
+ bool bgr_connection;
};
struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
if (var->grayscale)
val |= CNTL_LCDBW;
- if (fb->panel->caps && fb->board->caps &&
- var->bits_per_pixel >= 16) {
+ if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
/*
* if board and panel supply capabilities, we can support
- * changing BGR/RGB depending on supplied parameters
+ * changing BGR/RGB depending on supplied parameters. Here
+ * we switch to what the framebuffer is providing if need
+ * be, so if the framebuffer is BGR but the display connection
+ * is RGB (first case) we switch it around. Vice versa mutatis
+ * mutandis if the framebuffer is RGB but the display connection
+ * is BGR, we flip it around.
*/
- if (var->red.offset = 0)
- val &= ~CNTL_BGR;
- else
- val |= CNTL_BGR;
+ if (!fb->panel->bgr_connection) {
+ if (var->red.offset = 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ } else {
+ if (var->blue.offset = 0)
+ val &= ~CNTL_BGR;
+ else
+ val |= CNTL_BGR;
+ }
}
switch (var->bits_per_pixel) {
--
2.4.3
^ permalink raw reply related
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-25 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56CF2FB1.106@ti.com>
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Anyway, if it's likely that we're not seeing new CLCD boards, I think
> it's fine if we don't go to any great lengths to clean things up there.
> Let's just get it working.
Do you think you could merge the other patch set I made, that doesn't
even deal with this plug-n-play-panel issue?
I have rebased the two approaches to autodetection on top of that.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-25 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56CF2FB1.106@ti.com>
On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 25/02/16 16:04, Linus Walleij wrote:
>> *All* the others
>> will be very happy with *ONE* display defined as panel in the
>> device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
Russell beat me to it, yes there is an external VGA encoder.
It needs some bits set up through the "misc registers" system
controller as indicated. From the CLCD hardware point of view
it's no different than any other panel. So the DTS fragment looks
like so:
panel {
compatible = "panel-dpi";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
/* Standard 640x480 VGA timings */
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
hback-porch = <48>;
hfront-porch = <16>;
hsync-len = <96>;
vactive = <480>;
vback-porch = <33>;
vfront-porch = <10>;
vsync-len = <2>;
};
};
This is reported as the default display type if no LCD panel
is connected.
If a LCD panel is also connected, it take precedence.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Russell King - ARM Linux @ 2016-02-25 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56CF2FB1.106@ti.com>
On Thu, Feb 25, 2016 at 06:45:37PM +0200, Tomi Valkeinen wrote:
> > *All* the others
> > will be very happy with *ONE* display defined as panel in the
> > device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?
There is a 15-pin VGA connector too. No DDC though.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Tomi Valkeinen @ 2016-02-25 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3393 bytes --]
On 25/02/16 16:04, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> Maybe Versatile is different. If CLCD is only used on that board, or a
>> small family of boards, from one vendor, I guess it is maintainable to
>> have board specific driver parts for CLCD. But if CLCD can be used by
>> many vendors in many different boards, I'd steer clear of board specific
>> driver code.
>
> OK I think at this point we would say that CLCD is a legacy driver.
Ok.
My biggest fear with this is the maintenance nightmare that comes if an
IP or panel is used in multiple SoCs and future designs. We have the
same display subsystem and panel drivers used from OMAP2 forward, and
it's been a constant struggle, so I've come to appreciate the effort to
split things up as much as possible, so that when the time comes when
the HW guys have decided to change a piece here or there, it's easier to
cope with.
Anyway, if it's likely that we're not seeing new CLCD boards, I think
it's fine if we don't go to any great lengths to clean things up there.
Let's just get it working.
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
Ok. And presumably no new boards will use that plug'n'play display, so
we can just consider it specific to versatile.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
You keep mentioning VGA. So is there are VGA output? Or do you just mean
MIPI DPI panels, which happen to take the same video timings as VGA?
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel == 16 && var->green.length == 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
Hmm so is there an external VGA encoder on the board?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Russell King - ARM Linux @ 2016-02-25 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
On Thu, Feb 25, 2016 at 03:04:52PM +0100, Linus Walleij wrote:
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.
And Realview, at least Realview EB, which is the same format board as
Versatile and carries the same LCD connector.
> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
> much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
> like today, using "panel-dpi" to define their displays.
Versatile Express only has a DVI connector.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Arnd Bergmann @ 2016-02-25 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
On Thursday 25 February 2016 15:04:52 Linus Walleij wrote:
>
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
>
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
> struct fb_var_screeninfo *var = &fb->fb.var;
> u32 val;
>
> dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
>
> val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
> INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
> if (var->bits_per_pixel <= 8 ||
> (var->bits_per_pixel = 16 && var->green.length = 5))
> /* Pseudocolor, RGB555, BGR555 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
> else if (fb->fb.var.bits_per_pixel <= 16)
> /* truecolor RGB565 */
> val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
> else
> val = 0; /* no idea for this, don't trust the docs */
>
> regmap_update_bits(versatile_syscon_map,
> INTEGRATOR_HDR_CTRL_OFFSET,
> 0,
> INTEGRATOR_CLCD_MASK);
> }
>
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.
I think the nicest approach here would be to make this a layered
driver, where you have a separate platform_driver instance
that contains all the versatile specific add-ons, and this calls
into the common driver that handles everything that is not specific
to versatile.
It may not be worth investing much into a rework to get there
though, so simply putting it all into one module sounds like
a reasonable compromise.
Arnd
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Pantelis Antoniou @ 2016-02-25 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbi+cJFP8gUvuLKEWVVU_LScZDvnWH59RC7ug-xt2PK4Q@mail.gmail.com>
Hi Linus,
> On Feb 25, 2016, at 17:36 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>> It also means there is no way to get the console up without the right
>>> firmware files in the filesystem. I think that is really crap compared
>>> to what we have today where the display will always come up, and
>>> basically a regression.
>>>
>>> I understand the stance with respect to things like add-on hardware
>>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>>> is just too basic, like a serial port IMO.
>>>
>>> Sure in the ARM world we usually have a serial console, but this is
>>> seriously breaking current practice.
>>
>> As Tomi mentioned firmware files can be located in the kernel image; there is no
>> requirement to be in a filesystem, and that application can be performed really
>> early, before even early init.
>
> Are you thinking about exploiting an appended DT with
> CONFIG_ARM_APPENDED_DTB or something else?
>
It’s not much of a problem to scan for extra blobs appended to the booting blob.
If found, you just apply them and that’s it.
The concatenation operation can either be made off-line on the host, or by the bootloader
if it’s capable of doing so.
If the bootloader is not smart enough to do it, just put the concatenated dtb in place
of the original.
> Yours,
> Linus Walleij
Regards
— Pantelis
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-25 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DF3259B0-8A3A-4AB0-A805-F5A8F7295E5C@konsulko.com>
On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
<pantelis.antoniou@konsulko.com> wrote:
>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>> It also means there is no way to get the console up without the right
>> firmware files in the filesystem. I think that is really crap compared
>> to what we have today where the display will always come up, and
>> basically a regression.
>>
>> I understand the stance with respect to things like add-on hardware
>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>> is just too basic, like a serial port IMO.
>>
>> Sure in the ARM world we usually have a serial console, but this is
>> seriously breaking current practice.
>
> As Tomi mentioned firmware files can be located in the kernel image; there is no
> requirement to be in a filesystem, and that application can be performed really
> early, before even early init.
Are you thinking about exploiting an appended DT with
CONFIG_ARM_APPENDED_DTB or something else?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Pantelis Antoniou @ 2016-02-25 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
Hi Linus,
> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
>
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it’s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel’s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
>
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
>
> This kills of early boot graphics and getting crash logs on the fbdev
> console until that has happened.
>
> It also means there is no way to get the console up without the right
> firmware files in the filesystem. I think that is really crap compared
> to what we have today where the display will always come up, and
> basically a regression.
>
> I understand the stance with respect to things like add-on hardware
> like a Bluetooth board or WLAN or whatnot. But the fbdev console
> is just too basic, like a serial port IMO.
>
> Sure in the ARM world we usually have a serial console, but this is
> seriously breaking current practice.
>
As Tomi mentioned firmware files can be located in the kernel image; there is no
requirement to be in a filesystem, and that application can be performed really
early, before even early init.
The comparison with x86 is not absolutely valid, since on x86 you know that
the video hardware is going to be present, always.
This is not so in ARM world, especially in the case we’re talking about, an add-on board.
> Yours,
> Linus Walleij
Regards
— Pantelis
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-25 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56CC60C4.6040908@ti.com>
On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Maybe Versatile is different. If CLCD is only used on that board, or a
> small family of boards, from one vendor, I guess it is maintainable to
> have board specific driver parts for CLCD. But if CLCD can be used by
> many vendors in many different boards, I'd steer clear of board specific
> driver code.
OK I think at this point we would say that CLCD is a legacy driver.
It is a PrimceCell (IP block) made by ARM Ltd for their reference
designs, and intended for demonstration purposes. It is used in
these:
arch/arm/mach-integrator/
arch/arm/mach-versatile/
arch/arm/mach-realview/
arch/arm/mach-vexpress/
At the last iteration of their reference designs, ARM invented a
new display driver called HDLCD, which you can find in
drivers/gpu/drm/arm in linux-next. Thus the CLCD is now legacy.
As part of signing a deal with ARM to synthesize their silicon,
vendors get copies of the IP blocks to jumpstart design work.
Sometimes they will design their own display controller, sometimes
they will take the ARM CLCD and synthesize it right off
and not innovate around it at all. That is why CLCD also
appears in:
arch/arm/configs/axm55xx_defconfig
arch/arm/configs/lpc18xx_defconfig
arch/arm/boot/dts/lpc18xx.dtsi
arch/arm/configs/lpc32xx_defconfig
arch/arm/boot/dts/lpc32xx.dtsi
arch/arm/configs/netx_defconfig
arch/arm/configs/spear3xx_defconfig
Sometimes the vendors will tweak the CLCD. St Microelectronics
did the latter, and that is why I add support for that variant as
well.
HOWEVER: the ARM Versatile is the *only* platform I have
seen of these that have plug'n'play for the display.
*All* the others
will be very happy with *ONE* display defined as panel in the
device tree, and off they go. Usually VGA. And that will look
much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
like today, using "panel-dpi" to define their displays.
They and their displays may need some board-specific or SoC
specific tweaks though, just like the Nomadik. The Vexpress is
happy to be able to go without, because I guess it is hard-coded
to just use the DVI output, so no path for the signal needs to be
set up.
I add support for doing this for the Integrator and RealView in
the patch set, by grabbing a handle to the system controller
where they have a few "misc registers". However if you look at
it:
static void integrator_clcd_enable(struct clcd_fb *fb)
{
struct fb_var_screeninfo *var = &fb->fb.var;
u32 val;
dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
if (var->bits_per_pixel <= 8 ||
(var->bits_per_pixel = 16 && var->green.length = 5))
/* Pseudocolor, RGB555, BGR555 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
else if (fb->fb.var.bits_per_pixel <= 16)
/* truecolor RGB565 */
val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
else
val = 0; /* no idea for this, don't trust the docs */
regmap_update_bits(versatile_syscon_map,
INTEGRATOR_HDR_CTRL_OFFSET,
0,
INTEGRATOR_CLCD_MASK);
}
This is stuff that is so closely tied in to the fbdev driver that even
if it is SoC-specific (and reside in arch/arm/mach-integrator etc
today) it would be hard to argument that it should not be part
of the fbdev driver: what it does is connect the lines out of the
CLCD block to the physical VGA encode chip in different ways
depending on how the pixels were set up.
Yours,
Linus Walleij
^ 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