On Thu, Dec 03, 2015 at 09:01:11PM +0800, Kefeng Wang wrote:
> Hi Graeme, Arnd, and Lorenzo,
>
> Firstly, we absolutely agree with the point which use AML to do some "special"
> initialisation and configuration.
Good.
> SAS and NIC driver were accepted by linux in hisilicon hip05 chip, and the drivers
> reset the control by syscon, we want to use "_RST" method, which is introduced by
> ACPI 6.0 spec in "7.3.25 _RST (Device Reset)", is it reasonable and standard for us?
Can you point me at the drivers you are referring to please ?
> But here is a scene, we can not find a suitable way to support ACPI. There is no
> independent memory region in some module(the driver not upstreamed), that is,
> when write and read the module's register, we must r/w by syscon. Any advice?
What do you mean ? You mean that the reset control is a piece of HW
that is shared between multiple "components" ? What's your concern
about AML code driving those registers here ?
Thanks,
Lorenzo
>
> Thanks,
> Kefeng
>
> On 2015/12/3 18:41, Graeme Gregory wrote:
> > On Wed, Dec 02, 2015 at 11:44:51AM +0100, Arnd Bergmann wrote:
> >> On Wednesday 02 December 2015 17:09:28 Kefeng Wang wrote:
> >>> This enables syscon with ACPI support.
> >>> syscon_regmap_lookup_by_dev_property() function was added. With helper
> >>> device_get_reference_node() and acpi_dev_find_plat_dev(), it can be used
> >>> in both DT and ACPI.
> >>>
> >>> The device driver can obtain syscon using _DSD method in DSDT, an example
> >>> is shown below.
> >>>
> >>> Device(CTL0) {
> >>> Name(_HID, "HISI0061")
> >>> Name(_CRS, ResourceTemplate() {
> >>> Memory32Fixed(ReadWrite, 0x80000000, 0x10000)
> >>> })
> >>> }
> >>>
> >>> Device(DEV0) {
> >>> Name(_HID, "HISI00B1")
> >>> Name(_CRS, ResourceTemplate() {
> >>> Memory32Fixed(ReadWrite, 0x8c030000, 0x10000)
> >>> Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive){ 192 }
> >>> })
> >>>
> >>> Name (_DSD, Package () {
> >>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >>> Package () {
> >>> Package () {"syscon",Package() {\_SB.CTL0} }
> >>> }
> >>> })
> >>> }
> >>>
> >>> Signed-off-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
> >>
> >> This sounds like a bad idea:
> >>
> >> syscon is basically a hack to let us access register that the SoC designer
> >> couldn't fit in anywhere sane. We need something like this with devicetree
> >> because we decided not to have any interpreted bytecode to do this behind
> >> our back.
> >>
> >> With ACPI, the same thing is done with AML, which is actually nicer than
> >> syscon (once you have to deal with all the problems introduced by AML).
> >>
> >> Use that instead.
> >>
> >
> > I have to agree with Arnd here, this is specifically why it was chosen
> > to use ACPI on machines to move all these "hacks" to AML.
> >
> > This leaves your driver being generic and any "special" initialisation
> > can be supplied by the OEM through the ACPI tables.
> >
> > Graeme
> >
> >
> > .
> >
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
