login
Search
This patch series contains sub-device drivers for Qualcomm PMIC8058. It is submitted here as RFC, due the dependent drivers like PMIC8058 core driver and SSBI bus driver are not yet merged into the mainline. So we are sending these patches early to get the feedback from the community. If you want to refer the PMIC8058 core and SSBI driver then they are here: PMIC8058 core driver: https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/mfd/pmic8... SSBI driver: https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/i2c/busse... Anirudh Ghayal (2): input: pmic8058-othc: Add support for PM8058 based OTHC drivers: rtc: Add support for Qualcomm PMIC8058 RTC Trilok Soni (4): matrix_keypad: Increase the max limit of rows and columns input: pm8058_keypad: Qualcomm PMIC8058 keypad controller driver led: pmic8058: Add PMIC8058 leds driver input: pmic8058_pwrkey: Add support for power key drivers/input/keyboard/Kconfig | 11 + drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/pmic8058-keypad.c | 769 ++++++++++++++++++++++++++++++ drivers/input/misc/Kconfig | 21 + drivers/input/misc/Makefile | 2 + drivers/input/misc/pmic8058-othc.c | 544 +++++++++++++++++++++ drivers/input/misc/pmic8058-pwrkey.c | 322 +++++++++++++ drivers/leds/Kconfig | 11 + drivers/leds/Makefile | 1 + drivers/leds/leds-pmic8058.c | 405 ++++++++++++++++ drivers/rtc/Kconfig | 9 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-pm8058.c | 487 +++++++++++++++++++ include/linux/input/matrix_keypad.h | 8 +- include/linux/input/pmic8058-keypad.h | 58 +++ include/linux/input/pmic8058-othc.h | ...
Some keyboard controller have support for more than 16 columns and rows. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Trilok Soni <tsoni@codeaurora.org> --- include/linux/input/matrix_keypad.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/input/matrix_keypad.h b/include/linux/input/matrix_keypad.h index 80352ad..d80845e 100644 --- a/include/linux/input/matrix_keypad.h +++ b/include/linux/input/matrix_keypad.h @@ -4,11 +4,11 @@ #include <linux/types.h> #include <linux/input.h> -#define MATRIX_MAX_ROWS 16 -#define MATRIX_MAX_COLS 16 +#define MATRIX_MAX_ROWS 18 +#define MATRIX_MAX_COLS 18 -#define KEY(row, col, val) ((((row) & (MATRIX_MAX_ROWS - 1)) << 24) |\ - (((col) & (MATRIX_MAX_COLS - 1)) << 16) |\ +#define KEY(row, col, val) ((((row) % (MATRIX_MAX_ROWS)) << 24) |\ + (((col) % (MATRIX_MAX_COLS)) << 16) |\ (val & 0xffff)) #define KEY_ROW(k) (((k) >> 24) & 0xff) -- 1.7.0.2 --
Or maybe we can solve this completely by introducing something like:
struct matrix_keycode {
int row;
int col;
int value;
}
And make changes to KEY() macro and other places. You may also want to
--
Though that triples the space needed to store initial keymaps. -- Dmitry --
Looking at it I think we should simply bump up max cols/rows to 32 and be done with it. It will grow the matrix keypad structure by a few bytes but nothing drastic. -- Dmitry --
Add Qualcomm PMIC8058 based keypad controller driver supporting upto 18x8 matrix configuration. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Trilok Soni <tsoni@codeaurora.org> --- drivers/input/keyboard/Kconfig | 11 + drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/pmic8058-keypad.c | 769 ++++++++++++++++++++++++++++++ include/linux/input/pmic8058-keypad.h | 58 +++ 4 files changed, 839 insertions(+), 0 deletions(-) create mode 100644 drivers/input/keyboard/pmic8058-keypad.c create mode 100644 include/linux/input/pmic8058-keypad.h diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index b8c51b9..d536acb 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -364,6 +364,17 @@ config KEYBOARD_PXA930_ROTARY To compile this driver as a module, choose M here: the module will be called pxa930_rotary. +config KEYBOARD_PMIC8058 + tristate "Qualcomm PMIC8058 keypad support" + depends on PMIC8058 + help + Say Y here if you want to enable the driver for the PMIC8058 + keypad provided as a reference design from Qualcomm. This is intended + to support upto 18x8 matrix based keypad design. + + To compile this driver as a module, choose M here: the module will + be called pmic8058-keypad. + config KEYBOARD_SAMSUNG tristate "Samsung keypad support" depends on SAMSUNG_DEV_KEYPAD diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile index a34452e..9ff8dbe 100644 --- a/drivers/input/keyboard/Makefile +++ b/drivers/input/keyboard/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_KEYBOARD_OMAP4) += omap4-keypad.o obj-$(CONFIG_KEYBOARD_OPENCORES) += opencores-kbd.o obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o +obj-$(CONFIG_KEYBOARD_PMIC8058) += pmic8058-keypad.o obj-$(CONFIG_KEYBOARD_QT2160) += qt2160.o obj-$(CONFIG_KEYBOARD_SAMSUNG) += samsung-keypad.o ...
Hi Dmitry, Any comments on this patch? ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Since the size of keycode table is constant there is no need to allocate it separately (and even if it was variable you still could move it to Mixing style (logical || either in front of expression or after), please use kp->input->phys = pdata->input_phys_device ?: "pmic8058_keypad/input0"; Is shorter. Thanks. -- Dmitry --
Hi Trilok, I'd pull the keycodes into this structure (at the end) so it can be allocated in one shot. Hmm it even appears to be constant-sized. So just You need to protect suspend/resume from racing with open_close. Take These are declared as unsigned. Hmm, doesn't sparse catch it? Thanks. -- Dmitry --
Hi Dmitry As discussed earlier we can either have one big header file having all of the sub-device(s) or have separate file for each sub-device driver, I need to check which one would be better but I will atleast move pmic8058-keypad.h header to "mfd" directory, as these patch series is in RFC state, we can have final I will fix it. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Oops ;) Did I need to review something else from you then? I have a nagging feeling that I have a patch outstanding... -- Dmitry --
Hi Dmitry, You need to review PMIC8058 OTHC patch. https://patchwork.kernel.org/patch/314092/ ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Add support for PMIC8058 power key driven over dedicated KYPD_PWR_N pin. It allows the user to specify the amount of time by which the power key reporting can be delayed. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Trilok Soni <tsoni@codeaurora.org> --- drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile | 1 + drivers/input/misc/pmic8058-pwrkey.c | 322 +++++++++++++++++++++++++++++++++ include/linux/input/pmic8058-pwrkey.h | 37 ++++ 4 files changed, 371 insertions(+), 0 deletions(-) create mode 100644 drivers/input/misc/pmic8058-pwrkey.c create mode 100644 include/linux/input/pmic8058-pwrkey.h diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index b99b8cb..aeb9165 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -348,6 +348,17 @@ config INPUT_PWM_BEEPER To compile this driver as a module, choose M here: the module will be called pwm-beeper. +config INPUT_PMIC8058_PWRKEY + tristate "PMIC8058 power key support" + depends on PMIC8058 + help + Say Y here if you want support for the PMIC8058 power key. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called pmic8058-pwrkey. + config INPUT_GPIO_ROTARY_ENCODER tristate "Rotary encoders connected to GPIO pins" depends on GPIOLIB && GENERIC_GPIO diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 1fe1f6c..c4357a0 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_INPUT_PCF8574) += pcf8574_keypad.o obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o +obj-$(CONFIG_INPUT_PMIC8058_PWRKEY) += pmic8058-pwrkey.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git ...
Hi Trilkok, Why do we need to delay KEY_POWER reporting? Do we need to use high resolution timers or regular timers would do as well? KEY_END appears to be abused (you don't want to move your cursor to the end of line, do you?). Also I wonder if header file should reside in linux/mfd with the rest of pmic8058 components. -- Dmitry --
Hi Dmitry, Most of the time Mobile devices come with single physical key for POWER, which if pressed for less than 500ms (configurable) then it will only report KEY_END (which say locks the screen on mobile) and if it pressed more than 500ms then it will also report KEY_POWER event too, which will say display menu on your mobile for asking you to suspend/switch off/etc, operations. For the timers I can move from hrtimers to regular timers. For the header file, I can move them to include/linux/mfd too. No problem on that. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
I see,. If you would have used KEY_SCREENLOCK iinstead of KEY_END I I am not even sure we need to keep them in separate header files, but it is up to you. Thanks. -- Dmitry --
Hi Dmitry, KEY_SCRENNLOCK looks good, let me analyze the impact on userspace framework Do you suggest that all the MFD sub-devices's platform data structures should come from single header file? ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
It is an option, depends on how many external headers are needed, etc. When I looked at this particular file I got the feeling that it could be folded together with the rest. I expect that the board code that will specify platform resources will include every one of this sub-files anyway. But maybe if I was presented with the combined header I'd say "wow, thats too big"... Like I said, it is up to you. -- Dmitry --
From: Anirudh Ghayal <aghayal@codeaurora.org> One-touch headset controller is a hardware module in Qualcomm's PMIC8058. It supports headset insert/remove and switch press/release detection events over 3 MIC BIAS lines. The MIC BIAS lines can be configured to support headset detection or act as regular BIAS lines. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org> --- drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile | 1 + drivers/input/misc/pmic8058-othc.c | 544 +++++++++++++++++++++++++++++++++++ include/linux/input/pmic8058-othc.h | 117 ++++++++ 4 files changed, 672 insertions(+), 0 deletions(-) create mode 100644 drivers/input/misc/pmic8058-othc.c create mode 100644 include/linux/input/pmic8058-othc.h diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index aeb9165..df6097c 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -359,6 +359,16 @@ config INPUT_PMIC8058_PWRKEY To compile this driver as a module, choose M here: the module will be called pmic8058-pwrkey. +config INPUT_PMIC8058_OTHC + tristate "Qualcomm PMIC8058 OTHC support" + depends on PMIC8058 + help + Say Y here if you want support PMIC8058 One-touch Headset Controller + (OTHC) + + To compile this driver as a module, choose M here: the + module will be called pmic8058-othc. + config INPUT_GPIO_ROTARY_ENCODER tristate "Rotary encoders connected to GPIO pins" depends on GPIOLIB && GENERIC_GPIO diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index c4357a0..a713370 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o obj-$(CONFIG_INPUT_PCF8574) += pcf8574_keypad.o obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o +obj-$(CONFIG_INPUT_PMIC8058_OTHC) += pmic8058-othc.o ...
Hi Dmitry, Any comments on this patch? ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Hi Shubhrajyoti, Nope. Please see we are making othc_ipd = NULL, so everything should be fine. Thanks for the review comments. -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Hi Dimitry, Please me know your comments this patch. Thank you, Anirudh -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Hi Trilok, I am not quite sure whether this locking helps anything... You do protect the check by condition can change once you leave the protected dd->othc_ir_state = !dd->othc_ir_state; input_report_key(dd->othc_ipd, SW_HEADPHONE_INSERT, dd->othc_ir_state); What exactly this button is supposed to do? I do not think KEY_MEDIA is Hmm, non-threaded IRQs do not support IRQF_ONESHOT, do they? BTW, is Thanks. -- Dmitry --
Hi Dimitry, Thanks for your comments. On PMIC 8058 we have 3 MIC_BIAS lines and all 3 have the capability to support HSED OTHC controller. So, I register all the 3 BIAS lines, though only the ones which are enabled for HSED regitser as input devices. Also, I export an API pm8058_micbias_enable (above) which Sorry, I didn't quite get your concern. Here, only the timer updates the varible and the int. handler checks for the condition and returns. As This key acts as send/end key while in call and play/pause in case of audio playback. So we used KEY_MEDIA as a generic media key. Could you -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
From: Anirudh Ghayal <aghayal@codeaurora.org> PMIC8058 is Qualcomm's power management IC. A 32-bit RTC is housed inside this PMIC. The RTC driver uses SSBI to communicate with the RTC module. Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Anirudh Ghayal <aghayal@codeaurora.org> --- drivers/rtc/Kconfig | 9 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-pm8058.c | 487 ++++++++++++++++++++++++++++++++++++++++ include/linux/rtc/rtc-pm8058.h | 29 +++ 4 files changed, 526 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-pm8058.c create mode 100644 include/linux/rtc/rtc-pm8058.h diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 2883428..9f4ea00 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -665,6 +665,15 @@ config RTC_DRV_NUC900 If you say yes here you get support for the RTC subsystem of the NUC910/NUC920 used in embedded systems. +config RTC_DRV_PM8058 + tristate "Qualcomm PMIC8058 RTC" + depends on PMIC8058 + help + Say Y here if you want to support the Qualcomm PMIC8058 RTC. + + To compile this driver as a module, choose M here: the + module will be called pmic8058-rtc. + comment "on-CPU RTC drivers" config RTC_DRV_DAVINCI diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 4c2832d..d7a4f7d 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -73,6 +73,7 @@ obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o obj-$(CONFIG_RTC_DRV_PCF2123) += rtc-pcf2123.o obj-$(CONFIG_RTC_DRV_PCF50633) += rtc-pcf50633.o +obj-$(CONFIG_RTC_DRV_PM8058) += rtc-pm8058.o obj-$(CONFIG_RTC_DRV_PL030) += rtc-pl030.o obj-$(CONFIG_RTC_DRV_PL031) += rtc-pl031.o obj-$(CONFIG_RTC_DRV_PS3) += rtc-ps3.o diff --git a/drivers/rtc/rtc-pm8058.c b/drivers/rtc/rtc-pm8058.c new file mode 100644 index 0000000..9fef82d --- /dev/null +++ b/drivers/rtc/rtc-pm8058.c @@ -0,0 +1,487 @@ +/* Copyright (c) 2010, Code ...
Hi Alessandro, Please review this driver. Thanks. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Are there other bits in the ctrl register which are not touch by this driver? If not you could turn the read-modify-write operations changing the ctrl register Hm, I don't know the hardware, but I would assume that The upper layer will already check if alarm->time is valid, so there is no need to Is there a technical reason why changing the rtc clocks time should be disabled or is --
I did try this earlier but the RTC register does not get updated/return In some of our MSM/QSD designs, we have a single RTC shared by multiple processors (other than the ones running Linux). Thus, the need to have a Thank you for the detailed review. I will make these changes in my next patch. --Anirudh -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Add support for Qualcomm PMIC8058 keyboard backlight, flash and low current leds. Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Trilok Soni <tsoni@codeaurora.org> --- drivers/leds/Kconfig | 11 + drivers/leds/Makefile | 1 + drivers/leds/leds-pmic8058.c | 405 +++++++++++++++++++++++++++++++++++++++++ include/linux/leds-pmic8058.h | 63 +++++++ 4 files changed, 480 insertions(+), 0 deletions(-) create mode 100644 drivers/leds/leds-pmic8058.c create mode 100644 include/linux/leds-pmic8058.h diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index cc2a88d..e1ebcad 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -214,6 +214,17 @@ config LEDS_PCA955X LED driver chips accessed via the I2C bus. Supported devices include PCA9550, PCA9551, PCA9552, and PCA9553. +config LEDS_PMIC8058 + tristate "LED Support for Qualcomm PMIC8058" + depends on PMIC8058 + help + This option enables support for LEDs connected over PMIC8058 + (Power Management IC) chip on Qualcomm reference boards, + for example SURF and FFAs. + + To compile this driver as a module, choose M here: the module will + be called leds-pmic8058. + config LEDS_WM831X_STATUS tristate "LED support for status LEDs on WM831x PMICs" depends on MFD_WM831X diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 9c96db4..6c51883 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o +obj-$(CONFIG_LEDS_PMIC8058) += leds-pmic8058.o obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o diff --git a/drivers/leds/leds-pmic8058.c b/drivers/leds/leds-pmic8058.c new file mode 100644 index 0000000..2933eb0 --- /dev/null +++ ...
You allocate a separate pmic8058_led_data for each led, so one "u8 reg" should be This function is only ever called from within the workqueue so there is no need for Shouldn't you be returning the actual brightness here instead of only either on or off? The brightness is btw. stored in led->brightness, so you can use the same getter This function is only ever called from within the workqueue so there is no need for This function is only ever called from within the workqueue so there is no need for Since this is a workqueue and there will only one running instance per led at a time This looks at least a bit bogus since you'll overwrite the drvdata later. Can't you How about adding a helper function which will initializes the leds 'reg' field Should max_brightness not rather be hardcoded in the driver? As far as I can tell it depend on the hardware and is 4 bits wide for flash and bl leds and 5 bits for the If max_brightness is hardcoded in the driver you can reuse "struct led_info" and --
That is a common misconception, unfortunately. The same work may be executing on several CPUs at the same time if it was scheduled on multi-threaded work queue. And sure enough, keventd is such workqueue. Now, whether having the same work run simultaneously is OK or not is a different question altogether... -- Dmitry --
Hm, right my fault. Still the comment above is still valid, because the original workqueue handler was locked by a mutex. But the comment regarding the mutex should have been: - Lars --
There is a historical reason here, but not application to upstream. You can see that we have flash_drv lines also for flash leds in this code, which is used to drive the camera flash leds. The core problem here is that there is no "camera flash" framework in the v4l2 which could drive these pins from the kernel space, so internally we had to also export this _set functions so that v4l2 drivers can use them to control the brightness of the camera flash. Looking at another way, you can use all of these low level leds, flash leds and keyboard leds drive strengths by combining them into the h/w and driver single camera flash requiring around 990mA of current. I could remove these spin locks from this code though, as we don't have generic solution I will check this and see if I can add it in next version. Thanks for the review. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
I couldn't remove these pmic8058_led structure due to the "enum pmic8058_led id" member info which I need from every led. This can be removed completely only if I abuse the "flags" parameter in struct led_info to pass the led id. Let me know what you think. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Hi I think that would be ok, other drivers seem to do the same. - Lars --
Thanks. I will use "flags" parameter for "id" then and submit the re-worked version as V2. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
