[Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.

[Rodrigo Vivi]

On Fri, Sep 07, 2018 at 06:26:32PM +0000, Srivatsa, Anusha wrote:
> 
> 
> >-----Original Message-----
> >From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of
> >Joonas Lahtinen
> >Sent: Friday, September 7, 2018 12:47 AM
> >To: Nikula, Jani <jani.nikula at intel.com>; Vivi, Rodrigo <rodrigo.vivi at intel.com>
> >Cc: intel-gfx at lists.freedesktop.org; Zanoni, Paulo R <paulo.r.zanoni at intel.com>
> >Subject: Re: [Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.
> >
> >Quoting Rodrigo Vivi (2018-09-06 20:35:19)
> >> On Thu, Sep 06, 2018 at 09:46:13AM +0300, Jani Nikula wrote:
> >> > On Wed, 05 Sep 2018, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> >> > > On Wed, Sep 05, 2018 at 12:07:43PM +0300, Joonas Lahtinen wrote:
> >> > >> Was not the decision that we only gate the MODULE_FIRMWARE line
> >> > >> until the firmware is in linux-firmware.git?
> >> > >>
> >> > >> So it should be no harm to support loading firmwares that are
> >> > >> available from drm-firmware.git as long as we don't add the
> >> > >> MODULE_FIRMWARE which would trigger false positives for distro
> >packagers.
> >> > >
> >> > > As far as I can remember we had agreed on changing this and adding
> >> > > MODULE_FIRMWARE from the beginning.
> >> > >
> >> > > 1. the process gets complex
> >> > > 2. we forgot many times to add it afterwards 3. module_firmware
> >> > > changes nothing... only the fact that initrd generation
> >> > >    wont complain if firmware is not there yet.
> >> > > 4. The old issue was that patches were merged without the pull request
> >> > >    being sent... We fixed that by only accepting patches after pull request
> >> > >    is sent.
> >> > > 5. By the time that all lands to distros linux-firmware.git will
> >> > > have the firmware because of 4.
> >> > > 6. We have now drm-firmware to mirror what official
> >> > > linux-firmware.git will be in few weeks from now.
> >> > >
> >> > > So I don't see a reason anymore why to keep with complicated
> >> > > process with split MODULE_FIRMWARE.
> >> >
> >> > I've changed my mind, I agree with *not* splitting MODULE_FIRMWARE
> >> > changes to another patch anymore.
> >> >
> >> > However, with that I think we need to redefine when we can add
> >> > request_firmware and MODULE_FIRMWARE for a specific firmware blob.
> >> > Here's my proposal.
> >> >
> >> > - Before merging a patch adding or changing a firmware blob in dinq,
> >> >   said blob must be publicly available at a known location, and no known
> >> >   blockers for linux-firmware.git merge may exist.
> >> >
> >> > - We take care to get the blob to linux-firmware.git before the changes
> >> >   hit Linus' -rc1 after the merge window. With our -rc5 feature
> >> >   deadline, this should give us at least 4-5 weeks to get the blob
> >> >   merged to linux-firmware.git.
> >> >
> >> > - It follows that linux-next and drm-tip may contain MODULE_FIRMWARE for
> >> >   blobs that don't exist in linux-firmware.git.
> >>
> >> Agreed. And we should document this somewhere.
> >
> >Well, there are still quite a few conditionals included, if you ask me.
> >
> >But if you see the MODULE_FIRMWARE as a separate patch as such a burden that
> >we should make the assumptions, I can live with it. At least I know who to call in
> >case there was one too many conditional and we get a distro complaint again :)
> 
> Lets hope we wont have anyone complaining.
> 
> Regarding documenting this, Rodrigo, is wiki the place for it? 

I'm not sure where is the best place for this currently.

So for now maybe use the internal one... Unless someone has a better idea.

> With regard to this patch in particular, shall I send a new version of ICL patch with MODULE_FIRMWARE in it? 
> Thoughts?

Let's do this to move with dmc on ICL, but for future fw patches
let's do all in one patch ;)

I just pushed this patch to dinq. Thanks for patch and review.

Now please send a separated one for MODULE_FIRMWARE.


Thanks,
Rodrigo.

> 
> Thanks,
> Anusha 
> >Regards, Joonas
> >
> >>
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> > --
> >> > Jani Nikula, Intel Open Source Graphics Center
> >_______________________________________________
> >Intel-gfx mailing list
> >Intel-gfx at lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx