Re: [PATCH] intel_scu_pcidrv: add back PCI id for Medfield

[Julian Winkler <julian.winkler1@web.de>]

Hi,

On 25.04.23 11:03, Hans de Goede wrote:
> Hi,
>
> On 4/17/23 15:02, Julian Winkler wrote:
>> On 17.04.23 12:16, Andy Shevchenko wrote:
>>> On Mon, Apr 17, 2023 at 1:11 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>> +Cc Andy, Mika,
>>>
>>> Thanks for Cc'ing me.
>>>
>>>> On 4/16/23 17:49, Julian Winkler wrote:
>>>>> This id was removed in b47018a778c1a18cbc98b4a11936dec4f8c4bb7b, saying it
>>>>> is only used on Moorestown, but apparently the same id is also used on
>>>>> Medfield.
>>>>>
>>>>> Tested on the Medfield based Motorola RAZR i smartphone.
>>>
>>> Wow! This is surprising.
>>> Can you tell more about your test environment? What is the Linux
>>> kernel version in use and what is the userspace (AOSP, Buildroot,
>>> Yocto, custom)? If custom, more details would be nice to hear.
>>
>> The test enviroment is postmarketOS. You can find more details on the
>> Wiki page
>> https://wiki.postmarketos.org/wiki/Motorola_RAZR_i_(XT890)_(motorola-smi)
>>
>>>>> Signed-off-by: Julian Winkler <julian.winkler1@web.de>
>>>>
>>>> Hmm, so this is a former SFI platform, from your:
>>>> https://lore.kernel.org/all/20230223060107.23029-1-julian.winkler1@web.de/
>>>>
>>>> patch I guess the plan is to use some custom bootloader
>>>> and then use x86 with devicetree support to replace SFI ?
>>>
>>> That would also be nice to hear in detail. With other Intel MID
>>> platforms the decision was made to pursue ACPI (and U-Boot, as an
>>> example) supports that for Intel Merrifield platform.
>>
>> I boot a 5.10 kernel, which still has SFI support, and from there I can
>> boot latest mainline kernel with petitboot, kexec and devicetree.
>
> Nice, so AFAICT the old 5.10 kernel is hidden/abstracted away in pettit
> boot and the user just sees a bootloader-binary + mainline kernels.
>
> Interesting approach :)
>
>
>>>> Do you already have this working ?
>>>>
>>>> Sorry for all the questions for what is just a simple PCI-id
>>>> addition. I guess I'm worried this is just the tip of
>>>> the iceberg for getting medfield support back into
>>>> the kernel and I'm a bit worried about how much maintenance
>>>> work this will cause.
>>>>
>>>> E.g. also see commit e1da811218d2dc ("drm/gma500: Remove Medfield support")
>>>> which I guess you will want to see reverted too ?
>>>>
>>>> That is an example of a lot more code to bring back
>>>> then just a single PCI-id addition.
>>>>
>>>> Don't get me wrong I'm all for supporting older hw
>>>> if there are users who are interested in actively
>>>> maintaining support for it. I just want to get a feel
>>>> of the amount of work this is going to involve.
>>>>
>>>> Andy, Mika, any remarks ?
>>>
>>> I'm not against a patch if it helps existing users, but we need to
>>> understand first if it will be really helpful for upstream (taking
>>> into account 32-bit Intel MID support removal).
>>
>> My downstream kernel tree can be seen here:
>> https://gitlab.com/julianwi/linux-intel-medfield.
>
> Ok, the amount of patches there does not look to bad. Although there
> are some patches which will need some work before they can be mainlined
> (e.g. the IRQ handling patches).
>
> So what is the long term end goal here. Do you want to get everything
> supported in mainline (sounds feasible to me), or are you just trying
> to reduce your delta to mainline so rebasing is easier ?

Actually I don't have a clear plan. I just thought I would start
submitting some of the trivial patches and see how far it goes. Sadly I
don't have always time to work on this project.

> I guess that for either goal you will want this patch merged and
> it is just a single line, so I'll go and merge this patch now.
>
> If you want to get as much in mainline as possible, I think it would
> be good to try and get the gma500 changes merged. That seems to be
> the biggest change when talking about lines of code. So if you get
> that in place then for discussions surrounding further patches you
> can say that your branch for this is just a couple of 100-s of lines
> code away from mainline and you would like to get those last 100-s
> of lines in mainline :)

I think the gma500 medfield code would need some more cleanups before
being suitable for mainline. It currently includes its own MIPI-DSI
implementation instead of using the available infrastructure in recent
kernel versions.

> Regards,
>
> Hans

Regards,
Julian