From: Lan Tianyu <tianyu.lan@intel.com>
To: "Moore, Robert" <robert.moore@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
"Zhang, Rui" <rui.zhang@intel.com>,
"khali@linux-fr.org" <khali@linux-fr.org>,
"ben-linux@fluff.org" <ben-linux@fluff.org>,
"w.sang@pengutronix.de" <w.sang@pengutronix.de>,
"lenb@kernel.org" <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jkosina@suse.cz" <jkosina@suse.cz>,
"chatty@enac.fr" <chatty@enac.fr>,
"jj_ding@emc.com.tw" <jj_ding@emc.com.tw>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"abelay@mit.edu" <abelay@mit.edu>,
"Lin, Ming M" <ming.m.lin@intel.com>,
"Tang, Feng" <feng.tang@intel.com>
Subject: Re: Fwd: Hid over I2C and ACPI interaction
Date: Mon, 09 Jul 2012 15:28:28 +0800 [thread overview]
Message-ID: <4FFA881C.5030001@intel.com> (raw)
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E346B0A606@ORSMSX101.amr.corp.intel.com>
On 2012年07月09日 12:02, Moore, Robert wrote:
> These are already defined in acpica - in the file acrestyp.h
>
> ACPI_RESOURCE_FIXED_DMA FixedDma;
>
> ACPI_RESOURCE_GPIO Gpio;
> ACPI_RESOURCE_I2C_SERIALBUS I2cSerialBus;
> ACPI_RESOURCE_SPI_SERIALBUS SpiSerialBus;
> ACPI_RESOURCE_UART_SERIALBUS UartSerialBus;
> ACPI_RESOURCE_COMMON_SERIALBUS CommonSerialBus;
>
Yeah. Thanks for Bob's reminder. We can reuse these macros.
>
>
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Lan Tianyu
>> Sent: Sunday, July 08, 2012 8:25 PM
>> To: Mika Westerberg
>> Cc: Zhang, Rui; khali@linux-fr.org; ben-linux@fluff.org;
>> w.sang@pengutronix.de; lenb@kernel.org; linux-acpi@vger.kernel.org; linux-
>> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; jkosina@suse.cz;
>> chatty@enac.fr; jj_ding@emc.com.tw; bhelgaas@google.com; abelay@mit.edu
>> Subject: Re: Fwd: Hid over I2C and ACPI interaction
>>
>> On 2012年07月06日 13:52, Mika Westerberg wrote:
>>> On Thu, Jul 05, 2012 at 03:01:57PM +0800, Zhang Rui wrote:
>>>> +Note that although these are ACPI devices, we prefer to use PnP drivers
>>>> for them,
>>>> +this is because:
>>>> +1. all the non-ACPI-predefined Devices are exported as PnP devices as
>>>> well
>>>> +2. PnP bus is a well designed bus. Probing via PnP layer saves a lot of
>>>> work
>>>> + for the device driver, e.g. getting& parsing ACPI resources.
>>>
>>> (Nice BKM, thanks for sharing)
>>>
>>> I have few questions about using PnP drivers instead of pure ACPI
>> drivers.
>>>
>>> ACPI 5.0 defined some new resources, for example "Fixed DMA descriptor"
>>> that has information about the request line + channel for the device to
>>> use. Hovewer, PnP drivers pass resources as 'struct resource', which
>>> basically only has start and end - how do you represent all this new
>> stuff
>>> using 'struct resource'?
>>>
>> I think we can add new interface to get acpi specific resources. e.g
>> struct acpi_resource pnp_get_acpi_resource(...). When the pnp acpi devices
>> were initialized, put those acpi specific resources into a new resource
>> list
>> pnpdev->acpi_resources. What pnp_get_acpi_resource does is to get specified
>> type acpi resources and return. We also need to define some acpi resource
>> types.
>>
>> ACPI_RESOURCE_DMA
>> ACPI_RESOURCE_I2C_SERIALBUS
>> ACPI_RESOURCE_SPI_SERIALBUS
>> ACPI_RESOURCE_UART_SERIALBUS
>> ACPI_RESOURCE_COMMON_SERIALBUS
>> ...
>>
>> How about this? welcome to comments.
>>
>>> Or should we use acpi_walk_resources() where 'struct resource' is not
>>> suitable?
>>>
>>
>> --
>> Best Regards
>> Tianyu Lan
>> linux kernel enabling team
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Tianyu Lan
linux kernel enabling team
next prev parent reply other threads:[~2012-07-09 7:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 13:46 Hid over I2C and ACPI interaction Benjamin Tissoires
[not found] ` <4FF52C70.9010601@intel.com>
[not found] ` <4FF52C70.9010601-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2012-07-05 7:01 ` Fwd: " Zhang Rui
[not found] ` <1341471717.1682.125.camel-fuY85erJQUO75v1z/vFq2g@public.gmane.org>
2012-07-05 7:20 ` Zhang Rui
2012-07-05 8:44 ` Benjamin Tissoires
2012-07-09 0:41 ` Zhang Rui
2012-07-06 5:52 ` Mika Westerberg
2012-07-09 3:24 ` Lan Tianyu
[not found] ` <4FFA4EFD.6090708-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2012-07-09 4:02 ` Moore, Robert
2012-07-09 7:28 ` Lan Tianyu [this message]
2012-07-09 7:51 ` Mika Westerberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FFA881C.5030001@intel.com \
--to=tianyu.lan@intel.com \
--cc=abelay@mit.edu \
--cc=ben-linux@fluff.org \
--cc=bhelgaas@google.com \
--cc=chatty@enac.fr \
--cc=feng.tang@intel.com \
--cc=jj_ding@emc.com.tw \
--cc=jkosina@suse.cz \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=ming.m.lin@intel.com \
--cc=robert.moore@intel.com \
--cc=rui.zhang@intel.com \
--cc=w.sang@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).