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

[Srivatsa, Anusha]

>-----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? 
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 at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx