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@xxxxxxxxxx> 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@xxxxxx> >>> >>> Hmm, so this is a former SFI platform, from your: >>> https://lore.kernel.org/all/20230223060107.23029-1-julian.winkler1@xxxxxx/ >>> >>> 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 ? 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 :) Regards, Hans
