> -----Original Message----- > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > Sent: Friday, May 14, 2010 6:32 PM > To: Guruswamy, Senthilvadivu > Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx; > tony@xxxxxxxxxxx; Hiremath, Vaibhav > Subject: RE: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB > > On Fri, 2010-05-14 at 12:03 +0200, ext Guruswamy, Senthilvadivu wrote: > > > > > -----Original Message----- > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > > > Sent: Friday, May 14, 2010 12:54 PM > > > To: Guruswamy, Senthilvadivu > > > Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx; > > > tony@xxxxxxxxxxx; Hiremath, Vaibhav > > > Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB > > <snip> > > > > The patch set makes VRFB optional. What happens if VRFB > is turned off, > > > and the user uses VRFB for a framebuffer? > > [Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3. > > User would have got an option to turn it OFF if it had appeared in > > the menuconfig selections. I did not give that option in > menuconfig > > explicitly. > > ie config OMAP2_VRFB > > bool <No name given here> > > > > Suppose on a build the user deliberately gives > "CONFIG_OMAP2_VRFB not set", > > then VRFB functions are made as empty functions by the compiler. > > > > This is fine as long as the user does not say omapfb.vrfb=1. > > > > But if the user sets omapfb.vrfb=1, then it is a wrong > usage of the bootargs > > as he has already deliberately changed the defconfig to say > "VRFB not set". > > > > The result of his experiment: No bootup on the board as the > vaddr of VRFB > > is populated nor of the normal RAM buffer. > > The kernel should be able to cope with that. While giving wrong boot > arguments to the kernel causing it to not boot is bad, it could be > somewhat acceptable. But if the user changes the rotation > type via sysfs > file, and the kernel crashes (which is what I fear will happen), it's > totally unacceptable. > > If it's possible to turn VRFB off, then the code should > handle the case > where VRFB is not there. Meaning, returning error values or > somehow else > failing gracefully, and informing the user of wrong arguments. > [Senthil] Yes, I could provide a check in the driver for wrong arguments. > Tomi > > > ��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
