On Mon, Apr 17, 2023 at 4:02 PM Julian Winkler <julian.winkler1@xxxxxx> 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: > >> 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. Aha, but would it be possible to boot a U-Boot instead? > >> 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. Okay, I see that it doesn't have many patches, but it still has some code that won't be acceptable upstream. What I would suggest is to actually provide the ACPI tables rather than going Device Tree way. Also note, that GPIO driver has to be integrated into gpio-pxa.c which is the historical parent IP of the Medfield case (it was a mistake to have a separate driver to begin with). U-Boot would be ideal to have flashed there instead of so called bootstub (which is 4k or 8k blob to load kernel and initrd and pass the execution to it). > Indeed, I needed to > bring back some removed code to get the display working, but even > without display driver, old smartphones can be used as a server or > Raspberry Pi replacement. True. P.S. I'm on a long leave, but I can help you with the stuff to be upstreamed and tested, we still have a device available to test in our lab. Just see above. -- With Best Regards, Andy Shevchenko
