[meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module

[Tom Zanussi]

On Fri, 2014-10-10 at 14:14 -0700, Darren Hart wrote:
> On 10/10/14, 12:00, "Tom Zanussi" <tom.zanussi at intel.com> wrote:
> 
> >On Fri, 2014-10-10 at 12:46 -0500, Kamble, Nitin A wrote:
> >> 
> >> On 10/10/14, 10:31 AM, "Zanussi, Tom" <tom.zanussi at intel.com> wrote:
> >> 
> >> >On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
> >> >> 
> >> >> On 10/10/14, 6:37 AM, "Zanussi, Tom" <tom.zanussi at intel.com> wrote:
> >> >> 
> >> >> >On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kamble at intel.com wrote:
> >> >> >> From: Nitin A Kamble <nitin.a.kamble at intel.com>
> >> >> >> 
> >> >> >> The gmx500 graphics driver does not work on this BSP, but it takes
> >> >> >> the ownership of the graphics hardware at boot time, blocking
> >>other
> >> >> >> drivers from using the graphics hardware.
> >> >> >> 
> >> >> >> Fix the issue by blacklisting the gma500_gfx kernel module in the
> >> >>kmod
> >> >> >> configuration, so that it doesn't get loaded at boot time.
> >> >> >> 
> >> >> >
> >> >> >Is this really the right way to do this?  It will only work if
> >> >> >CONFIG_XXX=m.  If m->y at some point, the whole .bbappend becomes
> >> >> >useless at best.
> >> >> 
> >> >> That is why the gma500 is converted from y to m. And with the common
> >> >> kernel,
> >> >> It should be m anyway. If you have better way to solve you can share.
> >> >> 
> >> >
> >> >Why not a config fragment that turns it off for that BSP?
> >> >
> >> >The more general question is whether the common kernel mandates
> >> >everything be 'm' for this reason.
> >> >
> >> >Tom
> >> 
> >> This will be going backwards. We are trying to consolidate kernel and
> >
> >What seems backwards to me is starting with a broken config and using a
> >band-aid to fix the brokenness.
> >
> >> BSPs. 
> >> And this suggested approach will make a separate kernel for this BSP.
> >> 
> >> The common kernel has lot of drivers enabled. And very few of them will
> >>be
> >> actually used on any particular BSP. Not using kernel modules for these
> >> many
> >> drivers will be insane.
> >> 
> >
> >I guess I need to understand the new model where creating an embedded
> >system that only includes what it needs and which therefore doesn't need
> >to be a module is considered "insane".
> >
> >So what you're saying is that not only does everything in an Intel BSP
> >need to be configured as "m", but also that an Intel BSP can't touch the
> >kernel, not even configuration.
> 
> 
> Well, perhaps we need to sync up on this. We have a goal/vision of
> simplifying what is a lot of per-board BSPs where it isn't necessary.
> Since we don't know how each BSP is going to be used, we find we're often
> adding USB drivers, etc. to the kernel configurations. To avoid a huge
> bzImage, we do these as modules wherever feasible. The Linux kernel has
> excellent support for Intel Architecture, which makes pervasive use of
> enumerable and self describing buses and devices - this makes it possible
> to use general purpose images across multiple boards and generations of
> CPUs. Since the use-case tends to have a lot to say about which drivers
> are needed - and we don't know what the use case will be - we serve users
> best, IMO, but providing a highly functional kernel out of the box, and
> enable them to tailor it themselves if they need a minimal image. This in
> turn simplifies our maintenance and support effort through the use of the
> intel-common package arch for the Linux kernel.
> 
> This particular driver challenges that vision, and there will be others,
> but I don't think it defeats it. Worst case we have to drop gma500 from
> the intel common kernel and build emenlow as an independent BSP. For now,
> the blacklist seems like a reasonable workaround to maintain the
> advantages of the common kernel mechanism.
> 
> At least, that's my take on it.
> 
> Thoughts?
> 

Right, so I guess what it boils down to is that the whole common-kernel
philosophy is just fundamentally at odds with the concept of a BSP,
which is what we have here.

I don't object to the goal of a common image for all Intel, etc, but my
point was that if we do have a BSP, it should be allowed to modify the
kernel as needed, and making use of config fragments to directly address
the root problem seems the simplest and most straightforward way to do
that.

If the assumption here is that a dedicated crownbay BSP is going away
soon, then I have no problem pulling in whatever expedient hack works on
the grounds that it's temporary.

Tom

> --
> Darren
> 
> >
> >Tom
> >
> >> Nitin
> >> 
> >> 
> >> >
> >> >> Nitin
> >> >> 
> >> >> 
> >> >> >
> >> >> >Tom
> >> >> >
> >> >> >> Fixes Bug:
> >> >> >> [YOCTO #6807]
> >> >> >> 
> >> >> >> Signed-off-by: Nitin A Kamble <nitin.a.kamble at intel.com>
> >> >> >> ---
> >> >> >>  meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
> >> >> >>  1 file changed, 3 insertions(+)
> >> >> >>  create mode 100644
> >> >>meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
> >> >> >> 
> >> >> >> diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
> >> >> >>b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
> >> >> >> new file mode 100644
> >> >> >> index 0000000..56d8fcb
> >> >> >> --- /dev/null
> >> >> >> +++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
> >> >> >> @@ -0,0 +1,3 @@
> >> >> >> +do_install_append () {
> >> >> >> +	echo "blacklist gma500_gfx" >
> >> >> >>${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
> >> >> >> +}
> >> >> >
> >> >> >
> >> >> 
> >> >
> >> >
> >> 
> >
> >
> >
> 
>