Hi,
Since RPC and SMD drivers are not fully integrated to vanilla linux,
I'd like to discuss a few points about them so that we don't face
troubles when these drivers are submitted.
As you know, most AMSS versions for modern QSD/MSM chips have the same
magic numbers for RPC program/version/procedure calls. Older ones
(namely, msm72[02]x), on the contrary, all have different versions. It
has been solved in hackish ways in Android kernel trees. Google's tree
had the AMSS version selectable in the config and code for different
AMSS was put under ifdefs. It is needless to say that this is a very
bad practice. No only the code size grows with any new version added,
but also we cannot support multiple devices or even multiple firmwares
on the same device in one kernel binary. Besides, if someone makes a
change to one branch of an ifdef, chances are they break the
compilation of another branch unless they're testing all possible
combinations. The kernel at CodeAurora git defines some kind of
functions that check if the RPC version on the BP is compatible with
the one in AP linux kernel, but it also needs to do like 3 or 4 probes
to get version which makes code unreadable.
What I suggest is that a lookup table is used instead. Let us have the
following enum
enum amss_id {
AMSS_AUDMGR_PROG,
AMSS_AUDMGR_VERS,
AMSS_AUDMGR_CB_PROG,
...
}
and the function "extern bool amss_get_id(enum amss_id, uint32_t* out)"
Then, the board code checks the AMSS version (since its detection is
SoC specific or even device-specific) and registers the AMSS platform
device. This platform device probes the SMD driver and probably other
drivers depending on it (RPC, QDSP etc).
We can either make a table of "struct amss_value { enum amss_id id;
uint32_t value }" in the AMSS platfrom driver or just an array indexed
by the amss_id enum.
I also propose that we pass the following platform data structure to
the SMD driver
struct msm_smd_platform_data {
struct amss_value *amss_values; //can be just an array
as mentioned above
int n_amss_values;
struct msm_early_server *early_servers;
int n_early_servers;
}
where struct msm_early_server is { uint32_t cid; uint32_t pid;
uint32_t prog; uint32_t vers; }. Some legacy AMSS versions (namely,
5225 and 6150) need to manually register some servers for the ADSP.
Finally, I propose that we add a wait_queue_head into the SMD driver
and wait_event in the probe function until the channel probe worker
completes. This is to ensure that all SMD channels and RPC servers are
ready when we probe the drivers dependant on the SMD.
What I want is to be able to integrate both official Android phones
and community ports into vanilla and to be able to build the support
for as many devices as possible in a single binary and set everything
up in runtime. Please let me know what the current plans on
integrating RPC and SMD (tty driver) are and whether you need help
with implementing the proposed changes.
If anyone is interested, my git repository is at
git://gitorious.org/~ast/linux-on-qualcomm-s-msm/alex-linux-xperia.git
branch android-2.6.35 (you can use the
https://gitorious.org/~ast/linux-on-qualcomm-s-msm/alex-linux-xperia/
for a web UI if you don't want to clone it). It contains the
implementation of the proposed features for the AMSS 5225. Native
devices (like dream) are probably broken in my tree because I do not
have any of them and cannot test.
--
Regards, Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
