[PATCH 6/6] drivers:misc: sources for ST header file
pavan...@ti.com
Texas Instruments BT, FM and GPS combo chips/drivers
make use of a single TTY to communicate with the chip.
This is the common header file for both the ST driver and the
protocol drivers which intend to use ST as their mode of
transport.
Signed-off-by: Pavan Savoy <pavan...@ti.com>
---
drivers/misc/ti-st/fm.h | 13 +++++++
drivers/misc/ti-st/st.h | 85 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ti-st/fm.h
create mode 100644 drivers/misc/ti-st/st.h
diff --git a/drivers/misc/ti-st/fm.h b/drivers/misc/ti-st/fm.h
new file mode 100644
index 0000000..be41453
--- /dev/null
+++ b/drivers/misc/ti-st/fm.h
@@ -0,0 +1,13 @@
+struct fm_event_hdr {
+ unsigned char plen;
+} __attribute__ ((packed));
+
+#define FM_MAX_FRAME_SIZE 0xFF /* TODO: */
+#define FM_EVENT_HDR_SIZE 1 /* size of fm_event_hdr */
+#define ST_FM_CH8_PKT 0x8
+
+/* gps stuff */
+struct gps_event_hdr {
+unsigned char opcode;
+unsigned short plen;
+} __attribute__ ((packed));
diff --git a/drivers/misc/ti-st/st.h b/drivers/misc/ti-st/st.h
new file mode 100644
index 0000000..ec821d2
--- /dev/null
+++ b/drivers/misc/ti-st/st.h
@@ -0,0 +1,85 @@
+/*
+ * Shared Transport Header file
+ * To be included by the protocol stack drivers for
+ * Texas Instruments BT,FM and GPS combo chip drivers
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef ST_H
+#define ST_H
+
+#include <linux/skbuff.h>
+/*
+ * st.h
+ */
+
+/* some gpios have active high, others like fm have
+ * active low
+ */
+enum kim_gpio_state {
+ KIM_GPIO_INACTIVE,
+ KIM_GPIO_ACTIVE,
+};
+/*
+ * the list of protocols on chip
+ */
+enum proto_type {
+ ST_BT,
+ ST_FM,
+ ST_GPS,
+ ST_MAX,
+};
+
+enum {
+ ST_ERR_FAILURE = -1, /* check struct */
+ ST_SUCCESS,
+ ST_ERR_PENDING = -5, /* to call reg_complete_cb */
+ ST_ERR_ALREADY, /* already registered */
+ ST_ERR_INPROGRESS,
+ ST_ERR_NOPROTO, /* protocol not supported */
+};
+
+/* per protocol structure
+ * for BT/FM and GPS
+ */
+struct st_proto_s {
+ enum proto_type type;
+/*
+ * to be called by ST when data arrives
+ */
+ long (*recv) (struct sk_buff *);
+/*
+ * for future use, logic now to be in ST
+ */
+ unsigned char (*match_packet) (const unsigned char *data);
+/*
+ * subsequent registration return PENDING,
+ * signalled complete by this callback function
+ */
+ void (*reg_complete_cb) (char data);
+/*
+ * write function, sent in as NULL and to be returned to
+ * protocol drivers
+ */
+ long (*write) (struct sk_buff *skb);
+};
+
+extern long st_register(struct st_proto_s *new_proto);
+extern long st_unregister(enum proto_type type);
+
+#endif /* ST_H */
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pavan...@ti.com
Texas Instruments BT, FM and GPS combo chips/drivers
make use of a single TTY to communicate with the chip.
This module constitutes the proprietary power management
protocol from TI for the BT/FM/GPS combo chips
Signed-off-by: Pavan Savoy <pavan...@ti.com>
---
drivers/misc/ti-st/st_ll.c | 169 ++++++++++++++++++++++++++++++++++++++++++++
drivers/misc/ti-st/st_ll.h | 67 +++++++++++++++++
2 files changed, 236 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ti-st/st_ll.c
create mode 100644 drivers/misc/ti-st/st_ll.h
diff --git a/drivers/misc/ti-st/st_ll.c b/drivers/misc/ti-st/st_ll.c
new file mode 100644
index 0000000..5e42cbe
--- /dev/null
+++ b/drivers/misc/ti-st/st_ll.c
@@ -0,0 +1,169 @@
+/*
+ * Shared Transport driver
+ * HCI-LL module responsible for TI proprietary HCI_LL protocol
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "st_ll.h"
+
+/* all debug macros go in here */
+#define ST_LL_ERR(fmt, arg...) printk(KERN_ERR "(stll):"fmt"\n" , ## arg)
+#if defined(DEBUG) /* limited debug messages */
+#define ST_LL_DBG(fmt, arg...) printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#define ST_LL_VER(fmt, arg...)
+#elif defined(VERBOSE) /* very verbose */
+#define ST_LL_DBG(fmt, arg...) printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#define ST_LL_VER(fmt, arg...) printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#else /* error msgs only */
+#define ST_LL_DBG(fmt, arg...)
+#define ST_LL_VER(fmt, arg...)
+#endif
+
+static struct ll_struct_s *ll;
+
+/**********************************************************************/
+/* internal functions */
+static void send_ll_cmd(unsigned char cmd)
+{
+
+ ST_LL_DBG("%s: writing %x", __func__, cmd);
+ st_int_write(&cmd, 1);
+ return;
+}
+
+static void ll_device_want_to_sleep(void)
+{
+ ST_LL_DBG("%s", __func__);
+ /* sanity check */
+ if (ll->ll_state != ST_LL_AWAKE)
+ ST_LL_ERR("ERR hcill: ST_LL_GO_TO_SLEEP_IND"
+ "in state %ld", ll->ll_state);
+
+ send_ll_cmd(LL_SLEEP_ACK);
+ /* update state */
+ ll->ll_state = ST_LL_ASLEEP;
+}
+
+static void ll_device_want_to_wakeup(void)
+{
+ /* diff actions in diff states */
+ switch (ll->ll_state) {
+ case ST_LL_ASLEEP:
+ send_ll_cmd(LL_WAKE_UP_ACK); /* send wake_ack */
+ break;
+ case ST_LL_ASLEEP_TO_AWAKE:
+ /* duplicate wake_ind */
+ ST_LL_ERR("duplicate wake_ind while waiting for Wake ack");
+ break;
+ case ST_LL_AWAKE:
+ /* duplicate wake_ind */
+ ST_LL_ERR("duplicate wake_ind already AWAKE");
+ break;
+ case ST_LL_AWAKE_TO_ASLEEP:
+ /* duplicate wake_ind */
+ ST_LL_ERR("duplicate wake_ind");
+ break;
+ }
+ /* update state */
+ ll->ll_state = ST_LL_AWAKE;
+}
+
+/**********************************************************************/
+/* functions invoked by ST Core */
+
+/* called when ST Core wants to
+ * enable ST LL */
+void st_ll_enable(void)
+{
+ ll->ll_state = ST_LL_AWAKE;
+}
+
+/* called when ST Core /local module wants to
+ * disable ST LL */
+void st_ll_disable(void)
+{
+ ll->ll_state = ST_LL_INVALID;
+}
+
+/* called when ST Core wants to update the state */
+void st_ll_wakeup(void)
+{
+ if (likely(ll->ll_state != ST_LL_AWAKE)) {
+ send_ll_cmd(LL_WAKE_UP_IND); /* WAKE_IND */
+ ll->ll_state = ST_LL_ASLEEP_TO_AWAKE;
+ } else {
+ /* don't send the duplicate wake_indication */
+ ST_LL_ERR(" Chip already AWAKE ");
+ }
+}
+
+/* called when ST Core wants the state */
+unsigned long st_ll_getstate(void)
+{
+ ST_LL_DBG(" returning state %ld", ll->ll_state);
+ return ll->ll_state;
+}
+
+/* called from ST Core, when a PM related packet arrives */
+unsigned long st_ll_sleep_state(unsigned char cmd)
+{
+ switch (cmd) {
+ case LL_SLEEP_IND: /* sleep ind */
+ ST_LL_DBG("sleep indication recvd");
+ ll_device_want_to_sleep();
+ break;
+ case LL_SLEEP_ACK: /* sleep ack */
+ ST_LL_ERR("sleep ack rcvd: host shouldn't");
+ break;
+ case LL_WAKE_UP_IND: /* wake ind */
+ ST_LL_DBG("wake indication recvd");
+ ll_device_want_to_wakeup();
+ break;
+ case LL_WAKE_UP_ACK: /* wake ack */
+ ST_LL_DBG("wake ack rcvd");
+ ll->ll_state = ST_LL_AWAKE;
+ break;
+ default:
+ ST_LL_ERR(" unknown input/state ");
+ return ST_ERR_FAILURE;
+ }
+ return ST_SUCCESS;
+}
+
+/* Called from ST CORE to initialize ST LL */
+long st_ll_init(void)
+{
+ long err = ST_SUCCESS;
+
+ /* Allocate memory for ST LL private structure */
+ ll = kzalloc(sizeof(*ll), GFP_ATOMIC);
+ if (!ll) {
+ ST_LL_ERR("kzalloc failed to alloc memory for ST LL");
+ err = -ENOMEM;
+ return err;
+ }
+ /* set state to invalid */
+ ll->ll_state = ST_LL_INVALID;
+ return err;
+}
+
+/* Called from ST CORE to de-initialize ST LL */
+long st_ll_deinit(void)
+{
+ kfree(ll);
+ return 0;
+}
diff --git a/drivers/misc/ti-st/st_ll.h b/drivers/misc/ti-st/st_ll.h
new file mode 100644
index 0000000..fff88cb
--- /dev/null
+++ b/drivers/misc/ti-st/st_ll.h
@@ -0,0 +1,67 @@
+/*
+ * Shared Transport Low Level (ST LL)
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef ST_LL_H
+#define ST_LL_H
+
+#include <linux/skbuff.h>
+#include "st.h"
+#include "st_core.h"
+
+/* ST LL receiver states */
+#define ST_W4_PACKET_TYPE 0
+#define ST_BT_W4_EVENT_HDR 1
+#define ST_BT_W4_ACL_HDR 2
+#define ST_BT_W4_SCO_HDR 3
+#define ST_BT_W4_DATA 4
+#define ST_FM_W4_EVENT_HDR 5
+#define ST_GPS_W4_EVENT_HDR 6
+
+/* ST LL state machines */
+#define ST_LL_ASLEEP 0
+#define ST_LL_ASLEEP_TO_AWAKE 1
+#define ST_LL_AWAKE 2
+#define ST_LL_AWAKE_TO_ASLEEP 3
+#define ST_LL_INVALID 4
+
+#define LL_SLEEP_IND 0x30
+#define LL_SLEEP_ACK 0x31
+#define LL_WAKE_UP_IND 0x32
+#define LL_WAKE_UP_ACK 0x33
+
+/* ST LL private information */
+struct ll_struct_s {
+ unsigned long ll_state; /* ST LL power state */
+};
+
+/* initialize and de-init ST LL */
+long st_ll_init(void);
+long st_ll_deinit(void);
+
+/* enable/disable ST LL along with KIM start/stop
+ * called by ST Core
+ */
+void st_ll_enable(void);
+void st_ll_disable(void);
+
+unsigned long st_ll_getstate(void);
+unsigned long st_ll_sleep_state(unsigned char);
+void st_ll_wakeup(void);
+#endif /* ST_LL_H */
pavan...@ti.com
Kernel Space Init-Manager works along with User-Mode
Init Manager daemon running to maintain the UART state.
It also is a platform driver with a relevant platform device
in the board-*.c along with the list of BT/FM/GPS chip enable
gpio configuration
Signed-off-by: Pavan Savoy <pavan...@ti.com>
---
drivers/misc/ti-st/st_kim.c | 717 +++++++++++++++++++++++++++++++++++++++++++
drivers/misc/ti-st/st_kim.h | 151 +++++++++
2 files changed, 868 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ti-st/st_kim.c
create mode 100644 drivers/misc/ti-st/st_kim.h
diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
new file mode 100644
index 0000000..20d6927
--- /dev/null
+++ b/drivers/misc/ti-st/st_kim.c
@@ -0,0 +1,717 @@
+/*
+ * Shared Transport Line discipline driver Core
+ * Init Manager module responsible for GPIO control
+ * and firmware download
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/jiffies.h>
+#include <linux/firmware.h>
+#include <linux/delay.h>
+#include <linux/wait.h>
+#include <linux/gpio.h>
+
+#include <linux/sched.h>
+
+#include "st_kim.h"
+/* understand BT events for fw response */
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+
+/* all debug macros go in here */
+#define ST_KIM_ERR(fmt, arg...) printk(KERN_ERR "(stk):"fmt"\n" , ## arg)
+#if defined(DEBUG) /* limited debug messages */
+#define ST_KIM_DBG(fmt, arg...) printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#define ST_KIM_VER(fmt, arg...)
+#elif defined(VERBOSE) /* very verbose */
+#define ST_KIM_DBG(fmt, arg...) printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#define ST_KIM_VER(fmt, arg...) printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#else /* error msgs only */
+#define ST_KIM_DBG(fmt, arg...)
+#define ST_KIM_VER(fmt, arg...)
+#endif
+
+static int kim_probe(struct platform_device *pdev);
+static int kim_remove(struct platform_device *pdev);
+static ssize_t show_pid(struct device *dev, struct device_attribute
+ *attr, char *buf);
+static ssize_t store_pid(struct device *dev, struct device_attribute
+ *devattr, char *buf, size_t count);
+static ssize_t show_list(struct device *dev, struct device_attribute
+ *attr, char *buf);
+/* KIM platform device driver structure */
+static struct platform_driver kim_platform_driver = {
+ .probe = kim_probe,
+ .remove = kim_remove,
+ /* TODO: ST driver power management during suspend/resume ?
+ */
+#if 0
+ .suspend = kim_suspend,
+ .resume = kim_resume,
+#endif
+ .driver = {
+ .name = "kim",
+ .owner = THIS_MODULE,
+ },
+};
+
+/* structures specific for sysfs entries */
+static struct kobj_attribute pid_attr =
+__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
+
+static struct kobj_attribute list_protocols =
+__ATTR(protocols, 0444, (void *)show_list, NULL);
+
+static struct attribute *uim_attrs[] = {
+ &pid_attr.attr,
+ /* add more debug sysfs entries */
+ &list_protocols.attr,
+ NULL,
+};
+
+static struct attribute_group uim_attr_grp = {
+ .attrs = uim_attrs,
+};
+
+/* strings to be used for rfkill entries and by
+ * ST Core to be used for sysfs debug entry
+ */
+#define PROTO_ENTRY(type, name) name
+const unsigned char *protocol_names[] = {
+ PROTO_ENTRY(ST_BT, "Bluetooth"),
+ PROTO_ENTRY(ST_FM, "FM"),
+ PROTO_ENTRY(ST_GPS, "GPS"),
+};
+static int kim_toggle_radio(void*, bool);
+static const struct rfkill_ops kim_rfkill_ops = {
+ .set_block = kim_toggle_radio,
+};
+
+static struct kim_data_s *kim_gdata;
+
+/**********************************************************************/
+/* internal functions */
+
+/*
+ * function to return whether the firmware response was proper
+ * in case of error don't complete so that waiting for proper
+ * response times out
+ */
+void validate_firmware_response(struct sk_buff *skb)
+{
+ if (unlikely(skb->data[5] != 0)) {
+ ST_KIM_ERR("no proper response during fw download");
+ ST_KIM_ERR("data6 %x", skb->data[5]);
+ return; /* keep waiting for the proper response */
+ }
+ /* becos of all the script being downloaded */
+ complete_all(&kim_gdata->kim_rcvd);
+ kfree_skb(skb);
+}
+
+/* check for data len received inside kim_int_recv
+ * most often hit the last case to update state to waiting for data
+ */
+static inline int kim_check_data_len(int len)
+{
+ register int room = skb_tailroom(kim_gdata->rx_skb);
+
+ ST_KIM_DBG("len %d room %d", len, room);
+
+ if (!len) {
+ validate_firmware_response(kim_gdata->rx_skb);
+ } else if (len > room) {
+ /* Received packet's payload length is larger.
+ * We can't accommodate it in created skb.
+ */
+ ST_KIM_ERR("Data length is too large len %d room %d", len,
+ room);
+ kfree_skb(kim_gdata->rx_skb);
+ } else {
+ /* Packet header has non-zero payload length and
+ * we have enough space in created skb. Lets read
+ * payload data */
+ kim_gdata->rx_state = ST_BT_W4_DATA;
+ kim_gdata->rx_count = len;
+ return len;
+ }
+
+ /* Change ST LL state to continue to process next
+ * packet */
+ kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+ kim_gdata->rx_skb = NULL;
+ kim_gdata->rx_count = 0;
+
+ return 0;
+}
+
+/* receive function called during firmware download
+ * - firmware download responses on different UART drivers
+ * have been observed to come in bursts of different
+ * tty_receive and hence the logic
+ */
+void kim_int_recv(const unsigned char *data, long count)
+{
+ register char *ptr;
+ struct hci_event_hdr *eh;
+ register int len = 0, type = 0;
+
+ ST_KIM_DBG("%s", __func__);
+ /* Decode received bytes here */
+ ptr = (char *)data;
+ if (unlikely(ptr == NULL)) {
+ ST_KIM_ERR(" received null from TTY ");
+ return;
+ }
+ while (count) {
+ if (kim_gdata->rx_count) {
+ len = min_t(unsigned int, kim_gdata->rx_count, count);
+ memcpy(skb_put(kim_gdata->rx_skb, len), ptr, len);
+ kim_gdata->rx_count -= len;
+ count -= len;
+ ptr += len;
+
+ if (kim_gdata->rx_count)
+ continue;
+
+ /* Check ST RX state machine , where are we? */
+ switch (kim_gdata->rx_state) {
+ /* Waiting for complete packet ? */
+ case ST_BT_W4_DATA:
+ ST_KIM_DBG("Complete pkt received");
+ validate_firmware_response(kim_gdata->rx_skb);
+ kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+ kim_gdata->rx_skb = NULL;
+ continue;
+ /* Waiting for Bluetooth event header ? */
+ case ST_BT_W4_EVENT_HDR:
+ eh = (struct hci_event_hdr *)kim_gdata->
+ rx_skb->data;
+ ST_KIM_DBG("Event header: evt 0x%2.2x"
+ "plen %d", eh->evt, eh->plen);
+ kim_check_data_len(eh->plen);
+ continue;
+ } /* end of switch */
+ } /* end of if rx_state */
+ switch (*ptr) {
+ /* Bluetooth event packet? */
+ case HCI_EVENT_PKT:
+ ST_KIM_DBG("Event packet");
+ kim_gdata->rx_state = ST_BT_W4_EVENT_HDR;
+ kim_gdata->rx_count = HCI_EVENT_HDR_SIZE;
+ type = HCI_EVENT_PKT;
+ break;
+ default:
+ ST_KIM_DBG("unknown packet");
+ ptr++;
+ count--;
+ continue;
+ } /* end of switch *ptr */
+ ptr++;
+ count--;
+ kim_gdata->rx_skb =
+ bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
+ if (!kim_gdata->rx_skb) {
+ ST_KIM_ERR("can't allocate mem for new packet");
+ kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+ kim_gdata->rx_count = 0;
+ return;
+ } /* not necessary in this case */
+ bt_cb(kim_gdata->rx_skb)->pkt_type = type;
+ } /* end of while count */
+ ST_KIM_DBG("done %s", __func__);
+ return;
+}
+
+static long read_local_version(char *bts_scr_name)
+{
+ unsigned short version = 0, chip = 0, min_ver = 0, maj_ver = 0;
+ char read_ver_cmd[] = { 0x01, 0x01, 0x10, 0x00 };
+
+ ST_KIM_DBG("%s", __func__);
+
+ INIT_COMPLETION(kim_gdata->kim_rcvd);
+ if (4 != st_int_write(read_ver_cmd, 4)) {
+ ST_KIM_ERR("kim: couldn't write 4 bytes");
+ return ST_ERR_FAILURE;
+ }
+
+ if (!wait_for_completion_timeout
+ (&kim_gdata->kim_rcvd, msecs_to_jiffies(CMD_RESP_TIME))) {
+ ST_KIM_ERR(" waiting for ver info- timed out ");
+ return ST_ERR_FAILURE;
+ }
+
+ version =
+ MAKEWORD(kim_gdata->resp_buffer[13], kim_gdata->resp_buffer[14]);
+ chip = (version & 0x7C00) >> 10;
+ min_ver = (version & 0x007F);
+ maj_ver = (version & 0x0380) >> 7;
+
+ if (version & 0x8000)
+ maj_ver |= 0x0008;
+
+ sprintf(bts_scr_name, "TIInit_%d.%d.%d.bts", chip, maj_ver, min_ver);
+ ST_KIM_DBG("%s", bts_scr_name);
+ return ST_SUCCESS;
+}
+
+/* internal function which parses through the .bts firmware script file
+ * intreprets SEND, DELAY actions only as of now
+ */
+static long download_firmware(void)
+{
+ long err = ST_SUCCESS;
+ long len = 0;
+ register unsigned char *ptr = NULL;
+ register unsigned char *action_ptr = NULL;
+ unsigned char bts_scr_name[30] = { 0 }; /* 30 char long bts scr name? */
+
+ ST_KIM_VER("%s", __func__);
+
+ err = read_local_version(bts_scr_name);
+ if (err != ST_SUCCESS) {
+ ST_KIM_ERR("kim: failed to read local ver");
+ return err;
+ }
+ err =
+ request_firmware(&kim_gdata->fw_entry, bts_scr_name,
+ &kim_gdata->kim_pdev->dev);
+ if (unlikely((err != 0) || (kim_gdata->fw_entry->data == NULL) ||
+ (kim_gdata->fw_entry->size == 0))) {
+ ST_KIM_ERR(" request_firmware failed(errno %ld) for %s", err,
+ bts_scr_name);
+ return ST_ERR_FAILURE;
+ }
+ ptr = (void *)kim_gdata->fw_entry->data;
+ len = kim_gdata->fw_entry->size;
+ /* bts_header to remove out magic number and
+ * version
+ */
+ ptr += sizeof(struct bts_header);
+ len -= sizeof(struct bts_header);
+
+ while (len > 0 && ptr) {
+ ST_KIM_VER(" action size %d, type %d ",
+ ((struct bts_action *)ptr)->size,
+ ((struct bts_action *)ptr)->type);
+
+ switch (((struct bts_action *)ptr)->type) {
+ case ACTION_SEND_COMMAND: /* action send */
+ action_ptr = &(((struct bts_action *)ptr)->data[0]);
+ if (unlikely
+ (((struct hci_command *)action_ptr)->opcode ==
+ 0xFF36)) {
+ /* ignore remote change
+ * baud rate HCI VS command */
+ ST_KIM_ERR
+ (" change remote baud\
+ rate command in firmware");
+ break;
+ }
+
+ INIT_COMPLETION(kim_gdata->kim_rcvd);
+ err = st_int_write(((struct bts_action_send *)
+ action_ptr)->data,
+ ((struct bts_action *)ptr)->size);
+ if (unlikely(err < 0)) {
+ release_firmware(kim_gdata->fw_entry);
+ return ST_ERR_FAILURE;
+ }
+ if (!wait_for_completion_timeout
+ (&kim_gdata->kim_rcvd,
+ msecs_to_jiffies(CMD_RESP_TIME))) {
+ ST_KIM_ERR
+ (" response timeout during fw download ");
+ /* timed out */
+ release_firmware(kim_gdata->fw_entry);
+ return ST_ERR_FAILURE;
+ }
+ break;
+ case ACTION_DELAY: /* sleep */
+ ST_KIM_DBG("sleep command in scr");
+ action_ptr = &(((struct bts_action *)ptr)->data[0]);
+ mdelay(((struct bts_action_delay *)action_ptr)->msec);
+ break;
+ }
+ len =
+ len - (sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size);
+ ptr =
+ ptr + sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size;
+ }
+ /* fw download complete */
+ release_firmware(kim_gdata->fw_entry);
+ return ST_SUCCESS;
+}
+
+/**********************************************************************/
+/* functions called from ST core */
+
+/* function to toggle the GPIO
+ * needs to know whether the GPIO is active high or active low
+ */
+void st_kim_chip_toggle(enum proto_type type, enum kim_gpio_state state)
+{
+ ST_KIM_DBG(" %s ", __func__);
+
+ if (kim_gdata->gpios[type] == -1) {
+ ST_KIM_DBG(" gpio not requested for protocol %s",
+ protocol_names[type]);
+ return;
+ }
+ switch (type) {
+ case ST_BT:
+ /*Do Nothing */
+ break;
+
+ case ST_FM:
+ if (state == KIM_GPIO_ACTIVE)
+ gpio_set_value(kim_gdata->gpios[ST_FM], GPIO_LOW);
+ else
+ gpio_set_value(kim_gdata->gpios[ST_FM], GPIO_HIGH);
+ break;
+
+ case ST_GPS:
+ if (state == KIM_GPIO_ACTIVE)
+ gpio_set_value(kim_gdata->gpios[ST_GPS], GPIO_HIGH);
+ else
+ gpio_set_value(kim_gdata->gpios[ST_GPS], GPIO_LOW);
+ break;
+
+ case ST_MAX:
+ default:
+ break;
+ }
+
+ return;
+}
+
+/* called from ST Core, when REG_IN_PROGRESS (registration in progress)
+ * can be because of
+ * 1. response to read local version
+ * 2. during send/recv's of firmware download
+ */
+void st_kim_recv(const unsigned char *data, long count)
+{
+ ST_KIM_DBG(" %s ", __func__);
+ /* copy to local buffer */
+ if (unlikely(data[4] == 0x01 && data[5] == 0x10 && data[0] == 0x04)) {
+ /* must be the read_ver_cmd */
+ memcpy(kim_gdata->resp_buffer, data, count);
+ complete_all(&kim_gdata->kim_rcvd);
+ return;
+ } else {
+ kim_int_recv(data, count);
+ /* either completes or times out */
+ }
+ return;
+}
+
+/* to signal completion of line discipline installation
+ * called from ST Core, upon tty_open
+ */
+void st_kim_complete(void)
+{
+ complete(&kim_gdata->ldisc_installed);
+}
+
+/* called from ST Core upon 1st registration
+*/
+long st_kim_start(void)
+{
+ long err = ST_SUCCESS;
+ long retry = POR_RETRY_COUNT;
+ ST_KIM_DBG(" %s", __func__);
+
+ do {
+ /* Configure BT nShutdown to HIGH state */
+ gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+ mdelay(5); /* FIXME: a proper toggle */
+ gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_HIGH);
+ mdelay(100);
+
+ /* re-initialize the completion */
+ INIT_COMPLETION(kim_gdata->ldisc_installed);
+ /* send signal to UIM */
+ err = kill_pid(find_get_pid(kim_gdata->uim_pid), SIGUSR2, 0);
+ if (err != 0) {
+ ST_KIM_VER(" sending SIGUSR2 to uim failed %ld", err);
+ err = ST_ERR_FAILURE;
+ continue;
+ }
+ /* wait for ldisc to be installed */
+ err = wait_for_completion_timeout(&kim_gdata->ldisc_installed,
+ msecs_to_jiffies(LDISC_TIME));
+ if (!err) { /* timeout */
+ ST_KIM_ERR("line disc installation timed out ");
+ err = ST_ERR_FAILURE;
+ continue;
+ } else {
+ /* ldisc installed now */
+ ST_KIM_DBG(" line discipline installed ");
+ err = download_firmware();
+ if (err != ST_SUCCESS) {
+ ST_KIM_ERR("download firmware failed");
+ continue;
+ } else { /* on success don't retry */
+ break;
+ }
+ }
+ } while (retry--);
+ return err;
+}
+
+/* called from ST Core, on the last un-registration
+*/
+long st_kim_stop(void)
+{
+ long err = ST_SUCCESS;
+
+ INIT_COMPLETION(kim_gdata->ldisc_installed);
+ /* send signal to UIM */
+ err = kill_pid(find_get_pid(kim_gdata->uim_pid), SIGUSR2, 1);
+ if (err != 0) {
+ ST_KIM_ERR("sending SIGUSR2 to uim failed %ld", err);
+ return ST_ERR_FAILURE;
+ }
+
+ /* wait for ldisc to be un-installed */
+ err = wait_for_completion_timeout(&kim_gdata->ldisc_installed,
+ msecs_to_jiffies(LDISC_TIME));
+ if (!err) { /* timeout */
+ ST_KIM_ERR(" timed out waiting for ldisc to be un-installed");
+ return ST_ERR_FAILURE;
+ }
+
+ /* By default configure BT nShutdown to LOW state */
+ gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+ mdelay(1);
+ gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_HIGH);
+ mdelay(1);
+ gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+ return err;
+}
+
+/**********************************************************************/
+/* functions called from subsystems */
+
+/* called when sysfs entry is written to */
+static ssize_t store_pid(struct device *dev, struct device_attribute
+ *devattr, char *buf, size_t count)
+{
+ ST_KIM_DBG("%s: pid %s ", __func__, buf);
+ sscanf(buf, "%ld", &kim_gdata->uim_pid);
+ /* to be made use by kim_start to signal SIGUSR2
+ */
+ return strlen(buf);
+}
+
+/* called when sysfs entry is read from */
+static ssize_t show_pid(struct device *dev, struct device_attribute
+ *attr, char *buf)
+{
+ sprintf(buf, "%ld", kim_gdata->uim_pid);
+ return strlen(buf);
+}
+
+/* called when sysfs entry is read from */
+static ssize_t show_list(struct device *dev, struct device_attribute
+ *attr, char *buf)
+{
+ kim_st_list_protocols(buf);
+ return strlen(buf);
+}
+
+#ifdef LEGACY_RFKILL_SUPPORT
+/* function called from rfkill subsystem, when someone from
+ * user space would write 0/1 on the sysfs entry
+ * /sys/class/rfkill/rfkill0,1,3/state
+ */
+static int kim_toggle_radio(void *data, bool blocked)
+{
+ enum proto_type type = *((enum proto_type *)data);
+ ST_KIM_DBG(" %s: %d ", __func__, type);
+
+ switch (type) {
+ case ST_BT:
+ /* do nothing */
+ break;
+ case ST_FM:
+ case ST_GPS:
+ if (blocked)
+ st_kim_chip_toggle(type, KIM_GPIO_INACTIVE);
+ else
+ st_kim_chip_toggle(type, KIM_GPIO_ACTIVE);
+ break;
+ case ST_MAX:
+ ST_KIM_ERR(" wrong proto type ");
+ break;
+ }
+ return ST_SUCCESS;
+}
+#endif
+
+/**********************************************************************/
+/* functions called from platform device driver subsystem
+ * need to have a relevant platform device entry in the platform's
+ * board-*.c file
+ */
+
+static int kim_probe(struct platform_device *pdev)
+{
+ long status;
+ long proto;
+ long *gpios = pdev->dev.platform_data;
+
+ for (proto = 0; proto < ST_MAX; proto++) {
+ kim_gdata->gpios[proto] = gpios[proto];
+ ST_KIM_VER(" %ld gpio to be requested", gpios[proto]);
+ }
+
+ for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+ /* Claim the Bluetooth/FM/GPIO
+ * nShutdown gpio from the system
+ */
+ status = gpio_request(gpios[proto], "kim");
+ if (unlikely(status)) {
+ ST_KIM_ERR(" gpio %ld request failed ", gpios[proto]);
+ proto -= 1;
+ while (proto >= 0) {
+ if (gpios[proto] != -1)
+ gpio_free(gpios[proto]);
+ }
+ return status;
+ }
+
+ /* Configure nShutdown GPIO as output=0 */
+ status =
+ gpio_direction_output(gpios[proto], 0);
+ if (unlikely(status)) {
+ ST_KIM_ERR(" unable to configure gpio %ld",
+ gpios[proto]);
+ proto -= 1;
+ while (proto >= 0) {
+ if (gpios[proto] != -1)
+ gpio_free(gpios[proto]);
+ }
+ return status;
+ }
+ }
+ /* pdev to contain BT, FM and GPS enable/N-Shutdown GPIOs
+ * execute request_gpio, set output direction
+ */
+ kim_gdata->kim_kobj = kobject_create_and_add("uim", NULL);
+ /* create the sysfs entry for UIM to put in pid */
+ if (sysfs_create_group(kim_gdata->kim_kobj, &uim_attr_grp)) {
+ ST_KIM_ERR(" sysfs entry creation failed");
+ kobject_put(kim_gdata->kim_kobj);
+ /* free requested GPIOs and fail probe */
+ for (proto = ST_BT; proto < ST_MAX; proto++) {
+ if (gpios[proto] != -1)
+ gpio_free(gpios[proto]);
+ }
+ return -1; /* fail insmod */
+ }
+
+ ST_KIM_DBG(" sysfs entry created ");
+
+ /* get reference of pdev for request_firmware
+ */
+ kim_gdata->kim_pdev = pdev;
+ init_completion(&kim_gdata->kim_rcvd);
+ init_completion(&kim_gdata->ldisc_installed);
+#ifdef LEGACY_RFKILL_SUPPORT
+ for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+ /* TODO: should all types be rfkill_type_bt ? */
+ kim_gdata->rfkill[proto] = rfkill_alloc(protocol_names[proto],
+ &pdev->dev, RFKILL_TYPE_BLUETOOTH,
+ &kim_rfkill_ops, &proto);
+ if (kim_gdata->rfkill[proto] == NULL) {
+ ST_KIM_ERR("cannot create rfkill entry for gpio %ld",
+ gpios[proto]);
+ continue;
+ }
+ status = rfkill_register(kim_gdata->rfkill[proto]);
+ if (unlikely(status)) {
+ ST_KIM_ERR("rfkill registration failed for gpio %ld",
+ gpios[proto]);
+ rfkill_unregister(kim_gdata->rfkill[proto]);
+ continue;
+ }
+ ST_KIM_DBG("rfkill entry created for %ld", gpios[proto]);
+ }
+#endif
+ return ST_SUCCESS;
+}
+
+static int kim_remove(struct platform_device *pdev)
+{
+ /* free the GPIOs requested
+ */
+ long *gpios = pdev->dev.platform_data;
+ long proto;
+
+ for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+ /* Claim the Bluetooth/FM/GPIO
+ * nShutdown gpio from the system
+ */
+ gpio_free(gpios[proto]);
+#ifdef LEGACY_RFKILL_SUPPORT
+ rfkill_unregister(kim_gdata->rfkill[proto]);
+ rfkill_destroy(kim_gdata->rfkill[proto]);
+ kim_gdata->rfkill[proto] = NULL;
+#endif
+ }
+ ST_KIM_DBG("kim: GPIO Freed");
+ /* delete the sysfs entries */
+ sysfs_remove_group(kim_gdata->kim_kobj, &uim_attr_grp);
+ kobject_put(kim_gdata->kim_kobj);
+ kim_gdata->kim_pdev = NULL;
+ return ST_SUCCESS;
+}
+
+/**********************************************************************/
+/* entry point for ST KIM module, called in from ST Core */
+
+long st_kim_init(void)
+{
+ long ret = ST_SUCCESS;
+ kim_gdata = kzalloc(sizeof(struct kim_data_s), GFP_ATOMIC);
+ if (!kim_gdata) {
+ ST_KIM_ERR("no mem to allocate");
+ return -ENOMEM;
+ }
+ ret = platform_driver_register(&kim_platform_driver);
+ if (ret != 0) {
+ ST_KIM_ERR("platform drv registration failed");
+ return ST_ERR_FAILURE;
+ }
+ return ST_SUCCESS;
+}
+
+long st_kim_deinit(void)
+{
+ /* the following returns void */
+ platform_driver_unregister(&kim_platform_driver);
+ kfree(kim_gdata);
+ kim_gdata = NULL;
+ return ST_SUCCESS;
+}
diff --git a/drivers/misc/ti-st/st_kim.h b/drivers/misc/ti-st/st_kim.h
new file mode 100644
index 0000000..4e73bb4
--- /dev/null
+++ b/drivers/misc/ti-st/st_kim.h
@@ -0,0 +1,151 @@
+/*
+ * Shared Transport Line discipline driver Core
+ * Init Manager Module header file
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef ST_KIM_H
+#define ST_KIM_H
+
+#include <linux/types.h>
+#include "st.h"
+#include "st_core.h"
+#include "st_ll.h"
+#include <linux/rfkill.h>
+
+/* time in msec to wait for
+ * line discipline to be installed
+ */
+#define LDISC_TIME 500
+#define CMD_RESP_TIME 500
+#define MAKEWORD(a, b) ((unsigned short)(((unsigned char)(a)) \
+ | ((unsigned short)((unsigned char)(b))) << 8))
+
+#define GPIO_HIGH 1
+#define GPIO_LOW 0
+
+/* the Power-On-Reset logic, requires to attempt
+ * to download firmware onto chip more than once
+ * since the self-test for chip takes a while
+ */
+#define POR_RETRY_COUNT 5
+/*
+ * legacy rfkill support where-in 3 rfkill
+ * devices are created for the 3 gpios
+ * that ST has requested
+ */
+#define LEGACY_RFKILL_SUPPORT
+/*
+ * header file for ST provided by KIM
+ */
+struct kim_data_s {
+ long uim_pid;
+ struct platform_device *kim_pdev;
+ struct completion kim_rcvd, ldisc_installed;
+ /* MAX len of the .bts firmware script name */
+ char resp_buffer[30];
+ const struct firmware *fw_entry;
+ long gpios[ST_MAX];
+ struct kobject *kim_kobj;
+/* used by kim_int_recv to validate fw response */
+ unsigned long rx_state;
+ unsigned long rx_count;
+ struct sk_buff *rx_skb;
+#ifdef LEGACY_RFKILL_SUPPORT
+ struct rfkill *rfkill[ST_MAX];
+#endif
+};
+
+long st_kim_init(void);
+long st_kim_deinit(void);
+
+long st_kim_start(void);
+long st_kim_stop(void);
+/*
+ * called from st_tty_receive to authenticate fw_download
+ */
+void st_kim_recv(const unsigned char *, long count);
+
+void st_kim_chip_toggle(enum proto_type, enum kim_gpio_state);
+
+void st_kim_complete(void);
+
+/* function called from ST KIM to ST Core, to
+ * list out the protocols registered
+ */
+void kim_st_list_protocols(char *);
+
+/*
+ * BTS headers
+ */
+#define ACTION_SEND_COMMAND 1
+#define ACTION_WAIT_EVENT 2
+#define ACTION_SERIAL 3
+#define ACTION_DELAY 4
+#define ACTION_RUN_SCRIPT 5
+#define ACTION_REMARKS 6
+
+/*
+ * * BRF Firmware header
+ * */
+struct bts_header {
+ uint32_t magic;
+ uint32_t version;
+ uint8_t future[24];
+ uint8_t actions[0];
+} __attribute__ ((packed));
+
+/*
+ * * BRF Actions structure
+ * */
+struct bts_action {
+ uint16_t type;
+ uint16_t size;
+ uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_send {
+ uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_wait {
+ uint32_t msec;
+ uint32_t size;
+ uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_delay {
+ uint32_t msec;
+} __attribute__ ((packed));
+
+struct bts_action_serial {
+ uint32_t baud;
+ uint32_t flow_control;
+} __attribute__ ((packed));
+
+/* for identifying the change speed HCI VS
+ * command
+ */
+struct hci_command {
+ uint8_t prefix;
+ uint16_t opcode;
+ uint8_t plen;
+ uint32_t speed;
+} __attribute__ ((packed));
+
+
+#endif /* ST_KIM_H */
Greg KH
> +/* structures specific for sysfs entries */
> +static struct kobj_attribute pid_attr =
> +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> +
> +static struct kobj_attribute list_protocols =
> +__ATTR(protocols, 0444, (void *)show_list, NULL);
As you are creating sysfs attributes, you have to have
Documentation/ABI/ updates as well. Please include them so we can see
what you are trying to do here.
And why "raw" attributes and not device ones?
thanks,
greg k-h
Savoy, Pavan
----------------------
Thanks & Regards,
Pavan Savoy | x0099669
________________________________________
From: Greg KH [gre...@suse.de]
Sent: Tuesday, March 23, 2010 3:06 AM
To: Savoy, Pavan
Cc: al...@lxorguk.ukuu.org.uk; linux-...@vger.kernel.org
Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
On Mon, Mar 22, 2010 at 04:19:14PM -0500, pavan...@ti.com wrote:
> +/* structures specific for sysfs entries */
> +static struct kobj_attribute pid_attr =
> +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> +
> +static struct kobj_attribute list_protocols =
> +__ATTR(protocols, 0444, (void *)show_list, NULL);
>As you are creating sysfs attributes, you have to have
>Documentation/ABI/ updates as well. Please include them so we can see
>what you are trying to do here.
>And why "raw" attributes and not device ones?
>thanks,
>greg k-h
[pavan] >>>>>>>>
I am creating a sysfs entry for the daemon/service to write in it's PID to the sysfs entry, so
as to whenever a new protocol driver - BT/FM or GPS wants to use the N_TI_SHARED ldisc,
the driver would then send signal to daemon on this PID.
The source for this problem, was that I could not install line discipline from kernel space.
i.e make N_TI_SHARED line discipline the current ldisc from kernel space itself.
>>>>>>
From 92d89d132b5036d8ab58ce4f36b24bb1859610e0 Mon Sep 17 00:00:00 2001
From: Pavan Savoy <pavan...@ti.com>
Date: Mon, 22 Mar 2010 18:11:32 -0400
Subject: [PATCH 1/1] Documentation/ABI: for N_TI_SHARED ldisc
N_TI_SHARED creates a sysfs entry to communicate
with the application/daemon which would want to install/
un-install the line discipline, it's documentation
now exists in testing/ subdirectory.
Signed-off-by: Pavan Savoy <pavan...@ti.com>
---
Documentation/ABI/testing/sysfs-uim | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-uim
diff --git a/Documentation/ABI/testing/sysfs-uim b/Documentation/ABI/testing/sysfs-uim
new file mode 100644
index 0000000..899aa4d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-uim
@@ -0,0 +1,24 @@
+What: /sys/uim
+Date: March 22
+Contact: Pavan Savoy <pavan...@ti.com>
+Description:
+ Create a new kobject to pass information about the
+ N_TI_SHARED line discipline created to application/daemon
+ which would install/un-install line discipline.
+
+What: /sys/uim/pid
+Date: March 22
+Contact: Pavan Savoy <pavan...@ti.com>
+Description:
+ The daemon/application wanting to use the line discipline
+ N_TI_SHARED will write in it's process Id, for the LDISC
+ driver to send SIGUSR2 signal to the process whenever a
+ upper layer protocol driver wants to make use of the LDISC
+ driver.
+
+What: /sys/uim/protocols
+Date: March 22
+Contact: Pavan Savoy <pavan...@ti.com>
+Description:
+ List the protocols currently making use of the LDISC to ensure
+ LDISC is not un-installed when BT/FM or GPS is making use of it.
--
1.5.4.3--
Greg KH
>
> ----------------------
> Thanks & Regards,
> Pavan Savoy | x0099669
That made no sense :(
> On Mon, Mar 22, 2010 at 04:19:14PM -0500, pavan...@ti.com wrote:
> > +/* structures specific for sysfs entries */
> > +static struct kobj_attribute pid_attr =
> > +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> > +
> > +static struct kobj_attribute list_protocols =
> > +__ATTR(protocols, 0444, (void *)show_list, NULL);
>
> >As you are creating sysfs attributes, you have to have
> >Documentation/ABI/ updates as well. Please include them so we can see
> >what you are trying to do here.
> >And why "raw" attributes and not device ones?
> >thanks,
> >greg k-h
>
> [pavan] >>>>>>>>
Ick. Please fix your email client to quote properly. There are
hundreds of free email programs out there that will do that. Heck,
there are free web email clients that even get this right...
> I am creating a sysfs entry for the daemon/service to write in it's
> PID to the sysfs entry, so as to whenever a new protocol driver -
> BT/FM or GPS wants to use the N_TI_SHARED ldisc, the driver would then
> send signal to daemon on this PID.
Then document it. All sysfs files need documentation.
Hm, writing a PID to a sysfs file? Oh, that's going to be ripe for
problems. What namespace is that PID in?
> The source for this problem, was that I could not install line
> discipline from kernel space. i.e make N_TI_SHARED line discipline
> the current ldisc from kernel space itself.
Are you sure? I thought the bluetooth core did this already. Have you
looked at how that works?
No, you don't get to create a new root sysfs file, sorry. Please put it
in the correct subsystem location, if anywhere at all.
thanks,
greg k-h
Marcel Holtmann
> > The source for this problem, was that I could not install line
> > discipline from kernel space. i.e make N_TI_SHARED line discipline
> > the current ldisc from kernel space itself.
>
> Are you sure? I thought the bluetooth core did this already. Have you
> looked at how that works?
I didn't have time to look at it at all so far. However I think this
should just go via a proper review process. And it might need some
architecture review first. It is clearly not a candidate for staging
since it is not really self-contained.
Regards
Marcel
Pavan Savoy
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
Marcel, Greg,
I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
Some details about this driver -
1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space N_TI_WL Init manager (UIM) maintaining the Line discipline.
3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.
4. As Alan suggested, If I make it self-contained by pushing number of line disciplines to a slightly larger number, then would it be OK ?
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
Greg KH
> 4. As Alan suggested, If I make it self-contained by pushing number of
> line disciplines to a slightly larger number, then would it be OK ?
That is fine with me, as long as you continue to work on fixing the
issues in the code, and do not object to changing the user/kernel
interface over time to be one that is more sane.
thanks,
greg k-h
Marcel Holtmann
> I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
> Some details about this driver -
>
> 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
>
> 2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space N_TI_WL Init manager (UIM) maintaining the Line discipline.
can you explain why you think this is needed and we can not interface
this directly. If it is a serial port, what protocol does it talk?
> 3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.
I don't understand this. This sounds like a broken concept to me.
> 4. As Alan suggested, If I make it self-contained by pushing number of line disciplines to a slightly larger number, then would it be OK ?
Just from a quick look, I think within a few review cycles this might be
able to get proper upstream inclusion. No idea why bother with staging
in the first place. Lets do this correctly.
Greg KH
> > I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
> > Some details about this driver -
> >
> > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
> >
> > 2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space N_TI_WL Init manager (UIM) maintaining the Line discipline.
>
> can you explain why you think this is needed and we can not interface
> this directly. If it is a serial port, what protocol does it talk?
>
> > 3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.
>
> I don't understand this. This sounds like a broken concept to me.
I also agree, those sysfs files are not acceptable, and will not work
as-designed due to the pid namespace issues :(
thanks,
greg k-h
Pavan Savoy
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
> Cc: "Greg KH" <gre...@suse.de>, "PavanSavoy" <pavan...@ti.com>, "al...@lxorguk.ukuu.org.uk" <al...@lxorguk.ukuu.org.uk>, "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 9:41 PM
> Hi Pavan,
>
>
> > I wanted to somehow put this in staging because then
> it would probably have a thorough architectural review
> process.
> > Some details about this driver -
> >
> > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
> and GPS (probably character device driver) using the
> EXPORTED symbols (-register/_unregister).
> >
> > 2. Much like the hciattach daemon which maintains
> N_HCI bluetooth line discipline, this driver will also have
> a User-Space N_TI_WL Init manager (UIM) maintaining
> the Line discipline.
>
> can you explain why you think this is needed and we can not
> interface
> this directly. If it is a serial port, what protocol does
> it talk?
Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
The same concept goes for FM-V4L2 and GPS character driver.
The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.
>
> > 3. Because of the UIM should know when to
> install/uninstall line discipline, the /sys entry is created
> a root called UIM (a new kobject) and UIM daemon would write
> it's PID to it.
>
> I don't understand this. This sounds like a broken concept
> to me.
Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that,
and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.
>
> > 4. As Alan suggested, If I make it self-contained by
> pushing number of line disciplines to a slightly larger
> number, then would it be OK ?
>
> Just from a quick look, I think within a few review cycles
> this might be
> able to get proper upstream inclusion. No idea why bother
> with staging
> in the first place. Lets do this correctly.
>
The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.
> Regards
>
> Marcel
>
>
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Pavan Savoy
> From: Greg KH <gre...@suse.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
Ok, How do I then from kernel space, ask a user-space daemon to open the TTY port and do a tiocsetd on it ?
[i.e ask for a line discipline to be installed ?]
Can't open the TTY and TIOCSETD upon boot, because BT, FM and GPS might be used or not used anytime.
And the idea of creating a device node, specifically for this and then doing an fasync/SIGIO was somehow rubbished.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Randy Dunlap
> Hi Pavan,
>
>>>> I wanted to somehow put this in staging because then
>>> it would probably have a thorough architectural review
>>> process.
>>>> Some details about this driver -
>>>>
>>>> 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
>>> and GPS (probably character device driver) using the
>>> EXPORTED symbols (-register/_unregister).
>>>>
>>>> 2. Much like the hciattach daemon which maintains
>>> N_HCI bluetooth line discipline, this driver will also have
>>> a User-Space N_TI_WL Init manager (UIM) maintaining
>>> the Line discipline.
>>>
>>> can you explain why you think this is needed and we can not
>>> interface
>>> this directly. If it is a serial port, what protocol does
>>> it talk?
>>
>> Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
>> The same concept goes for FM-V4L2 and GPS character driver.
>>
>> The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.
>
> serial port to connect to the host and then multiplexing BT, FM and GPS
> over it. My question again, what protocol does it talk.
>
> Also why not just install the line discipline and then control the
> subdevices via RFKILL?
>
> You need to share some information about your hardware with us that
> explain what are your objections and how it works.
>
>>>> 3. Because of the UIM should know when to
>>> install/uninstall line discipline, the /sys entry is created
>>> a root called UIM (a new kobject) and UIM daemon would write
>>> it's PID to it.
>>>
>>> I don't understand this. This sounds like a broken concept
>>> to me.
>>
>> Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
>> Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that,
>> and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.
>
> to figure out a workable solution.
>
>>>> 4. As Alan suggested, If I make it self-contained by
>>> pushing number of line disciplines to a slightly larger
>>> number, then would it be OK ?
>>>
>>> Just from a quick look, I think within a few review cycles
>>> this might be
>>> able to get proper upstream inclusion. No idea why bother
>>> with staging
>>> in the first place. Lets do this correctly.
>>>
>>
>> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.
>
> review on LKML and go towards a real upstream solution.
I agree. If I had a new driver, I would try to keep it out of staging,
not get it added there.
--
~Randy
Marcel Holtmann
> > > I wanted to somehow put this in staging because then
> > it would probably have a thorough architectural review
> > process.
> > > Some details about this driver -
> > >
> > > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
> > and GPS (probably character device driver) using the
> > EXPORTED symbols (-register/_unregister).
> > >
> > > 2. Much like the hciattach daemon which maintains
> > N_HCI bluetooth line discipline, this driver will also have
> > a User-Space N_TI_WL Init manager (UIM) maintaining
> > the Line discipline.
> >
> > can you explain why you think this is needed and we can not
> > interface
> > this directly. If it is a serial port, what protocol does
> > it talk?
>
> Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
> The same concept goes for FM-V4L2 and GPS character driver.
>
> The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.
so let us get the facts straight here. The device in question is using a
serial port to connect to the host and then multiplexing BT, FM and GPS
over it. My question again, what protocol does it talk.
Also why not just install the line discipline and then control the
subdevices via RFKILL?
You need to share some information about your hardware with us that
explain what are your objections and how it works.
> > > 3. Because of the UIM should know when to
> > install/uninstall line discipline, the /sys entry is created
> > a root called UIM (a new kobject) and UIM daemon would write
> > it's PID to it.
> >
> > I don't understand this. This sounds like a broken concept
> > to me.
>
> Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
> Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that,
> and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.
Lets forget about this at all. This is not working out at all. We need
to figure out a workable solution.
> > > 4. As Alan suggested, If I make it self-contained by
> > pushing number of line disciplines to a slightly larger
> > number, then would it be OK ?
> >
> > Just from a quick look, I think within a few review cycles
> > this might be
> > able to get proper upstream inclusion. No idea why bother
> > with staging
> > in the first place. Lets do this correctly.
> >
>
> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.
I dislike using the staging tree as review process. We can make a proper
review on LKML and go towards a real upstream solution.
Regards
Marcel
Pavan Savoy
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
Ok, On TTY/4-wire UART, BT talks standard HCI, and HCI-LL for power management as in hci_ll.c/hciattach_ti.c which is already upstream.
And in a very similar way, FM talks over what is known as "channel 8" and GPS over "channel 9", Although these are not standard.
So, basically data going/coming to/out of chip is
1,2,3,4 - HCI
30,31,32,33 for HCI-LL
8 - FM
9 - GPS.
So consider this an extension of hci_ll/hci_ldisc but only more features to accomodate the FM and GPS.
>
> Also why not just install the line discipline and then
> control the
> subdevices via RFKILL?
The chip side PM would be fine, and is being done so, st_kim.c creates the rfkill entries, and controls them locally, also allows applications to control them.
But ldisc can't be install upon boot, because UART clks would be used up for no reason at all.
(say on a mobile phone, how many times in a day - do we actually use BT/FM or GPS - so UART needs to be most often idle, and ldisc should be installed only upon requirement)
>
> You need to share some information about your hardware with
> us that
> explain what are your objections and how it works.
Ok, I am already talking to my managers as to how much I can reveal etc..
>
> > > > 3. Because of the UIM should know when to
> > > install/uninstall line discipline, the /sys entry
> is created
> > > a root called UIM (a new kobject) and UIM daemon
> would write
> > > it's PID to it.
> > >
> > > I don't understand this. This sounds like a
> broken concept
> > > to me.
> >
> > Yes, I don't feel good about it either. But how do I
> request for a line discipline from kernel space ?
> > Currently a daemon has to run in user-space to
> maintain the ldisc, at all times, and I don't want to open
> TTY @ boot, and install Ldisc (tiocsetd) on it, without
> BT/FM or GPS core on chip being used - The Power Management
> team here would beat me up if I do that,
> > and hence the very dumb idea of passing the PID of the
> daemon via sysfs entry, and the driver sending SIGUSR2 to
> that PID, daemon doing a tiocsetd upon that signal.
>
> Lets forget about this at all. This is not working out at
> all. We need
> to figure out a workable solution.
Yes, couple were discussed, like creating a device node, and UIM would open device node, and ldisc driver then can do a fasync/SIGIO upon it - Sounds complex for a simplistic job.
Any more suggestion ?
requirement is the daemon should open/set-baud/and then TIOCSETD only upon requirement for either BT, FM or GPS.
which is currently only known to ldisc driver via the st_register function.
> > > > 4. As Alan suggested, If I make it
> self-contained by
> > > pushing number of line disciplines to a slightly
> larger
> > > number, then would it be OK ?
> > >
> > > Just from a quick look, I think within a few
> review cycles
> > > this might be
> > > able to get proper upstream inclusion. No idea
> why bother
> > > with staging
> > > in the first place. Lets do this correctly.
> > >
> >
> > The only reason I wanted this to be in staging was to
> have sort of continuous review process, and in hope the
> driver wouldn't be forgotten.
>
> I dislike using the staging tree as review process. We can
> make a proper
> review on LKML and go towards a real upstream solution.
Well, the idea is the driver isn't forgotten when this sort of thing happens.
Controversial (may be wrong) concepts like sending signal from kernel to user-space, parsing the script request via firmware class, creating a root kobject just to create a sysfs entry.
I am ok with it going in staging or not - but just want the review to happen, and thanks a lot for having a look.
> Regards
>
> Marcel
>
>
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Alan Cox
The device is always in WL protocol mode and starts this way ?
If so lets simply fix the tty layer to allow a driver to set the initial
ldisc.
> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.
I would certainly prefer this as it is much easier to refine this way
Alan
Pavan Savoy
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
> Cc: "Marcel Holtmann" <mar...@holtmann.org>, "Greg KH" <gre...@suse.de>, "PavanSavoy" <pavan...@ti.com>, "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:28 PM
> > The core of the problem is we
> cannot ask/install/ldisc_put for a line discipline from
> kernel space.
>
> The device is always in WL protocol mode and starts this
> way ?
Totally makes sense, just EXPORT the symbol tty_set_ldisc or tiocsetd, so that kernel space drivers can install/un-install LDISC.
>
> If so lets simply fix the tty layer to allow a driver to
> set the initial
> ldisc.
>
> > The only reason I wanted this to be in staging was to
> have sort of continuous review process, and in hope the
> driver wouldn't be forgotten.
>
> I would certainly prefer this as it is much easier to
> refine this way
>
> Alan
>
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
Greg KH
> --- On Wed, 24/3/10, Greg KH <gre...@suse.de> wrote:
>
> > From: Greg KH <gre...@suse.de>
> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> > To: "Marcel Holtmann" <mar...@holtmann.org>
> > Cc: "Pavan Savoy" <pavan...@yahoo.co.in>, "PavanSavoy" <pavan...@ti.com>, "al...@lxorguk.ukuu.org.uk" <al...@lxorguk.ukuu.org.uk>, "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
> > Date: Wednesday, 24 March, 2010, 9:56 PM
> > On Wed, Mar 24, 2010 at 09:11:45AM
> > -0700, Marcel Holtmann wrote:
> > > > I wanted to somehow put this in staging because
> > then it would probably have a thorough architectural review
> > process.
> > > > Some details about this driver -
> > > >
> > > > 1. This driver will be used by
> > Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device
> > driver) using the EXPORTED symbols (-register/_unregister).
> > > >
> > > > 2. Much like the hciattach daemon which maintains
> > N_HCI bluetooth line discipline, this driver will also have
> > the Line discipline.
> > >
> > > can you explain why you think this is needed and we
> > can not interface
> > > this directly. If it is a serial port, what protocol
> > does it talk?
> > >
> > > > 3. Because of the UIM should know when to
> > install/uninstall line discipline, the /sys entry is created
> > a root called UIM (a new kobject) and UIM daemon would write
> > it's PID to it.
> > >
> > > I don't understand this. This sounds like a broken
> > concept to me.
> >
> > I also agree, those sysfs files are not acceptable, and
> > will not work
> > as-designed due to the pid namespace issues :(
>
> Ok, How do I then from kernel space, ask a user-space daemon to open the TTY port and do a tiocsetd on it ?
> [i.e ask for a line discipline to be installed ?]
What would cause the kernel to want to tell userspace to do this? Is it
an external event that happens somehow that userspace should know to
look for?
> Can't open the TTY and TIOCSETD upon boot, because BT, FM and GPS
> might be used or not used anytime.
What causes them to want to be used? The user, right?
> And the idea of creating a device node, specifically for this and then
> doing an fasync/SIGIO was somehow rubbished.
Why?
Pavan Savoy
> From: Greg KH <gre...@suse.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
Yes, Userspace events like opening the /dev/radio0 device for FM, or hci0 interface for BT.
However the apps/stack would not want to know what LDISC is being used underneath, well they might not even want to know whether it's TTY or USB/i2C - right ?
> > Can't open the TTY and TIOCSETD upon boot, because BT,
> FM and GPS
> > might be used or not used anytime.
>
> What causes them to want to be used? The user,
> right?
>
> > And the idea of creating a device node, specifically
> for this and then
> > doing an fasync/SIGIO was somehow rubbished.
>
> Why?
It does pretty much the same thing, But we would be stuffing in more interfaces to the already huge driver.
I mean just 3 fops on the device ? open/ioctl-fasync/close - but it also uses the SIGnaling concept - but not via PID though.
Alan's talking about opening up the LDISC installation to kernel (say EXPORTING tty_set_ldisc/tiocsetd), That's like ideal scenario in this case.
>
> thanks,
>
> greg k-h
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Alan Cox
Making a driver able to say "and open me in this ldisc" is about ten
lines of code to the core tty layer if that.
There is one caveat - the actual ldisc attach method for an ldisc attach
isn't allowed to fail the attach. That's something we eventually need to
fix anyway.
Otherwise it doesn't look too scary and it would occur when the user
opened the file not when the device was created.
Alan
Marcel Holtmann
So why are we not making the hci_ll into a generic driver that can
register besides Bluetooth also FM and GPS.
Then we can attach that driver to the TTY via line discipline on boot
and let the LL part handle the power management.
Registration of Bluetooth device, FM and GPS nodes are done via RFKILL
that the LL driver exports.
> > Also why not just install the line discipline and then
> > control the
> > subdevices via RFKILL?
>
> The chip side PM would be fine, and is being done so, st_kim.c creates the rfkill entries, and controls them locally, also allows applications to control them.
> But ldisc can't be install upon boot, because UART clks would be used up for no reason at all.
> (say on a mobile phone, how many times in a day - do we actually use BT/FM or GPS - so UART needs to be most often idle, and ldisc should be installed only upon requirement)
I think the driver should make sure it doesn't use the UART clocks if in
deep sleep. This has nothing to do with installing the line discipline
on boot via a userspace tool.
You do the power management for the hci_ll driver already today. So why
can't we do the same in this driver?
Another way to view this is that the LL driver has to create a virtual
bus for Bluetooth, FM and GPS devices. However RFKILL might be a bit
more suitable and simpler.
Regards
Marcel
Alan Cox
Ok I lied - its four lines of code changing, and just set
.ldisc = N_whatever
in your tty_driver
Marcel - that should also clean up some of the other pending goodies
[Untested Patch]
--
tty: Allow the driver to force an ldisc on open
From: Alan Cox <al...@linux.intel.com>
We need this because some hardware is always in various mux or control
modes. At the moment we do handstands via userspace to sort this out on
devices where it makes no sense. Given the size of the patch to fix this
inanity we might as well do so.
Signed-off-by: Alan Cox <al...@linux.intel.com>
---
drivers/char/tty_ldisc.c | 6 +++---
include/linux/tty_driver.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
index 500e740..b149f9c 100644
--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -863,8 +863,8 @@ void tty_ldisc_release(struct tty_struct *tty, struct tty_struct *o_tty)
/* Force an oops if we mess this up */
tty->ldisc = NULL;
- /* Ensure the next open requests the N_TTY ldisc */
- tty_set_termios_ldisc(tty, N_TTY);
+ /* Ensure the next open requests the expected (usually N_TTY) ldisc */
+ tty_set_termios_ldisc(tty, tty->driver->ldisc);
mutex_unlock(&tty->ldisc_mutex);
/* This will need doing differently if we need to lock */
@@ -885,7 +885,7 @@ void tty_ldisc_release(struct tty_struct *tty, struct tty_struct *o_tty)
void tty_ldisc_init(struct tty_struct *tty)
{
- struct tty_ldisc *ld = tty_ldisc_get(N_TTY);
+ struct tty_ldisc *ld = tty_ldisc_get(tty->driver->ldisc);
if (IS_ERR(ld))
panic("n_tty: init_tty");
tty_ldisc_assign(tty, ld);
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index b086779..fc22a41 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -291,6 +291,7 @@ struct tty_driver {
short type; /* type of tty driver */
short subtype; /* subtype of tty driver */
struct ktermios init_termios; /* Initial termios */
+ int ldisc; /* initial ldisc */
int flags; /* tty driver flags */
struct proc_dir_entry *proc_entry; /* /proc fs entry */
struct tty_driver *other; /* only used for the PTY driver */
Pavan Savoy
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
> Cc: "Marcel Holtmann" <mar...@holtmann.org>, "Greg KH" <gre...@suse.de>, "PavanSavoy" <pavan...@ti.com>, "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:33 PM
> Ok I had a brief dig
>
> Making a driver able to say "and open me in this ldisc" is
> about ten
> lines of code to the core tty layer if that.
>
> There is one caveat - the actual ldisc attach method for an
> ldisc attach
> isn't allowed to fail the attach. That's something we
> eventually need to
> fix anyway.
>
> Otherwise it doesn't look too scary and it would occur when
> the user
> opened the file not when the device was created.
So as I understand the user-space application/daemon should do an open on the TTY and then do nothing ?
Somewhere down the line, the driver may do a tty_set_ldisc, and use it the way it wants to ?
Isn't there a mechanism for the tty_set_ldisc to do what _open does ?
I mean there might be plenty of devices on UART which might not need /dev/tty at all ? i.e An App need not open for a ldisc to be installed.
>
> Alan
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Alan Cox
> I mean there might be plenty of devices on UART which might not need /dev/tty at all ? i.e An App need not open for a ldisc to be installed.
There is no mechanism to have an open tty without having an open file
attached to it - and changing that would be very very non trivial. Plus
you still need a way to tell the kernel you want the device in question
active. That probably should get addressed some day but its not a quick
fix up!
Alan
Alan Cox
> [with your patch one of the steps of installing ldisc would be reduced upon opening].
Perhaps but its up to you how you write your low level driver and how the
ldisc indicates it wishes to be active (eg speed B0 is used to indicate
'no carrier' in many cases)
> Actually why do I even need a TTY device in this case - right ?
> ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc..
You don't need a tty if you are simply demuxing some kind of stream of
bytes to/from the hardware and you gain nothing from the tty layer and
user space interfaces such as control signal and speed setting.
That may be even cleaner in your case as you can then then provide
suitable links between your demux and the drivers attached to it
indicating when they should be on or off.
Pavan Savoy
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
> Cc: "Marcel Holtmann" <mar...@holtmann.org>, "Greg KH" <gre...@suse.de>, "PavanSavoy" <pavan...@ti.com>, "linux-...@vger.kernel.org" <linux-...@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:56 PM
> > Isn't there a mechanism for the
> tty_set_ldisc to do what _open does ?
> > I mean there might be plenty of devices on UART which
> might not need /dev/tty at all ? i.e An App need not open
> for a ldisc to be installed.
>
> There is no mechanism to have an open tty without having an
> open file
> attached to it - and changing that would be very very non
> trivial. Plus
> you still need a way to tell the kernel you want the device
> in question
> active. That probably should get addressed some day but its
> not a quick
> fix up!
Which puts me back to square 1, the requirement is TTY device should be open, only when either BT, FM or GPS would want to use it.
[with your patch one of the steps of installing ldisc would be reduced upon opening].
Now from kernel-space which is the first to get notification about requirement of BT/FM or GPS, I somehow have to communicate it to user-space, without the much disliked sysfs entry method.
How do I tell the user-space when I want the TTY device to be opened ?
Actually why do I even need a TTY device in this case - right ?
ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc..
That would mean, a device can be on UART, a ldisc driver attached to it, and doesn't require a user-space daemon to maintain the device node.
>
> Alan
>
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
Pavan Savoy
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
Well hci_ll is tied up with hci_ldisc, we might not even want BT/FM on system, may be just GPS (like we have for 1 version of chip).
In that case GPS directly uses the ST line discipline.
Also few other things like firmware download, a chance for the ldisc driver to be platform device, to take in chip enable GPIOs, is sort of appropriate for a new driver isn't it ?
> Registration of Bluetooth device, FM and GPS nodes are done
> via RFKILL
> that the LL driver exports.
>
> > > Also why not just install the line discipline and
> then
> > > control the
> > > subdevices via RFKILL?
> >
> > The chip side PM would be fine, and is being done so,
> st_kim.c creates the rfkill entries, and controls them
> locally, also allows applications to control them.
> > But ldisc can't be install upon boot, because UART
> clks would be used up for no reason at all.
> > (say on a mobile phone, how many times in a day - do
> we actually use BT/FM or GPS - so UART needs to be most
> often idle, and ldisc should be installed only upon
> requirement)
>
> I think the driver should make sure it doesn't use the UART
> clocks if in
> deep sleep. This has nothing to do with installing the line
> discipline
> on boot via a userspace tool.
>
> You do the power management for the hci_ll driver already
> today. So why
> can't we do the same in this driver?
>
Correct, However that piece of Android code, as far as I have seen it depends on bunch of interfaces provided by the UART driver.
This ldisc on other hand doesn't can work on 8250 driver or with complicated ones like the omap-serial which provides such interfaces to shut off UART clks as and when required.
> Another way to view this is that the LL driver has to
> create a virtual
> bus for Bluetooth, FM and GPS devices. However RFKILL might
> be a bit
> more suitable and simpler.
>
Currently rfkill provided is just sort of an extension, but really it just depends on what protocol (bt, fm, GPS) is being ST_registered, the relevant chip_enable gpio is picked up from platform_device entry in arch/XX/board-YY.c and enabled.
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at� http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at� http://www.tux.org/lkml/
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Pavan Savoy
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
I still want to maintain this as a ldisc driver and the TTY layer is still required to be able to use this with different sort of serial drivers.
example:
We do a have a system here where both 8250/omap-serial co-exist creating their own device nodes (ttyS for 8250, ttyO for omap-serial) and I would want to be able to on boot suggest which serial driver to use, so I can open/install ldisc on ttyS or on ttyO.
> That may be even cleaner in your case as you can then then
> provide
> suitable links between your demux and the drivers attached
> to it
> indicating when they should be on or off.
And as Marcel suggested, can't really put in the PM/UART-clk shut off code in ldisc driver because few of these driver provide interfaces and few don't.
So is there no way this can be accepted with the sysfs entry way of communication ?
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Marcel Holtmann
to be quite honest, I can't see how that can be accepted right now. It
looks wrong on too many levels.
Regards
Marcel
Marcel Holtmann
that is what I am saying. Lets take the hci_ll driver out of it and
create some sort of LL subsystem. Then the TI Bluetooth driver just uses
LL and doesn't have to use hci_ldisc framework.
Don't be afraid of taking hci_ll out of the Bluetooth part and make it a
"subdriver" of your LL driver/ST line discipline.
> Also few other things like firmware download, a chance for the ldisc driver to be platform device, to take in chip enable GPIOs, is sort of appropriate for a new driver isn't it ?
I don't see a problem with it in general. However having some more
details would help here to give clearer directions.
That sounds just like an excuse. We should be able to abstract this
properly and make it work for Android and generic devices.
> > Another way to view this is that the LL driver has to
> > create a virtual
> > bus for Bluetooth, FM and GPS devices. However RFKILL might
> > be a bit
> > more suitable and simpler.
> >
>
> Currently rfkill provided is just sort of an extension, but really it just depends on what protocol (bt, fm, GPS) is being ST_registered, the relevant chip_enable gpio is picked up from platform_device entry in arch/XX/board-YY.c and enabled.
If possible please share some more details about the protocol in use and
the platform architecture of the chip. I think you are trying to make
this more complicated than it has to be.
Pavan Savoy
--- On Thu, 25/3/10, Marcel Holtmann <mar...@holtmann.org> wrote:
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan...@yahoo.co.in>
Sigh -
So to save power, and open/install tty-ldisc only when required, the sysfs entry was introduced.
So now I guess I have 2 options :-
1. Fix the UART/LDISC upon boot by the daemon, get away with the sysfs entry + signaling altogether.
2. find a better way of telling the user-space daemon to open/install the line discipline.
- So any suggestions on option 2 ? like some event mechanism which is simple and clean ?
While we are at it, I will send across the BT driver too which makes use of this LDISC.
>
> Regards
>
> Marcel
>
>
>
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Pavan Savoy
> From: Marcel Holtmann <mar...@holtmann.org>
> Subject: RE: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Savoy, Pavan" <pavan...@ti.com>
> Cc: "Pavan Savoy" <pavan...@yahoo.co.in>, "Greg KH" <gre...@suse.de>, "al...@lxorguk.ukuu.org.uk" <al...@lxorguk.ukuu.org.uk>, "Deosthali, Amey" <adeos...@ti.com>, "Alathur, Pramodh" <pramo...@ti.com>
> Date: Thursday, 25 March, 2010, 3:05 AM
> Hi Pavan,
>
> > Find enclosed the design document, where in figure-1
> pretty much explains the different protocols for FM, GPS, BT
> and HCI-LL.
>
> just after quickly going through that document, I think you
> should
> create an actual ST bus. The ST line discipline should be
> just one
> transport driver for that bus. Since you clearly looking
> into SPI and
> other transports as well.
Had planned a range of TTY drivers for SPI/SlimBus 'ala usb-serial device driver for that.
And hence somehow assumed TTY line discipline should be enough.
SPI/SlimBus I tend to agree, their device nodes in user space is not used, and settings like bus freq, CPOL/CPHA are all set via drivers (for spi atleast).
Even after doing that, what about the requirement of opening an tty device upon request from BT or FM when chip is on UART ?
>
> And then the bus can export Bluetooth, FM and GPS devices.
> And we can
> have separate drivers for these devices.
Hnm, Any such example drivers to look around ?
> You might wanna pick a different name than ST to not make
> ST
> Microelectronics unhappy and next time they call their next
> thing TI ;)
I had called it SHUART for some reason earlier, Yep point to be considered.
Thanks,
> Regards
>
> Marcel
>
>
>
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/