* Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2011-03-22 8:20 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, Randy Dunlap, linuxppc-dev,
Wolfgang Denk
In-Reply-To: <4D81A668.8060500@denx.de>
On Thu, Mar 17, 2011 at 07:12:56AM +0100, Heiko Schocher wrote:
> Paul Mundt schrieb:
> > On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote:
> >>> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission.
> >>>
> >>> Documentation/powerpc/dts-bindings/sm501.txt | 34 +++++++++++++++++++++
> >>> drivers/mfd/sm501.c | 9 +++++-
> >>> drivers/video/sm501fb.c | 42 ++++++++++++++++++++++++--
> >>> 3 files changed, 81 insertions(+), 4 deletions(-)
> >>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
> >> This patchset is pending know for a while. I got Acked by from
> >>
> >> Samuel Ortiz for the mfd part, see here:
> >>
> >> http://www.spinics.net/lists/linux-fbdev/msg02550.html
> >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html
> >>
> >> and for the DTS part from Benjamin Herrenschmidt:
> >>
> >> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html
> >>
> >> Are there some more issues?
> >>
> > Not that I remember off the top of my head, but I think they've been lost
> > in my backlog. Could you re-send the current series with the appropriate
> > acked-bys? If there's nothing else obvious outstanding I'll roll them in.
>
> Ok, I resend them (I also rebase them to current tree, ok?)
>
Ok, I've dug them up on l-k in the meantime and applied 1-3. 4/4 doesn't
apply due to a missing dts file, but I assume you're aware of that and
will take care of it separately. Let me know if I've overlooked anything,
and sorry for the delay!
^ permalink raw reply
* Re: [patch v2] fbdev: sh_mobile_lcdc: checking NULL instead of IS_ERR()
From: Paul Mundt @ 2011-03-22 7:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110321150313.GQ2008@bicker>
On Mon, Mar 21, 2011 at 06:03:13PM +0300, Dan Carpenter wrote:
> backlight_device_register() returns an ERR_PTR. It doesn't return NULL.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> V2: print the error code as well.
> This patch is againts linux-next, in case you missed that earlier.
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/5] s3fb: various changes
From: Paul Mundt @ 2011-03-22 6:51 UTC (permalink / raw)
To: Ondrej Zary, David S. Miller
Cc: Ondrej Zajicek, linux-fbdev, Kernel development list
In-Reply-To: <201103012018.01607.linux@rainbow-software.org>
On Tue, Mar 01, 2011 at 08:17:59PM +0100, Ondrej Zary wrote:
> This patch set adds new hardware support, fixes some display problems and also
> improves performance of s3fb driver.
>
> Everything was tested on various Trio32, Trio64V+, Trio64V2/DX, Virge,
> Virge/DX, Trio3D and Trio3D/2X cards.
>
> It assumes that David Miller's "Make SVGA oriented FBs work on multi-domain
> PCI" patch set is applied.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
Both series are now applied.
^ permalink raw reply
* Re: [PATCH 06/13] omap: use list_move() instead of list_del()/list_add() combination
From: Paul Mundt @ 2011-03-22 6:14 UTC (permalink / raw)
To: Tomi Valkeinen, Kirill A. Shutemov
Cc: linux-kernel@vger.kernel.org, Tomi Valkeinen,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
Tejun Heo
In-Reply-To: <1300275829.1917.94.camel@lappyti>
On Wed, Mar 16, 2011 at 05:13:49PM +0530, Tomi Valkeinen wrote:
> On Tue, 2011-03-15 at 17:53 -0500, Kirill A. Shutemov wrote:
> > Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
> > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: linux-omap@vger.kernel.org
> > ---
> > drivers/video/omap/blizzard.c | 3 +--
> > drivers/video/omap/hwa742.c | 3 +--
> > 2 files changed, 2 insertions(+), 4 deletions(-)
>
> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On Wed, Mar 16, 2011 at 12:53:19AM +0200, Kirill A. Shutemov wrote:
> Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/vermilion/vermilion.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
Both applied, thanks.
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Tomi Valkeinen @ 2011-03-22 5:55 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <20110322054049.GB25925@linux-sh.org>
On Tue, 2011-03-22 at 00:40 -0500, Paul Mundt wrote:
> On Mon, Mar 21, 2011 at 11:51:23AM +0200, Tomi Valkeinen wrote:
> > One problem I noticed just now, the committer names seem a bit messed
> > up. For example, Archit Taneja has three different style names there. Do
> > you think I should rebase and fix them? Not a big job, but it'll mean,
> > well, rebasing.
> >
> No need, this is what .mailmap is for. It seems there are quite a few
> variations, I've added entries now for all of:
>
> Archit Taneja <archit@ti.com>
> Mayuresh Janorkar <mayur@ti.com>
> Mythri P K <mythripk@ti.com>
> Sumit Semwal <sumit.semwal@ti.com>
>
> which traps all of the offenders in these patches. There seems to be a
> general issue of author names and sign-offs using reverse order naming, I
> assume because this is some absurd convention used by TI's mail servers.
Yes, TI's mail servers have this nice feature.
> We can of course continue fixing them up as they pop up, but people
> should ideally be aware of the need for consistency before committing
> things, too. A bit of name mangling is certainly a lesser evil than
> rewriting history, though.
I think the mix of multiple different styles is a result of me taking
some patches from emails (thus getting "Lastname, Firstname" style
names) and some directly from git trees or patch attachments (thus
getting whatever was configured in .gitconfig).
We'll need to see (in TI) how to make this more sensible.
> > There's a minor conflict in Overo's board file. I have pushed
> > "for-paul-merged" branch to gitorious, which contains a merge with
> > Linus' tree. I'm not sure that is the best way to show how to fix the
> > conflict, but hopefully it'll give the idea.
> >
> Seemed pretty straightforward, I took care of it and made sure that it
> still built. I assume Tony or someone will yell loudly if I've
> inadvertently broken something :-)
>
> Pulled now. I'll send things off to Linus shortly.
Thanks!
Tomi
^ permalink raw reply
* Re: [GIT PULL] omap display subsystem changes for 2.6.39
From: Paul Mundt @ 2011-03-22 5:40 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1300701083.2891.77.camel@deskari>
On Mon, Mar 21, 2011 at 11:51:23AM +0200, Tomi Valkeinen wrote:
> One problem I noticed just now, the committer names seem a bit messed
> up. For example, Archit Taneja has three different style names there. Do
> you think I should rebase and fix them? Not a big job, but it'll mean,
> well, rebasing.
>
No need, this is what .mailmap is for. It seems there are quite a few
variations, I've added entries now for all of:
Archit Taneja <archit@ti.com>
Mayuresh Janorkar <mayur@ti.com>
Mythri P K <mythripk@ti.com>
Sumit Semwal <sumit.semwal@ti.com>
which traps all of the offenders in these patches. There seems to be a
general issue of author names and sign-offs using reverse order naming, I
assume because this is some absurd convention used by TI's mail servers.
We can of course continue fixing them up as they pop up, but people
should ideally be aware of the need for consistency before committing
things, too. A bit of name mangling is certainly a lesser evil than
rewriting history, though.
> There's a minor conflict in Overo's board file. I have pushed
> "for-paul-merged" branch to gitorious, which contains a merge with
> Linus' tree. I'm not sure that is the best way to show how to fix the
> conflict, but hopefully it'll give the idea.
>
Seemed pretty straightforward, I took care of it and made sure that it
still built. I assume Tony or someone will yell loudly if I've
inadvertently broken something :-)
Pulled now. I'll send things off to Linus shortly.
^ permalink raw reply
* Re: [PATCH 09/20] video: msm: Split out MDP2.2 HW specific code.
From: Carl Vanderlip @ 2011-03-22 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110320092215.GA16646@n2100.arm.linux.org.uk>
> On Fri, Mar 18, 2011 at 02:57:03PM -0700, Carl Vanderlip wrote:
>> +int mdp_ppp_cfg_edge_cond(struct mdp_blit_req *req, struct ppp_regs
>> *regs)
>> +{
>> + int32_t luma_interp[4];
>> + int32_t luma_repeat[4];
>> + int32_t chroma_interp[4];
>> + int32_t chroma_bound[4];
>> + int32_t chroma_repeat[4];
>> + uint32_t dst_w, dst_h;
>> +
>> + memset(&luma_interp, 0, sizeof(int32_t) * 4);
>> + memset(&luma_repeat, 0, sizeof(int32_t) * 4);
>> + memset(&chroma_interp, 0, sizeof(int32_t) * 4);
>> + memset(&chroma_bound, 0, sizeof(int32_t) * 4);
>> + memset(&chroma_repeat, 0, sizeof(int32_t) * 4);
>> + regs->edge = 0;
>> +
>> + if (req->flags & MDP_ROT_90) {
>> + dst_w = req->dst_rect.h;
>> + dst_h = req->dst_rect.w;
>> + } else {
>> + dst_w = req->dst_rect.w;
>> + dst_h = req->dst_rect.h;
>> + }
>> +
>> + if (regs->op & (PPP_OP_SCALE_Y_ON | PPP_OP_SCALE_X_ON)) {
>> + get_edge_info(req->src_rect.h, req->src_rect.y, dst_h,
>> + &luma_interp[IMG_TOP], &luma_interp[IMG_BOTTOM],
>> + &luma_repeat[IMG_TOP], &luma_repeat[IMG_BOTTOM]);
>> + get_edge_info(req->src_rect.w, req->src_rect.x, dst_w,
>> + &luma_interp[IMG_LEFT], &luma_interp[IMG_RIGHT],
>> + &luma_repeat[IMG_LEFT], &luma_repeat[IMG_RIGHT]);
>> + } else {
>> + luma_interp[IMG_LEFT] = req->src_rect.x;
>> + luma_interp[IMG_RIGHT] = req->src_rect.x + req->src_rect.w - 1;
>> + luma_interp[IMG_TOP] = req->src_rect.y;
>> + luma_interp[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h - 1;
>> + luma_repeat[IMG_LEFT] = 0;
>> + luma_repeat[IMG_TOP] = 0;
>> + luma_repeat[IMG_RIGHT] = 0;
>> + luma_repeat[IMG_BOTTOM] = 0;
>> + }
>> +
>> + chroma_interp[IMG_LEFT] = luma_interp[IMG_LEFT];
>> + chroma_interp[IMG_RIGHT] = luma_interp[IMG_RIGHT];
>> + chroma_interp[IMG_TOP] = luma_interp[IMG_TOP];
>> + chroma_interp[IMG_BOTTOM] = luma_interp[IMG_BOTTOM];
>> +
>> + chroma_bound[IMG_LEFT] = req->src_rect.x;
>> + chroma_bound[IMG_RIGHT] = req->src_rect.x + req->src_rect.w - 1;
>> + chroma_bound[IMG_TOP] = req->src_rect.y;
>> + chroma_bound[IMG_BOTTOM] = req->src_rect.y + req->src_rect.h - 1;
>> +
>> + if (IS_YCRCB(req->src.format)) {
>> + chroma_interp[IMG_LEFT] = chroma_interp[IMG_LEFT] >> 1;
>> + chroma_interp[IMG_RIGHT] = (chroma_interp[IMG_RIGHT] + 1) >> 1;
>> +
>> + chroma_bound[IMG_LEFT] = chroma_bound[IMG_LEFT] >> 1;
>> + chroma_bound[IMG_RIGHT] = chroma_bound[IMG_RIGHT] >> 1;
>> + }
>> +
>> + if (req->src.format = MDP_Y_CBCR_H2V2 ||
>> + req->src.format = MDP_Y_CRCB_H2V2) {
>> + chroma_interp[IMG_TOP] = (chroma_interp[IMG_TOP] - 1) >> 1;
>> + chroma_interp[IMG_BOTTOM] = (chroma_interp[IMG_BOTTOM] + 1)
>> + >> 1;
>> + chroma_bound[IMG_TOP] = (chroma_bound[IMG_TOP] + 1) >> 1;
>> + chroma_bound[IMG_BOTTOM] = chroma_bound[IMG_BOTTOM] >> 1;
>> + }
>> +
>> + chroma_repeat[IMG_LEFT] = chroma_bound[IMG_LEFT] -
>> + chroma_interp[IMG_LEFT];
>> + chroma_repeat[IMG_RIGHT] = chroma_interp[IMG_RIGHT] -
>> + chroma_bound[IMG_RIGHT];
>> + chroma_repeat[IMG_TOP] = chroma_bound[IMG_TOP] -
>> + chroma_interp[IMG_TOP];
>> + chroma_repeat[IMG_BOTTOM] = chroma_interp[IMG_BOTTOM] -
>> + chroma_bound[IMG_BOTTOM];
>> +
>> + if (chroma_repeat[IMG_LEFT] < 0 || chroma_repeat[IMG_LEFT] > 3 ||
>> + chroma_repeat[IMG_RIGHT] < 0 || chroma_repeat[IMG_RIGHT] > 3 ||
>> + chroma_repeat[IMG_TOP] < 0 || chroma_repeat[IMG_TOP] > 3 ||
>> + chroma_repeat[IMG_BOTTOM] < 0 || chroma_repeat[IMG_BOTTOM] > 3 ||
>> + luma_repeat[IMG_LEFT] < 0 || luma_repeat[IMG_LEFT] > 3 ||
>> + luma_repeat[IMG_RIGHT] < 0 || luma_repeat[IMG_RIGHT] > 3 ||
>> + luma_repeat[IMG_TOP] < 0 || luma_repeat[IMG_TOP] > 3 ||
>> + luma_repeat[IMG_BOTTOM] < 0 || luma_repeat[IMG_BOTTOM] > 3)
>> + return -1;
>
> Lazy programming strikes again. Public functions really should not
> return things that look like errno codes, rather they should return
> real errno codes.
>
> Secondly, why is this stuff, which looks very driver like, under arch/arm
> and not in drivers/ somewhere?
>
Fixed.
Secondly, I think this code in particular is in drivers/video/msm; I think
you've been included since there are some Kconfig updates under arch/arm
(additionally, I think David B. will be pulling this into his for-next
tree if approved).
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* RE: [PATCH 07/20] video: msm: Allow users to request a larger x
From: Carl Vanderlip @ 2011-03-22 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EAE7@dbde02.ent.ti.com>
>> diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
>> index 04d0067..6af8b41 100644
>> --- a/drivers/video/msm/msm_fb.c
>> +++ b/drivers/video/msm/msm_fb.c
>> @@ -323,14 +327,46 @@ error:
>>
>> static int msmfb_check_var(struct fb_var_screeninfo *var, struct
>> fb_info
>> *info)
>> {
>> + u32 size;
>> +
>> if ((var->xres != info->var.xres) ||
>> (var->yres != info->var.yres) ||
>> - (var->xres_virtual != info->var.xres_virtual) ||
>> - (var->yres_virtual != info->var.yres_virtual) ||
>> (var->xoffset != info->var.xoffset) ||
>> (var->bits_per_pixel != info->var.bits_per_pixel) ||
>> (var->grayscale != info->var.grayscale))
>> return -EINVAL;
>> +
>> + size = var->xres_virtual * var->yres_virtual *
>> + (var->bits_per_pixel >> 3);
>
> How about defining a new macro BYTES_PER_PIXEL_VAR for fb_var_screeninfo
> also? That would make code more readable.
>
>> + if (size > info->fix.smem_len)
>> + return -EINVAL;
>> + return 0;
>> +}
Name might be a little easy to confuse with the other BYTES_PER_PIXEL, but
overall readability would increase IMHO; Done.
>> +static int msmfb_set_par(struct fb_info *info)
>> +{
>> + struct fb_var_screeninfo *var = &info->var;
>> + struct fb_fix_screeninfo *fix = &info->fix;
>> +
>> + /* we only support RGB ordering for now */
>> + if (var->bits_per_pixel = 32 || var->bits_per_pixel = 24) {
>> + var->red.offset = 0;
>> + var->red.length = 8;
>> + var->green.offset = 8;
>> + var->green.length = 8;
>> + var->blue.offset = 16;
>> + var->blue.length = 8;
>
> var->red is a fb_bitfield variable.
> It provides offset, length and msb_right.
>
> struct fb_bitfield {
> __u32 offset; /* beginning of bitfield */
> __u32 length; /* length of bitfield */
> __u32 msb_right; /* != 0 : Most significant bit is */
> /* right */
> }
> Please don't keep msb_right unassigned.
>
>> + } else if (var->bits_per_pixel = 16) {
>> + var->red.offset = 11;
>> + var->red.length = 5;
>> + var->green.offset = 5;
>> + var->green.length = 6;
>> + var->blue.offset = 0;
>> + var->blue.length = 5;
>> + } else
>> + return -1;
>
> Please use standard error code provided by Linux kernel -EINVAL
> (-22 Invalid argument)
>
>> + fix->line_length = var->xres * var->bits_per_pixel / 8;
> Why to divide by 8? Atleast use >>3, bitwise operations that would take
> less cpu cycles)
> As I stated earlier define a new macro for var also.
>
>> +
>> return 0;
>> }
And Done. And done again... and while I'm at it, all the changes you
suggested are being pulled into v2 (except for updating Google's copyright
date (see: Brian Swetland's response)).
Thank you for reviewing my patches :)
-Carl V.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* RE: [PATCH 01/20] video: msm: Fix typo 'mpd'->'mdp'
From: Carl Vanderlip @ 2011-03-22 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB033D22EABA@dbde02.ent.ti.com>
>
>
>> -----Original Message-----
>> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
>> owner@vger.kernel.org] On Behalf Of Carl Vanderlip
>> Sent: Saturday, March 19, 2011 3:22 AM
>> To: Russell King; David Brown; Daniel Walker; Bryan Huntsman
>> Cc: Brian Swetland; Dima Zavin; Rebecca Schultz Zavin; Colin Cross;
>> linux-
>> fbdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-arm-
>> msm@vger.kernel.org; linux-kernel@vger.kernel.org; Carl Vanderlip
>> Subject: [PATCH 01/20] video: msm: Fix typo 'mpd'->'mdp'
>>
>> From: Brian Swetland <swetland@google.com>
>>
>> Trivial fix
>
> The Subject line states that you are only changing a typo from mpd to mdp.
> The description doesn't state anything more.
> But the patch is changing Copyright info also.
>>
>> Authors:
>> Dima Zavin <dima@android.com>
>> Rebecca Schultz Zavin <rebecca@android.com>
>> Colin Cross <ccross@android.com>
>>
>> Signed-off-by: Carl Vanderlip <carlv@codeaurora.org>
It was my intention to update the files I was changing in this patchset
with the correct copyright assignments. v2 commit text will mention this
change.
-Carl V.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 17/20] video: msm: Prevent framebuffer glitch
From: Carl Vanderlip @ 2011-03-21 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D87552D.4070205@ru.mvista.com>
> Carl Vanderlip wrote:
>
>> Holds a reference to the mdp_clk until lateinit, and moves the
>> frambuffer
>> initialization to device_init.
>
> Maybe I'm just blind but I don't see where the patch does the
> latter...
>
>> The framebuffer lcdc driver will grab a
>> reference to mdp_clk, which prevents the clock from being disabled by
>> clock_late_init.
>
>> Authors:
>> Dima Zavin <dima@android.com>
>> Rebecca Schultz Zavin <rebecca@android.com>
>> Colin Cross <ccross@android.com>
>
Fear not. You are not going blind :P, I got a bit overzealous when trying
to re-use the commit text that was available from the squashed patch that
this patch set is spawned from (hence why [18/20] also has this same
issue.
I will be re-writing this commit text for v2 (unless this c-text is
desired to be kept for "historical" purposes).
>> ---
>> drivers/video/msm/mdp.c | 10 ++++++++++
>> 1 files changed, 10 insertions(+), 0 deletions(-)
>
>> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
>> index 0bb19fa..b3f334ad 100644
>> --- a/drivers/video/msm/mdp.c
>> +++ b/drivers/video/msm/mdp.c
>> @@ -38,6 +38,7 @@ struct class *mdp_class;
>>
>> static DECLARE_WAIT_QUEUE_HEAD(mdp_ppp_waitqueue);
>> static unsigned int mdp_irq_mask;
>> +struct clk *mdp_clk_to_disable_later;
>
> Why not just 'mdp_clk'? :-)
>
I was not the original author for these variable names, though I do see
some reason behind the naming of this variable. I'd be more willing to
change this name, to "mdp_clk" if it weren't so visually similar to
mdp->clk (tired programmer eyes/brain could read (or write) the wrong
one).
As it is, the name is a little long, but it makes it extraordinarily clear
what its purpose is (i.e. you know exactly what it is being used for
without having to go searching for other places it is used).
So while I don't like the name as it is, I don't really like 'mdp_clk'
either (though would be willing to change it if anyone feels like being
stubborn :-)).
-Carl V.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 1/2] viafb: refresh rate bug collection
From: Florian Tobias Schandinat @ 2011-03-21 22:46 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300748487-9883-1-git-send-email-FlorianSchandinat@gmx.de>
This patch fixes multiple issues with the handling of refresh rates
especially for multi-display setups. If you experienced problems
with wrong refresh rates this patch might fix them.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/chip.h | 1 -
drivers/video/via/hw.c | 17 ++++++---------
drivers/video/via/hw.h | 3 +-
drivers/video/via/viafbdev.c | 45 ++++++++++++++++++++++++++---------------
4 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index 781f3aa..29d7024 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -139,7 +139,6 @@ struct chip_information {
struct crt_setting_information {
int iga_path;
- int refresh_rate;
};
struct tmds_setting_information {
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 5728fd7..dc4c778 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2002,13 +2002,15 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
int i;
int index = 0;
int h_addr, v_addr;
- u32 pll_D_N, clock;
+ u32 pll_D_N, clock, refresh = viafb_refresh;
+
+ if (viafb_SAMM_ON && set_iga = IGA2)
+ refresh = viafb_refresh1;
for (i = 0; i < video_mode->mode_array; i++) {
index = i;
- if (crt_table[i].refresh_rate = viaparinfo->
- crt_setting_info->refresh_rate)
+ if (crt_table[i].refresh_rate = refresh)
break;
}
@@ -2019,7 +2021,7 @@ void viafb_fill_crtc_timing(struct crt_mode_table *crt_table,
if ((viafb_LCD_ON | viafb_DVI_ON)
&& video_mode->crtc[0].crtc.hor_addr = 640
&& video_mode->crtc[0].crtc.ver_addr = 480
- && viaparinfo->crt_setting_info->refresh_rate = 60) {
+ && refresh = 60) {
/* The border is 8 pixels. */
crt_reg.hor_blank_start = crt_reg.hor_blank_start - 8;
@@ -2070,7 +2072,6 @@ void __devinit viafb_init_chip_info(int chip_type)
init_lvds_chip_info();
viaparinfo->crt_setting_info->iga_path = IGA1;
- viaparinfo->crt_setting_info->refresh_rate = viafb_refresh;
/*Set IGA path for each device */
viafb_set_iga_path();
@@ -2083,13 +2084,9 @@ void __devinit viafb_init_chip_info(int chip_type)
viaparinfo->lvds_setting_info->lcd_mode;
}
-void viafb_update_device_setting(int hres, int vres,
- int bpp, int vmode_refresh, int flag)
+void viafb_update_device_setting(int hres, int vres, int bpp, int flag)
{
if (flag = 0) {
- viaparinfo->crt_setting_info->refresh_rate - vmode_refresh;
-
viaparinfo->tmds_setting_info->h_active = hres;
viaparinfo->tmds_setting_info->v_active = vres;
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 7295263..8858593 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -949,8 +949,7 @@ void __devinit viafb_init_chip_info(int chip_type);
void __devinit viafb_init_dac(int set_iga);
int viafb_get_pixclock(int hres, int vres, int vmode_refresh);
int viafb_get_refresh(int hres, int vres, u32 float_refresh);
-void viafb_update_device_setting(int hres, int vres, int bpp,
- int vmode_refresh, int flag);
+void viafb_update_device_setting(int hres, int vres, int bpp, int flag);
void viafb_set_iga_path(void);
void viafb_set_primary_color_register(u8 index, u8 red, u8 green, u8 blue);
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index f555b89..fd6a15f 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -182,13 +182,24 @@ static int viafb_release(struct fb_info *info, int user)
return 0;
}
+static inline int get_var_refresh(struct fb_var_screeninfo *var)
+{
+ u32 htotal, vtotal;
+
+ htotal = var->left_margin + var->xres + var->right_margin
+ + var->hsync_len;
+ vtotal = var->upper_margin + var->yres + var->lower_margin
+ + var->vsync_len;
+ return PICOS2KHZ(var->pixclock) * 1000 / (htotal * vtotal);
+}
+
static int viafb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
- int htotal, vtotal, depth;
+ int depth, refresh;
struct VideoModeTable *vmode_entry;
struct viafb_par *ppar = info->par;
- u32 long_refresh, line;
+ u32 line;
DEBUG_MSG(KERN_INFO "viafb_check_var!\n");
/* Sanity check */
@@ -231,17 +242,11 @@ static int viafb_check_var(struct fb_var_screeninfo *var,
/* Based on var passed in to calculate the refresh,
* because our driver use some modes special.
*/
- htotal = var->xres + var->left_margin +
- var->right_margin + var->hsync_len;
- vtotal = var->yres + var->upper_margin +
- var->lower_margin + var->vsync_len;
- long_refresh = 1000000000UL / var->pixclock * 1000;
- long_refresh /= (htotal * vtotal);
-
- viafb_refresh = viafb_get_refresh(var->xres, var->yres, long_refresh);
+ refresh = viafb_get_refresh(var->xres, var->yres,
+ get_var_refresh(var));
/* Adjust var according to our driver's own table */
- viafb_fill_var_timing_info(var, viafb_refresh, vmode_entry);
+ viafb_fill_var_timing_info(var, refresh, vmode_entry);
if (var->accel_flags & FB_ACCELF_TEXT &&
!ppar->shared->vdev->engine_mmio)
var->accel_flags = 0;
@@ -253,12 +258,13 @@ static int viafb_set_par(struct fb_info *info)
{
struct viafb_par *viapar = info->par;
struct VideoModeTable *vmode_entry, *vmode_entry1 = NULL;
+ int refresh;
DEBUG_MSG(KERN_INFO "viafb_set_par!\n");
viafb_update_fix(info);
viapar->depth = fb_get_color_depth(&info->var, &info->fix);
viafb_update_device_setting(viafbinfo->var.xres, viafbinfo->var.yres,
- viafbinfo->var.bits_per_pixel, viafb_refresh, 0);
+ viafbinfo->var.bits_per_pixel, 0);
vmode_entry = viafb_get_mode(viafbinfo->var.xres, viafbinfo->var.yres);
if (viafb_dual_fb) {
@@ -266,7 +272,7 @@ static int viafb_set_par(struct fb_info *info)
viafbinfo1->var.yres);
viafb_update_device_setting(viafbinfo1->var.xres,
viafbinfo1->var.yres, viafbinfo1->var.bits_per_pixel,
- viafb_refresh1, 1);
+ 1);
} else if (viafb_SAMM_ON = 1) {
DEBUG_MSG(KERN_INFO
"viafb_second_xres = %d, viafb_second_yres = %d, bpp = %d\n",
@@ -275,14 +281,19 @@ static int viafb_set_par(struct fb_info *info)
viafb_second_yres);
viafb_update_device_setting(viafb_second_xres,
- viafb_second_yres, viafb_bpp1, viafb_refresh1, 1);
+ viafb_second_yres, viafb_bpp1, 1);
}
+ refresh = viafb_get_refresh(info->var.xres, info->var.yres,
+ get_var_refresh(&info->var));
if (vmode_entry) {
- if (viafb_dual_fb && viapar->iga_path = IGA2)
+ if (viafb_dual_fb && viapar->iga_path = IGA2) {
viafb_bpp1 = info->var.bits_per_pixel;
- else
+ viafb_refresh1 = refresh;
+ } else {
viafb_bpp = info->var.bits_per_pixel;
+ viafb_refresh = refresh;
+ }
if (info->var.accel_flags & FB_ACCELF_TEXT)
info->flags &= ~FBINFO_HWACCEL_DISABLED;
@@ -1843,7 +1854,7 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
default_var.bits_per_pixel = viafb_bpp1;
default_var.pixclock viafb_get_pixclock(viafb_second_xres, viafb_second_yres,
- viafb_refresh);
+ viafb_refresh1);
default_var.left_margin = (viafb_second_xres >> 3) & 0xf8;
default_var.right_margin = 32;
default_var.upper_margin = 16;
--
1.6.3.2
^ permalink raw reply related
* [PATCH 2/2] viafb: initialize margins correct
From: Florian Tobias Schandinat @ 2011-03-21 22:46 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <1300748487-9883-1-git-send-email-FlorianSchandinat@gmx.de>
This patch initializes the margins for the initial mode correct.
This is required to get the desired initial refresh rate. Also do
more verbose sanity checking to prevent misbehavior.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/viafbdev.c | 31 +++++++++++--------------------
1 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index fd6a15f..9d9bb9b 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1806,14 +1806,9 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
default_var.xres_virtual = default_xres;
default_var.yres_virtual = default_yres;
default_var.bits_per_pixel = viafb_bpp;
- default_var.pixclock - viafb_get_pixclock(default_xres, default_yres, viafb_refresh);
- default_var.left_margin = (default_xres >> 3) & 0xf8;
- default_var.right_margin = 32;
- default_var.upper_margin = 16;
- default_var.lower_margin = 4;
- default_var.hsync_len = default_var.left_margin;
- default_var.vsync_len = 4;
+ viafb_fill_var_timing_info(&default_var, viafb_get_refresh(
+ default_var.xres, default_var.yres, viafb_refresh),
+ viafb_get_mode(default_var.xres, default_var.yres));
viafb_setup_fixinfo(&viafbinfo->fix, viaparinfo);
viafbinfo->var = default_var;
@@ -1852,15 +1847,9 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
default_var.xres_virtual = viafb_second_virtual_xres;
default_var.yres_virtual = viafb_second_virtual_yres;
default_var.bits_per_pixel = viafb_bpp1;
- default_var.pixclock - viafb_get_pixclock(viafb_second_xres, viafb_second_yres,
- viafb_refresh1);
- default_var.left_margin = (viafb_second_xres >> 3) & 0xf8;
- default_var.right_margin = 32;
- default_var.upper_margin = 16;
- default_var.lower_margin = 4;
- default_var.hsync_len = default_var.left_margin;
- default_var.vsync_len = 4;
+ viafb_fill_var_timing_info(&default_var, viafb_get_refresh(
+ default_var.xres, default_var.yres, viafb_refresh1),
+ viafb_get_mode(default_var.xres, default_var.yres));
viafb_setup_fixinfo(&viafbinfo1->fix, viaparinfo1);
viafb_check_var(&default_var, viafbinfo1);
@@ -2015,15 +2004,17 @@ static int __init viafb_setup(char *options)
*/
int __init viafb_init(void)
{
- u32 dummy;
+ u32 dummy_x, dummy_y;
#ifndef MODULE
char *option = NULL;
if (fb_get_options("viafb", &option))
return -ENODEV;
viafb_setup(option);
#endif
- if (parse_mode(viafb_mode, &dummy, &dummy)
- || parse_mode(viafb_mode1, &dummy, &dummy)
+ if (parse_mode(viafb_mode, &dummy_x, &dummy_y)
+ || !viafb_get_mode(dummy_x, dummy_y)
+ || parse_mode(viafb_mode1, &dummy_x, &dummy_y)
+ || !viafb_get_mode(dummy_x, dummy_y)
|| viafb_bpp < 0 || viafb_bpp > 32
|| viafb_bpp1 < 0 || viafb_bpp1 > 32
|| parse_active_dev())
--
1.6.3.2
^ permalink raw reply related
* viafb fixes
From: Florian Tobias Schandinat @ 2011-03-21 22:46 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel
This series contains two patches to fix handling of initial values
selected via parameters. They are tested and confirmed to work on
CLE266, VX800 and VX900.
They will show up in linux-next soon and are designated for 2.6.39,
probably will go there at the end of the merge window or in an early
release candidate.
Note: These patches are minimal, further cleanup in this area is
planned for the next merge window.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alex Deucher @ 2011-03-21 21:46 UTC (permalink / raw)
To: Ondrej Zary
Cc: Linux Fbdev development list, Geert Uytterhoeven,
timofonic timofonic, dri-devel, wayland-devel
In-Reply-To: <201103212213.51565.linux@rainbow-software.org>
On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +0000
>> >
>> > timofonic timofonic <timofonic@gmail.com> wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what? All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia). If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it? There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> > 1) inertia: fbdev has been around a lot longer, and provides most of
>> > what embedded devices need anyway
>> > 2) feature set: why bother doing a full KMS driver if you're not
>> > going to use any of the additional features it would provide (output
>> > management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.
You'd need to update the existing DDX to work with KMS. Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.
Alex
>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Matt Turner @ 2011-03-21 21:37 UTC (permalink / raw)
To: Alan Cox
Cc: Linux Fbdev development list, dri-devel, wayland-devel,
Geert Uytterhoeven, timofonic timofonic
In-Reply-To: <20110321212008.384711f0@lxorguk.ukuu.org.uk>
On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> 1) inertia: fbdev has been around a lot longer, and provides most of
>> what embedded devices need anyway
>> 2) feature set: why bother doing a full KMS driver if you're not
>> going to use any of the additional features it would provide (output
>> management, memory management, execution management)
>
> 3) its got documentation
My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.
http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz
My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary
There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.
It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.
Thanks,
Matt
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 21:22 UTC (permalink / raw)
To: Alan Cox
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20110321212008.384711f0-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Mon, 21 Mar 2011 21:20:08 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > 1) inertia: fbdev has been around a lot longer, and provides most of
> > what embedded devices need anyway
> > 2) feature set: why bother doing a full KMS driver if you're not
> > going to use any of the additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alan Cox @ 2011-03-21 21:20 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
3) its got documentation
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Ondrej Zary @ 2011-03-21 21:13 UTC (permalink / raw)
To: dri-devel
Cc: Linux Fbdev development list, wayland-devel, Geert Uytterhoeven,
timofonic timofonic
In-Reply-To: <AANLkTi=kRdC1LoHxqwKxYKZJf99vBEU=OmQoY+zS1dK-@mail.gmail.com>
On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> >
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). If you want it for a particular device, you
> > can always port it over.
> >
> > As for fbdev emulation, what's still using it? There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> >
> >> I know the graphic driver situation is quite bad on Linux, especially
> >> on the embedded world. Fbdev seems is still quite used there by binary
> >> blob drivers.
> >
> > Probably for a couple of reasons:
> > 1) inertia: fbdev has been around a lot longer, and provides most of
> > what embedded devices need anyway
> > 2) feature set: why bother doing a full KMS driver if you're not
> > going to use any of the additional features it would provide (output
> > management, memory management, execution management)
>
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)
This looks interesting. If existing *fb drivers could be easily converted to
KMS (including 2D acceleration) and then used in X with a common driver, it
would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
with 2D acceleration.
> This is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 16/20] video: msm: Set the EBI1 clock to 128MHz when performing
From: Stephen Boyd @ 2011-03-21 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1300485562-27560-1-git-send-email-carlv@codeaurora.org>
On 03/18/2011 02:59 PM, Carl Vanderlip wrote:
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index b03204d..0bb19fa 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -656,6 +657,13 @@ int mdp_probe(struct platform_device *pdev)
> goto error_get_mdp_clk;
> }
>
> + mdp->ebi1_clk = clk_get(NULL, "ebi1_clk");
Please pass a device pointer as the first argument so we can match up
the ebi1_clk to the right device. MSM supports clkdev now so it's fairly
simple to do this.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Alex Deucher @ 2011-03-21 20:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: dri-devel, timofonic timofonic, Linux Fbdev development list,
wayland-devel
In-Reply-To: <AANLkTikAeQ=z-M3kW2zPgVRK-bmoiTeA5ktjjTokEybW@mail.gmail.com>
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> On Mon, 21 Mar 2011 19:19:43 +0000
>> timofonic timofonic <timofonic@gmail.com> wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what? All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia). If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...
Sadly it gets worse. A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.
Alex
>
>> As for fbdev emulation, what's still using it? There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>> 1) inertia: fbdev has been around a lot longer, and provides most of
>> what embedded devices need anyway
>> 2) feature set: why bother doing a full KMS driver if you're not
>> going to use any of the additional features it would provide (output
>> management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:59 UTC (permalink / raw)
To: Corbin Simpson
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <AANLkTi=kRdC1LoHxqwKxYKZJf99vBEU=OmQoY+zS1dK-@mail.gmail.com>
On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson <mostawesomedude@gmail.com> wrote:
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)
Yeah, we used to call that drmcon, and it's still a big open. I think
there are some projects that sit on top of fbdev and provide a good
text console with fancy character and input support, but I don't know
if any of them have been ported to KMS to handle multiple outputs or
with an aim toward integrating into a distro as a VT replacement.
kmsset or something would be pretty easy to do; the modetest program in
the drm repo would be a good starting point for that. One limitation
there is handling fbcon, which makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: timofonic timofonic, Linux Fbdev development list, dri-devel,
wayland-devel
In-Reply-To: <AANLkTikAeQ=z-M3kW2zPgVRK-bmoiTeA5ktjjTokEybW@mail.gmail.com>
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). If you want it for a particular device, you
> > can always port it over.
>
> The three major GPU device classes on PC...
Yes, good point. :)
> > As for fbdev emulation, what's still using it? There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
Yes. Fundamentally, the Wayland protocol just assumes a way to share
buffers between processes. For the software raster version of the Qt
port, Kristian created a shmem interface for doing that to allow the
results of CPU rendering to be passed around without copying. On an
embedded device that would be one way to go.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Geert Uytterhoeven @ 2011-03-21 19:50 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Linux Fbdev development list, dri-devel,
wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). If you want it for a particular device, you
> can always port it over.
The three major GPU device classes on PC...
> As for fbdev emulation, what's still using it? There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
Can Wayland handle fbdev APIs ...
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
... if no additional features of KMS are needed?
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: Future desktop on dumb frame buffers?
From: Corbin Simpson @ 2011-03-21 19:34 UTC (permalink / raw)
To: Jesse Barnes
Cc: timofonic timofonic, Geert Uytterhoeven,
Linux Fbdev development list, dri-devel, wayland-devel
In-Reply-To: <20110321122518.6b7ec7e4@jbarnes-desktop>
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it? There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
>
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> 1) inertia: fbdev has been around a lot longer, and provides most of
> what embedded devices need anyway
> 2) feature set: why bother doing a full KMS driver if you're not
> going to use any of the additional features it would provide (output
> management, memory management, execution management)
Related: We are still missing basic userspace tools (kmsset, e.g.),
some kind of direct KMS console (kmscon would work, if it existed),
and an xf86-video-modesetting which compiles and works (this is
actually possible now, with some patches that landed in 2.6.38 for
generic KMS access.)
This is important to me, as the various old drivers I've been hacking
on won't be accepted upstream without some sort of userspace which can
work with them. One of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<MostAwesomeDude@gmail.com>
^ permalink raw reply
* Re: Future desktop on dumb frame buffers?
From: Jesse Barnes @ 2011-03-21 19:25 UTC (permalink / raw)
To: timofonic timofonic
Cc: Linux Fbdev development list, Geert Uytterhoeven,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <AANLkTimjOs8ZuKRUt1aOizhbRw2-Ni4bTPty-dKpZ-rz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic <timofonic@gmail.com> wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?
Used by what? All three major GPU device classes have KMS support
(Intel, ATI, and nVidia). If you want it for a particular device, you
can always port it over.
As for fbdev emulation, what's still using it? There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.
> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.
Probably for a couple of reasons:
1) inertia: fbdev has been around a lot longer, and provides most of
what embedded devices need anyway
2) feature set: why bother doing a full KMS driver if you're not
going to use any of the additional features it would provide (output
management, memory management, execution management)
Jesse
^ 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