On Thu, Apr 27, 2023 at 11:06 AM Julian Winkler <julian.winkler1@xxxxxx> wrote: > On 25.04.23 21:02, Andy Shevchenko wrote: > > 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? > > Having U-Boot support would be nice. But since I don't have a good way > to debug the boot procedure on my device and the 5.10 mainline kernel > just booted out of the box with working USB and eMMC drivers, it was a > much easier way to go. It's possible to boot U-Boot instead of the v5.10 kernel though. And then it can provide an ACPI table. > >>>> 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. > > The primary reason I chose to use devicetree was that the required > drivers already have devicetree bindings (maxtouch, max17042 and > wl1271). Which is not a problem for ACPI. Most of that can be supported without modifying kernel code. > Also, I'm not really familiar with ACPI tables and don't know > if they are flexible enough for my purposes. More than that. There are some corner cases since DT and ACPI have different paradigms, but ACPI is superior here. As I pointed out the U-Boot already has support for Intel Merrifield, but won't be a big deal to support Medfield since the critical parts are already there (SCU, PMU, ...). > > 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). > I have seen your the comment in 944dcbe84b8ab7efdfcc592b6905a797324da51c > > > 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). > > The bootstub is probably part of the "bos" partition, which also > includes the implementation of androids fastboot protocol, which I need > to reflash my device. Therefore I would rather not risk breaking it. I think the fastboot is a separate stuff, the bootstub is a really slim shim between firmware and the kernel. > >> 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
