Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [120831 04:24]:
> On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote:
> > Hi,
> > 
> > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [120830 00:35]:
> > > On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote:
> > > > 
> > > > Good to see this, we need this badly to avoid blocking
> > > > single zImage effort on omaps. Can you also please take
> > > 
> > > What is the issue with single zImage? How do cpu_is_ check affect it?
> > 
> > The usage for that should only be limited to arch/arm/mach-omap2
> > so we can make cpu.h local as we can't include mach and plat
> > header files from the drivers with single zImage.
> 
> Ok.
> 
> > > $ git grep -E "<plat|<mach" drivers/video/omap*
> > > drivers/video/omap/lcd_ams_delta.c:#include <plat/board-ams-delta.h>
> > > * Needs to be moved
> > 
> > Yes, that should be either mach/board-ams-delta.h, or separate driver
> > specific headers in include/linux/platform_data. For omap1 we are not
> > planning common zImage support, so let's just make sure we're not
> > breaking anything there as people are still using it.
> 
> Hmm, so did I understand right, for omap1 stuff we can still include
> from arch/arm/mach-omap1/include/mach?

Yes that's a separate issue to fix that up for armv4/5 common
zImage support if people want to do that later on.
 
> If so, that makes things easier. I can manage the omap2+ stuff fine, but
> I have no experience with omap1, nor do I have any omap1 devices. So I'd
> rather keep the omap1 code as it is, in fear that I'd just break it
> totally, and I'd rather spend my time on omap2+ code.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Tourism]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux