Using the Sys Interface
The files in /sys/devices/system/cpu/cpu0/cpufreq/ provide information and a means of controlling the frequency scaling subsystem. Seed values are given in Khz. You need to be root to access the /sys filesystem.
Your max speed is at /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq.
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
700000
Your min speed is at /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq.
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
500000
If you are using the userspace governor, you can write to /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed to change the current speed.
# echo 700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
# cat /proc/cpuinfo
cpu MHz : 697.252
# echo 900000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
# cat /proc/cpuinfo
cpu MHz : 976.152
Using Frequency Scaling Governors
You can get a list of available governors with (as root):
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand powersave userspace performance
Note: If the governors are compiled as modules, load them first:
# modprobe cpufreq_performance cpufreq_ondemand cpufreq_conservative cpufreq_powersave cpufreq_userspace
Now we set our governor: What is our current governor?
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace
Set new governor and watch if it has changed
# echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative
Congrats! Your governor is active.
You may set the governor in your init.rc, to make it used on every boot.
9/18/2012
6/22/2012
qualcomm msm7227 Audio device flow in Android part
Reagrding audio device flow, we can find some document for AMSS such as 80-VH828-1.
However, there is few code flow document for MSM7227 Android regarding device handling. Here shows device code flow in Android part.
Brief flow fordevice is "Application --> Libaudio --> qdsp5 --> QDSP or AMSS(ARM9)"
There are four parts for device handling.
1) Audio routing : do_routing / Android
2) Audio Tuning : AudioFilter.csv / Android
3) Voice Tuning : voccal.c / AMSS
4) ADIE setting : msm_aud.h / AMSS
Android source is starting from 'do_routing' in AudioHardware.cpp
There are two paths in audio routing function. One is for ADSP and the other is for AMSS.
* ADSP path
1) msm72xx_enable_audpp() : open device 'msm_pcm_ctl' to handle AFE
sending filter parameters through ioctl().
2) audpp_ioctl in /qdsp5/audio_out.c : msms_adsp_write() is sending audio filter parameters.
ex) MBADRC setting is called by audpp_dsp_set_mbadrc().
* AMSS path
1) doAudioRouteOrMute() : open device 'msm_snd' to handle AFE
do_route_audio_rpc() is sending routing parameter through ioctl for RPC.
2) snd_ioctl in qdsp5/snd.c : msms_rpc_call is called to send the paramters to AMSS
ex) SND DEVICE
volume table, ADIE configuration is defined in AMSS with SND_DEVICE id from Android.
However, there is few code flow document for MSM7227 Android regarding device handling. Here shows device code flow in Android part.
Brief flow fordevice is "Application --> Libaudio --> qdsp5 --> QDSP or AMSS(ARM9)"
There are four parts for device handling.
1) Audio routing : do_routing / Android
2) Audio Tuning : AudioFilter.csv / Android
3) Voice Tuning : voccal.c / AMSS
4) ADIE setting : msm_aud.h / AMSS
Android source is starting from 'do_routing' in AudioHardware.cpp
There are two paths in audio routing function. One is for ADSP and the other is for AMSS.
* ADSP path
1) msm72xx_enable_audpp() : open device 'msm_pcm_ctl' to handle AFE
sending filter parameters through ioctl().
2) audpp_ioctl in /qdsp5/audio_out.c : msms_adsp_write() is sending audio filter parameters.
ex) MBADRC setting is called by audpp_dsp_set_mbadrc().
* AMSS path
1) doAudioRouteOrMute() : open device 'msm_snd' to handle AFE
do_route_audio_rpc() is sending routing parameter through ioctl for RPC.
2) snd_ioctl in qdsp5/snd.c : msms_rpc_call is called to send the paramters to AMSS
ex) SND DEVICE
volume table, ADIE configuration is defined in AMSS with SND_DEVICE id from Android.
HSUSB related NV items in qualcomm chipset
NV Items defined by HS-USB
High Speed USB Current Composition
a.. Number: 04526
b.. Area: System
c.. Description: USB Composition value
HS USB Remote Wakeup Delay
a.. Number: 04918
b.. Area: System
c.. Description:
a.. Indicates the number of milliseconds to wait before performing explicit remote wakeup when in suspend mode. When set to 0, the device doesn't perform explicit remote wakeup.
b.. Default (inactive) is 0.
c.. Set to 3000 before running USBCV.
HS USB Use PMIC OTG comparators
a.. Number: 06235
b.. Area: System
c.. Description:
a.. Indicates whether to use PMIC comparators in LCU.
b.. Default (inactive) is FALSE.
HS USB Number of SDCC LUNS
a.. Number: 06239
b.. Area: System
c.. Description:
a.. Indicates the number of SDCC/MMC LUNs that are enabled. The actual number of MS LUNS will be the maximum of this value and the actual number of SDCC controllers defined by the target.
b.. Default (inactive) is 1.
Host Mode Enabled
a.. Number: 06259
b.. Area: System
c.. Description:
a.. 0x01 means host mode is enabled. 0x00 means host mode is disabled.
b.. Default (inactive) is 0x00.
HS USB Use Diag on Legacy Port
a.. Number: 05044
b.. Area: System
c.. Description:
a.. Indicates whether DIAG should run over HS-USB or (if available) FS-USB (legacy). If full-speed device support is disabled in the target, this NV item is not being used.
b.. Default (inactive) is FALSE.
HS-USB disable sleep voting
a.. Number: 06327
b.. Area: System
c.. Description
a.. Indicates whether to disable voting for sleep when entering LPM after the USB bus is suspended.
b.. This NV item does not affect sleep voting when the USB port is disconnected. Sleep voting is always enabled in this case.
a.. 1 - Disable sleep voting during USB bus suspend state.
b.. 0 - Sleep voting is enabled during USB bus suspend state (default).
Set HS USB performance
a.. Name: NV_HS_USB_PERFORMANCE_SETTING_I
b.. Number: 6841
c.. Area: System
d.. Description:
a.. Determine HS USB performance
a.. LOW = 0 - minimum speed : CPU MIPS will be voted with 0 for NPA. This is only for a testing purpose because it does not guarantee the 4 MHz minimum PCLK requirement for HS USB link HW.
b.. MID = 1 - medium speed
c.. HIGH = 2 - maximum speed
Disable LPM
a.. Number: 6843
b.. Area: System
c.. Description:
a.. Indicates whether phone will enter LPM (low power mode)or not
a.. 0 - LPM is enabled
b.. 1 - LPM is disabled.
a.. By default LPM is enabled.
b.. Note - Disabling LPM also disables HS-USB sleep voting.
PHY Configuration
a.. Number: 06872
b.. Area: System
c.. Description:
a.. change the PHY configuration parameters
a.. pre_emphasis_enable - enable/disable pre-emphasis configure.
b.. pre_emphasis_value - the value for pre-emphasis.
c.. amplitude_adjustment_enable - enable/disable amplitude adjustment.
d.. amplitude_adjustment_value - the value for amplitude adjustment.
External NV Items useful to HS-USB
USB Charging NV Disable Value
a.. Number: 02822
b.. Area: Factory
c.. Description:
a.. Indicates to PMIC charging software whether to use USB charging. When set to 0, USB charging is enabled. When set to 1, USB charging is disabled.
b.. Default (inactive) is handled as charging disabled.
RMNet Autoconnect
a.. Number: 03534
b.. Area: Data
c.. Description:
a.. Indicates whether RMNet will automatically start the data call after the USB ECM connection is established.
a.. FALSE - Don't use RMNet autoconnect.
b.. TRUE - Use RMNet autoconnect.
a.. Default (inactive) is FALSE.
UIM First Instruction Class
a.. Number: 00896
b.. Area: GSM
c.. Description:
a.. Indicates whether to use UICC:
a.. 0-1 Don't use UICC
b.. 2 Use UICC without ISO Reset line high workaround
c.. 3 Use UICC with ISO Reset line high workaround
a.. Default (inactive) is 2.
Application Power Disable
a.. Number: 04201
b.. Area: Debug
c.. Description:
a.. Indicates whether to disable power on application processor (apps power collapse). Prerequisite to TCXO shutdown.
a.. FALSE - Use apps power collapse.
b.. TRUE - Don't use apps power collapse.
DCVS Application NV
a.. Number: 04393
b.. Area: System
c.. Description:
a.. Indicates whether to disable CPU clock control.
a.. type = 0 - Disable DCVS.
b.. type = 1 - Enable DCVS.
Enable reset logging
a.. Number: 04399
b.. Area: Debug
c.. Description:
a.. Indicates whether Phone will go to download mode after reset
a.. type = 0 - Disable the move to sw dload..
b.. type = 1 - Enable the move to sw dload.
High Speed USB Current Composition
a.. Number: 04526
b.. Area: System
c.. Description: USB Composition value
HS USB Remote Wakeup Delay
a.. Number: 04918
b.. Area: System
c.. Description:
a.. Indicates the number of milliseconds to wait before performing explicit remote wakeup when in suspend mode. When set to 0, the device doesn't perform explicit remote wakeup.
b.. Default (inactive) is 0.
c.. Set to 3000 before running USBCV.
HS USB Use PMIC OTG comparators
a.. Number: 06235
b.. Area: System
c.. Description:
a.. Indicates whether to use PMIC comparators in LCU.
b.. Default (inactive) is FALSE.
HS USB Number of SDCC LUNS
a.. Number: 06239
b.. Area: System
c.. Description:
a.. Indicates the number of SDCC/MMC LUNs that are enabled. The actual number of MS LUNS will be the maximum of this value and the actual number of SDCC controllers defined by the target.
b.. Default (inactive) is 1.
Host Mode Enabled
a.. Number: 06259
b.. Area: System
c.. Description:
a.. 0x01 means host mode is enabled. 0x00 means host mode is disabled.
b.. Default (inactive) is 0x00.
HS USB Use Diag on Legacy Port
a.. Number: 05044
b.. Area: System
c.. Description:
a.. Indicates whether DIAG should run over HS-USB or (if available) FS-USB (legacy). If full-speed device support is disabled in the target, this NV item is not being used.
b.. Default (inactive) is FALSE.
HS-USB disable sleep voting
a.. Number: 06327
b.. Area: System
c.. Description
a.. Indicates whether to disable voting for sleep when entering LPM after the USB bus is suspended.
b.. This NV item does not affect sleep voting when the USB port is disconnected. Sleep voting is always enabled in this case.
a.. 1 - Disable sleep voting during USB bus suspend state.
b.. 0 - Sleep voting is enabled during USB bus suspend state (default).
Set HS USB performance
a.. Name: NV_HS_USB_PERFORMANCE_SETTING_I
b.. Number: 6841
c.. Area: System
d.. Description:
a.. Determine HS USB performance
a.. LOW = 0 - minimum speed : CPU MIPS will be voted with 0 for NPA. This is only for a testing purpose because it does not guarantee the 4 MHz minimum PCLK requirement for HS USB link HW.
b.. MID = 1 - medium speed
c.. HIGH = 2 - maximum speed
Disable LPM
a.. Number: 6843
b.. Area: System
c.. Description:
a.. Indicates whether phone will enter LPM (low power mode)or not
a.. 0 - LPM is enabled
b.. 1 - LPM is disabled.
a.. By default LPM is enabled.
b.. Note - Disabling LPM also disables HS-USB sleep voting.
PHY Configuration
a.. Number: 06872
b.. Area: System
c.. Description:
a.. change the PHY configuration parameters
a.. pre_emphasis_enable - enable/disable pre-emphasis configure.
b.. pre_emphasis_value - the value for pre-emphasis.
c.. amplitude_adjustment_enable - enable/disable amplitude adjustment.
d.. amplitude_adjustment_value - the value for amplitude adjustment.
External NV Items useful to HS-USB
USB Charging NV Disable Value
a.. Number: 02822
b.. Area: Factory
c.. Description:
a.. Indicates to PMIC charging software whether to use USB charging. When set to 0, USB charging is enabled. When set to 1, USB charging is disabled.
b.. Default (inactive) is handled as charging disabled.
RMNet Autoconnect
a.. Number: 03534
b.. Area: Data
c.. Description:
a.. Indicates whether RMNet will automatically start the data call after the USB ECM connection is established.
a.. FALSE - Don't use RMNet autoconnect.
b.. TRUE - Use RMNet autoconnect.
a.. Default (inactive) is FALSE.
UIM First Instruction Class
a.. Number: 00896
b.. Area: GSM
c.. Description:
a.. Indicates whether to use UICC:
a.. 0-1 Don't use UICC
b.. 2 Use UICC without ISO Reset line high workaround
c.. 3 Use UICC with ISO Reset line high workaround
a.. Default (inactive) is 2.
Application Power Disable
a.. Number: 04201
b.. Area: Debug
c.. Description:
a.. Indicates whether to disable power on application processor (apps power collapse). Prerequisite to TCXO shutdown.
a.. FALSE - Use apps power collapse.
b.. TRUE - Don't use apps power collapse.
DCVS Application NV
a.. Number: 04393
b.. Area: System
c.. Description:
a.. Indicates whether to disable CPU clock control.
a.. type = 0 - Disable DCVS.
b.. type = 1 - Enable DCVS.
Enable reset logging
a.. Number: 04399
b.. Area: Debug
c.. Description:
a.. Indicates whether Phone will go to download mode after reset
a.. type = 0 - Disable the move to sw dload..
b.. type = 1 - Enable the move to sw dload.
I2C Power collapse issue in android build
Problem: The modem side processor keeps spinning for the spinlock acquired by the apps side processor for an I2C transaction when the apps side processor is power collapsed.
Solution:
As a solution to this, wakelocks can be used. "Wakelock" is a mechanism which can prevent the system from going into a low-power state.
To prevent the above mentioned problem, the I2C driver at the apps side grabs a wakelock at the beginning of the I2C transaction (inside the msm_i2c_xfer() and then releases it at the end of the transaction. With this, the power collapse is delayed for the time the wakelock is held by the i2c driver i.e. till the spinlock held by the apps side processor is released, and the released spinlock can, then, be used by the modem side processor.
To setup a wakelock in the kernel space:
#include <linux/wakelock.h>
wake_lock_init(struct wake_lock *lock, int type, const char *name)
where,
name: name of the lock
type: kind of wakelock
The two types are : WAKE_LOCK_SUSPEND : prevents the system from suspending
WAKE_LOCK_IDLE: prevents going into a low_power idle state
Following are the APIs to handle this lock:
void wake_lock(struct wake_lock *lock);
void wake_lock_timeout(struct wake_lock *lock, long timeout);
void wake_unlock(struct wake_lock *lock);
Note: pm_qos() is not intended to influence the suspend power collapse. It influences the idle power collapse. Thus, pm_qos() should not be used in the above mentioned scenario.
Solution:
As a solution to this, wakelocks can be used. "Wakelock" is a mechanism which can prevent the system from going into a low-power state.
To prevent the above mentioned problem, the I2C driver at the apps side grabs a wakelock at the beginning of the I2C transaction (inside the msm_i2c_xfer() and then releases it at the end of the transaction. With this, the power collapse is delayed for the time the wakelock is held by the i2c driver i.e. till the spinlock held by the apps side processor is released, and the released spinlock can, then, be used by the modem side processor.
To setup a wakelock in the kernel space:
#include <linux/wakelock.h>
wake_lock_init(struct wake_lock *lock, int type, const char *name)
where,
name: name of the lock
type: kind of wakelock
The two types are : WAKE_LOCK_SUSPEND : prevents the system from suspending
WAKE_LOCK_IDLE: prevents going into a low_power idle state
Following are the APIs to handle this lock:
void wake_lock(struct wake_lock *lock);
void wake_lock_timeout(struct wake_lock *lock, long timeout);
void wake_unlock(struct wake_lock *lock);
Note: pm_qos() is not intended to influence the suspend power collapse. It influences the idle power collapse. Thus, pm_qos() should not be used in the above mentioned scenario.
I2C Suspend Power Collapse in AMSS 8650 Software
Problem: The modem side processor keeps spinning for the spinlock acquired by the apps side processor for an I2C transaction when the apps side processor is suspend power collapsed.
Solution: The interrupts should be enabled before calling I2C on the Apps side.
Suspend() is already using a mutex_lock (which is also being used for the I2C transaction) which makes sure that the transaction is over before suspend happens. So, suspend power collapse should not happen until ongoing I2C transaction is done. And once suspend is called, any further I2C transaction cannot even acquire remote lock.
In such a situation, one should check that the interrupts are enabled when an I2C transaction on the apps side is being initiated. If the interrupts are disabled, then the driver cannot finish the transaction since the driver is interrupt driven and the lock acquired is never released. Thus, the interrupts should be enabled before calling I2C on the Apps side.
Solution: The interrupts should be enabled before calling I2C on the Apps side.
Suspend() is already using a mutex_lock (which is also being used for the I2C transaction) which makes sure that the transaction is over before suspend happens. So, suspend power collapse should not happen until ongoing I2C transaction is done. And once suspend is called, any further I2C transaction cannot even acquire remote lock.
In such a situation, one should check that the interrupts are enabled when an I2C transaction on the apps side is being initiated. If the interrupts are disabled, then the driver cannot finish the transaction since the driver is interrupt driven and the lock acquired is never released. Thus, the interrupts should be enabled before calling I2C on the Apps side.
If Host PC do not set DTR high on rmnet interface, how to set it to high by default in AMSS
Question: If Host PC do not set DTR high on rmnet interface, how to set it to high by default in AMSS.
Detail:A2 Rmnet interface depends on DTR high signal, it do not work if DTR low. In standard USB ECM driver(Linux/Mac), there is no operation for setting DTR in host driver side, so we call invoke_app_enable_disable_cbs directly in hsu_al_ecm_enabled_cb.
if (hsu_al_ecm_is_standard)
{
invoke_app_enable_disable_cbs(context_ptr);
}
When customer refer to ECM to implement QC rmnet driver in Linux/Mac, they are likely not set DTR high, thus invoke_app_enable_disable_cbs will never be called in hsu_al_ecm_set_control_line_state_cb.
BTW, when it's not set, MDM9200 could have problem like receive "1" byte no matter how long data packet is sent from host side.
Answer:
We could add a line in the end of hsu_al_ecm_enabled_cb.
hsu_al_ecm_set_control_line_state_cb(1, ctx).
Then it will be called when modem get SET_CONFIGURATION command during enumeration.
It's also a good idea to suggest customer add SET_DTR high command in host driver side.
Detail:A2 Rmnet interface depends on DTR high signal, it do not work if DTR low. In standard USB ECM driver(Linux/Mac), there is no operation for setting DTR in host driver side, so we call invoke_app_enable_disable_cbs directly in hsu_al_ecm_enabled_cb.
if (hsu_al_ecm_is_standard)
{
invoke_app_enable_disable_cbs(context_ptr);
}
When customer refer to ECM to implement QC rmnet driver in Linux/Mac, they are likely not set DTR high, thus invoke_app_enable_disable_cbs will never be called in hsu_al_ecm_set_control_line_state_cb.
BTW, when it's not set, MDM9200 could have problem like receive "1" byte no matter how long data packet is sent from host side.
Answer:
We could add a line in the end of hsu_al_ecm_enabled_cb.
hsu_al_ecm_set_control_line_state_cb(1, ctx).
Then it will be called when modem get SET_CONFIGURATION command during enumeration.
It's also a good idea to suggest customer add SET_DTR high command in host driver side.
In CATC USB analyser log file, USB reset signal is not shown during HS mode
Issue: When using Lecroy's CATC USB log analyzer, Reset signal is not shown correctly during HS mode operation.
Cause: HS mode idle signal electric characteristic is same as SE0.
If the device is being reset from a non-suspended high-speed state, then the device must wait no less than 3.0 ms and no more than 3.125 ms (TWTREV) before reverting to full-speed.
Reversion to fullspeed is accomplished by removing the high-speed termination and reconnecting the D+ pull-up
resistor.
The device samples the bus state, and checks for SE0 (reset as opposed to suspend), no less than 100 μs and no more than 875 μs (TWTRSTHS) after starting reversion to full-speed.
If SE0 (reset) is detected, then the device begins a high-speed detection handshake
Solution: Instead of reset packet, Chirp signal can be used for detecting reset signal. Because chirp signal always happen when HSUSB capable device get reset signal. So we can assume that reset signal happens when chirp packet is shown in CATC usb log file.
Cause: HS mode idle signal electric characteristic is same as SE0.
If the device is being reset from a non-suspended high-speed state, then the device must wait no less than 3.0 ms and no more than 3.125 ms (TWTREV) before reverting to full-speed.
Reversion to fullspeed is accomplished by removing the high-speed termination and reconnecting the D+ pull-up
resistor.
The device samples the bus state, and checks for SE0 (reset as opposed to suspend), no less than 100 μs and no more than 875 μs (TWTRSTHS) after starting reversion to full-speed.
If SE0 (reset) is detected, then the device begins a high-speed detection handshake
Solution: Instead of reset packet, Chirp signal can be used for detecting reset signal. Because chirp signal always happen when HSUSB capable device get reset signal. So we can assume that reset signal happens when chirp packet is shown in CATC usb log file.
Instead of TCXO_EN, can any GPIO be used for controlling USB clock buffer (NAND gate)?
Question :
As seeing Reference schematic for all the MSMs which are supporting HS-USB by using internal HS-USB PHY circuit, TCXO_EN signal is used for enable signal of NAND gate for USB clock. But USB clock is usually not required when USB block is not operating without USB cable inserted.
So to reduce leakage current on this NAND gate and control USB clock properly at this case, can any GPIO instead of TCXO_EN be used for enable signal of this NAND gate?
Answer :
No. TCXO_EN should be used for this. Basically, USB clock should be supplied during normal operation even when USB is not operating including suspend mode, in order to meet USB 2.0 specification requirement for HS-USB enumeration time.
In addition, in case of using normal GPIO, sleep current actually increases to more than 1mA from both VREG_MSMC & VREG_MSMA due to feedback nature of the external NAND circuit when TCXO was no longer supplied.
As seeing Reference schematic for all the MSMs which are supporting HS-USB by using internal HS-USB PHY circuit, TCXO_EN signal is used for enable signal of NAND gate for USB clock. But USB clock is usually not required when USB block is not operating without USB cable inserted.
So to reduce leakage current on this NAND gate and control USB clock properly at this case, can any GPIO instead of TCXO_EN be used for enable signal of this NAND gate?
Answer :
No. TCXO_EN should be used for this. Basically, USB clock should be supplied during normal operation even when USB is not operating including suspend mode, in order to meet USB 2.0 specification requirement for HS-USB enumeration time.
In addition, in case of using normal GPIO, sleep current actually increases to more than 1mA from both VREG_MSMC & VREG_MSMA due to feedback nature of the external NAND circuit when TCXO was no longer supplied.
Is Gadget frame work supported and how to enable Gadget framework?
Q) Is gadget framework supported on Android Eclair?
Ans) Yes, Gadget framework is supported on the Android éclair
Q) How to check whether Gadget framework is enabled or not?
Ans) There are two frameworks for USB device driver in Android. One is Gadget framework and the other is Function framework.
Android Cupcake and Donut baselines use Function framework.
Android éclair have Gadget framework enabled by default. OEMs can check the below flags for their reference.
If gadget frame is enabled following flags are defined in the .config file of the chipset.
1) USB_MSM_OTG_72K(Device Drivers-> USB support -> OTG Support for Qualcomm On-chip USB controller).
2) CONFIG_USB_GADGET(Drivers-> USB support -> USB Gadget support ).
3) USB_GADGET_MSM_72K(Drivers-> USB support -> USB Gadget support -> USB peripheral Controller as MSM 72k USB controller).
4) CONFIG_USB_ANDROID(Drivers-> USB support -> USB Gadget support -> USB Gadget Drivers as Android Gadget).
5) CONFIG_USB_ANDROID_DIAG (select Diag function driver).
6) CONFIG_USB_ANDROID_CDC_ECM
7) CONFIG_USB_F_SERIAL
8) CONFIG_MODEM_SUPPORT
9) CONFIG_USB_CSW_HACK
Note: If gadget frame work is enabled, function frame work should to be disabled. Please check that flag CONFIG_USB_FUNCTION undefined or not.
Go to Device Drivers-> USB support -> USB Function support -> [ ] Support for USB Function drivers.(Exclude this)
Exclude this option in the kernelconfig.
Ans) Yes, Gadget framework is supported on the Android éclair
Q) How to check whether Gadget framework is enabled or not?
Ans) There are two frameworks for USB device driver in Android. One is Gadget framework and the other is Function framework.
Android Cupcake and Donut baselines use Function framework.
Android éclair have Gadget framework enabled by default. OEMs can check the below flags for their reference.
If gadget frame is enabled following flags are defined in the .config file of the chipset.
1) USB_MSM_OTG_72K(Device Drivers-> USB support -> OTG Support for Qualcomm On-chip USB controller).
2) CONFIG_USB_GADGET(Drivers-> USB support -> USB Gadget support ).
3) USB_GADGET_MSM_72K(Drivers-> USB support -> USB Gadget support -> USB peripheral Controller as MSM 72k USB controller).
4) CONFIG_USB_ANDROID(Drivers-> USB support -> USB Gadget support -> USB Gadget Drivers as Android Gadget).
5) CONFIG_USB_ANDROID_DIAG (select Diag function driver).
6) CONFIG_USB_ANDROID_CDC_ECM
7) CONFIG_USB_F_SERIAL
8) CONFIG_MODEM_SUPPORT
9) CONFIG_USB_CSW_HACK
Note: If gadget frame work is enabled, function frame work should to be disabled. Please check that flag CONFIG_USB_FUNCTION undefined or not.
Go to Device Drivers-> USB support -> USB Function support -> [ ] Support for USB Function drivers.(Exclude this)
Exclude this option in the kernelconfig.
Is it possible to use UART1DM and UART1 simultaneously on MSM7x27a?
Q) Is it possible to use UART1DM and UART1 simultaneously on MSM7x27a?
Ans) OEMS wants to use UART1DM and UART1 cores simultaneously and wants to support the below
-- Configuring GPIO [43 - 46] --> as UART1DM (high speed) for Bluetooth.
-- And GPIO [122 - 123] --> as UART1 for debug.
The above is feasible. However, the bit 3 (UART1_RX_SEL) of TLMM_SPARE_WR register should be set to 1 for configuring UART1_RX to GPIO_122.
UART1DM and UART1 are different UART cores in the MSM7x27a chipset and there is no GPIO conflict exists for these cores. Please refer to the Software interface manual for UART1DM core address(0x A020 0000) and UART1 core address(0xa9a00000)
With the above setting, the simultaneous operation of UART1DM and UART1 (on GPIO122,123) can be accomplished.
Also OEMS need to select functionality UART1_TX on GPIO_123, the correct alternate functionality need to be selected in the GPIO_CFG.
Note:- 1) It is not possible to enable the HW flow control on the UART1 if OEMS are using the both UART1DM and UART1 simultaneously.
2) On MSM7x27 chipset both cores can be used simultaneously, as there is GPIO conflict between UART1DM and UART1 cores.
Ans) OEMS wants to use UART1DM and UART1 cores simultaneously and wants to support the below
-- Configuring GPIO [43 - 46] --> as UART1DM (high speed) for Bluetooth.
-- And GPIO [122 - 123] --> as UART1 for debug.
The above is feasible. However, the bit 3 (UART1_RX_SEL) of TLMM_SPARE_WR register should be set to 1 for configuring UART1_RX to GPIO_122.
UART1DM and UART1 are different UART cores in the MSM7x27a chipset and there is no GPIO conflict exists for these cores. Please refer to the Software interface manual for UART1DM core address(0x A020 0000) and UART1 core address(0xa9a00000)
With the above setting, the simultaneous operation of UART1DM and UART1 (on GPIO122,123) can be accomplished.
Also OEMS need to select functionality UART1_TX on GPIO_123, the correct alternate functionality need to be selected in the GPIO_CFG.
Note:- 1) It is not possible to enable the HW flow control on the UART1 if OEMS are using the both UART1DM and UART1 simultaneously.
2) On MSM7x27 chipset both cores can be used simultaneously, as there is GPIO conflict between UART1DM and UART1 cores.
Subscribe to:
Posts (Atom)