[PATCH] intel_scu_pcidrv: add back PCI id for Medfield

[PATCH] intel_scu_pcidrv: add back PCI id for Medfield

[Julian Winkler]

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.

Signed-off-by: Julian Winkler <julian.winkler1@web.de>
---
 drivers/platform/x86/intel_scu_pcidrv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/intel_scu_pcidrv.c b/drivers/platform/x86/intel_scu_pcidrv.c
index 80abc708e4f2..d904fad499aa 100644
--- a/drivers/platform/x86/intel_scu_pcidrv.c
+++ b/drivers/platform/x86/intel_scu_pcidrv.c
@@ -34,6 +34,7 @@ static int intel_scu_pci_probe(struct pci_dev *pdev,
 
 static const struct pci_device_id pci_ids[] = {
 	{ PCI_VDEVICE(INTEL, 0x080e) },
+	{ PCI_VDEVICE(INTEL, 0x082a) },
 	{ PCI_VDEVICE(INTEL, 0x08ea) },
 	{ PCI_VDEVICE(INTEL, 0x0a94) },
 	{ PCI_VDEVICE(INTEL, 0x11a0) },
-- 
2.39.2

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

[Hans de Goede]

Hi Julian,

+Cc Andy, Mika,

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.
> 
> 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 ?

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 ?

Regards,

Hans





> ---
>  drivers/platform/x86/intel_scu_pcidrv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/intel_scu_pcidrv.c b/drivers/platform/x86/intel_scu_pcidrv.c
> index 80abc708e4f2..d904fad499aa 100644
> --- a/drivers/platform/x86/intel_scu_pcidrv.c
> +++ b/drivers/platform/x86/intel_scu_pcidrv.c
> @@ -34,6 +34,7 @@ static int intel_scu_pci_probe(struct pci_dev *pdev,
>  
>  static const struct pci_device_id pci_ids[] = {
>  	{ PCI_VDEVICE(INTEL, 0x080e) },
> +	{ PCI_VDEVICE(INTEL, 0x082a) },
>  	{ PCI_VDEVICE(INTEL, 0x08ea) },
>  	{ PCI_VDEVICE(INTEL, 0x0a94) },
>  	{ PCI_VDEVICE(INTEL, 0x11a0) },

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

[Andy Shevchenko]

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.

> > 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.

> 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).

-- 
With Best Regards,
Andy Shevchenko

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

[Julian Winkler]

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.

>> 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. 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.

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

[Hans de Goede]

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 ?

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

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

[Julian Winkler]

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

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

[Andy Shevchenko]

On Mon, Apr 17, 2023 at 4:02 PM Julian Winkler <julian.winkler1@web.de> 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:
> >> 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.

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

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

[Julian Winkler]

On 25.04.23 21:02, Andy Shevchenko wrote:
> On Mon, Apr 17, 2023 at 4:02 PM Julian Winkler <julian.winkler1@web.de> 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:
>>>> 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.
>
> 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.

>>>> 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). Also, I'm not really familiar with ACPI tables and don't know
if they are flexible enough for my purposes.

> 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.

>> 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.
>

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

[Andy Shevchenko]

On Thu, Apr 27, 2023 at 11:06 AM Julian Winkler <julian.winkler1@web.de> wrote:
> On 25.04.23 21:02, Andy Shevchenko wrote:
> > On Mon, Apr 17, 2023 at 4:02 PM Julian Winkler <julian.winkler1@web.de> 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:
> >>>> 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.
> >
> > 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

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

[Hans de Goede]

Hi Julian,

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.
> 
> Signed-off-by: Julian Winkler <julian.winkler1@web.de>

Thank you for your patch, I've applied this patch to my review-hans 
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Patches which are added to review-hans now are intended for
the next rc1. This branch will get rebased to the next rc1 when
it is out and after the rebasing the contents of review-hans
will be pushed to the platform-drivers-x86/for-next branch.

Regards,

Hans






> ---
>  drivers/platform/x86/intel_scu_pcidrv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/intel_scu_pcidrv.c b/drivers/platform/x86/intel_scu_pcidrv.c
> index 80abc708e4f2..d904fad499aa 100644
> --- a/drivers/platform/x86/intel_scu_pcidrv.c
> +++ b/drivers/platform/x86/intel_scu_pcidrv.c
> @@ -34,6 +34,7 @@ static int intel_scu_pci_probe(struct pci_dev *pdev,
>  
>  static const struct pci_device_id pci_ids[] = {
>  	{ PCI_VDEVICE(INTEL, 0x080e) },
> +	{ PCI_VDEVICE(INTEL, 0x082a) },
>  	{ PCI_VDEVICE(INTEL, 0x08ea) },
>  	{ PCI_VDEVICE(INTEL, 0x0a94) },
>  	{ PCI_VDEVICE(INTEL, 0x11a0) },