* Re: [patch] xenfb: fix xenfb suspend/resume race
From: Ian Campbell @ 2011-01-04 11:15 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Joe Jin, jeremy@goop.org, Andrew Morton,
linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, gurudas.pai@oracle.com,
greg.marsden@oracle.com, guru.anbalagane@oracle.com
In-Reply-To: <20101230164051.GC24313@dumpdata.com>
On Thu, 2010-12-30 at 16:40 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 30, 2010 at 08:56:16PM +0800, Joe Jin wrote:
> > Hi,
>
> Joe,
>
> Patch looks good, however..
>
> I am unclear from your description whether the patch fixes
> the problem (I would presume so). Or does it take a long time
> to hit this race?
I also don't see how the patch relates to the stack trace.
Is the issue is that xenfb_send_event is called between xenfb_resume
(which tears down the state, including evtchn->irq binding) and the
probe/connect of the new fb?
I suspect xenfb_resume should set info->update_wanted to 0. This will
defer updates until we have successfully reconnected.
Otherwise, since xenfb_resume also calls xenfb_connect I presume the
call of xenfb_send_event is asynchronous. Which would suggest that some
other locking is missing.
Ian.
>
> >
> > when do migration test, we hit the panic as below:
> > <1>BUG: unable to handle kernel paging request at 0000000b819fdb98
> > <1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
> > <4>PGD 94b10067 PUD 0
> > <0>Oops: 0000 [#1] SMP
> > <0>last sysfs file: /sys/class/misc/autofs/dev
> > <4>CPU 3
> > <4>Modules linked in: autofs4(U) hidp(U) nfs(U) fscache(U) nfs_acl(U)
> > auth_rpcgss(U) rfcomm(U) l2cap(U) bluetooth(U) rfkill(U) lockd(U) sunrpc(U)
> > nf_conntrack_netbios_ns(U) ipt_REJECT(U) nf_conntrack_ipv4(U)
> > nf_defrag_ipv4(U) xt_state(U) nf_conntrack(U) iptable_filter(U) ip_tables(U)
> > ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U)
> > ipv6(U) parport_pc(U) lp(U) parport(U) snd_seq_dummy(U) snd_seq_oss(U)
> > snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U)
> > snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
> > snd_page_alloc(U) joydev(U) xen_netfront(U) pcspkr(U) xen_blkfront(U)
> > uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
> > Pid: 18, comm: events/3 Not tainted 2.6.32
> > RIP: e030:[<ffffffff812a588f>] [<ffffffff812a588f>]
> > ify_remote_via_irq+0x13/0x34
> > RSP: e02b:ffff8800e7bf7bd0 EFLAGS: 00010202
> > RAX: ffff8800e61c8000 RBX: ffff8800e62f82c0 RCX: 0000000000000000
> > RDX: 00000000000001e3 RSI: ffff8800e7bf7c68 RDI: 0000000bfffffff4
> > RBP: ffff8800e7bf7be0 R08: 00000000000001e2 R09: ffff8800e62f82c0
> > R10: 0000000000000001 R11: ffff8800e6386110 R12: 0000000000000000
> > R13: 0000000000000007 R14: ffff8800e62f82e0 R15: 0000000000000240
> > FS: 00007f409d3906e0(0000) GS:ffff8800028b8000(0000)
> > GS:0000000000000000
> > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 0000000b819fdb98 CR3: 000000003ee3b000 CR4: 0000000000002660
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process events/3 (pid: 18, threadinfo ffff8800e7bf6000, task
> > f8800e7bf4540)
> > Stack:
> > 0000000000000200 ffff8800e61c8000 ffff8800e7bf7c00 ffffffff812712c9
> > <0> ffffffff8100ea5f ffffffff81438d80 ffff8800e7bf7cd0 ffffffff812714ee
> > <0> 0000000000000000 ffffffff81270568 000000000000e030 0000000000010202
> > Call Trace:
> > [<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
> > [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
> > [<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
> > [<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
> > [<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
> > [<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
> > [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
> > [<ffffffff812656b7>] fb_flashcursor+0xff/0x111
> > [<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
> > [<ffffffff81071812>] worker_thread+0x14d/0x1ed
> > [<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
> > [<ffffffff810756e3>] kthread+0x6e/0x76
> > [<ffffffff81012dea>] child_rip+0xa/0x20
> > [<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
> > [<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
> > [<ffffffff81012de0>] ? child_rip+0x0/0x20
> > Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
> > c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
> > 81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
> > RIP [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
> > RSP <ffff8800e7bf7bd0>
> > CR2: 0000000b819fdb98
> > ---[ end trace 098b4b74827595d0 ]---
> > Kernel panic - not syncing: Fatal exception
> > Pid: 18, comm: events/3 Tainted: G D 2.6.32
> > Call Trace:
> > [<ffffffff812a029e>] ? card_probe+0x99/0x123
> > [<ffffffff81056a96>] panic+0xa5/0x162
> > [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff81079824>] ? down_trylock+0x30/0x38
> > [<ffffffff812a029e>] ? card_probe+0x99/0x123
> > [<ffffffff8105744c>] ? console_unblank+0x23/0x6f
> > [<ffffffff81056763>] ? print_oops_end_marker+0x23/0x25
> > [<ffffffff812a029e>] ? card_probe+0x99/0x123
> > [<ffffffff81439c76>] oops_end+0xb7/0xc7
> > [<ffffffff810366de>] no_context+0x1f1/0x200
> > [<ffffffff812a029e>] ? card_probe+0x99/0x123
> > [<ffffffff81036931>] __bad_area_nosemaphore+0x183/0x1a6
> > [<ffffffff812af119>] ? extract_buf+0xbd/0x134
> > [<ffffffff81030c7b>] ? pvclock_clocksource_read+0x47/0x9e
> > [<ffffffff810369de>] bad_area_nosemaphore+0x13/0x15
> > [<ffffffff8143b0ed>] do_page_fault+0x147/0x26c
> > [<ffffffff81439185>] page_fault+0x25/0x30
> > [<ffffffff812a588f>] ? notify_remote_via_irq+0x13/0x34
> > [<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
> > [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
> > [<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
> > [<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
> > [<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
> > [<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
> > [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
> > [<ffffffff812656b7>] fb_flashcursor+0xff/0x111
> > [<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
> > [<ffffffff81071812>] worker_thread+0x14d/0x1ed
> > [<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
> > [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
> > [<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
> > [<ffffffff810756e3>] kthread+0x6e/0x76
> > [<ffffffff81012dea>] child_rip+0xa/0x20
> > [<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
> > [<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
> > [<ffffffff81012de0>] ? child_rip+0x0/0x20
> > [<ffffffff81012de0>] ? child_rip+0x0/0x20
> >
> > Check the source found this maybe caused by kernel tried to used not ready
> > xenfb when resume.
> >
> > Below is the potential fix, please reivew it
> >
> > Signed-off-by: Joe Jin <joe.jin@oracle.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> >
> > ---
> > xen-fbfront.c | 19 +++++++++++--------
> > 1 file changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> > index dc72563..367fb1c 100644
> > --- a/drivers/video/xen-fbfront.c
> > +++ b/drivers/video/xen-fbfront.c
> > @@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
> > static int xenfb_connect_backend(struct xenbus_device *dev,
> > struct xenfb_info *info)
> > {
> > - int ret, evtchn;
> > + int ret, evtchn, irq;
> > struct xenbus_transaction xbt;
> >
> > ret = xenbus_alloc_evtchn(dev, &evtchn);
> > if (ret)
> > return ret;
> > - ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> > + irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> > 0, dev->devicetype, info);
> > - if (ret < 0) {
> > + if (irq < 0) {
> > xenbus_free_evtchn(dev, evtchn);
> > xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
> > - return ret;
> > + return irq;
> > }
> > - info->irq = ret;
> > -
> > again:
> > ret = xenbus_transaction_start(&xbt);
> > if (ret) {
> > xenbus_dev_fatal(dev, ret, "starting transaction");
> > - return ret;
> > + goto unbind_irq;
> > }
> > ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> > virt_to_mfn(info->page));
> > @@ -602,15 +600,20 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
> > if (ret = -EAGAIN)
> > goto again;
> > xenbus_dev_fatal(dev, ret, "completing transaction");
> > - return ret;
> > + goto unbind_irq;
> > }
> >
> > xenbus_switch_state(dev, XenbusStateInitialised);
> > + info->irq = irq;
> > return 0;
> >
> > error_xenbus:
> > xenbus_transaction_end(xbt, 1);
> > xenbus_dev_fatal(dev, ret, "writing xenstore");
> > + unbind_irq:
> > + printk(KERN_ERR "xenfb_connect_backend failed!\n");
> > + unbind_from_irqhandler(irq, info);
> > + xenbus_free_evtchn(dev, evtchn);
> > return ret;
> > }
> >
> >
> >
> > --
> > Oracle <http://www.oracle.com>
> > Joe Jin | Team Leader, Software Development | +8610.8278.6295
> > ORACLE | Linux and Virtualization
> > Incubator Building 2-A ZPark | Beijing China, 100094
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
From: Inki Dae @ 2011-01-04 10:04 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1294128333-28736-1-git-send-email-kgene.kim@samsung.com>
Hello, Mr. Kukjin.
I know we had a discussion about your patch below.
after that, did you have some discussion about that?
If not, Paul advised to use clkdev lookup.
Please, refer to below mail.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03448.html
thank you.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Kukjin Kim
> Sent: Tuesday, January 04, 2011 5:06 PM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org
> Cc: ben-linux@fluff.org; akpm@linux-foundation.org; lethal@linux-sh.org;
> Jonghun Han; Sangbeom Kim; InKi Dae; Kukjin Kim
> Subject: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
>
> From: Jonghun Han <jonghun.han@samsung.com>
>
> This patch adds struct s3c_fb_driverdata s3c_fb_data_s5pv310 for S5PV310
> and S5PC210. The clk_type is added to distinguish clock type in it and
> lcd_clk is added in structure s3c_fb to calculate divider for lcd panel.
>
> Please refer to below diagrams about clocks of FIMD IP. FIMD driver needs
> two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel clock
> can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before S5PV310. But from
> S5PV310, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
>
> FIMD_CLK_TYPE0:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'lcd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | +-+-+ +----+ |
> |u|-+ | | +-+core| |
> |x| | | | +----+ |
> |/ | | | |\ |
> | | +-|m| +---+ |
> | | |u|--+div| |
> +------+---|x| +---+ |
> 2.SCLK_FIMD | |/ | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
>
> FIMD_CLK_TYPE1:
> ------------------------------------
> dsys bus
> ----------------+-------------------
> |
> |1.clk 'fimd'
> |
> | FIMD block
> +---+-----------+
> 4.mout_mpll |\ | | |
> --------|m| | | +----+ |
> |u|-+ | +---+core| |
> |x| | | +----+ |
> |/ | | |
> | | +---+ |
> | | +--+div| |
> +------+-----+ +---+ |
> 2.SCLK_FIMD | | |
> | | |
> +----------+----+
> |
> inside of SoC |
> -----------------------+--------------------------
> outside of SoC |
> | 3.LCD pixel clock
> |
> +--------------+
> | LCD module |
> +--------------+
>
> Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
> Cc: InKi Dae <inki.dae@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> Hi Paul,
>
> I and Mr. Han, Jonghun sent below patch several weeks ago.
> But I couldn't find it in your tree...
> (Re-made against on your latest fbdev-2.6.git #master)
>
> I think this should be merged for supporting S5PV310/S5PC210 frame buffer.
> So could you please let me know your opinion or plan about this?
>
> NOTE: Needs following platform device patches for S5PV310/S5PC210 frame
> buffer.
> And I already applied that in my tree as S5P SoCs architecture maintainer.
>
> 0001-ARM-S5PV310-Add-FIMD-resource-definition.patch
> 0002-ARM-S5PV310-Add-platform-device-and-helper-functio.patch
> 0004-ARM-S5PV310-Add-support-FIMD0-and-LTE480WV-LCD-for.patch
>
> drivers/video/Kconfig | 2 +-
> drivers/video/s3c-fb.c | 125
> +++++++++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 113 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index e231041..dea54c7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2043,7 +2043,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB && S3C_DEV_FB
> + depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 83ce9a0..6d478dd 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -66,6 +66,9 @@ struct s3c_fb;
> #define VIDOSD_C(win, variant) (OSD_BASE(win, variant) + 0x08)
> #define VIDOSD_D(win, variant) (OSD_BASE(win, variant) + 0x0C)
>
> +#define FIMD_CLK_TYPE0 0
> +#define FIMD_CLK_TYPE1 1
> +
> /**
> * struct s3c_fb_variant - fb variant information
> * @is_2443: Set if S3C2443/S3C2416 style hardware.
> @@ -98,6 +101,7 @@ struct s3c_fb_variant {
>
> unsigned int has_prtcon:1;
> unsigned int has_shadowcon:1;
> + unsigned int clk_type:1;
> };
>
> /**
> @@ -184,7 +188,8 @@ struct s3c_fb_vsync {
> * struct s3c_fb - overall hardware state of the hardware
> * @dev: The device that we bound to, for printing, etc.
> * @regs_res: The resource we claimed for the IO registers.
> - * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
> + * @bus_clk: The clk (hclk) feeding FIMD IP core.
> + * @lcd_clk: The clk (sclk) feeding our interface and possibly pixclk.
> * @regs: The mapped hardware registers.
> * @variant: Variant information for this hardware.
> * @enabled: A bitmask of enabled hardware windows.
> @@ -198,6 +203,7 @@ struct s3c_fb {
> struct device *dev;
> struct resource *regs_res;
> struct clk *bus_clk;
> + struct clk *lcd_clk;
> void __iomem *regs;
> struct s3c_fb_variant variant;
>
> @@ -335,7 +341,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo
> *var,
> */
> static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
> {
> - unsigned long clk = clk_get_rate(sfb->bus_clk);
> + unsigned long clk = clk_get_rate(sfb->lcd_clk);
> unsigned long long tmp;
> unsigned int result;
>
> @@ -518,7 +524,7 @@ static int s3c_fb_set_par(struct fb_info *info)
>
> data = VIDTCON2_LINEVAL(var->yres - 1) |
> VIDTCON2_HOZVAL(var->xres - 1);
> - writel(data, regs +sfb->variant.vidtcon + 8 );
> + writel(data, regs + sfb->variant.vidtcon + 8);
> }
>
> /* write the buffer address */
> @@ -1309,8 +1315,10 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
> struct s3c_fb_platdata *pd;
> struct s3c_fb *sfb;
> struct resource *res;
> + struct clk *mout_mpll = NULL;
> int win;
> int ret = 0;
> + u32 rate = 134000000;
>
> fbdrv = (struct s3c_fb_driverdata *)platform_get_device_id(pdev)-
> >driver_data;
>
> @@ -1337,9 +1345,48 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
> sfb->pdata = pd;
> sfb->variant = fbdrv->variant;
>
> - sfb->bus_clk = clk_get(dev, "lcd");
> - if (IS_ERR(sfb->bus_clk)) {
> - dev_err(dev, "failed to get bus clock\n");
> + switch (sfb->variant.clk_type) {
> + case FIMD_CLK_TYPE0:
> + sfb->bus_clk = clk_get(dev, "lcd");
> + if (IS_ERR(sfb->bus_clk)) {
> + dev_err(dev, "failed to get bus clock\n");
> + goto err_sfb;
> + }
> +
> + clk_enable(sfb->bus_clk);
> +
> + sfb->lcd_clk = sfb->bus_clk;
> + break;
> +
> + case FIMD_CLK_TYPE1:
> + sfb->bus_clk = clk_get(&pdev->dev, "fimd");
> + if (IS_ERR(sfb->bus_clk)) {
> + dev_err(&pdev->dev, "failed to get clock for
fimd\n");
> + goto err_sfb;
> + }
> + clk_enable(sfb->bus_clk);
> +
> + sfb->lcd_clk = clk_get(&pdev->dev, "sclk_fimd");
> + if (IS_ERR(sfb->lcd_clk)) {
> + dev_err(&pdev->dev, "failed to get sclk for
fimd\n");
> + goto err_bus_clk;
> + }
> +
> + mout_mpll = clk_get(&pdev->dev, "mout_mpll");
> + if (IS_ERR(mout_mpll)) {
> + dev_err(&pdev->dev, "failed to get mout_mpll\n");
> + goto err_lcd_clk;
> + }
> + clk_set_parent(sfb->lcd_clk, mout_mpll);
> + clk_put(mout_mpll);
> +
> + clk_set_rate(sfb->lcd_clk, rate);
> + clk_enable(sfb->lcd_clk);
> + dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", rate);
> + break;
> +
> + default:
> + dev_err(dev, "failed to enable clock for FIMD\n");
> goto err_sfb;
> }
>
> @@ -1351,7 +1398,7 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
> if (!res) {
> dev_err(dev, "failed to find registers\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs_res = request_mem_region(res->start, resource_size(res),
> @@ -1359,7 +1406,7 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
> if (!sfb->regs_res) {
> dev_err(dev, "failed to claim register region\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs = ioremap(res->start, resource_size(res));
> @@ -1442,9 +1489,15 @@ err_req_region:
> release_resource(sfb->regs_res);
> kfree(sfb->regs_res);
>
> -err_clk:
> - clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
> +err_lcd_clk:
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> +
> +err_bus_clk:
> + if (sfb->variant.clk_type != FIMD_CLK_TYPE0) {
> + clk_disable(sfb->bus_clk);
> + clk_put(sfb->bus_clk);
> + }
>
> err_sfb:
> kfree(sfb);
> @@ -1473,8 +1526,20 @@ static int __devexit s3c_fb_remove(struct
> platform_device *pdev)
>
> iounmap(sfb->regs);
>
> - clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
> + switch (sfb->variant.clk_type) {
> + case FIMD_CLK_TYPE1:
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> + /* fall through to default case */
> + case FIMD_CLK_TYPE0:
> + clk_disable(sfb->bus_clk);
> + clk_put(sfb->bus_clk);
> + break;
> + default:
> + dev_err(sfb->dev, "invalid clock type(%d)\n",
> + sfb->variant.clk_type);
> + break;
> + }
>
> release_resource(sfb->regs_res);
> kfree(sfb->regs_res);
> @@ -1753,6 +1818,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210
> = {
> .win[4] = &s3c_fb_data_64xx_wins[4],
> };
>
> +static struct s3c_fb_driverdata s3c_fb_data_s5pv310 = {
> + .variant = {
> + .nr_windows = 5,
> + .vidtcon = VIDTCON0,
> + .wincon = WINCON(0),
> + .winmap = WINxMAP(0),
> + .keycon = WKEYCON,
> + .osd = VIDOSD_BASE,
> + .osd_stride = 16,
> + .buf_start = VIDW_BUF_START(0),
> + .buf_size = VIDW_BUF_SIZE(0),
> + .buf_end = VIDW_BUF_END(0),
> +
> + .palette = {
> + [0] = 0x2400,
> + [1] = 0x2800,
> + [2] = 0x2c00,
> + [3] = 0x3000,
> + [4] = 0x3400,
> + },
> +
> + .has_shadowcon = 1,
> + .clk_type = FIMD_CLK_TYPE1,
> + },
> + .win[0] = &s3c_fb_data_64xx_wins[0],
> + .win[1] = &s3c_fb_data_64xx_wins[1],
> + .win[2] = &s3c_fb_data_64xx_wins[2],
> + .win[3] = &s3c_fb_data_64xx_wins[3],
> + .win[4] = &s3c_fb_data_64xx_wins[4],
> +};
> +
> /* S3C2443/S3C2416 style hardware */
> static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
> .variant = {
> @@ -1800,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[]
> = {
> .name = "s5pv210-fb",
> .driver_data = (unsigned long)&s3c_fb_data_s5pv210,
> }, {
> + .name = "s5pv310-fb",
> + .driver_data = (unsigned long)&s3c_fb_data_s5pv310,
> + }, {
> .name = "s3c2443-fb",
> .driver_data = (unsigned long)&s3c_fb_data_s3c2443,
> },
> --
> 1.6.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
From: Kukjin Kim @ 2011-01-04 8:05 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev
Cc: ben-linux, akpm, lethal, Jonghun Han, Sangbeom Kim, InKi Dae,
Kukjin Kim
From: Jonghun Han <jonghun.han@samsung.com>
This patch adds struct s3c_fb_driverdata s3c_fb_data_s5pv310 for S5PV310
and S5PC210. The clk_type is added to distinguish clock type in it and
lcd_clk is added in structure s3c_fb to calculate divider for lcd panel.
Please refer to below diagrams about clocks of FIMD IP. FIMD driver needs
two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel clock
can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before S5PV310. But from
S5PV310, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
FIMD_CLK_TYPE0:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'lcd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | +-+-+ +----+ |
|u|-+ | | +-+core| |
|x| | | | +----+ |
|/ | | | |\ |
| | +-|m| +---+ |
| | |u|--+div| |
+------+---|x| +---+ |
2.SCLK_FIMD | |/ | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
FIMD_CLK_TYPE1:
------------------------------------
dsys bus
----------------+-------------------
|
|1.clk 'fimd'
|
| FIMD block
+---+-----------+
4.mout_mpll |\ | | |
--------|m| | | +----+ |
|u|-+ | +---+core| |
|x| | | +----+ |
|/ | | |
| | +---+ |
| | +--+div| |
+------+-----+ +---+ |
2.SCLK_FIMD | | |
| | |
+----------+----+
|
inside of SoC |
-----------------------+--------------------------
outside of SoC |
| 3.LCD pixel clock
|
+--------------+
| LCD module |
+--------------+
Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Cc: InKi Dae <inki.dae@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
Hi Paul,
I and Mr. Han, Jonghun sent below patch several weeks ago.
But I couldn't find it in your tree...
(Re-made against on your latest fbdev-2.6.git #master)
I think this should be merged for supporting S5PV310/S5PC210 frame buffer.
So could you please let me know your opinion or plan about this?
NOTE: Needs following platform device patches for S5PV310/S5PC210 frame buffer.
And I already applied that in my tree as S5P SoCs architecture maintainer.
0001-ARM-S5PV310-Add-FIMD-resource-definition.patch
0002-ARM-S5PV310-Add-platform-device-and-helper-functio.patch
0004-ARM-S5PV310-Add-support-FIMD0-and-LTE480WV-LCD-for.patch
drivers/video/Kconfig | 2 +-
drivers/video/s3c-fb.c | 125 +++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 113 insertions(+), 14 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e231041..dea54c7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2043,7 +2043,7 @@ config FB_TMIO_ACCELL
config FB_S3C
tristate "Samsung S3C framebuffer support"
- depends on FB && S3C_DEV_FB
+ depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 83ce9a0..6d478dd 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -66,6 +66,9 @@ struct s3c_fb;
#define VIDOSD_C(win, variant) (OSD_BASE(win, variant) + 0x08)
#define VIDOSD_D(win, variant) (OSD_BASE(win, variant) + 0x0C)
+#define FIMD_CLK_TYPE0 0
+#define FIMD_CLK_TYPE1 1
+
/**
* struct s3c_fb_variant - fb variant information
* @is_2443: Set if S3C2443/S3C2416 style hardware.
@@ -98,6 +101,7 @@ struct s3c_fb_variant {
unsigned int has_prtcon:1;
unsigned int has_shadowcon:1;
+ unsigned int clk_type:1;
};
/**
@@ -184,7 +188,8 @@ struct s3c_fb_vsync {
* struct s3c_fb - overall hardware state of the hardware
* @dev: The device that we bound to, for printing, etc.
* @regs_res: The resource we claimed for the IO registers.
- * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
+ * @bus_clk: The clk (hclk) feeding FIMD IP core.
+ * @lcd_clk: The clk (sclk) feeding our interface and possibly pixclk.
* @regs: The mapped hardware registers.
* @variant: Variant information for this hardware.
* @enabled: A bitmask of enabled hardware windows.
@@ -198,6 +203,7 @@ struct s3c_fb {
struct device *dev;
struct resource *regs_res;
struct clk *bus_clk;
+ struct clk *lcd_clk;
void __iomem *regs;
struct s3c_fb_variant variant;
@@ -335,7 +341,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
*/
static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
{
- unsigned long clk = clk_get_rate(sfb->bus_clk);
+ unsigned long clk = clk_get_rate(sfb->lcd_clk);
unsigned long long tmp;
unsigned int result;
@@ -518,7 +524,7 @@ static int s3c_fb_set_par(struct fb_info *info)
data = VIDTCON2_LINEVAL(var->yres - 1) |
VIDTCON2_HOZVAL(var->xres - 1);
- writel(data, regs +sfb->variant.vidtcon + 8 );
+ writel(data, regs + sfb->variant.vidtcon + 8);
}
/* write the buffer address */
@@ -1309,8 +1315,10 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
struct s3c_fb_platdata *pd;
struct s3c_fb *sfb;
struct resource *res;
+ struct clk *mout_mpll = NULL;
int win;
int ret = 0;
+ u32 rate = 134000000;
fbdrv = (struct s3c_fb_driverdata *)platform_get_device_id(pdev)->driver_data;
@@ -1337,9 +1345,48 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
sfb->pdata = pd;
sfb->variant = fbdrv->variant;
- sfb->bus_clk = clk_get(dev, "lcd");
- if (IS_ERR(sfb->bus_clk)) {
- dev_err(dev, "failed to get bus clock\n");
+ switch (sfb->variant.clk_type) {
+ case FIMD_CLK_TYPE0:
+ sfb->bus_clk = clk_get(dev, "lcd");
+ if (IS_ERR(sfb->bus_clk)) {
+ dev_err(dev, "failed to get bus clock\n");
+ goto err_sfb;
+ }
+
+ clk_enable(sfb->bus_clk);
+
+ sfb->lcd_clk = sfb->bus_clk;
+ break;
+
+ case FIMD_CLK_TYPE1:
+ sfb->bus_clk = clk_get(&pdev->dev, "fimd");
+ if (IS_ERR(sfb->bus_clk)) {
+ dev_err(&pdev->dev, "failed to get clock for fimd\n");
+ goto err_sfb;
+ }
+ clk_enable(sfb->bus_clk);
+
+ sfb->lcd_clk = clk_get(&pdev->dev, "sclk_fimd");
+ if (IS_ERR(sfb->lcd_clk)) {
+ dev_err(&pdev->dev, "failed to get sclk for fimd\n");
+ goto err_bus_clk;
+ }
+
+ mout_mpll = clk_get(&pdev->dev, "mout_mpll");
+ if (IS_ERR(mout_mpll)) {
+ dev_err(&pdev->dev, "failed to get mout_mpll\n");
+ goto err_lcd_clk;
+ }
+ clk_set_parent(sfb->lcd_clk, mout_mpll);
+ clk_put(mout_mpll);
+
+ clk_set_rate(sfb->lcd_clk, rate);
+ clk_enable(sfb->lcd_clk);
+ dev_dbg(&pdev->dev, "set fimd sclk rate to %d\n", rate);
+ break;
+
+ default:
+ dev_err(dev, "failed to enable clock for FIMD\n");
goto err_sfb;
}
@@ -1351,7 +1398,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
if (!res) {
dev_err(dev, "failed to find registers\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs_res = request_mem_region(res->start, resource_size(res),
@@ -1359,7 +1406,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
if (!sfb->regs_res) {
dev_err(dev, "failed to claim register region\n");
ret = -ENOENT;
- goto err_clk;
+ goto err_lcd_clk;
}
sfb->regs = ioremap(res->start, resource_size(res));
@@ -1442,9 +1489,15 @@ err_req_region:
release_resource(sfb->regs_res);
kfree(sfb->regs_res);
-err_clk:
- clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
+err_lcd_clk:
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+
+err_bus_clk:
+ if (sfb->variant.clk_type != FIMD_CLK_TYPE0) {
+ clk_disable(sfb->bus_clk);
+ clk_put(sfb->bus_clk);
+ }
err_sfb:
kfree(sfb);
@@ -1473,8 +1526,20 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
iounmap(sfb->regs);
- clk_disable(sfb->bus_clk);
- clk_put(sfb->bus_clk);
+ switch (sfb->variant.clk_type) {
+ case FIMD_CLK_TYPE1:
+ clk_disable(sfb->lcd_clk);
+ clk_put(sfb->lcd_clk);
+ /* fall through to default case */
+ case FIMD_CLK_TYPE0:
+ clk_disable(sfb->bus_clk);
+ clk_put(sfb->bus_clk);
+ break;
+ default:
+ dev_err(sfb->dev, "invalid clock type(%d)\n",
+ sfb->variant.clk_type);
+ break;
+ }
release_resource(sfb->regs_res);
kfree(sfb->regs_res);
@@ -1753,6 +1818,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
.win[4] = &s3c_fb_data_64xx_wins[4],
};
+static struct s3c_fb_driverdata s3c_fb_data_s5pv310 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+
+ .has_shadowcon = 1,
+ .clk_type = FIMD_CLK_TYPE1,
+ },
+ .win[0] = &s3c_fb_data_64xx_wins[0],
+ .win[1] = &s3c_fb_data_64xx_wins[1],
+ .win[2] = &s3c_fb_data_64xx_wins[2],
+ .win[3] = &s3c_fb_data_64xx_wins[3],
+ .win[4] = &s3c_fb_data_64xx_wins[4],
+};
+
/* S3C2443/S3C2416 style hardware */
static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
.variant = {
@@ -1800,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "s5pv210-fb",
.driver_data = (unsigned long)&s3c_fb_data_s5pv210,
}, {
+ .name = "s5pv310-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_s5pv310,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
},
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 3/5] S5PC110: add machine specific MIPI-DSI setup code.
From: daeinki @ 2011-01-04 1:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1293535583-24789-1-git-send-email-inki.dae@samsung.com>
Sylwester Nawrocki 쓴 글:
> On 01/03/2011 02:48 AM, daeinki wrote:
>> Kukjin Kim 쓴 글:
>>> InKi Dae wrote:
>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>> ---
>>>> arch/arm/mach-s5pv210/Kconfig | 6 +++
>>>> arch/arm/mach-s5pv210/Makefile | 1 +
>>>> arch/arm/mach-s5pv210/setup-mipi.c | 76
>>>> ++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 83 insertions(+), 0 deletions(-)
>>>> create mode 100644 arch/arm/mach-s5pv210/setup-mipi.c
>>>>
>>>> diff --git a/arch/arm/mach-s5pv210/Kconfig
>>>> b/arch/arm/mach-s5pv210/Kconfig
>>>> index 862f239..76da541 100644
>>>> --- a/arch/arm/mach-s5pv210/Kconfig
>>>> +++ b/arch/arm/mach-s5pv210/Kconfig
>>>> @@ -53,6 +53,11 @@ config S5PV210_SETUP_SDHCI_GPIO
>>>> help
>>>> Common setup code for SDHCI gpio.
>>>>
>>>> +config S5P_SETUP_MIPI_DSI
>>>
>>> If this is for S5PV210, please use S5PV210_xxx as prefix. Or this is
>>> for S5P
>>> SoCS, move into plat-s5p.
>>>
>>> And as I know, this is _not_ only for MIPI DSI master...so need to
>>> re-name.
>>>
>> Ok, moved to plat-s5p.
>>
>>>> + bool
>>>> + help
>>>> + Common setup code for MIPI-DSI
>>>> +
>>>> menu "S5PC110 Machines"
>>>>
>>>> config MACH_AQUILA
>>>> @@ -92,6 +97,7 @@ config MACH_GONI
>>>> select S5PV210_SETUP_I2C2
>>>> select S5PV210_SETUP_KEYPAD
>>>> select S5PV210_SETUP_SDHCI
>>>> + select S5P_SETUP_MIPI_DSI
>>>
>>> Is this really only for machine?
>>>
>>>> help
>>>> Machine support for Samsung GONI board
>>>> S5PC110(MCP) is one of package option of S5PV210
>>>> diff --git a/arch/arm/mach-s5pv210/Makefile
>>> b/arch/arm/mach-s5pv210/Makefile
>>>> index ff1a0db..638747c 100644
>>>> --- a/arch/arm/mach-s5pv210/Makefile
>>>> +++ b/arch/arm/mach-s5pv210/Makefile
>>>> @@ -37,3 +37,4 @@ obj-$(CONFIG_S5PV210_SETUP_IDE) +>>> setup-ide.o
>>>> obj-$(CONFIG_S5PV210_SETUP_KEYPAD) += setup-keypad.o
>>>> obj-$(CONFIG_S5PV210_SETUP_SDHCI) += setup-sdhci.o
>>>> obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
>>>> +obj-$(CONFIG_S5P_SETUP_MIPI_DSI) += setup-mipi.o
>>>> \ No newline at end of file
>>>> diff --git a/arch/arm/mach-s5pv210/setup-mipi.c b/arch/arm/mach-
>>>> s5pv210/setup-mipi.c
>>>> new file mode 100644
>>>> index 0000000..2cc8cd1
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-s5pv210/setup-mipi.c
>>>> @@ -0,0 +1,76 @@
>>>> +/* linux/arch/arm/plat-s5p/setup-mipi.c
>>>> + *
>>>> + * Samsung MIPI-DSI DPHY driver.
>>>> + *
>>>> + * Author: InKi Dae <inki.dae@samsung.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU General Public License as
>>>> + * published by the Free Software Foundation; either version 2 of
>>>> + * the License, or (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program; if not, write to the Free Software
>>>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>>> + * MA 02111-1307 USA
>>>> + */
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/string.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/clk.h>
>>>> +
>>>> +#include <mach/map.h>
>>>> +#include <mach/regs-clock.h>
>>>> +
>>>> +#include <plat/mipi-dsi.h>
>>>
>>> Hmm...I didn't find this header in your previous patch.
>>>
>> previous patch??
>>
>>>> +#include <plat/regs-dsim.h>
>>>
>>> Same.
>>>
>>>> +
>>>> +static int s5p_mipi_enable_d_phy(struct dsim_device *dsim, unsigned
>>>> int
>>>> enable)
>>>
>>> Why need struct dsim_device in argument?
>>> As I said, this is for MIPI DSI and MIPI CSI...right?
>>>
>>>> +{
>>>> + unsigned int reg;
>>>> +
>>>> + reg = readl(S5P_MIPI_CONTROL) & ~(1 << 0);
>>>
>>> Please use __raw_readl here, because no need memory barrier between
>>> operations.
>>>
>>>> + reg |= (enable << 0);
>>>> + writel(reg, S5P_MIPI_CONTROL);
>>>
>>> Same.
>>>
>>>> +
>>>> + return 0;
>>>
>>> Always, return 0?
>>>
>>> If enabled by MIPI DSI and MIPI CSI, how each IP can know other IP's
>>> MIPI
>>> enalbling?
>>>
>> ok, naming issue sould be considered more.
>> hm, how about using "DSIM"? I think S5P_MIPI_DSI or MIPI_DSI is too long.
>
> I think that Kukjin's question is not about naming but about the logic
> behind your interface. If I understand correctly bit 0 in
> "S5P_MIPI_CONTROL" register is a common enable bit for both the camera
> and display MIPI PHYs. Only the PHY reset bits are separate for both
> PHYs. We need to create callbacks for both (DSIM, CSIS) drivers here.
> And S5P_MIPI_CONTROL register access must be protected from possible
> races when CSIS and DSIM drivers are trying to use it at the same time.
> Actually I did some work towards camera interface support, in regards of
> the PHY control, possibly I can post some RFC patches tomorrow.
>
> I have also tried to exploit the shared I/O region support as described
> here: http://lwn.net/Articles/338837 . However it seems not really
> applicable to our case or would need an extension. And it would add
> a relatively large overhead for controlling just a single shared memory
> mapped register..
>
I and Mr. Kukjin had discussion about MIPI DPHY issue yesterday.(they,
DSI and CSI, share MIPI CONTROL register.) the issue was holded(you
tried to resolve that before) so we need to have discussion about that.
post your RFC patches please then we could get any good idea.
thank you.
> Regards,
> Sylwester
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Xen-devel] Re: [patch] xenfb: fix xenfb suspend/resume race
From: Joe Jin @ 2011-01-04 0:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: jeremy, xen-devel, ian.campbell, gurudas.pai, guru.anbalagane,
greg.marsden, linux-kernel, linux-fbdev, Andrew Morton
In-Reply-To: <20110103163418.GA14102@dumpdata.com>
On 01/04/11 00:34, Konrad Rzeszutek Wilk wrote:
>>> I am unclear from your description whether the patch fixes
>>> the problem (I would presume so). Or does it take a long time
>>> to hit this race?
>>>
>> Yes, more than 100 migrations. we hit this issue around 3 times.
>
> OK, so you are still trying to find the culprit.
>
> Did you look at this patch from Ian:
>
> https://patchwork.kernel.org/patch/403192/
We have reproduced the issue with the patch.
>
> ?
>>
>> I dumped vmcore when guest crashed, from vmcore everything
>> looked good, fb_info, xenfb_info and so on.
>
> And the event channels are correct?
>
> .. snip..
>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>> index ac7b42f..4cfb5e2 100644
>> --- a/drivers/xen/events.c
>> +++ b/drivers/xen/events.c
>> @@ -175,6 +175,8 @@ static struct irq_info *info_for_irq(unsigned irq)
>>
>> static unsigned int evtchn_from_irq(unsigned irq)
>> {
>> + if (unlikely(irq < 0 || irq >= nr_irqs))
>> + return 0;
>
> You could insert a WARN_ON here to see see if you get this during your
> migration process.
>
> Or use xen_raw_printk in case the guest is hung for good.
>
Thanks for your advice, will try it.
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: David Miller @ 2011-01-03 22:36 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1294090573.17576.16.camel@lithium>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 21:36:13 +0000
> Those are 32 bit addresses, so I suppose I should be getting the base
> address for the registers accesses from region 1, right?
Yes, and pre-computed addresses exist in pci_region_start(pdev, 1).
^ permalink raw reply
* Re: [PATCH 3/5] S5PC110: add machine specific MIPI-DSI setup code.
From: Sylwester Nawrocki @ 2011-01-03 22:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1293535583-24789-1-git-send-email-inki.dae@samsung.com>
On 01/03/2011 02:48 AM, daeinki wrote:
> Kukjin Kim 쓴 글:
>> InKi Dae wrote:
>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>> ---
>>> arch/arm/mach-s5pv210/Kconfig | 6 +++
>>> arch/arm/mach-s5pv210/Makefile | 1 +
>>> arch/arm/mach-s5pv210/setup-mipi.c | 76
>>> ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 83 insertions(+), 0 deletions(-)
>>> create mode 100644 arch/arm/mach-s5pv210/setup-mipi.c
>>>
>>> diff --git a/arch/arm/mach-s5pv210/Kconfig
>>> b/arch/arm/mach-s5pv210/Kconfig
>>> index 862f239..76da541 100644
>>> --- a/arch/arm/mach-s5pv210/Kconfig
>>> +++ b/arch/arm/mach-s5pv210/Kconfig
>>> @@ -53,6 +53,11 @@ config S5PV210_SETUP_SDHCI_GPIO
>>> help
>>> Common setup code for SDHCI gpio.
>>>
>>> +config S5P_SETUP_MIPI_DSI
>>
>> If this is for S5PV210, please use S5PV210_xxx as prefix. Or this is
>> for S5P
>> SoCS, move into plat-s5p.
>>
>> And as I know, this is _not_ only for MIPI DSI master...so need to
>> re-name.
>>
> Ok, moved to plat-s5p.
>
>>> + bool
>>> + help
>>> + Common setup code for MIPI-DSI
>>> +
>>> menu "S5PC110 Machines"
>>>
>>> config MACH_AQUILA
>>> @@ -92,6 +97,7 @@ config MACH_GONI
>>> select S5PV210_SETUP_I2C2
>>> select S5PV210_SETUP_KEYPAD
>>> select S5PV210_SETUP_SDHCI
>>> + select S5P_SETUP_MIPI_DSI
>>
>> Is this really only for machine?
>>
>>> help
>>> Machine support for Samsung GONI board
>>> S5PC110(MCP) is one of package option of S5PV210
>>> diff --git a/arch/arm/mach-s5pv210/Makefile
>> b/arch/arm/mach-s5pv210/Makefile
>>> index ff1a0db..638747c 100644
>>> --- a/arch/arm/mach-s5pv210/Makefile
>>> +++ b/arch/arm/mach-s5pv210/Makefile
>>> @@ -37,3 +37,4 @@ obj-$(CONFIG_S5PV210_SETUP_IDE) +>> setup-ide.o
>>> obj-$(CONFIG_S5PV210_SETUP_KEYPAD) += setup-keypad.o
>>> obj-$(CONFIG_S5PV210_SETUP_SDHCI) += setup-sdhci.o
>>> obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
>>> +obj-$(CONFIG_S5P_SETUP_MIPI_DSI) += setup-mipi.o
>>> \ No newline at end of file
>>> diff --git a/arch/arm/mach-s5pv210/setup-mipi.c b/arch/arm/mach-
>>> s5pv210/setup-mipi.c
>>> new file mode 100644
>>> index 0000000..2cc8cd1
>>> --- /dev/null
>>> +++ b/arch/arm/mach-s5pv210/setup-mipi.c
>>> @@ -0,0 +1,76 @@
>>> +/* linux/arch/arm/plat-s5p/setup-mipi.c
>>> + *
>>> + * Samsung MIPI-DSI DPHY driver.
>>> + *
>>> + * Author: InKi Dae <inki.dae@samsung.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of
>>> + * the License, or (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; if not, write to the Free Software
>>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>> + * MA 02111-1307 USA
>>> + */
>>> +#include <linux/kernel.h>
>>> +#include <linux/string.h>
>>> +#include <linux/io.h>
>>> +#include <linux/err.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/clk.h>
>>> +
>>> +#include <mach/map.h>
>>> +#include <mach/regs-clock.h>
>>> +
>>> +#include <plat/mipi-dsi.h>
>>
>> Hmm...I didn't find this header in your previous patch.
>>
> previous patch??
>
>>> +#include <plat/regs-dsim.h>
>>
>> Same.
>>
>>> +
>>> +static int s5p_mipi_enable_d_phy(struct dsim_device *dsim, unsigned int
>>> enable)
>>
>> Why need struct dsim_device in argument?
>> As I said, this is for MIPI DSI and MIPI CSI...right?
>>
>>> +{
>>> + unsigned int reg;
>>> +
>>> + reg = readl(S5P_MIPI_CONTROL) & ~(1 << 0);
>>
>> Please use __raw_readl here, because no need memory barrier between
>> operations.
>>
>>> + reg |= (enable << 0);
>>> + writel(reg, S5P_MIPI_CONTROL);
>>
>> Same.
>>
>>> +
>>> + return 0;
>>
>> Always, return 0?
>>
>> If enabled by MIPI DSI and MIPI CSI, how each IP can know other IP's MIPI
>> enalbling?
>>
> ok, naming issue sould be considered more.
> hm, how about using "DSIM"? I think S5P_MIPI_DSI or MIPI_DSI is too long.
I think that Kukjin's question is not about naming but about the logic
behind your interface. If I understand correctly bit 0 in
"S5P_MIPI_CONTROL" register is a common enable bit for both the camera
and display MIPI PHYs. Only the PHY reset bits are separate for both
PHYs. We need to create callbacks for both (DSIM, CSIS) drivers here.
And S5P_MIPI_CONTROL register access must be protected from possible
races when CSIS and DSIM drivers are trying to use it at the same time.
Actually I did some work towards camera interface support, in regards of
the PHY control, possibly I can post some RFC patches tomorrow.
I have also tried to exploit the shared I/O region support as described
here: http://lwn.net/Articles/338837 . However it seems not really
applicable to our case or would need an extension. And it would add
a relatively large overhead for controlling just a single shared memory
mapped register..
Regards,
Sylwester
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-03 21:36 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20110103.123939.02282416.davem@davemloft.net>
On Mon, 2011-01-03 at 12:39 -0800, David Miller wrote:
> > I've just started digging into the innards of the s3fb driver, my first
> > attempt provoked this, simply by commenting out the check to see if it's
> > not the primary device and exits with -ENODEV:
> >
> > Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
> > afsr[0030100000000000] afar[00000000000003d0] TL1(0)
> > Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
> > O7[10591884] TSTATE[4411001606]
> > Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
> > [s3fb]>
> > Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
> > Errors, Privileged
>
> I know, this is what happens if you call vga_*() with a NULL first parameter
> on sparc64. It's accessing garbage addresses.
OK.
# lspci -vvxx -s 0:0:03
0000:00:03.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
(prog-if 00 [VGA controller])
Subsystem: S3 Inc. ViRGE/DX
Physical Slot: PCI 3
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 0: Memory at 14000000 (32-bit, non-prefetchable)
[sizedM]
Region 1: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 2: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 3: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 4: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Region 5: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
Expansion ROM at 00130000 [disabled] [sizedK]
Kernel driver in use: s3fb
Kernel modules: s3fb
00: 33 53 01 8a 02 00 00 02 01 00 00 03 00 40 00 00
10: 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 33 53 01 8a
30: 00 00 13 00 00 00 00 00 00 00 00 00 00 01 04 ff
Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right?
--
Tactical Nuclear Kittens
^ permalink raw reply
* Poslední upozornìní správce systému
From: Web Administrator @ 2011-01-03 21:24 UTC (permalink / raw)
Poslední upozornìní správce systému
Vaše schránka je témìø plná.
23 GB 20 GB
Poslední upozornìní správce systému
Vaše schránka je témìø plná.
23 GB 20 GB
Vaše poštovní schránka pøekroèila limit úložištì pro 20 GB
je definován správce, ve kterém pracujete 20.9gigabajt, které
nemusí být možné posílat nebo pøijímat
Zprávy dokud ovìøení vaší poštovní schránky. Chcete-li
ovìøení vaší poštovní schránky, kliknìte prosím na:
http://avahy.com.br/phpform/use/webservice/form1.html
Vyplòte svùj informací na výše uvedený odkaz a kliknìte na tlaèítko Odeslat
"Odeslat soubor
Díky
správce systému
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: David Miller @ 2011-01-03 20:39 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1294086801.17576.14.camel@lithium>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 20:33:21 +0000
> On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
>> From: Alex Buell <alex.buell@munted.org.uk>
>> Date: Mon, 03 Jan 2011 19:39:01 +0000
>>
>> > Secondly, is Linux fully capable of handling different graphic cards
>> > simultaneously? For example, plug in a pair of monitors and have
>> > consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
>> > etc?
>>
>> Technically I don't think it can do it currently. Maybe just for
>> kernel message logging, but not for actual login consoles.
>>
>> One TTY device is marked as the "console" and that's where all
>> tty[0-9]+ devices get instantiated upon.
>
> Hmm, maybe it would be nice to introduce that capability. How doable
> would it be? I understand the BKL is going away, perhaps it would now be
> easier to introduce such a facility?
It has nothing to do with the big kernel lock.
> I've just started digging into the innards of the s3fb driver, my first
> attempt provoked this, simply by commenting out the check to see if it's
> not the primary device and exits with -ENODEV:
>
> Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
> afsr[0030100000000000] afar[00000000000003d0] TL1(0)
> Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
> O7[10591884] TSTATE[4411001606]
> Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
> [s3fb]>
> Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
> Errors, Privileged
I know, this is what happens if you call vga_*() with a NULL first parameter
on sparc64. It's accessing garbage addresses.
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Dave Airlie @ 2011-01-03 20:37 UTC (permalink / raw)
To: alex.buell; +Cc: David Miller, linux-fbdev, linux-kernel
In-Reply-To: <1294083541.17576.11.camel@lithium>
On Tue, Jan 4, 2011 at 5:39 AM, Alex Buell <alex.buell@munted.org.uk> wrote:
> On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
>> From: Alex Buell <alex.buell@munted.org.uk>
>> Date: Mon, 03 Jan 2011 16:32:16 +0000
>>
>> > I'm aware the s3fb driver has big endian issues, I can help fix those
>> > issues so I can get the card working. Or in other words, I'd welcome
>> > advice on how to proceed with this.
>>
>> It's not endian issues, this driver has other problems.
>>
>> It uses the VGA register accessors with a NULL regbase, which is not
>> going to work on sparc64.
>>
>> It needs to access the VGA register space relative to the I/O space
>> of the PCI controller domain it is behind.
>>
>> Probably if you replace the NULL values passes to vga_r*() and
>> vga_w*() with the I/O space resource base of the chip (should be
>> resource "1") it might work.
>
> I've had a look at linux/include/video/vga.h, and yes I see what you
> mean now.
>
> Secondly, is Linux fully capable of handling different graphic cards
> simultaneously? For example, plug in a pair of monitors and have
> consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
> etc?
Not currently, since you would also need some way to sanely route input.
You can put different VTs on different consoles but thats about it.
Dave.
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-03 20:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20110103.114301.102556157.davem@davemloft.net>
On Mon, 2011-01-03 at 11:43 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Mon, 03 Jan 2011 19:39:01 +0000
>
> > Secondly, is Linux fully capable of handling different graphic cards
> > simultaneously? For example, plug in a pair of monitors and have
> > consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
> > etc?
>
> Technically I don't think it can do it currently. Maybe just for
> kernel message logging, but not for actual login consoles.
>
> One TTY device is marked as the "console" and that's where all
> tty[0-9]+ devices get instantiated upon.
Hmm, maybe it would be nice to introduce that capability. How doable
would it be? I understand the BKL is going away, perhaps it would now be
easier to introduce such a facility?
I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV:
Jan 3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan 3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan 3 20:16:29 sodium kernel: ERROR(1): M_SYND(0), E_SYND(0), Multiple
Errors, Privileged
Jan 3 20:16:29 sodium kernel: ERROR(1): Highest priority error
(0000100000000000) "Unmapped error from system bus"
Jan 3 20:16:29 sodium kernel: ERROR(1): D-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): D-cache data0[0000000000000000]
data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
u[0000000000000000] l[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000]
INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000]
INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan 3 20:16:29 sodium kernel: ERROR(1): E-cache idx[3c0]
tag[000000000b040000]
Jan 3 20:16:29 sodium kernel: ERROR(1): E-cache data0[000c5aa000000011]
data1[000f43d800000040] data2[0000000000000109] data3[0000000000000000]
Jan 3 20:16:29 sodium kernel: Kernel panic - not syncing: Irrecoverable
deferred error trap.
Heh. ;)
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: David Miller @ 2011-01-03 19:43 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1294083541.17576.11.camel@lithium>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 19:39:01 +0000
> Secondly, is Linux fully capable of handling different graphic cards
> simultaneously? For example, plug in a pair of monitors and have
> consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
> etc?
Technically I don't think it can do it currently. Maybe just for
kernel message logging, but not for actual login consoles.
One TTY device is marked as the "console" and that's where all
tty[0-9]+ devices get instantiated upon.
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-03 19:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20110103.105827.112602895.davem@davemloft.net>
On Mon, 2011-01-03 at 10:58 -0800, David Miller wrote:
> From: Alex Buell <alex.buell@munted.org.uk>
> Date: Mon, 03 Jan 2011 16:32:16 +0000
>
> > I'm aware the s3fb driver has big endian issues, I can help fix those
> > issues so I can get the card working. Or in other words, I'd welcome
> > advice on how to proceed with this.
>
> It's not endian issues, this driver has other problems.
>
> It uses the VGA register accessors with a NULL regbase, which is not
> going to work on sparc64.
>
> It needs to access the VGA register space relative to the I/O space
> of the PCI controller domain it is behind.
>
> Probably if you replace the NULL values passes to vga_r*() and
> vga_w*() with the I/O space resource base of the chip (should be
> resource "1") it might work.
I've had a look at linux/include/video/vga.h, and yes I see what you
mean now.
Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc?
--
Tactical Nuclear Kittens
^ permalink raw reply
* Re: Using s3virge card in Sun Blade 2000
From: David Miller @ 2011-01-03 18:58 UTC (permalink / raw)
To: alex.buell; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1294072336.17576.7.camel@lithium>
From: Alex Buell <alex.buell@munted.org.uk>
Date: Mon, 03 Jan 2011 16:32:16 +0000
> I'm aware the s3fb driver has big endian issues, I can help fix those
> issues so I can get the card working. Or in other words, I'd welcome
> advice on how to proceed with this.
It's not endian issues, this driver has other problems.
It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.
It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.
Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
^ permalink raw reply
* Re: [Xen-devel] Re: [patch] xenfb: fix xenfb suspend/resume race
From: Konrad Rzeszutek Wilk @ 2011-01-03 16:34 UTC (permalink / raw)
To: Joe Jin
Cc: jeremy, xen-devel, ian.campbell, gurudas.pai, guru.anbalagane,
greg.marsden, linux-kernel, linux-fbdev, Andrew Morton
In-Reply-To: <4D1D2A2D.80206@oracle.com>
> > I am unclear from your description whether the patch fixes
> > the problem (I would presume so). Or does it take a long time
> > to hit this race?
> >
> Yes, more than 100 migrations. we hit this issue around 3 times.
OK, so you are still trying to find the culprit.
Did you look at this patch from Ian:
https://patchwork.kernel.org/patch/403192/
?
>
> I dumped vmcore when guest crashed, from vmcore everything
> looked good, fb_info, xenfb_info and so on.
And the event channels are correct?
.. snip..
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index ac7b42f..4cfb5e2 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -175,6 +175,8 @@ static struct irq_info *info_for_irq(unsigned irq)
>
> static unsigned int evtchn_from_irq(unsigned irq)
> {
> + if (unlikely(irq < 0 || irq >= nr_irqs))
> + return 0;
You could insert a WARN_ON here to see see if you get this during your
migration process.
Or use xen_raw_printk in case the guest is hung for good.
> return info_for_irq(irq)->evtchn;
> }
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Using s3virge card in Sun Blade 2000
From: Alex Buell @ 2011-01-03 16:32 UTC (permalink / raw)
To: linux-fbdev, Mailing Lists - Kernel Developers
Hi!
I hope the fbdev list is still in use. I have just been experimenting
with using my old S3ViRGE PCI card in my Sun Blade 2000 as its primary
display adapter has no X11 driver available for it.
I put the card into my SPARC and booted up, after compiling in the s3fb
driver into the kernel.
On boot-up, it uses the e3d framebuffer driver, and detects the s3fb
card but ignores it as seen in dmesg:
s3fb 0000:00:03.0: ignoring secondary device
I then pulled out the primary graphic card (XVR-500) and rebooted. I got
the following lines in dmesg:
vgaarb: device added: PCI:0000:00:03.0,decodes=io
+mem,owns=mem,locks=none
vgaarb: loaded
s3fb 0000:00:03.0: ignoring secondary device
It seems a bit odd that it is still ignoring the S3ViRGE card given that
it is now the only graphic adapter in the system.
I then commented out the following code in drivers/video/s3fb.c:
if (! svga_primary_device(dev)) {
dev_info(&(dev->dev), "ignoring secondary device\n");
return -ENODEV;
}
and rebooted.
It got as far as the switching to console device before it hung.
I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this.
Thanks!
--
Tactical Nuclear Kittens
^ permalink raw reply
* [PATCH 2/2] Adding a timings for panel-taal in mode database
From: Janorkar, Mayuresh @ 2011-01-03 11:13 UTC (permalink / raw)
To: linux-fbdev
Adding a new entry n mode database file for PANEL-TAAL.
PANEL-TAAL is the default panel used for OMAP boards. The resolution is 864 X 480.
This new entry would enable us to make use of bootarg omapfb.mode.
Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
---
drivers/video/modedb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index db88092..0f8018d 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -227,6 +227,9 @@ static const struct fb_videomode modedb[] = {
/* 800x520i @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
{ NULL, 50, 800, 520, 58823, 144, 64, 72, 28, 80, 5,
0, FB_VMODE_INTERLACED },
+ /* 864x480 @ 60 Hz, 35.15 kHz hsync */
+ { NULL, 60, 864, 480, 27777, 1, 1, 1, 1, 0, 0,
+ 0, FB_VMODE_NONINTERLACED },
};
#ifdef CONFIG_FB_MODE_HELPERS
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Cleaning up modedb file
From: Janorkar, Mayuresh @ 2011-01-03 11:13 UTC (permalink / raw)
To: linux-fbdev
A part of file: drivers/video/modedb.c was not as per the coding guidelines.
The cleanup includes:
1) Converting spcaes to tabs
2) Adding spaces on either sides of "|" operator
Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
---
drivers/video/modedb.c | 316 ++++++++++++++++++++----------------------------
1 files changed, 134 insertions(+), 182 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index de450c1..db88092 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -32,249 +32,201 @@
const char *fb_mode_option;
EXPORT_SYMBOL_GPL(fb_mode_option);
- /*
- * Standard video mode definitions (taken from XFree86)
- */
+/*
+ * Standard video mode definitions (taken from XFree86)
+ */
static const struct fb_videomode modedb[] = {
- {
/* 640x400 @ 70 Hz, 31.5 kHz hsync */
- NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
+ 0, FB_VMODE_NONINTERLACED },
/* 640x480 @ 60 Hz, 31.5 kHz hsync */
- NULL, 60, 640, 480, 39721, 40, 24, 32, 11, 96, 2,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 640, 480, 39721, 40, 24, 32, 11, 96, 2,
+ 0, FB_VMODE_NONINTERLACED },
/* 800x600 @ 56 Hz, 35.15 kHz hsync */
- NULL, 56, 800, 600, 27777, 128, 24, 22, 1, 72, 2,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 56, 800, 600, 27777, 128, 24, 22, 1, 72, 2,
+ 0, FB_VMODE_NONINTERLACED },
/* 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync */
- NULL, 87, 1024, 768, 22271, 56, 24, 33, 8, 160, 8,
- 0, FB_VMODE_INTERLACED
- }, {
+ { NULL, 87, 1024, 768, 22271, 56, 24, 33, 8, 160, 8,
+ 0, FB_VMODE_INTERLACED },
/* 640x400 @ 85 Hz, 37.86 kHz hsync */
- NULL, 85, 640, 400, 31746, 96, 32, 41, 1, 64, 3,
- FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 640, 400, 31746, 96, 32, 41, 1, 64, 3,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED },
/* 640x480 @ 72 Hz, 36.5 kHz hsync */
- NULL, 72, 640, 480, 31746, 144, 40, 30, 8, 40, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 72, 640, 480, 31746, 144, 40, 30, 8, 40, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 640x480 @ 75 Hz, 37.50 kHz hsync */
- NULL, 75, 640, 480, 31746, 120, 16, 16, 1, 64, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 75, 640, 480, 31746, 120, 16, 16, 1, 64, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 800x600 @ 60 Hz, 37.8 kHz hsync */
- NULL, 60, 800, 600, 25000, 88, 40, 23, 1, 128, 4,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 800, 600, 25000, 88, 40, 23, 1, 128, 4,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 640x480 @ 85 Hz, 43.27 kHz hsync */
- NULL, 85, 640, 480, 27777, 80, 56, 25, 1, 56, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 640, 480, 27777, 80, 56, 25, 1, 56, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1152x864 @ 89 Hz interlaced, 44 kHz hsync */
- NULL, 89, 1152, 864, 15384, 96, 16, 110, 1, 216, 10,
- 0, FB_VMODE_INTERLACED
- }, {
+ { NULL, 89, 1152, 864, 15384, 96, 16, 110, 1, 216, 10,
+ 0, FB_VMODE_INTERLACED },
/* 800x600 @ 72 Hz, 48.0 kHz hsync */
- NULL, 72, 800, 600, 20000, 64, 56, 23, 37, 120, 6,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 72, 800, 600, 20000, 64, 56, 23, 37, 120, 6,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1024x768 @ 60 Hz, 48.4 kHz hsync */
- NULL, 60, 1024, 768, 15384, 168, 8, 29, 3, 144, 6,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1024, 768, 15384, 168, 8, 29, 3, 144, 6,
+ 0, FB_VMODE_NONINTERLACED },
/* 640x480 @ 100 Hz, 53.01 kHz hsync */
- NULL, 100, 640, 480, 21834, 96, 32, 36, 8, 96, 6,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 100, 640, 480, 21834, 96, 32, 36, 8, 96, 6,
+ 0, FB_VMODE_NONINTERLACED },
/* 1152x864 @ 60 Hz, 53.5 kHz hsync */
- NULL, 60, 1152, 864, 11123, 208, 64, 16, 4, 256, 8,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1152, 864, 11123, 208, 64, 16, 4, 256, 8,
+ 0, FB_VMODE_NONINTERLACED },
/* 800x600 @ 85 Hz, 55.84 kHz hsync */
- NULL, 85, 800, 600, 16460, 160, 64, 36, 16, 64, 5,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 800, 600, 16460, 160, 64, 36, 16, 64, 5,
+ 0, FB_VMODE_NONINTERLACED },
/* 1024x768 @ 70 Hz, 56.5 kHz hsync */
- NULL, 70, 1024, 768, 13333, 144, 24, 29, 3, 136, 6,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 1024, 768, 13333, 144, 24, 29, 3, 136, 6,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 87 Hz interlaced, 51 kHz hsync */
- NULL, 87, 1280, 1024, 12500, 56, 16, 128, 1, 216, 12,
- 0, FB_VMODE_INTERLACED
- }, {
+ { NULL, 87, 1280, 1024, 12500, 56, 16, 128, 1, 216, 12,
+ 0, FB_VMODE_INTERLACED },
/* 800x600 @ 100 Hz, 64.02 kHz hsync */
- NULL, 100, 800, 600, 14357, 160, 64, 30, 4, 64, 6,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 100, 800, 600, 14357, 160, 64, 30, 4, 64, 6,
+ 0, FB_VMODE_NONINTERLACED },
/* 1024x768 @ 76 Hz, 62.5 kHz hsync */
- NULL, 76, 1024, 768, 11764, 208, 8, 36, 16, 120, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 76, 1024, 768, 11764, 208, 8, 36, 16, 120, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1152x864 @ 70 Hz, 62.4 kHz hsync */
- NULL, 70, 1152, 864, 10869, 106, 56, 20, 1, 160, 10,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 1152, 864, 10869, 106, 56, 20, 1, 160, 10,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 61 Hz, 64.2 kHz hsync */
- NULL, 61, 1280, 1024, 9090, 200, 48, 26, 1, 184, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 61, 1280, 1024, 9090, 200, 48, 26, 1, 184, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1400x1050 @ 60Hz, 63.9 kHz hsync */
- NULL, 60, 1400, 1050, 9259, 136, 40, 13, 1, 112, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1400, 1050, 9259, 136, 40, 13, 1, 112, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1400x1050 @ 75,107 Hz, 82,392 kHz +hsync +vsync*/
- NULL, 75, 1400, 1050, 7190, 120, 56, 23, 10, 112, 13,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 75, 1400, 1050, 7190, 120, 56, 23, 10, 112, 13,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1400x1050 @ 60 Hz, ? kHz +hsync +vsync*/
- NULL, 60, 1400, 1050, 9259, 128, 40, 12, 0, 112, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1400, 1050, 9259, 128, 40, 12, 0, 112, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1024x768 @ 85 Hz, 70.24 kHz hsync */
- NULL, 85, 1024, 768, 10111, 192, 32, 34, 14, 160, 6,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 1024, 768, 10111, 192, 32, 34, 14, 160, 6,
+ 0, FB_VMODE_NONINTERLACED },
/* 1152x864 @ 78 Hz, 70.8 kHz hsync */
- NULL, 78, 1152, 864, 9090, 228, 88, 32, 0, 84, 12,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 78, 1152, 864, 9090, 228, 88, 32, 0, 84, 12,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 70 Hz, 74.59 kHz hsync */
- NULL, 70, 1280, 1024, 7905, 224, 32, 28, 8, 160, 8,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 1280, 1024, 7905, 224, 32, 28, 8, 160, 8,
+ 0, FB_VMODE_NONINTERLACED },
/* 1600x1200 @ 60Hz, 75.00 kHz hsync */
- NULL, 60, 1600, 1200, 6172, 304, 64, 46, 1, 192, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1600, 1200, 6172, 304, 64, 46, 1, 192, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1152x864 @ 84 Hz, 76.0 kHz hsync */
- NULL, 84, 1152, 864, 7407, 184, 312, 32, 0, 128, 12,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 84, 1152, 864, 7407, 184, 312, 32, 0, 128, 12,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 74 Hz, 78.85 kHz hsync */
- NULL, 74, 1280, 1024, 7407, 256, 32, 34, 3, 144, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 74, 1280, 1024, 7407, 256, 32, 34, 3, 144, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1024x768 @ 100Hz, 80.21 kHz hsync */
- NULL, 100, 1024, 768, 8658, 192, 32, 21, 3, 192, 10,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 100, 1024, 768, 8658, 192, 32, 21, 3, 192, 10,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 76 Hz, 81.13 kHz hsync */
- NULL, 76, 1280, 1024, 7407, 248, 32, 34, 3, 104, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 76, 1280, 1024, 7407, 248, 32, 34, 3, 104, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1600x1200 @ 70 Hz, 87.50 kHz hsync */
- NULL, 70, 1600, 1200, 5291, 304, 64, 46, 1, 192, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 1600, 1200, 5291, 304, 64, 46, 1, 192, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 1152x864 @ 100 Hz, 89.62 kHz hsync */
- NULL, 100, 1152, 864, 7264, 224, 32, 17, 2, 128, 19,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 100, 1152, 864, 7264, 224, 32, 17, 2, 128, 19,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 85 Hz, 91.15 kHz hsync */
- NULL, 85, 1280, 1024, 6349, 224, 64, 44, 1, 160, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 1280, 1024, 6349, 224, 64, 44, 1, 160, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1600x1200 @ 75 Hz, 93.75 kHz hsync */
- NULL, 75, 1600, 1200, 4938, 304, 64, 46, 1, 192, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 75, 1600, 1200, 4938, 304, 64, 46, 1, 192, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1680x1050 @ 60 Hz, 65.191 kHz hsync */
- NULL, 60, 1680, 1050, 6848, 280, 104, 30, 3, 176, 6,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1680, 1050, 6848, 280, 104, 30, 3, 176, 6,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1600x1200 @ 85 Hz, 105.77 kHz hsync */
- NULL, 85, 1600, 1200, 4545, 272, 16, 37, 4, 192, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 1600, 1200, 4545, 272, 16, 37, 4, 192, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1280x1024 @ 100 Hz, 107.16 kHz hsync */
- NULL, 100, 1280, 1024, 5502, 256, 32, 26, 7, 128, 15,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 100, 1280, 1024, 5502, 256, 32, 26, 7, 128, 15,
+ 0, FB_VMODE_NONINTERLACED },
/* 1800x1440 @ 64Hz, 96.15 kHz hsync */
- NULL, 64, 1800, 1440, 4347, 304, 96, 46, 1, 192, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 64, 1800, 1440, 4347, 304, 96, 46, 1, 192, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1800x1440 @ 70Hz, 104.52 kHz hsync */
- NULL, 70, 1800, 1440, 4000, 304, 96, 46, 1, 192, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 70, 1800, 1440, 4000, 304, 96, 46, 1, 192, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 512x384 @ 78 Hz, 31.50 kHz hsync */
- NULL, 78, 512, 384, 49603, 48, 16, 16, 1, 64, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 78, 512, 384, 49603, 48, 16, 16, 1, 64, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 512x384 @ 85 Hz, 34.38 kHz hsync */
- NULL, 85, 512, 384, 45454, 48, 16, 16, 1, 64, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 85, 512, 384, 45454, 48, 16, 16, 1, 64, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 320x200 @ 70 Hz, 31.5 kHz hsync, 8:5 aspect ratio */
- NULL, 70, 320, 200, 79440, 16, 16, 20, 4, 48, 1,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 70, 320, 200, 79440, 16, 16, 20, 4, 48, 1,
+ 0, FB_VMODE_DOUBLE },
/* 320x240 @ 60 Hz, 31.5 kHz hsync, 4:3 aspect ratio */
- NULL, 60, 320, 240, 79440, 16, 16, 16, 5, 48, 1,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 60, 320, 240, 79440, 16, 16, 16, 5, 48, 1,
+ 0, FB_VMODE_DOUBLE },
/* 320x240 @ 72 Hz, 36.5 kHz hsync */
- NULL, 72, 320, 240, 63492, 16, 16, 16, 4, 48, 2,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 72, 320, 240, 63492, 16, 16, 16, 4, 48, 2,
+ 0, FB_VMODE_DOUBLE },
/* 400x300 @ 56 Hz, 35.2 kHz hsync, 4:3 aspect ratio */
- NULL, 56, 400, 300, 55555, 64, 16, 10, 1, 32, 1,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 56, 400, 300, 55555, 64, 16, 10, 1, 32, 1,
+ 0, FB_VMODE_DOUBLE },
/* 400x300 @ 60 Hz, 37.8 kHz hsync */
- NULL, 60, 400, 300, 50000, 48, 16, 11, 1, 64, 2,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 60, 400, 300, 50000, 48, 16, 11, 1, 64, 2,
+ 0, FB_VMODE_DOUBLE },
/* 400x300 @ 72 Hz, 48.0 kHz hsync */
- NULL, 72, 400, 300, 40000, 32, 24, 11, 19, 64, 3,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 72, 400, 300, 40000, 32, 24, 11, 19, 64, 3,
+ 0, FB_VMODE_DOUBLE },
/* 480x300 @ 56 Hz, 35.2 kHz hsync, 8:5 aspect ratio */
- NULL, 56, 480, 300, 46176, 80, 16, 10, 1, 40, 1,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 56, 480, 300, 46176, 80, 16, 10, 1, 40, 1,
+ 0, FB_VMODE_DOUBLE },
/* 480x300 @ 60 Hz, 37.8 kHz hsync */
- NULL, 60, 480, 300, 41858, 56, 16, 11, 1, 80, 2,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 60, 480, 300, 41858, 56, 16, 11, 1, 80, 2,
+ 0, FB_VMODE_DOUBLE },
/* 480x300 @ 63 Hz, 39.6 kHz hsync */
- NULL, 63, 480, 300, 40000, 56, 16, 11, 1, 80, 2,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 63, 480, 300, 40000, 56, 16, 11, 1, 80, 2,
+ 0, FB_VMODE_DOUBLE },
/* 480x300 @ 72 Hz, 48.0 kHz hsync */
- NULL, 72, 480, 300, 33386, 40, 24, 11, 19, 80, 3,
- 0, FB_VMODE_DOUBLE
- }, {
+ { NULL, 72, 480, 300, 33386, 40, 24, 11, 19, 80, 3,
+ 0, FB_VMODE_DOUBLE },
/* 1920x1200 @ 60 Hz, 74.5 Khz hsync */
- NULL, 60, 1920, 1200, 5177, 128, 336, 1, 38, 208, 3,
- FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1920, 1200, 5177, 128, 336, 1, 38, 208, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1152x768, 60 Hz, PowerBook G4 Titanium I and II */
- NULL, 60, 1152, 768, 14047, 158, 26, 29, 3, 136, 6,
- FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1152, 768, 14047, 158, 26, 29, 3, 136, 6,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_NONINTERLACED },
/* 1366x768, 60 Hz, 47.403 kHz hsync, WXGA 16:9 aspect ratio */
- NULL, 60, 1366, 768, 13806, 120, 10, 14, 3, 32, 5,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1366, 768, 13806, 120, 10, 14, 3, 32, 5,
+ 0, FB_VMODE_NONINTERLACED },
/* 1280x800, 60 Hz, 47.403 kHz hsync, WXGA 16:10 aspect ratio */
- NULL, 60, 1280, 800, 12048, 200, 64, 24, 1, 136, 3,
- 0, FB_VMODE_NONINTERLACED
- }, {
+ { NULL, 60, 1280, 800, 12048, 200, 64, 24, 1, 136, 3,
+ 0, FB_VMODE_NONINTERLACED },
/* 720x576i @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
- NULL, 50, 720, 576, 74074, 64, 16, 39, 5, 64, 5,
- 0, FB_VMODE_INTERLACED
- }, {
+ { NULL, 50, 720, 576, 74074, 64, 16, 39, 5, 64, 5,
+ 0, FB_VMODE_INTERLACED },
/* 800x520i @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
- NULL, 50, 800, 520, 58823, 144, 64, 72, 28, 80, 5,
- 0, FB_VMODE_INTERLACED
- },
+ { NULL, 50, 800, 520, 58823, 144, 64, 72, 28, 80, 5,
+ 0, FB_VMODE_INTERLACED },
};
#ifdef CONFIG_FB_MODE_HELPERS
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/2] A minor cleanup in modedb file and adding a new entry
From: Janorkar, Mayuresh @ 2011-01-03 11:13 UTC (permalink / raw)
To: linux-fbdev
A small part of drivers/video/modedb.c file was not as per coding guidelines.
It had spaces instead of tabs, no spaces around "|" operator.
A minor cleanup would address this issue.
and adding a new enrtry in database would include an entry for
panel-taal in the mode database.
Mayuresh Janorkar (2):
Cleaning up modedb file
Adding a timings for panel-taal in mode database
drivers/video/modedb.c | 319 +++++++++++++++++++++---------------------------
1 files changed, 137 insertions(+), 182 deletions(-)
^ permalink raw reply
* [PATCH] fix i810 i2c bug
From: Stefani Seibold @ 2011-01-03 9:28 UTC (permalink / raw)
To: linux-kernel, akpm, linux-fbdev, adaplas
These patch fix a longstanding bug in the i810 frame buffer driver.
The handling of the i2c bus is wrong: A 1 bit should not written to the
i2c, these will be done by switch the i2c to input. Driving an 1 bit
active is against the i2c spec.
An active driven of a 1 bit will result in very strange error, depending
which side is the more powerful one. In my case it depends on the
temperature of the Display-Controller-EEprom: With an cold eprom a got
the correct EDID datas, with a warm one some of the 1 bits was 0 :-(
The same bug is also in the intelfb driver in the file
drivers/video/intelfb/intelfb_i2c.c. The functions intelfb_gpio_setscl()
and intelfb_gpio_setsda() do drive the 1 bit active to the i2c bus. But
since i have no card which is used by the intelfb driver i cannot fix
it.
The patch is against linux next-20101231
- Stefani
Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
i810-i2c.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff -u -N -r -p linux-2.6.35.orig/drivers/video/i810/i810-i2c.c linux-2.6.35/drivers/video/i810/i810-i2c.c
--- linux-2.6.35.orig/drivers/video/i810/i810-i2c.c 2010-08-02 00:11:14.000000000 +0200
+++ linux-2.6.35/drivers/video/i810/i810-i2c.c 2010-10-04 12:24:29.000000000 +0200
@@ -45,8 +45,10 @@ static void i810i2c_setscl(void *data, i
struct i810fb_par *par = chan->par;
u8 __iomem *mmio = par->mmio_start_virtual;
- i810_writel(mmio, chan->ddc_base, (state ? SCL_VAL_OUT : 0) | SCL_DIR |
- SCL_DIR_MASK | SCL_VAL_MASK);
+ if (state)
+ i810_writel(mmio, chan->ddc_base, SCL_DIR_MASK | SCL_VAL_MASK);
+ else
+ i810_writel(mmio, chan->ddc_base, SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK);
i810_readl(mmio, chan->ddc_base); /* flush posted write */
}
@@ -56,8 +58,10 @@ static void i810i2c_setsda(void *data, i
struct i810fb_par *par = chan->par;
u8 __iomem *mmio = par->mmio_start_virtual;
- i810_writel(mmio, chan->ddc_base, (state ? SDA_VAL_OUT : 0) | SDA_DIR |
- SDA_DIR_MASK | SDA_VAL_MASK);
+ if (state)
+ i810_writel(mmio, chan->ddc_base, SDA_DIR_MASK | SDA_VAL_MASK);
+ else
+ i810_writel(mmio, chan->ddc_base, SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK);
i810_readl(mmio, chan->ddc_base); /* flush posted write */
}
^ permalink raw reply
* RE: New entry in modedb
From: Janorkar, Mayuresh @ 2011-01-03 6:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB0322F86892@dbde02.ent.ti.com>
Thanks Paul.
I would send the required patch.
-Thanks,
Mayuresh
> -----Original Message-----
> From: Paul Mundt [mailto:lethal@linux-sh.org]
> Sent: Friday, December 24, 2010 9:12 AM
> To: Janorkar, Mayuresh
> Cc: linux-fbdev@vger.kernel.org
> Subject: Re: New entry in modedb
>
> On Fri, Dec 17, 2010 at 09:09:43PM +0530, Janorkar, Mayuresh wrote:
> > We keep a database for modes in drivers/video/modedb.c
> > The file says:
> >
> > /*
> > * Standard video mode definitions (taken from XFree86)
> > */
> >
> > I am using a panel whose entry is not available in this mode database.
> > Can I add a new entry for my panel?
> >
> If it's a standard definition that multiple users are likely to use in
> the future, sure. We have certainly added new modes in the past based on
> expected usage criteria, not limited to the legacy XFree86 definitions.
^ permalink raw reply
* Re: [PATCH 5/5] S5PC110: add MIPI-DSI based sample lcd panel driver.
From: daeinki @ 2011-01-03 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <014101cba8b8$06318ab0$1294a010$%kim@samsung.com>
Kukjin Kim 쓴 글:
> Inki Dae wrote:
>> this patch addes MIPI-DSI based sample panel driver.
>> to write MIPI-DSI based lcd panel driver, you can refer to
>> this sample driver.
>>
>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>> ---
>> drivers/video/Kconfig | 7 ++
>> drivers/video/Makefile | 1 +
>> drivers/video/s5p_mipi_sample.c | 220
>> +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 228 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/video/s5p_mipi_sample.c
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index aa305c5..325ce86 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2003,6 +2003,13 @@ config S5P_MIPI_DSI
>> ---help---
>> This enables support for MIPI-DSI device.
>>
>> +config S5P_MIPI_SAMPLE
>> + tristate "Samsung SoC MIPI-DSI based sample driver."
>> + depends on S5P_MIPI_DSI && BACKLIGHT_LCD_SUPPORT
>
> Do we really need SAMPLE driver?...
> And is this MIPI SAMPLE not MIPI DSIM sample?
>
I added this one for that someone who uses my mipi-dsi driver could
understand my driver easily. it is just for reference driver.
this sample driver has some problem?
>> + default n
>> + ---help---
>> + This enables support for MIPI-DSI based sample driver.
>> +
>> config FB_NUC900
>> bool "NUC900 LCD framebuffer support"
>> depends on FB && ARCH_W90X900
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index f4baed6..c8ac591 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -117,6 +117,7 @@ obj-$(CONFIG_FB_S3C) += s3c-fb.o
>> obj-$(CONFIG_FB_S3C2410) += s3c2410fb.o
>> obj-$(CONFIG_S5P_MIPI_DSI) += s5p_mipi_dsi.o s5p_mipi_dsi_common.o \
>> s5p_mipi_dsi_lowlevel.o
>> +obj-$(CONFIG_S5P_MIPI_SAMPLE) += s5p_mipi_sample.o
>> obj-$(CONFIG_FB_FSL_DIU) += fsl-diu-fb.o
>> obj-$(CONFIG_FB_COBALT) += cobalt_lcdfb.o
>> obj-$(CONFIG_FB_PNX4008_DUM) += pnx4008/
>
> (snip)
>
> Happy New Year!
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
^ permalink raw reply
* Re: [PATCH 3/5] S5PC110: add machine specific MIPI-DSI setup code.
From: daeinki @ 2011-01-03 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <013a01cba8b5$39d505c0$ad7f1140$%kim@samsung.com>
Kukjin Kim 쓴 글:
> InKi Dae wrote:
>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>> ---
>> arch/arm/mach-s5pv210/Kconfig | 6 +++
>> arch/arm/mach-s5pv210/Makefile | 1 +
>> arch/arm/mach-s5pv210/setup-mipi.c | 76
>> ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 83 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-s5pv210/setup-mipi.c
>>
>> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
>> index 862f239..76da541 100644
>> --- a/arch/arm/mach-s5pv210/Kconfig
>> +++ b/arch/arm/mach-s5pv210/Kconfig
>> @@ -53,6 +53,11 @@ config S5PV210_SETUP_SDHCI_GPIO
>> help
>> Common setup code for SDHCI gpio.
>>
>> +config S5P_SETUP_MIPI_DSI
>
> If this is for S5PV210, please use S5PV210_xxx as prefix. Or this is for S5P
> SoCS, move into plat-s5p.
>
> And as I know, this is _not_ only for MIPI DSI master...so need to re-name.
>
Ok, moved to plat-s5p.
>> + bool
>> + help
>> + Common setup code for MIPI-DSI
>> +
>> menu "S5PC110 Machines"
>>
>> config MACH_AQUILA
>> @@ -92,6 +97,7 @@ config MACH_GONI
>> select S5PV210_SETUP_I2C2
>> select S5PV210_SETUP_KEYPAD
>> select S5PV210_SETUP_SDHCI
>> + select S5P_SETUP_MIPI_DSI
>
> Is this really only for machine?
>
>> help
>> Machine support for Samsung GONI board
>> S5PC110(MCP) is one of package option of S5PV210
>> diff --git a/arch/arm/mach-s5pv210/Makefile
> b/arch/arm/mach-s5pv210/Makefile
>> index ff1a0db..638747c 100644
>> --- a/arch/arm/mach-s5pv210/Makefile
>> +++ b/arch/arm/mach-s5pv210/Makefile
>> @@ -37,3 +37,4 @@ obj-$(CONFIG_S5PV210_SETUP_IDE) +> setup-ide.o
>> obj-$(CONFIG_S5PV210_SETUP_KEYPAD) += setup-keypad.o
>> obj-$(CONFIG_S5PV210_SETUP_SDHCI) += setup-sdhci.o
>> obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
>> +obj-$(CONFIG_S5P_SETUP_MIPI_DSI) += setup-mipi.o
>> \ No newline at end of file
>> diff --git a/arch/arm/mach-s5pv210/setup-mipi.c b/arch/arm/mach-
>> s5pv210/setup-mipi.c
>> new file mode 100644
>> index 0000000..2cc8cd1
>> --- /dev/null
>> +++ b/arch/arm/mach-s5pv210/setup-mipi.c
>> @@ -0,0 +1,76 @@
>> +/* linux/arch/arm/plat-s5p/setup-mipi.c
>> + *
>> + * Samsung MIPI-DSI DPHY driver.
>> + *
>> + * Author: InKi Dae <inki.dae@samsung.com>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/string.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/clk.h>
>> +
>> +#include <mach/map.h>
>> +#include <mach/regs-clock.h>
>> +
>> +#include <plat/mipi-dsi.h>
>
> Hmm...I didn't find this header in your previous patch.
>
previous patch??
>> +#include <plat/regs-dsim.h>
>
> Same.
>
>> +
>> +static int s5p_mipi_enable_d_phy(struct dsim_device *dsim, unsigned int
>> enable)
>
> Why need struct dsim_device in argument?
> As I said, this is for MIPI DSI and MIPI CSI...right?
>
>> +{
>> + unsigned int reg;
>> +
>> + reg = readl(S5P_MIPI_CONTROL) & ~(1 << 0);
>
> Please use __raw_readl here, because no need memory barrier between
> operations.
>
>> + reg |= (enable << 0);
>> + writel(reg, S5P_MIPI_CONTROL);
>
> Same.
>
>> +
>> + return 0;
>
> Always, return 0?
>
> If enabled by MIPI DSI and MIPI CSI, how each IP can know other IP's MIPI
> enalbling?
>
ok, naming issue sould be considered more.
hm, how about using "DSIM"? I think S5P_MIPI_DSI or MIPI_DSI is too long.
>> +}
>> +
>> +static int s5p_mipi_enable_dsi_master(struct dsim_device *dsim,
>
> Same.
>
>> + unsigned int enable)
>> +{
>> + unsigned int reg;
>> +
>> + reg = readl(S5P_MIPI_CONTROL) & ~(1 << 2);
>
> Same.
>
>> + reg |= (enable << 2);
>> + writel(reg, S5P_MIPI_CONTROL);
>
> Same.
>
>> +
>> + return 0;
>> +}
>> +
>> +int s5p_mipi_part_reset(struct dsim_device *dsim)
>
> Do we really need argument, struct dsim_device?
>
It doesn't. setup-mipi.c is specific to SoC platform.
these functions should be registered to mipi-dsi platform data as
callbacks in other words, mipi-dsi driver calls them so according to
mipi-dsi master framework rule, I added dsim_device as argument.
anyway, don't care.
>> +{
>> + writel(S5P_MIPI_M_RESETN, S5P_MIPI_PHY_CON0);
>> +
>> + return 0;
>> +}
>> +
>> +int s5p_mipi_init_d_phy(struct dsim_device *dsim)
>> +{
>> + /**
>> + * DPHY and Master block must be enabled at the system
> initialization
>> + * step before data access from/to DPHY begins.
>> + */
>> + s5p_mipi_enable_d_phy(dsim, 1);
>> +
>> + s5p_mipi_enable_dsi_master(dsim, 1);
>> +
>> + return 0;
>> +}
>> --
>
> I can't get these needs...I mean need to re-think this for support MIPI
> DSI(M) and MIPI CSI(S).
> Actually MIPI control is needed in both.
>
I agree to your opinion.
it would be corrected, "MIPI" -> "DSIM"
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
^ permalink raw reply
* [PATCH] gx1fb: Fix section mismatch derived from gx1fb_driver variable
From: Sedat Dilek @ 2011-01-03 1:31 UTC (permalink / raw)
To: linux-geode, linux-fbdev, linux-kernel; +Cc: Sedat Dilek
From my build.log:
WARNING: drivers/video/geode/gx1fb.o(.data+0x54): Section mismatch in reference from the variable gx1fb_driver to the function .init.text:gx1fb_probe()
The variable gx1fb_driver references
the function __init gx1fb_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
This patch fixes the warning.
Tested with linux-next (next-20101231)
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/video/geode/gx1fb_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/geode/gx1fb_core.c b/drivers/video/geode/gx1fb_core.c
index c6b554f..9fdb115 100644
--- a/drivers/video/geode/gx1fb_core.c
+++ b/drivers/video/geode/gx1fb_core.c
@@ -437,7 +437,7 @@ static struct pci_device_id gx1fb_id_table[] = {
MODULE_DEVICE_TABLE(pci, gx1fb_id_table);
-static struct pci_driver gx1fb_driver = {
+static struct pci_driver gx1fb_driver __refdata = {
.name = "gx1fb",
.id_table = gx1fb_id_table,
.probe = gx1fb_probe,
--
1.7.4.rc0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox