From: Mircea Gherzan <hidden> Date: 2012-03-06 22:55:04
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Hi Luca,
* Mircea Gherzan [off-list ref] [120306 14:23]:
quoted hunk
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
Regards,
Tony
On Fri, 2012-03-09 at 10:31 -0800, Tony Lindgren wrote:
Hi Luca,
Hi Tony,
* Mircea Gherzan [off-list ref] [120306 14:23]:
quoted
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
This looks pretty weird to me too. The "/dev/ttyO1" thing doesn't look
right. But I don't really know how this works either, because this is
the BT/FM/GPS part of the wl12xx chip. And, to be honest, I don't know
anything about it. I only know about the wifi part of it. :\
--
Cheers,
Luca.
From: Mircea Gherzan <hidden> Date: 2012-03-11 20:05:14
Am 09.03.2012 19:31, schrieb Tony Lindgren:
Hi Luca,
* Mircea Gherzan [off-list ref] [120306 14:23]:
quoted
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
This is what the ti_st driver expects in the platform data structure.
More precisely, in kim_probe():
/* copying platform data */
strncpy(kim_gdata->dev_name, pdata->dev_name,UART_DEV_NAME_LEN);
kim_gdata->flow_cntrl = pdata->flow_cntrl;
kim_gdata->baud_rate = pdata->baud_rate;
pr_info("sysfs entries created\n");
So IMHO the patch is a valid fix. However, one more patch [1] is still
required to get BT and WLAN working on the PandaBoard.
Thanks,
Mircea
[1] http://elinux.org/images/8/8d/0001a-omap4-pandaboard-wlan-fix.patch
?#ifndef TI_WILINK_ST_H
?#define TI_WILINK_ST_H
+#include <linux/skbuff.h>
+
?/**
? * enum proto-type - The protocol on WiLink chips which share a
? * ?common physical interface like UART.
--
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
This is what the ti_st driver expects in the platform data structure.
More precisely, in kim_probe():
? ? ? ?/* copying platform data */
? ? ? ?strncpy(kim_gdata->dev_name, pdata->dev_name,UART_DEV_NAME_LEN);
? ? ? ?kim_gdata->flow_cntrl = pdata->flow_cntrl;
? ? ? ?kim_gdata->baud_rate = pdata->baud_rate;
? ? ? ?pr_info("sysfs entries created\n");
So IMHO the patch is a valid fix. However, one more patch [1] is still
required to get BT and WLAN working on the PandaBoard.
The patch looks alright to me.
Yes, the UART to which BT chip is connected (along with other
technologies for which shared transport is required), the baud rate
which the UART supports & also a flag so as to check whether it
supports flow control - ideally is supposed to come from boot-loader,
device tree sort of configuration - if not can be hard-coded in the
relevant platform specific files like in this case.
This is picked up from ST as platform data as is read from the
user-space daemon, because unfortunately none of these configurations
can be done in kernel (the right way for TTY).
1 more patch or an addition to this patch to add the wl1271_device &
the btwilink device is also required to get ST probe & BT probe.
The btwilink driver is a platform device because UART devices don't
have a probe mechanism unlike say usb, i2c..
From: Mircea Gherzan <hidden> Date: 2012-03-11 22:30:54
Am 11.03.2012 21:13, schrieb Pavan Savoy:
On Sun, Mar 11, 2012 at 2:05 PM, Mircea Gherzan [off-list ref] wrote:
quoted
Am 09.03.2012 19:31, schrieb Tony Lindgren:
quoted
Hi Luca,
* Mircea Gherzan [off-list ref] [120306 14:23]:
quoted
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Just checking.. Can you please take a look at this patch
and confirm that this is how things are supposed to be done?
To me passing some third driver's dev_name in pdata seems
pretty weird.. But then again maybe I just don't know how
this is supposed to work.
This is what the ti_st driver expects in the platform data structure.
More precisely, in kim_probe():
/* copying platform data */
strncpy(kim_gdata->dev_name, pdata->dev_name,UART_DEV_NAME_LEN);
kim_gdata->flow_cntrl = pdata->flow_cntrl;
kim_gdata->baud_rate = pdata->baud_rate;
pr_info("sysfs entries created\n");
So IMHO the patch is a valid fix. However, one more patch [1] is still
required to get BT and WLAN working on the PandaBoard.
The patch looks alright to me.
Yes, the UART to which BT chip is connected (along with other
technologies for which shared transport is required), the baud rate
which the UART supports & also a flag so as to check whether it
supports flow control - ideally is supposed to come from boot-loader,
device tree sort of configuration - if not can be hard-coded in the
relevant platform specific files like in this case.
This is picked up from ST as platform data as is read from the
user-space daemon, because unfortunately none of these configurations
can be done in kernel (the right way for TTY).
1 more patch or an addition to this patch to add the wl1271_device &
the btwilink device is also required to get ST probe & BT probe.
The btwilink driver is a platform device because UART devices don't
have a probe mechanism unlike say usb, i2c..
From: Mircea Gherzan <hidden> Date: 2012-03-17 12:57:31
Hi Tony,
Am 06.03.2012 23:55, schrieb Mircea Gherzan:
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Hi Tony,
Am 06.03.2012 23:55, schrieb Mircea Gherzan:
quoted
The "uim" deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan <redacted>
---
arch/arm/mach-omap2/board-omap4panda.c | 14 ++++++++++++--
include/linux/ti_wilink_st.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
Gentle ping.
Thanks for patience, applying to board branch finally.
Tony