* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
From: Linus Walleij @ 2016-02-20 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac0739e5-4339-7fc5-1179-73af722beb08@broadcom.com>
On Sat, Feb 20, 2016 at 2:23 AM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Do you have a system that needs this?
>
> Yah, we have a system (Cygnus) that can either use the HCLK, or an external
> clock generated from a PLL. To get certain pixel clock frequencies
> (depending on the LCD panel we use), we need to use the external clock
> source with the PLL configured to a particular VCO frequency.
>
> We have not enabled full LCD/video support on that platform in the mainline
> kernel, but we'll eventually get to it.
OK I hope to finish these patches soon so you have some nice stuff
to build upon. I guess it will need the same per-vendor plug-in that
I supplied for the ARMs and the Nomadik.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
From: Ray Jui @ 2016-02-20 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbGCidu_3qbTYf7WSoAhafU4Z5W0jDs4CGtH5XwSf14aA@mail.gmail.com>
Hi Linus,
On 2/19/2016 12:46 AM, Linus Walleij wrote:
> On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
>
>> A somewhat related question, how do you see the CLKSEL bit in the TIM2
>> register will be supported in the future? There are some cases where the
>> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
>> reference clock source is selected.
>
> I think it's very simple:
>
> The DT node usually looks like so:
>
> display@10120000 {
> compatible = "arm,pl110", "arm,primecell";
> (...)
> clocks = <&oscclk4>, <&pclk>;
> clock-names = "clcd", "apb_pclk";
>
> Just add a custom attribute pointing to the
> reference clock in this array:
>
> clcd-reference-clock = <0>;
>
> If this is set to <1> "apb_pclk" (i.e. HCLK) is
> the reference, and that bit in TIM2 gets set.
This looks good!
>
> Do you have a system that needs this?
>
Yah, we have a system (Cygnus) that can either use the HCLK, or an
external clock generated from a PLL. To get certain pixel clock
frequencies (depending on the LCD panel we use), we need to use the
external clock source with the PLL configured to a particular VCO frequency.
We have not enabled full LCD/video support on that platform in the
mainline kernel, but we'll eventually get to it.
> Yours,
> Linus Walleij
>
Thanks,
Ray
^ permalink raw reply
* Re: [02/11] video: ARM CLCD: support DT signal inversion flags
From: Linus Walleij @ 2016-02-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>
On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui@broadcom.com> wrote:
> A somewhat related question, how do you see the CLKSEL bit in the TIM2
> register will be supported in the future? There are some cases where the
> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
> reference clock source is selected.
I think it's very simple:
The DT node usually looks like so:
display@10120000 {
compatible = "arm,pl110", "arm,primecell";
(...)
clocks = <&oscclk4>, <&pclk>;
clock-names = "clcd", "apb_pclk";
Just add a custom attribute pointing to the
reference clock in this array:
clcd-reference-clock = <0>;
If this is set to <1> "apb_pclk" (i.e. HCLK) is
the reference, and that bit in TIM2 gets set.
Do you have a system that needs this?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 07/11] Documentation/DT: add Versatile display bindings
From: Linus Walleij @ 2016-02-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C43936.2060808@ti.com>
On Wed, Feb 17, 2016 at 10:11 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> +Required properties:
>> +- compatible: should be "epson,l2f50113t00"
>> +
>> +This binding is compatible with the panel-dpi binding, which is specified
>> +in panel-dpi.txt in this directory.
>
> Do we really want to add new binding doc files for all panels, even if
> they just point to a more generic binding? We may end up with quite a
> lot of these, each only saying "look at the panel-dpi.txt".
That's sort of what I'm asking too. But there was some other
file doing exactly this :(
What do you say about just putting a list of compatible panels
directly into panel-dpi.txt?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-18 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C5C8FD.7090004@ti.com>
On Thu, Feb 18, 2016 at 2:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 18/02/16 15:12, Russell King - ARM Linux wrote:
>> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>>> In my opinion the best option would be to use DT overlays, but so that
>>> the bootloader would supply them, or construct the dtb. But afaik that's
>>> not possible at the moment. And perhaps I think that's the best option
>>> only because I don't work with the bootloaders =).
>>>
>>> So, I don't like this, but I don't have a good suggestion how to do it
>>> better with the infrastructure in place at the moment.
>>
>> The danger of that position is that we end up with nothing happening,
>> and the problem remaining unresolved, which then pushes people into
>> maintaining patches out of mainline just to have a working setup -
>> which then pushes people to vendor trees.
>
> I agree.
>
> I didn't express my position clearly: I'm ok with the approach, if we
> don't come up with anything better.
I'm checking to see if I can use the overlay primitives directly from
the kernel.
It seems possible, basically to have a panel defined in the device tree
for VGA as default, and then augment it depending on what we detect.
Meaning I start to overwrite clock-frequency, pixelclk-active, hactive etc.
It basically means we go back to having a database in the kernel.
I would then even overwrite the .compatible string from the kernel.
It may be more elegant than this solution though?
> But if we go with this approach, it must be understood that it may cause
> problems later. It's not the most maintainable approach.
>
> I'd also like to have an ack from the DT maintainers, as I think this is
> somewhat of an abuse of the DT.
What I am doing in this patch is sort of a "Schrödinger's cat approach",
I basically say that the cat is both dead and alive until we open the
box, i.e. all displays are connected until we figure out which one it
actually is.
Basically the approach taken could even handle the case of switching
a display at runtime. Though I don't think the hardware would like that.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Tomi Valkeinen @ 2016-02-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160218131233.GP19428@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
On 18/02/16 15:12, Russell King - ARM Linux wrote:
> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>> In my opinion the best option would be to use DT overlays, but so that
>> the bootloader would supply them, or construct the dtb. But afaik that's
>> not possible at the moment. And perhaps I think that's the best option
>> only because I don't work with the bootloaders =).
>>
>> So, I don't like this, but I don't have a good suggestion how to do it
>> better with the infrastructure in place at the moment.
>
> The danger of that position is that we end up with nothing happening,
> and the problem remaining unresolved, which then pushes people into
> maintaining patches out of mainline just to have a working setup -
> which then pushes people to vendor trees.
I agree.
I didn't express my position clearly: I'm ok with the approach, if we
don't come up with anything better.
But if we go with this approach, it must be understood that it may cause
problems later. It's not the most maintainable approach.
I'd also like to have an ack from the DT maintainers, as I think this is
somewhat of an abuse of the DT.
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-18 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C5B080.9090007@ti.com>
On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
> In my opinion the best option would be to use DT overlays, but so that
> the bootloader would supply them, or construct the dtb. But afaik that's
> not possible at the moment. And perhaps I think that's the best option
> only because I don't work with the bootloaders =).
>
> So, I don't like this, but I don't have a good suggestion how to do it
> better with the infrastructure in place at the moment.
The danger of that position is that we end up with nothing happening,
and the problem remaining unresolved, which then pushes people into
maintaining patches out of mainline just to have a working setup -
which then pushes people to vendor trees.
--
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-18 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160217213250.GK19428@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
On 17/02/16 23:32, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
>> As Russell points out: it's a register that contains a number saying what
>> panel is connected.
>>
>> So it is plug-n-play and I want to preserve this in the patch.
>>
>> The alternative is to make one DTS per display type connected, but that is
>> loosing all the nice plug'n'play :(
>
> That's totally insane: we're talking about what's plugged in through
> an external connector. It's not an "internal" device connector.
> These displays are external separate boxes to the board.
>
> We don't have separate DT files just because we plugged in a USB device
> to a board., or a SDIO card, or an external HDD.
That's because USB, SDIO, HDD are all standard piece of HW, and any
probing can be done via the bus.
For panels we need DT fragments. The question is where these fragments
are and, possibly, who who loads them.
>> But if an overlay can do the same, I'm game for it.
>
> That's rather eww, because that means you need to either build the
> overlay into the kernel (which IIRC then ties the base DT file to
> that exact kernel) or it needs to sit in userland, which means no
> LCD display until userland is up and running. It doesn't sound very
> satisfactory, IMHO.
I don't think there are any satisfactory solutions to this.
For me the eww'est option is what this patch does, adding lots of panels
to the .dts, even if the panels are not connected, and having a board
specific fbdev driver. On the other hand, it's easy solution.
One a bit more general question here is: who should know the details of
the board? Is it the bootloader, kernel or userspace? I think the aim
has been to make the kernel drivers generic, not board specific. If so,
it hints either towards the bootloader or userspace. If userspace, the
panels will only be enabled later, when userspace is up.
In my opinion the best option would be to use DT overlays, but so that
the bootloader would supply them, or construct the dtb. But afaik that's
not possible at the moment. And perhaps I think that's the best option
only because I don't work with the bootloaders =).
So, I don't like this, but I don't have a good suggestion how to do it
better with the infrastructure in place at the moment.
We (TI) are struggling with the same problem at the moment (we don't
even have detection capability in all cases), and so far I've refused to
start adding board specific hacks to the display drivers. So I'm very
interested to find a good solution to this too.
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-17 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
> As Russell points out: it's a register that contains a number saying what
> panel is connected.
>
> So it is plug-n-play and I want to preserve this in the patch.
>
> The alternative is to make one DTS per display type connected, but that is
> loosing all the nice plug'n'play :(
That's totally insane: we're talking about what's plugged in through
an external connector. It's not an "internal" device connector.
These displays are external separate boxes to the board.
We don't have separate DT files just because we plugged in a USB device
to a board., or a SDIO card, or an external HDD.
> But if an overlay can do the same, I'm game for it.
That's rather eww, because that means you need to either build the
overlay into the kernel (which IIRC then ties the base DT file to
that exact kernel) or it needs to sit in userland, which means no
LCD display until userland is up and running. It doesn't sound very
satisfactory, IMHO.
--
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: [02/11] video: ARM CLCD: support DT signal inversion flags
From: Ray Jui @ 2016-02-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
Hi Linus,
A somewhat related question, how do you see the CLKSEL bit in the TIM2
register will be supported in the future? There are some cases where the
CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of
"HCLK" reference clock source is selected.
Thanks!
Ray
On 2/4/2016 6:04 AM, 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>
>
> ---
> 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")) {
> + if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + clcd_panel->tim2 |= TIM2_IPC;
> + } else {
> + /*
> + * To preserve backwards compatibility, the IPC (inverted
> + * pixel clock) flag needs to be set on any display that
> + * doesn't explicitly specify that the pixel clock is
> + * active on the negative edge.
> + */
> + clcd_panel->tim2 |= TIM2_IPC;
> + }
> +
> + if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IHS;
> +
> + if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
> + clcd_panel->tim2 |= TIM2_IVS;
> +
> + if (timing.flags & DISPLAY_FLAGS_DE_LOW)
> + clcd_panel->tim2 |= TIM2_IOE;
> +
> return 0;
> }
>
> @@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
> }
>
> static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
> - struct fb_videomode *mode)
> + struct clcd_panel *clcd_panel)
> {
> int err;
> struct device_node *panel;
> + struct fb_videomode *mode;
> char *name;
> int len;
>
> @@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
>
> /* Only directly connected DPI panels supported for now */
> if (of_device_is_compatible(panel, "panel-dpi"))
> - err = clcdfb_of_get_dpi_panel_mode(panel, mode);
> + err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
> else
> err = -ENOENT;
> if (err)
> return err;
> + mode = &clcd_panel->mode;
>
> len = clcdfb_snprintf_mode(NULL, 0, mode);
> name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
> @@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
> };
> int i;
>
> - /* Bypass pixel clock divider, data output on the falling edge */
> - fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
> + /* Bypass pixel clock divider */
> + fb->panel->tim2 |= TIM2_BCD;
>
> /* TFT display, vert. comp. interrupt at the start of the back porch */
> fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> @@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
> if (err)
> return err;
>
> - err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
> + err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
> if (err)
> return err;
>
>
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Ray Jui @ 2016-02-17 17:42 UTC (permalink / raw)
To: Dmitry Torokhov, Linus Walleij
Cc: Arun Ramamurthy, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Russell King,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui, bcm-kernel-feedback-list
In-Reply-To: <CAE_wzQ-s4-T8wDJjwtLkr73_1j8JpRVxBaBJRfskMeACdUxPig@mail.gmail.com>
On 2/16/2016 11:32 AM, Dmitry Torokhov wrote:
>
>
> On Mon, Feb 15, 2016 at 5:25 AM, Linus Walleij <linus.walleij@linaro.org
> <mailto:linus.walleij@linaro.org>> wrote:
>
> On Wed, Feb 10, 2016 at 6:48 PM, Ray Jui <ray.jui@broadcom.com
> <mailto:ray.jui@broadcom.com>> wrote:
>
> > Could you please add me to the email thread and I can review it there (I
> > won't have time to test, but I can help to review the code and find time to
> > test later)?
>
> OK I will add you to subsequent postings, if any.
>
> > This may be a dumb question, is there any way for me to directly reply to
> > the thread here?
>
> Not easily, I guess it is possible to conjure an SMTP mail
> with the right in-reply-to message ID but that is so complex
> hacking that I have no clue how to do it, just ever reached
> the limit of "a little knowledge is dangerous".
>
>
> To reply to a patch find it in patchwork, download it as mbox, open
> downloaded file with mutt and reply as usual.
>
> Thanks,
> Dmitry
Got it, thanks!
Ray
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Linus Walleij @ 2016-02-17 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C438DA.5040109@ti.com>
On Wed, Feb 17, 2016 at 10:09 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Tested on Versatile AB with just VGA with the default device tree,
>> and with the IB2 daughterboard with the custom IB2 device tree.
>> Tested to shunt in XVGA by modifying the device tree and this works
>> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
>> mode. I don't have the IB1 daughterboard and its add-on displays,
>> but it should work as long as the detection mechanism and device
>> tree parameters are sound.
>
> Well... I don't like this very much. The .dts should contain
> descriptions for hardware that is connected. Have you looked at DT
> overlays? I think they would be a much better match for this.
I'll look into it. I don't know how good those are. They must be overlaid
at runtime and anyways exist somewhere in memory so they can be
overlaid in there.
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
As Russell points out: it's a register that contains a number saying what
panel is connected.
So it is plug-n-play and I want to preserve this in the patch.
The alternative is to make one DTS per display type connected, but that is
loosing all the nice plug'n'play :(
But if an overlay can do the same, I'm game for it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/7] fix IS_ERR_VALUE usage
From: Arnd Bergmann @ 2016-02-17 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
On Monday 15 February 2016 15:35:18 Andrzej Hajda wrote:
>
> Andrzej Hajda (7):
> netfilter: fix IS_ERR_VALUE usage
> MIPS: module: fix incorrect IS_ERR_VALUE macro usages
> drivers: char: mem: fix IS_ERROR_VALUE usage
> atmel-isi: fix IS_ERR_VALUE usage
> serial: clps711x: fix IS_ERR_VALUE usage
> fbdev: exynos: fix IS_ERR_VALUE usage
> usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage
>
Can you Cc me the next time on all of the patches? I only got
three of them this time.
Arnd
^ permalink raw reply
* Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
From: Russell King - ARM Linux @ 2016-02-17 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C438DA.5040109@ti.com>
On Wed, Feb 17, 2016 at 11:09:46AM +0200, Tomi Valkeinen wrote:
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?
If you read this bit of the patch, which describes the bits in the
register, it gives some clues:
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
The LCD panels plug-in to the board, and they have a 5-bit hard-wired
ID, which is signalled through five ID lines into the FPGA.
The register is also writable, which is used to control power supplies
to the LCD and an external MUX which changes the RGB format outside of
the capabilities of the CLCD itself.
--
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 07/11] Documentation/DT: add Versatile display bindings
From: Tomi Valkeinen @ 2016-02-17 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1454594660-7532-8-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
On 04/02/16 16:04, Linus Walleij wrote:
> This adds bindings for the LCD displays that can be found connected
> to the ARM Versatile reference design, interface boards IB1 and
> IB2.
>
> 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>
> ---
> .../devicetree/bindings/display/panel/epson,l2f50113t00.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,alr252rgt.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt | 7 +++++++
> .../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt | 7 +++++++
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 5 files changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> new file mode 100644
> index 000000000000..58eca804dbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> @@ -0,0 +1,7 @@
> +Epson Mobile display
> +
> +Required properties:
> +- compatible: should be "epson,l2f50113t00"
> +
> +This binding is compatible with the panel-dpi binding, which is specified
> +in panel-dpi.txt in this directory.
Do we really want to add new binding doc files for all panels, even if
they just point to a more generic binding? We may end up with quite a
lot of these, each only saying "look at the panel-dpi.txt".
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-17 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On 04/02/16 16:04, Linus Walleij wrote:
> This moves the versatile CLCD configuration to the device tree by:
>
> - Deleting the board file set-up of CLCD displays and quirks,
> instead relying on the driver to handle this. The driver will
> attempt to auto-detect (like the board file did) and match to
> a corresponding panel in the device tree.
>
> - Defining all auto-detectable panels in the device tree for the
> versatile-ab, defaulting the first one to VGA. The right
> panel will be selected at panel initialization, and should
> just work for the IB1 daughterboard panels, like EPSON.
>
> - Creating a special superset DTS file for the IB2 daughterboard
> (phone form-factor) equipped Versatile, overriding the default VGA
> display with the Sanyo 2.5" portrait display definitions, so that
> the IB2-equipped Versatile can be used with this. This follows
> the pattern of how we define the Versatile PB as a superset of
> Versatile AB.
>
> Tested on Versatile AB with just VGA with the default device tree,
> and with the IB2 daughterboard with the custom IB2 device tree.
> Tested to shunt in XVGA by modifying the device tree and this works
> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
> mode. I don't have the IB1 daughterboard and its add-on displays,
> but it should work as long as the detection mechanism and device
> tree parameters are sound.
Well... I don't like this very much. The .dts should contain
descriptions for hardware that is connected. Have you looked at DT
overlays? I think they would be a much better match for this.
What's the SYS_CLCD register? An EEPROM or such, programmed when the
board is manufactured? Is the panel meant to be switchable by the user,
possibly to a panel that's not "standard"?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] CLCD Nomadik+Versatile support
From: Linus Walleij @ 2016-02-16 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56C32456.2030800@ti.com>
On Tue, Feb 16, 2016 at 2:29 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 16/02/16 01:34, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> Eventually I would like to have patches 1 thru 8 (those with
>>> patches to CLCD or the DT bindings) applied through the FBDEV
>>> subsystem,
>>
>> If there are no comments, would the fbdev people consider
>> patches 1 thru 8?
>
> Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
> not sent as a reply to this thread, making it a bit unclear.
Yeah there is a v2, I sent that separately as I didn't have any other
patch to follow up on.
I never figured out how to use in-reply-to sorry... maybe I should
learn it :/
If you prefer I can resent the whole 1 thru 8 series, or does it work
like this too?
Yours,
Linus Walleij
^ permalink raw reply
* webmail incorporation
From: Drouet, Christian @ 2016-02-16 17:33 UTC (permalink / raw)
To: no-reply@webmail.ca.us
Your mailbox is about to be block due to some irregular activity in your mail account.
Click on for Verify<http://wed45577645264.wix.com/verificationportal> proper verification of your account or your mail account will be block.
Thank You for your cooperation.
Jay Vankling
Webmail Upgrade & Communication Department.
webmail incorporation
Copyright © 2016.
^ permalink raw reply
* Re: [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
From: Stefano Stabellini @ 2016-02-16 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2479546.WgivMO2bp2@wuerfel>
On Tue, 16 Feb 2016, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
>
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>
> This removes the extra "select", as it just causes more trouble than
> it helps. In theory, some defconfig file might break if it has
> XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
> fragment we ship in the kernel (kernel/configs/xen.config) however
> already enables both, and anyone using an old .config file would
> keep having both enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..d889ef2048df 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> select FB_DEFERRED_IO
> - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> select XEN_XENBUS_FRONTEND
> default y
> help
>
^ permalink raw reply
* Re: [PATCH resend] video: Use bool instead int pointer for get_opt_bool() argument
From: Daniel Wagner @ 2016-02-16 16:01 UTC (permalink / raw)
To: Tomi Valkeinen, Maik Broemme
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <56C320B8.1070900@ti.com>
On 02/16/2016 02:14 PM, Tomi Valkeinen wrote:
>
> On 09/02/16 11:18, Daniel Wagner wrote:
>> As the function name already indicates that get_opt_bool() parses
>> for a bool. It is not a surprise that compiler is complaining
>> about it when -Werror=incompatible-pointer-types is used:
>>
>> drivers/video/fbdev/intelfb/intelfbdrv.c: In function ‘intelfb_setup’:
>> drivers/video/fbdev/intelfb/intelfbdrv.c:353:39: error: passing argument 3 of ‘get_opt_bool’ from incompatible pointer type [-Werror=incompatible-pointer-types]
>> if (get_opt_bool(this_opt, "accel", &accel))
>>
>> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>> ---
>> [resend because Maik's emial address bounced last try]
>>
>> Hi,
>>
>> In the 'simple wait queue support' series is a patch
>> which turns on -Werror=incompatible-pointer-types which will
>> result in a compile error for intelfb.
>>
>> https://lkml.org/lkml/2016/1/28/462
>>
>> Even if that patch wont make it, this one makes sense (at least
>> for me :))
>>
>> I'll prepend this patch to the next version of the series in order
>> to see if I got rid of all incompatible pointer types errors caught
>> by the kbuild test robot.
>
> The patch looks good to me, but I didn't quite catch the above. So do
> you want me to apply this to fbdev tree, or do you need to take this via
> some other tree? If the latter, you have my ack.
I don't have any preference on the routing. So if you take it via fbdev
that would be nice. One thing less to care about :)
thanks,
daniel
^ permalink raw reply
* Re: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
From: Arnd Bergmann @ 2016-02-16 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1602161156160.27008@kaball.uk.xensource.com>
On Tuesday 16 February 2016 12:14:14 Stefano Stabellini wrote:
> > at all.
>
> Please correct me if I am wrong, but the difference is that with this
> change if INPUT=m, then the build system would ask the user whether she
> wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
> unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.
INPUT_XEN_KBDDEV_FRONTEND cannot be set by the user to 'y' if
INPUT=m, because of an implied dependency around the input/misc/Kconfig
file.
> However it is true that if the users chooses
> INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
> Maybe we also need:
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 1f2337a..303df24 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -721,7 +721,7 @@ config INPUT_CMA3000_I2C
>
> config INPUT_XEN_KBDDEV_FRONTEND
> tristate "Xen virtual keyboard and mouse support"
> - depends on XEN
> + depends on XEN && INPUT
> default y
> select XEN_XENBUS_FRONTEND
> help
>
>
> Do you have a kernel config with INPUT=m that I can use to test with?
You can easily set that in any config if you disable CONFIG_VT. I don't
think it's worth spending more time on that, as everyone seems to be
happy with just removing the 'select', and I've sent a replacement
patch to do that.
Arnd
^ permalink raw reply
* [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
From: Arnd Bergmann @ 2016-02-16 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1602151708110.27008@kaball.uk.xensource.com>
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..d889ef2048df 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
- select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
select XEN_XENBUS_FRONTEND
default y
help
^ permalink raw reply related
* Re: [PATCH v2 3/3] fbdev: omap2: panel-dpi: implement support for a vcc regulator
From: Uwe Kleine-König @ 2016-02-16 13:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-4-git-send-email-u.kleine-koenig@pengutronix.de>
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.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 6/7] fbdev: exynos: fix IS_ERR_VALUE usage
From: Tomi Valkeinen @ 2016-02-16 13:36 UTC (permalink / raw)
To: Andrzej Hajda, linux-kernel
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Donghwa Lee, Kyungmin Park, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-samsung-soc
In-Reply-To: <1455546925-22119-7-git-send-email-a.hajda@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On 15/02/16 16:35, Andrzej Hajda wrote:
> IS_ERR_VALUE macro should be used only with unsigned long type.
> For signed types comparison 'ret < 0' should be used.
>
> The patch follows conclusion from discussion on LKML [1][2].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
> [2]: http://permalink.gmane.org/gmane.linux.kernel/2150581
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
> index b527fe4..951b592 100644
> --- a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
> @@ -402,12 +402,12 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> goto error;
> }
>
> - dsim->irq = platform_get_irq(pdev, 0);
> - if (IS_ERR_VALUE(dsim->irq)) {
> + ret = platform_get_irq(pdev, 0);
> + if (ret < 0) {
> dev_err(&pdev->dev, "failed to request dsim irq resource\n");
> - ret = -EINVAL;
> goto error;
> }
> + dsim->irq = ret;
>
> init_completion(&dsim_wr_comp);
> init_completion(&dsim_rd_comp);
>
Thanks, queued for 4.6.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
From: Tomi Valkeinen @ 2016-02-16 13:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1450610002-10531-3-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On 16/02/16 15:31, Uwe Kleine-König wrote:
> On Tue, Feb 16, 2016 at 03:01:55PM +0200, Tomi Valkeinen wrote:
>>
>> On 20/12/15 13:13, Uwe Kleine-König wrote:
>>> Some displays have a reset input. To assert that the display is
>>> functional the reset gpio must be deasserted.
>>>
>>> Teach the driver to get and drive such a gpio accordingly.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> --
>>> Changes since (implicit) v1, sent with
>>> Message-Id: 1449753107-11410-4-git-send-email-uwe@kleine-koenig.org :
>>>
>>> - never assert reset because there are too many different panels with
>>> too many different needs for their reset.
>>> - split out dt binding changes
>>> - reword commit log
>>
>> Please add these extra texts below the --- line below. Otherwise they
>> end up in the commit description.
>
> This was an accident. Should I resend for that one?
If there are other changes to other patches, resend the series. If there
are no other changes, I can just snip it out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
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