* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Haojian Zhuang @ 2014-03-06 2:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
> a real bugfix that is needed since the misc code doesn't set
> file->private_data for us implicitly anymore.
>
> The rest are just straight-forward cleanups.
>
> Thanks,
> Daniel
>
>
> Daniel Mack (4):
> video: pxa3xx-gcu: rename some symbols
> video: pxa3xx-gcu: pass around struct device *
> video: pxa3xx-gcu: provide an empty .open call
> video: pxa3xx-gcu: switch to devres functions
>
> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
> 1 file changed, 81 insertions(+), 110 deletions(-)
>
> --
> 1.8.5.3
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tomi Valkeinen @ 2014-03-06 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
> Hi,
>
> Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Then there are the .dts patches, 22-30, for which I haven't been able to
get any acks. I'm not sure who I should get acks from for those, but I
don't mind adding yours if you want to give it.
The .dts patches have had minor changes compared to the ones posted
here, according to the DT bindings review comments, but nothing much has
changed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Geert Uytterhoeven @ 2014-03-06 8:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <5316E31F.9050308@ti.com>
On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>
>> That's rather a lot of compatible strings. Another possibility is:
>>
>> compatible = "dvi-connector";
>> analog;
>> digital;
>> single-link;
>> dual-link;
>
> I made the following changes compared to the posted version. I decided
> to leave the "single-link" out, as it's implied if "digital" is set.
>
> Tomi
>
> @@ -6,11 +6,16 @@ Required properties:
>
> Optional properties:
> - label: a symbolic name for the connector
> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +- analog: the connector has DVI analog pins
> +- digital: the connector has DVI digital pins
> +- dual-link: the connector has pins for DVI dual-link
>
> Required nodes:
> - Video port for DVI input
>
> +Note: One (or both) of 'analog' or 'digital' must be set.
So dual-link needs both "digital" and "dual-link"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-06 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux, Linux Fbdev development list,
DRI Development,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Philipp Zabel, Laurent Pinchart, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding, Daniel Vetter
In-Reply-To: <CAMuHMdWVSfKrudBhE7FW-ZWBvMOLWjrQZvn1qZUfRt_H+P7A2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> compatible = "dvi-connector";
>>> analog;
>>> digital;
>>> single-link;
>>> dual-link;
>>
>> I made the following changes compared to the posted version. I decided
>> to leave the "single-link" out, as it's implied if "digital" is set.
>>
>> Tomi
>>
>> @@ -6,11 +6,16 @@ Required properties:
>>
>> Optional properties:
>> - label: a symbolic name for the connector
>> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> +- analog: the connector has DVI analog pins
>> +- digital: the connector has DVI digital pins
>> +- dual-link: the connector has pins for DVI dual-link
>>
>> Required nodes:
>> - Video port for DVI input
>>
>> +Note: One (or both) of 'analog' or 'digital' must be set.
>
> So dual-link needs both "digital" and "dual-link"?
Yes. It is extra, but it felt clearer to me to have 'digital' as a
matching property for 'analog'.
Alternatively we could have three options:
analog;
digital-single-link;
digital-dual-link;
My reasoning to the format I chose was basically that when a connector
supports 'digital', it contains TMDS clock and TMDS data for link 1.
Adding dual link to that adds only TMDS data for link 2, so the second
data link is kind of an additional feature, marked with a flag.
Not a very big argument, and I'm fine with other format suggestions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 9:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>> a real bugfix that is needed since the misc code doesn't set
>> file->private_data for us implicitly anymore.
>>
>> The rest are just straight-forward cleanups.
>>
>> Thanks,
>> Daniel
>>
>>
>> Daniel Mack (4):
>> video: pxa3xx-gcu: rename some symbols
>> video: pxa3xx-gcu: pass around struct device *
>> video: pxa3xx-gcu: provide an empty .open call
>> video: pxa3xx-gcu: switch to devres functions
>>
>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>
> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Thanks Haojian!
Given that this driver doesn't actually have any connection points to
the framebuffer or video subsystem (despite its location) maybe you can
just take these patches through your pxa tree? It's a PXA3xx specific
device, after all. Jean-Christophe, Tomi - any objections?
The driver is also broken since awhile, and the fact that nobody noticed
tells me that our platform is most probably the only real user.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Haojian Zhuang @ 2014-03-06 9:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On Thu, Mar 6, 2014 at 5:09 PM, Daniel Mack <zonque@gmail.com> wrote:
> On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
>> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>>> a real bugfix that is needed since the misc code doesn't set
>>> file->private_data for us implicitly anymore.
>>>
>>> The rest are just straight-forward cleanups.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> Daniel Mack (4):
>>> video: pxa3xx-gcu: rename some symbols
>>> video: pxa3xx-gcu: pass around struct device *
>>> video: pxa3xx-gcu: provide an empty .open call
>>> video: pxa3xx-gcu: switch to devres functions
>>>
>>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>>
>
>> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> Thanks Haojian!
>
> Given that this driver doesn't actually have any connection points to
> the framebuffer or video subsystem (despite its location) maybe you can
> just take these patches through your pxa tree? It's a PXA3xx specific
> device, after all. Jean-Christophe, Tomi - any objections?
>
If Jean or Tomi acked on this series, I can merge them into my pxa tree.
Best Regards
Haojian
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-06 9:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
On 06/03/14 11:09, Daniel Mack wrote:
> On 03/06/2014 03:09 AM, Haojian Zhuang wrote:
>> On Thu, Mar 6, 2014 at 12:12 AM, Daniel Mack <zonque@gmail.com> wrote:
>>> Here are some cleanups for the pxa3xx-gcu driver. Patch 3/4 is actually
>>> a real bugfix that is needed since the misc code doesn't set
>>> file->private_data for us implicitly anymore.
>>>
>>> The rest are just straight-forward cleanups.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> Daniel Mack (4):
>>> video: pxa3xx-gcu: rename some symbols
>>> video: pxa3xx-gcu: pass around struct device *
>>> video: pxa3xx-gcu: provide an empty .open call
>>> video: pxa3xx-gcu: switch to devres functions
>>>
>>> drivers/video/pxa3xx-gcu.c | 191 +++++++++++++++++++--------------------------
>>> 1 file changed, 81 insertions(+), 110 deletions(-)
>>>
>
>> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> Thanks Haojian!
>
> Given that this driver doesn't actually have any connection points to
> the framebuffer or video subsystem (despite its location) maybe you can
> just take these patches through your pxa tree? It's a PXA3xx specific
> device, after all. Jean-Christophe, Tomi - any objections?
>
> The driver is also broken since awhile, and the fact that nobody noticed
> tells me that our platform is most probably the only real user.
If these do not have any dependencies to non-fbdev patches, and nothing
else has dependencies to these patches, I'd rather take them via fbdev
tree, based on the file location. There shouldn't be any conflicts, but
just in case...
As a side note, I've got a drivers/video/ reorg patch series, possibly
headed for v3.15, which moves the pxa3xx-gcu file to
drivers/video/fbdev/. That's clearly not the right place for it, but I
think it's easier to move it along the other files, and later move it
back to drivers/video/.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: Remove redundant NULL check in uvesafb_remove
From: Tomi Valkeinen @ 2014-03-06 9:31 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, linux-fbdev, linux-kernel, fengguang.wu
In-Reply-To: <20140305155418.GA32106@udknight>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On 05/03/14 17:54, Wang YanQing wrote:
> Because uvesafb_par is allocated as part of fb_info in uvesafb_probe,
> so we don't need to do NULL check for both fb_info and uvesafb_par in
> uvesafb_remove.
>
> [ This patch also fix a warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:1815 uvesafb_remove()
> warn: variable dereferenced before check 'par'" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 1f38445..18352b2 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1812,11 +1812,9 @@ static int uvesafb_remove(struct platform_device *dev)
> fb_destroy_modedb(info->monspecs.modedb);
> fb_dealloc_cmap(&info->cmap);
>
> - if (par) {
> - kfree(par->vbe_modes);
> - kfree(par->vbe_state_orig);
> - kfree(par->vbe_state_saved);
> - }
> + kfree(par->vbe_modes);
> + kfree(par->vbe_state_orig);
> + kfree(par->vbe_state_saved);
>
> framebuffer_release(info);
> }
>
Thanks, queuing for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: Remove impossible code path in uvesafb_init_info
From: Tomi Valkeinen @ 2014-03-06 9:32 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <20140305155619.GA32166@udknight>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
On 05/03/14 17:56, Wang YanQing wrote:
> Because uvesafb_vbe_init will fail when get zero avaiable modes,
> and we have checked the return value of uvesafb_vbe_init_mode,
> so it is impossible to pass NULL as mode into uvesafb_init_info.
>
> [ This patch fix warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:1509 uvesafb_init_info()
> error: we previously assumed 'mode' could be null" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 18352b2..509d452 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1474,12 +1474,7 @@ static void uvesafb_init_info(struct fb_info *info, struct vbe_mode_ib *mode)
> * used video mode, i.e. the minimum amount of
> * memory we need.
> */
> - if (mode != NULL) {
> - size_vmode = info->var.yres * mode->bytes_per_scan_line;
> - } else {
> - size_vmode = info->var.yres * info->var.xres *
> - ((info->var.bits_per_pixel + 7) >> 3);
> - }
> + size_vmode = info->var.yres * mode->bytes_per_scan_line;
>
> /*
> * size_total -- all video memory we have. Used for mtrr
>
Thanks, queuing for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: use CONFIG_X86_PAE surround _PAGE_NX check code
From: Tomi Valkeinen @ 2014-03-06 9:56 UTC (permalink / raw)
To: Wang YanQing; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <20140305161611.GA32461@udknight>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On 05/03/14 18:16, Wang YanQing wrote:
> Because _PAGE_NX check will always false when we don't define
> CONFIG_X86_PAE for CONFIG_X86_32, so use CONFIG_X86_PAE surround
> the check code.
>
> Although I believe "smart" compile will optimize out and generate
> the same code, but use CONFIG_X86_PAE surround check code will
> clear it and prohibit warning from static source code analyze tool.
>
> [ This patch fix warning report by fengguang.wu@intel.com
> "drivers/video/fbdev/uvesafb.c:816 uvesafb_vbe_init()
> warn: bitwise AND condition is false here" ]
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 509d452..102858c 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -813,6 +813,7 @@ static int uvesafb_vbe_init(struct fb_info *info)
> par->ypan = ypan;
>
> if (par->pmi_setpal || par->ypan) {
> +#ifdef CONFIG_X86_PAE
> if (__supported_pte_mask & _PAGE_NX) {
> par->pmi_setpal = par->ypan = 0;
> printk(KERN_WARNING "uvesafb: NX protection is active, "
> @@ -820,6 +821,9 @@ static int uvesafb_vbe_init(struct fb_info *info)
> } else {
> uvesafb_vbe_getpmi(task, par);
> }
> +#else
> + uvesafb_vbe_getpmi(task, par);
> +#endif
> }
I don't like this, I think this makes the code more messy, just to avoid
that warning.
And it might even be buggy. For your patch to work correctly, you need
to know the internals of _PAGE_NX, i.e. that when CONFIG_X86_PAE is not
defined, _PAGE_NX is 0. But the driver should not depend on things like
that. If _PAGE_NX is changed later, the driver will not work correctly.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 10:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 10:23 AM, Tomi Valkeinen wrote:
> On 06/03/14 11:09, Daniel Mack wrote:
>> Given that this driver doesn't actually have any connection points to
>> the framebuffer or video subsystem (despite its location) maybe you can
>> just take these patches through your pxa tree? It's a PXA3xx specific
>> device, after all. Jean-Christophe, Tomi - any objections?
>>
>> The driver is also broken since awhile, and the fact that nobody noticed
>> tells me that our platform is most probably the only real user.
>
> If these do not have any dependencies to non-fbdev patches, and nothing
> else has dependencies to these patches, I'd rather take them via fbdev
> tree, based on the file location. There shouldn't be any conflicts, but
> just in case...
Ok for me. I really don't mind :)
> As a side note, I've got a drivers/video/ reorg patch series, possibly
> headed for v3.15, which moves the pxa3xx-gcu file to
> drivers/video/fbdev/.
Ah, ok. So then they really better go via your tree then.
> That's clearly not the right place for it, but I
> think it's easier to move it along the other files, and later move it
> back to drivers/video/.
Maybe it might be worth adding a subdirectory for hardware accelerators?
Because this is what the pxa3xx-gcu thing is all about really. And it's
only a tiny transport layer that passed commands between the hardware
block and a DirectFB userspace driver.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-06 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394036606-17784-1-git-send-email-pawel.moll@arm.com>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Hi Pawel,
On 05/03/14 18:23, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
Is this an old HW, and presumably there won't be new users for it? If
yes, this is probably fine. If not, you might want to look at the video
ports and endpoints, which is used by at least three not-yet-merged series:
[PATCHv3 00/41] OMAPDSS: DT support v3
[PATCH v5 00/11] imx-drm dt bindings
[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
Using bindings like that would be more future proof, even if the current
driver doesn't use them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-06 10:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On 06/03/14 12:18, Daniel Mack wrote:
>> As a side note, I've got a drivers/video/ reorg patch series, possibly
>> headed for v3.15, which moves the pxa3xx-gcu file to
>> drivers/video/fbdev/.
>
> Ah, ok. So then they really better go via your tree then.
Git should handle it fine, so it's not mandatory here. Still, I'd rather
have them via fbdev tree.
>> That's clearly not the right place for it, but I
>> think it's easier to move it along the other files, and later move it
>> back to drivers/video/.
>
> Maybe it might be worth adding a subdirectory for hardware accelerators?
> Because this is what the pxa3xx-gcu thing is all about really. And it's
> only a tiny transport layer that passed commands between the hardware
> block and a DirectFB userspace driver.
Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
I mean the word "gpu" sounds like a good match. I'm not sure if other
people have opinions on what drivers/gpu/ should contain, though.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: uvesafb: use CONFIG_X86_PAE surround _PAGE_NX check code
From: Wang YanQing @ 2014-03-06 10:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: plagnioj, fengguang.wu, linux-fbdev, linux-kernel
In-Reply-To: <53184655.2090106@ti.com>
On Thu, Mar 06, 2014 at 11:56:37AM +0200, Tomi Valkeinen wrote:
> I don't like this, I think this makes the code more messy, just to avoid
> that warning.
>
> And it might even be buggy. For your patch to work correctly, you need
> to know the internals of _PAGE_NX, i.e. that when CONFIG_X86_PAE is not
> defined, _PAGE_NX is 0. But the driver should not depend on things like
> that. If _PAGE_NX is changed later, the driver will not work correctly.
>
Very right! Thanks.
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Daniel Mack @ 2014-03-06 10:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
On 03/06/2014 11:30 AM, Tomi Valkeinen wrote:
> On 06/03/14 12:18, Daniel Mack wrote:
>>> That's clearly not the right place for it, but I
>>> think it's easier to move it along the other files, and later move it
>>> back to drivers/video/.
>>
>> Maybe it might be worth adding a subdirectory for hardware accelerators?
>> Because this is what the pxa3xx-gcu thing is all about really. And it's
>> only a tiny transport layer that passed commands between the hardware
>> block and a DirectFB userspace driver.
>
> Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
> I mean the word "gpu" sounds like a good match. I'm not sure if other
> people have opinions on what drivers/gpu/ should contain, though.
Yes, you're right. Do you think we should do that in a 2nd step maybe,
after 3.15?
Daniel
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-06 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
dri-devel@lists.freedesktop.org, Ingo Molnar
In-Reply-To: <531465FF.1000201@ti.com>
Hi Tomi
On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 03/03/14 13:09, David Herrmann wrote:
>
>>> What do you think, would it be possible to keep the sysfb stuff in
>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>> move the sysfs from arch/x86 to drivers/video later?
>>
>> I don't think there's any need for that. Linus does conflict
>> resolution all day long, so a short hint in Dave's pull-request (plus
>> an example merge) should be enough. Same is true for -next, I think.
>
> True, but, well, the conflict with this one is not a few lines. "git
> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
> to resolve that one, though, as it's really about copying all the stuff
> into its new place.
>
> So I'm not sure if that makes Linus think "this is simple one, 30 secs
> and done" or "who the f*** sends me this crap" ;). Especially for two
> reasons:
>
> - The fb-reogranization is not very critical, and often clean-ups are
> not worth it (although I think this one is good one, of course).
> - Conflicting fbdev changes coming from another tree
>
>> And this is really just a mechanical thing, nothing hard to do. But of
>> course, it's your decision. However, keeping the code in x86 is the
>> wrong thing to do. As discussed with Ingo, the patch that extends
>
> Yes, I didn't mean keeping the code in x86 for good, but just for one
> kernel version to make merging easier.
>
>> x86/sysfb is only provided for easier backporting. The followup patch
>> immediately removes it again and adds proper video/sysfb. I'd dislike
>> splitting these just to avoid merge conflicts. I can also maintain a
>> merge-fixup branch in my tree, if anyone wants that.
>
> You can have a try at merging. If you think it's trivial, maybe it is
> and we can just let Linus handle it:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
> work/fb-reorder
Ok, I'm fine with delaying this one more merge-window. However, to
make things easier, could you pick up the two fbdev cleanups? These
are:
fbdev: efifb: add dev->remove() callback
fbdev: vesafb: add dev->remove() callback
They only add ->remove() callbacks which are never triggered currently
except with my sysfb series. But I'd like to drop both to make the
series smaller.
Thanks
David
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-03-06 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53184C2E.3000807@ti.com>
On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
> Is this an old HW, and presumably there won't be new users for it? If
> yes, this is probably fine.
There is a DRM driver in the works, actually...
> If not, you might want to look at the video
> ports and endpoints, which is used by at least three not-yet-merged series:
>
> [PATCHv3 00/41] OMAPDSS: DT support v3
> [PATCH v5 00/11] imx-drm dt bindings
> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>
> Using bindings like that would be more future proof, even if the current
> driver doesn't use them.
... and this makes me try to get out of its way. In other words, I fully
agree with you, but I don't think this applies to this particular patch,
as I'm not even trying to represent the display pipeline. The (optional)
"display-timings" sub-node has been "borrowed" from other older drivers
and can be easily deprecated in the future, replaced by standard ones
(whatever final shape they will take :-). All other extra properties are
CLCD-specific and orthogonal.
Pawel
^ permalink raw reply
* [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:14 UTC (permalink / raw)
To: linux-kernel
Cc: Geert Uytterhoeven, linux-fbdev, Tomi Valkeinen, Andrew Morton,
Greg Kroah-Hartman, David Herrmann
Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
aren't checked by most higher-level options.
It's a relict of the times when fonts where exclusive to the VT layer and
fbcon.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
lib/fonts/Kconfig | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 4dc1b99..0ca66a3 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -9,7 +9,6 @@ if FONT_SUPPORT
config FONTS
bool "Select compiled-in fonts"
- depends on FRAMEBUFFER_CONSOLE
help
Say Y here if you would like to use fonts other than the default
your frame buffer console usually use.
@@ -22,7 +21,6 @@ config FONTS
config FONT_8x8
bool "VGA 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
@@ -45,7 +43,6 @@ config FONT_8x16
config FONT_6x11
bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && MAC
help
Small console font with Macintosh-style high-half glyphs. Some Mac
@@ -53,7 +50,6 @@ config FONT_6x11
config FONT_7x14
bool "console 7x14 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
Console font with characters just a bit smaller than the default.
If the standard 8x16 font is a little too big for you, say Y.
@@ -61,7 +57,6 @@ config FONT_7x14
config FONT_PEARL_8x8
bool "Pearl (old m68k) console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && AMIGA
help
Small console font with PC-style control-character and high-half
@@ -69,7 +64,6 @@ config FONT_PEARL_8x8
config FONT_ACORN_8x8
bool "Acorn console 8x8 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE
default y if !SPARC && !FONTS && ARM && ARCH_ACORN
help
Small console font with PC-style control characters and high-half
@@ -81,13 +75,13 @@ config FONT_MINI_4x6
config FONT_SUN8x16
bool "Sparc console 8x16 font"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines. Say Y.
config FONT_SUN12x22
bool "Sparc console 12x22 font (not supported by all drivers)"
- depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
+ depends on !SPARC && FONTS || SPARC
help
This is the high resolution console font for Sun machines with very
big letters (like the letters used in the SPARC PROM). If the
@@ -95,7 +89,6 @@ config FONT_SUN12x22
config FONT_10x18
bool "console 10x18 font (not supported by all drivers)" if FONTS
- depends on FRAMEBUFFER_CONSOLE
help
This is a high resolution console font for machines with very
big letters. It fits between the sun 12x22 and the normal 8x16 font.
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:39 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <1394187271-5857-1-git-send-email-dh.herrmann@gmail.com>
On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
> aren't checked by most higher-level options.
CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
which fonts to include by default. No dependencies are bypassed by the select.
Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
have FRAMEBUFFER_CONSOLE set, but have set any of these:
config EARLY_PRINTK_EFI
select FONT_SUPPORT
config VIDEO_VIVI
select FONT_SUPPORT
select FONT_8x16
config SOLO6X10
select FONT_SUPPORT
select FONT_8x16
config USB_SISUSBVGA
select FONT_SUPPORT
...
select FONT_8x16
config SGI_NEWPORT_CONSOLE
select FONT_SUPPORT
config STI_CONSOLE
select FONT_SUPPORT
will now get more (unused) fonts in their kernel image.
> It's a relict of the times when fonts where exclusive to the VT layer and
> fbcon.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> lib/fonts/Kconfig | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
> index 4dc1b99..0ca66a3 100644
> --- a/lib/fonts/Kconfig
> +++ b/lib/fonts/Kconfig
> @@ -9,7 +9,6 @@ if FONT_SUPPORT
>
> config FONTS
> bool "Select compiled-in fonts"
> - depends on FRAMEBUFFER_CONSOLE
> help
> Say Y here if you would like to use fonts other than the default
> your frame buffer console usually use.
> @@ -22,7 +21,6 @@ config FONTS
>
> config FONT_8x8
> bool "VGA 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> @@ -45,7 +43,6 @@ config FONT_8x16
>
> config FONT_6x11
> bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && MAC
> help
> Small console font with Macintosh-style high-half glyphs. Some Mac
> @@ -53,7 +50,6 @@ config FONT_6x11
>
> config FONT_7x14
> bool "console 7x14 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> Console font with characters just a bit smaller than the default.
> If the standard 8x16 font is a little too big for you, say Y.
> @@ -61,7 +57,6 @@ config FONT_7x14
>
> config FONT_PEARL_8x8
> bool "Pearl (old m68k) console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && AMIGA
> help
> Small console font with PC-style control-character and high-half
> @@ -69,7 +64,6 @@ config FONT_PEARL_8x8
>
> config FONT_ACORN_8x8
> bool "Acorn console 8x8 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> default y if !SPARC && !FONTS && ARM && ARCH_ACORN
> help
> Small console font with PC-style control characters and high-half
> @@ -81,13 +75,13 @@ config FONT_MINI_4x6
>
> config FONT_SUN8x16
> bool "Sparc console 8x16 font"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines. Say Y.
>
> config FONT_SUN12x22
> bool "Sparc console 12x22 font (not supported by all drivers)"
> - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)
> + depends on !SPARC && FONTS || SPARC
> help
> This is the high resolution console font for Sun machines with very
> big letters (like the letters used in the SPARC PROM). If the
> @@ -95,7 +89,6 @@ config FONT_SUN12x22
>
> config FONT_10x18
> bool "console 10x18 font (not supported by all drivers)" if FONTS
> - depends on FRAMEBUFFER_CONSOLE
> help
> This is a high resolution console font for machines with very
> big letters. It fits between the sun 12x22 and the normal 8x16 font.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdVxE2jXQE11swi8sM251GcWcdDYpgE37pCoxpb7oF1-Rg@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:39 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
>> Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
>> aren't checked by most higher-level options.
>
> CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
> which fonts to include by default. No dependencies are bypassed by the select.
Indeed, I missed that, sorry.
> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>
> config EARLY_PRINTK_EFI
> select FONT_SUPPORT
>
> config VIDEO_VIVI
> select FONT_SUPPORT
> select FONT_8x16
>
> config SOLO6X10
> select FONT_SUPPORT
> select FONT_8x16
>
> config USB_SISUSBVGA
> select FONT_SUPPORT
> ...
> select FONT_8x16
>
> config SGI_NEWPORT_CONSOLE
> select FONT_SUPPORT
>
> config STI_CONSOLE
> select FONT_SUPPORT
>
> will now get more (unused) fonts in their kernel image.
Why would they get more unused fonts? All those fonts are "default n"
(except for some arch-specific stuff and 8x8 and obviously 8x16). I
don't mind if we drop this, but it makes font-selection impossible if
fbcon is disabled, which is kinda unexpected.
Thanks
David
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 10:54 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SbA5jCh+5UqyJ=oxdiYdbfkUcfrbB=jGjKRZJ-LAuaXg@mail.gmail.com>
On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>
>> config EARLY_PRINTK_EFI
>> select FONT_SUPPORT
>>
>> config VIDEO_VIVI
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config SOLO6X10
>> select FONT_SUPPORT
>> select FONT_8x16
>>
>> config USB_SISUSBVGA
>> select FONT_SUPPORT
>> ...
>> select FONT_8x16
>>
>> config SGI_NEWPORT_CONSOLE
>> select FONT_SUPPORT
>>
>> config STI_CONSOLE
>> select FONT_SUPPORT
>>
>> will now get more (unused) fonts in their kernel image.
>
> Why would they get more unused fonts? All those fonts are "default n"
> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
So they get the 8x8 and the arch-specific ones by default (FONTS=n).
> don't mind if we drop this, but it makes font-selection impossible if
> fbcon is disabled, which is kinda unexpected.
IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
the driver, so allowing to select more fonts doesn't gain anything for them.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: David Herrmann @ 2014-03-07 10:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CAMuHMdUheaE00m289h=x0gxf+PAbPjhhdAKATAHGgOgk9YROVQ@mail.gmail.com>
Hi
On Fri, Mar 7, 2014 at 11:54 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>>
>>> config EARLY_PRINTK_EFI
>>> select FONT_SUPPORT
>>>
>>> config VIDEO_VIVI
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config SOLO6X10
>>> select FONT_SUPPORT
>>> select FONT_8x16
>>>
>>> config USB_SISUSBVGA
>>> select FONT_SUPPORT
>>> ...
>>> select FONT_8x16
>>>
>>> config SGI_NEWPORT_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> config STI_CONSOLE
>>> select FONT_SUPPORT
>>>
>>> will now get more (unused) fonts in their kernel image.
>>
>> Why would they get more unused fonts? All those fonts are "default n"
>> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
>
> So they get the 8x8 and the arch-specific ones by default (FONTS=n).
They also get it if they enable FRAMEBUFFER_CONSOLE (which most people
do, right?). I don't understand why we want multiple fonts compiled-in
at all, but ok, that's not up to me.
>> don't mind if we drop this, but it makes font-selection impossible if
>> fbcon is disabled, which is kinda unexpected.
>
> IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
> the driver, so allowing to select more fonts doesn't gain anything for them.
I don't. I use get_default_font() in the new drm_log.c patches.
Anyhow, I'm fine with 8x16, I just thought people might want to select
other fonts. But I guess it's up to them to deal with that, as long as
I use get_default_font() I guess I don't care.
Feel free to drop this patch then.
Thanks
David
^ permalink raw reply
* Re: [PATCH] lib: remove FBCON dependency for fonts
From: Geert Uytterhoeven @ 2014-03-07 11:17 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel@vger.kernel.org, Linux Fbdev development list,
Tomi Valkeinen, Andrew Morton, Greg Kroah-Hartman
In-Reply-To: <CANq1E4RehTJRG=5WEP42-R1AXzFOdFNF953Gh94Rjum=QgxHQQ@mail.gmail.com>
On Fri, Mar 7, 2014 at 11:58 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Fri, Mar 7, 2014 at 11:54 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Fri, Mar 7, 2014 at 11:47 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> Without the "depends on FRAMEBUFFER_CONSOLE", people who don't
>>>> have FRAMEBUFFER_CONSOLE set, but have set any of these:
>>>>
>>>> config EARLY_PRINTK_EFI
>>>> select FONT_SUPPORT
>>>>
>>>> config VIDEO_VIVI
>>>> select FONT_SUPPORT
>>>> select FONT_8x16
>>>>
>>>> config SOLO6X10
>>>> select FONT_SUPPORT
>>>> select FONT_8x16
>>>>
>>>> config USB_SISUSBVGA
>>>> select FONT_SUPPORT
>>>> ...
>>>> select FONT_8x16
>>>>
>>>> config SGI_NEWPORT_CONSOLE
>>>> select FONT_SUPPORT
>>>>
>>>> config STI_CONSOLE
>>>> select FONT_SUPPORT
>>>>
>>>> will now get more (unused) fonts in their kernel image.
>>>
>>> Why would they get more unused fonts? All those fonts are "default n"
>>> (except for some arch-specific stuff and 8x8 and obviously 8x16). I
>>
>> So they get the 8x8 and the arch-specific ones by default (FONTS=n).
>
> They also get it if they enable FRAMEBUFFER_CONSOLE (which most people
> do, right?). I don't understand why we want multiple fonts compiled-in
I was more thinking of the CONFIG_FB=n case.
> at all, but ok, that's not up to me.
Frame buffer users may do so.
>>> don't mind if we drop this, but it makes font-selection impossible if
>>> fbcon is disabled, which is kinda unexpected.
>>
>> IIRC, drivers that "select FONT_8x16" have the font name hardcoded in
>> the driver, so allowing to select more fonts doesn't gain anything for them.
>
> I don't. I use get_default_font() in the new drm_log.c patches.
Good ;-)
> Anyhow, I'm fine with 8x16, I just thought people might want to select
> other fonts. But I guess it's up to them to deal with that, as long as
> I use get_default_font() I guess I don't care.
If you want to allow people to select more fonts, you can drop the "depends on
FRAMEBUFFER_CONSOLE" for "config FONTS", and move the dependency
for the individual fonts into the "default y if" clause, right?
E.g.
config FONT_6x11
bool "Mac console 6x11 font (not supported by all drivers)" if FONTS
default y if !SPARC && !FONTS && MAC && FRAMEBUFFER_CONSOLE
help
(one more cleanup: several of the "!SPARC" can be removed, as they're
implied by e.g. "MAC" and "ARM").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [patch -resend] sisfb: fix 1280x720 resolution support
From: Dan Carpenter @ 2014-03-07 11:18 UTC (permalink / raw)
To: linux-fbdev
It uses the wrong mode index because there is no break statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index 4f26bc28e60b..bd40f5ecd901 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
switch(VDisplay) {
case 720:
ModeIndex = ModeIndex_1280x720[Depth];
+ break;
case 768:
if(VGAEngine = SIS_300_VGA) {
ModeIndex = ModeIndex_300_1280x768[Depth];
^ permalink raw reply related
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-07 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394119431.4160.84.camel@hornet>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
On 06/03/14 17:23, Pawel Moll wrote:
> On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
>> Is this an old HW, and presumably there won't be new users for it? If
>> yes, this is probably fine.
>
> There is a DRM driver in the works, actually...
>
>> If not, you might want to look at the video
>> ports and endpoints, which is used by at least three not-yet-merged series:
>>
>> [PATCHv3 00/41] OMAPDSS: DT support v3
>> [PATCH v5 00/11] imx-drm dt bindings
>> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>>
>> Using bindings like that would be more future proof, even if the current
>> driver doesn't use them.
>
> ... and this makes me try to get out of its way. In other words, I fully
> agree with you, but I don't think this applies to this particular patch,
> as I'm not even trying to represent the display pipeline. The (optional)
Right, you are not, at the moment. My point was, if the driver is
extended later to support pipelines, or common panel/encoder drivers,
you (most likely) need to have similar bindings than the other people use.
Note that the same DT bindings you add here should also work for the DRM
driver in the future. So, in fact, the question is extended to: will the
fbdev or drm driver support common panels/encoders?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 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