>-----Original Message----- >From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of >Joonas Lahtinen >Sent: Friday, September 7, 2018 12:47 AM >To: Nikula, Jani <jani.nikula@xxxxxxxxx>; Vivi, Rodrigo <rodrigo.vivi@xxxxxxxxx> >Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Zanoni, Paulo R <paulo.r.zanoni@xxxxxxxxx> >Subject: Re: [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@xxxxxxxxx> 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? With regard to this patch in particular, shall I send a new version of ICL patch with MODULE_FIRMWARE in it? Thoughts? Thanks, Anusha >Regards, Joonas > >> >> > >> > BR, >> > Jani. >> > >> > -- >> > Jani Nikula, Intel Open Source Graphics Center >_______________________________________________ >Intel-gfx mailing list >Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
