pinctrl: intel: merrifield: Introduce OF device table
Subsystems (5)
PATCH v2 1/1 pinctrl: intel: merrifield: Introduce OF device table
On Intel Merrifield the pin control device is a separate IP block without any PCI or ACPI ID assigned. We need some means to allow the device be enumerated in ACPI environment (*).
To achieve this without allocation special ACPI ID, which is really long and pretty much unachievable procedure, we just re-use special ACPI ID and standard compatible string.
(*) ACPI is enabled via second bootloader, i.e. U-Boot,
firmware is still left untouched and being SFI enabled.
---
In v2:
- add DT binding
- we asked internally for ACPI ID about month ago with full silence in response
.../devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt | 13 +++++++++++++ drivers/pinctrl/intel/pinctrl-merrifield.c | 7 +++++++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +13 -0
@@ -0,0 +1,13 @@ +Intel Corporation, Family-Level Interface Shim (FLIS) pin controller + +FLIS pin controller is a separate IP block on non-ACPI enabled Intel +platforms, such as Intel Merrifield. Very known board based on it is +Intel Edison. + +There is an ongoing effort to emulate ACPI on that kind of boards +and, since it is near to impossible to allocate an ACPI ID for the +such controller, the compatible string may be used along with special +PRP0001 ACPI ID. + +Required properties for FLIS pin controller: +- compatible: "intel,merrifield-pinctrl"
drivers/pinctrl/intel/pinctrl-merrifield.c +7 -0
@@ -931,10 +931,17 @@ static int mrfld_pinctrl_probe(struct platform_device *pdev)return 0 ; } +static const struct of_device_id mrfld_of_table[] = { + { .compatible ="intel,merrifield-pinctrl" }, + { }, +}; +MODULE_DEVICE_TABLE (of, mrfld_of_table); +static struct platform_driver mrfld_pinctrl_driver = { .probe = mrfld_pinctrl_probe, .driver = { .name ="pinctrl-merrifield" , + .of_match_table = mrfld_of_table, }, };
Signature · 6 lines
2.14.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170929135539.4046-1-andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]
Hi,
Quoted 8 lines · Andy Shevchenko
On Intel Merrifield the pin control device is a separate IP block without any PCI or ACPI ID assigned. We need some means to allow the device be enumerated in ACPI environment (*).
To achieve this without allocation special ACPI ID, which is really long and pretty much unachievable procedure, we just re-use special ACPI ID and standard compatible string.
Quoted 8 lines
(*) ACPI is enabled via second bootloader, i.e. U-Boot,
firmware is still left untouched and being SFI enabled.---
In v2:
- add DT binding
- we asked internally for ACPI ID about month ago with full silence in response
Just so that I understand, this means that you asked within Intel for an ACPI ID, but couldn't get one allocated?
This sounds like a workaround for an internal process issue.
Surely there are other ACPI folk within Intel you can poke to move that along?
Quoted 11 lines
.../devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt | 13 +++++++++++++ drivers/pinctrl/intel/pinctrl-merrifield.c | 7 +++++++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txtDocumentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +0
-0
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt line 10
Quoted 10 lines
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +10
-0@@ -0,0 +1,13 @@ +Intel Corporation, Family-Level Interface Shim (FLIS) pin controller + +FLIS pin controller is a separate IP block on non-ACPI enabled Intel +platforms, such as Intel Merrifield. Very known board based on it is +Intel Edison. + +There is an ongoing effort to emulate ACPI on that kind of boards +and, since it is near to impossible to allocate an ACPI ID for the +such controller, the compatible string may be used along with special +PRP0001 ACPI ID.
This paragraph is not relevant to the description of the device, nor is any of this relvevant to DT, given (AFAICT), this is only intended to be used with ACPI.
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt line 13
Quoted 3 lines
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +3
-0+ +Required properties for FLIS pin controller: +- compatible: "intel,merrifield-pinctrl"
This only has a compatible string?
As I've mentioned in the past, I'm not a fan of the whole PRP0001 approach, especially given that little care seems to be taken to actually comply with DT standards.
Thanks,
Mark.
Quoted 29 lines
drivers/pinctrl/intel/pinctrl-merrifield.c +7
-0@@ -931,10 +931,17 @@ static int mrfld_pinctrl_probe(struct platform_device *pdev)return 0 ; } +static const struct of_device_id mrfld_of_table[] = { + { .compatible ="intel,merrifield-pinctrl" }, + { }, +}; +MODULE_DEVICE_TABLE (of, mrfld_of_table); +static struct platform_driver mrfld_pinctrl_driver = { .probe = mrfld_pinctrl_probe, .driver = { .name ="pinctrl-merrifield" , + .of_match_table = mrfld_of_table, }, };Signature · 6 lines
2.14.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 23 lines · Mark Rutland
Hi,
Quoted 13 lines · Andy Shevchenko
On Intel Merrifield the pin control device is a separate IP block without any PCI or ACPI ID assigned. We need some means to allow the device be enumerated in ACPI environment (*).
To achieve this without allocation special ACPI ID, which is really long
and pretty much unachievable procedure, we just re-use special ACPI ID
and standard compatible string.(*) ACPI is enabled via second bootloader, i.e. U-Boot,
firmware is still left untouched and being SFI enabled.Quoted 6 lines
---
In v2:
- add DT binding
- we asked internally for ACPI ID about month ago with full silence in response
Quoted 3 lines
Just so that I understand, this means that you asked within Intel for an
ACPI ID, but couldn't get one allocated?
Correct. There are few reasons:
1. Platform was never designed as ACPI
2. Platform is EOL.
3. We tried, we pulled some strings, no ID.
Quoted 1 line
This sounds like a workaround for an internal process issue.
See above. Partially I can agree with you, but technically speaking the platform wasn't designed to be ACPI.
Quoted 3 lines
Surely there are other ACPI folk within Intel you can poke to move that
along?
I dunno. Mika, do you know anyone else we may ask about?
Quoted 7 lines
Quoted 5 lines
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +3
-0+There is an ongoing effort to emulate ACPI on that kind of boards +and, since it is near to impossible to allocate an ACPI ID for the +such controller, the compatible string may be used along withspecial
+PRP0001 ACPI ID.This paragraph is not relevant to the description of the device,
I agree, so, I exclude it in new version.
Quoted 4 lines
nor is
any of this relvevant to DT, given (AFAICT), this is only intended to be
used with ACPI.
Though, no one prevents to use it in DT environment. We chose to bring ACPI support to that platform.
Are you implying we should chose DT over ACPI?
Quoted 5 lines
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt line 13
Quoted 3 lines
Documentation/devicetree/bindings/pinctrl/intel,FLIS-pinctrl.txt new file +3
-0+ +Required properties for FLIS pin controller: +- compatible: "intel,merrifield-pinctrl"This only has a compatible string?
Should it have anything else? Perhaps register base and length? Sure, I will add them.
Quoted 3 lines
As I've mentioned in the past, I'm not a fan of the whole PRP0001 approach, especially given that little care seems to be taken to actually comply with DT standards.
Believe me, we also try to do the right things right, though there is an obstacle we can't jump over as easily as in DT world.
Signature · 6 lines
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1507653390.16112.422.camel-VuQAYsv1563Yd54FQh9/[email protected]
Quoted 5 lines · Andy Shevchenko
Quoted 3 lines
Surely there are other ACPI folk within Intel you can poke to move that
along?I dunno. Mika, do you know anyone else we may ask about?
Nope. Since this is not an ACPI platform originally nobody reserved ACPI IDs for it. We can try to ping the guy, though.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html