* Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Alan Cox @ 2012-11-06 9:45 UTC (permalink / raw)
To: Jun Chen; +Cc: Alan Cox, serial, russ.gorby, chao.bi, chuansheng.liu
In-Reply-To: <1352193872.4332.44.camel@chenjun-workstation>
> dev_warn(&ifx_dev->spi_dev->dev, "*** SPI Timeout ***");
> + saved_ifx_dev->hangup_reasons |= HU_TIMEOUT;
> ifx_spi_ttyhangup(ifx_dev);
This one should be using ifx_dev->hangup_reasons |=
this part of the code is clean for multiple devices so the ifx_dev
pointer should be used (it will always be the same as saved_ifx_dev
currently so it's just a tidy up)
> +/**
> + * reset_modem - modem reset command function
> + * @val: a reference to the string where the modem reset query is given
> + * @kp: an unused reference to the kernel parameter
> + */
> +
> +static int reset_modem(const char *val, const struct kernel_param *kp)
> +{
> + unsigned long reset_request;
> + int err = 0;
> +
> + u16 addr = V1P35CNT_W;
> + u8 data, def_value;
> +
> + if (kstrtoul(val, 10, &reset_request) < 0)
> + return -EINVAL;
> +
> + if (!saved_ifx_dev) {
> + dev_dbg(&saved_ifx_dev->spi_dev->dev,
> + "%s is called before probe\n", __func__);
> + return -ENODEV;
> + }
> +
> + dev_dbg(&saved_ifx_dev->spi_dev->dev,
> + "%s requested !\n", __func__);
> +
> + if (test_and_set_bit(MR_START, &saved_ifx_dev->mdm_reset_state))
> + goto out;
This case returns 0 - rather than an error like -EBUSY - is that
intentional ?
Otherwise
Acked-by: Alan Cox <alan@linux.intel.com>
and the two points noted can be fixed up with a later patch IMHO.
^ permalink raw reply
* Re: [PATCH] serial:ifx6x60:SPI header is decoded incorrectly
From: Alan Cox @ 2012-11-06 9:42 UTC (permalink / raw)
To: chao bi; +Cc: alan, linux-serial, richardx.r.gorby, jun.d.chen
In-Reply-To: <1352171639.4445.33.camel@bichao>
On Tue, 06 Nov 2012 11:13:59 +0800
chao bi <chao.bi@intel.com> wrote:
>
> This patch is to correct the bit mapping of "MORE" and "CTS" in SPI frame header.
> Per SPI protocol, SPI header is encoded with length of 4 byte, which is defined
> as below:
> bit 0 ~ 11: current data size;
> bit 12: "MORE" bit;
> bit 13: reserve
> bit 14 ~ 15: reserve
> bit 16 ~ 27: next data size
> bit 28: RI
> bit 29: DCD
> bit 30: CTS/RTS
> bit 31: DSR/DTR
>
> According to above SPI header structure, the bit mapping of "MORE" and "CTS" is
> incorrect in function ifx_spi_decode_spi_header();
>
> cc: Chen Jun <jun.d.chen@intel.com>
> Signed-off-by: channing <chao.bi@intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* [PATCH] serial:ifx6x60:SPI header is decoded incorrectly
From: chao bi @ 2012-11-06 3:13 UTC (permalink / raw)
To: alan; +Cc: linux-serial, richardx.r.gorby, jun.d.chen
This patch is to correct the bit mapping of "MORE" and "CTS" in SPI frame header.
Per SPI protocol, SPI header is encoded with length of 4 byte, which is defined
as below:
bit 0 ~ 11: current data size;
bit 12: "MORE" bit;
bit 13: reserve
bit 14 ~ 15: reserve
bit 16 ~ 27: next data size
bit 28: RI
bit 29: DCD
bit 30: CTS/RTS
bit 31: DSR/DTR
According to above SPI header structure, the bit mapping of "MORE" and "CTS" is
incorrect in function ifx_spi_decode_spi_header();
cc: Chen Jun <jun.d.chen@intel.com>
Signed-off-by: channing <chao.bi@intel.com>
---
drivers/tty/serial/ifx6x60.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 5b9bc19..60e767f 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -64,8 +64,8 @@
#include "ifx6x60.h"
#define IFX_SPI_MORE_MASK 0x10
-#define IFX_SPI_MORE_BIT 12 /* bit position in u16 */
-#define IFX_SPI_CTS_BIT 13 /* bit position in u16 */
+#define IFX_SPI_MORE_BIT 4 /* bit position in u8 */
+#define IFX_SPI_CTS_BIT 6 /* bit position in u8 */
#define IFX_SPI_MODE SPI_MODE_1
#define IFX_SPI_TTY_ID 0
#define IFX_SPI_TIMEOUT_SEC 2
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Chen, Jun D @ 2012-11-06 1:32 UTC (permalink / raw)
To: Alan Cox
Cc: alan@linux.intel.com, linux-serial@vger.kernel.org, Gorby, Russ,
Liu, Chuansheng, Bi, Chao
In-Reply-To: <20121105114329.0f60b484@pyramind.ukuu.org.uk>
Hi, Alan,
Thank you very much!
Jun
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Monday, November 05, 2012 7:43 PM
To: Chen, Jun D
Cc: alan@linux.intel.com; linux-serial@vger.kernel.org; Gorby, Russ; Liu, Chuansheng; Bi, Chao
Subject: Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
On Mon, 5 Nov 2012 08:26:08 +0000
"Chen, Jun D" <jun.d.chen@intel.com> wrote:
> Hi,Alan
> Thank your reply and advice.
> > + if (reset_request == IFX_COLD_RESET_REQ) {
> > + /* Need to add these action for modem cold reset:
> > + * - Set the RESET_BB_N to low (better SIM protection)
> > + * - Set the EXT1P35VREN field to low during 20ms (V1P35CNT_W register)
> > + * - set the EXT1P35VREN field to high during 10ms (V1P35CNT_W register)
> > + */
> I want to submit one finished version, but these code need to call the
> intel_scu_ipc_readv and intel_scu_ipc_writev function defined in the file <asm/intel_scu_ipc.h> But this module seem not to be maked. Now I add one macro to disable these functions. I will send the new patch to you and would you like to give more suggestion about this issue.
You probably need your Kconfig entry to have
depends on X86_INTEL_MID && INTEL_SCU_IPC
so that it can only be compiled when the feature is present.
Alan
^ permalink raw reply
* [PATCH] serial: ifx6x60: ifx_spi_write don't need to do mrdy_assert when fifo is not empty.
From: Jun Chen @ 2012-11-06 9:28 UTC (permalink / raw)
To: Alan Cox; +Cc: serial, russ.gorby, chao.bi, jun.d.chen
This patch check whether the kfifo lenth equal to the count of write data.If condition
is true,ifx_spi_write need to trigger one mrdy_assert. If condition is false,the mrdy_assert
will be triggered by the next ifx_spi_io.
Cc: Bi Chao <chao.bi@intel.com>
Signed-off-by: Chen Jun <jun.d.chen@intel.com>
---
drivers/tty/serial/ifx6x60.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index ac718e1..b52ef8d 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -522,7 +522,8 @@ static int ifx_spi_write(struct tty_struct *tty, const unsigned char *buf,
unsigned char *tmp_buf = (unsigned char *)buf;
int tx_count = kfifo_in_locked(&ifx_dev->tx_fifo, tmp_buf, count,
&ifx_dev->fifo_lock);
- mrdy_assert(ifx_dev);
+ if (kfifo_len(&ifx_dev->tx_fifo) == count)
+ mrdy_assert(ifx_dev);
return tx_count;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Jun Chen @ 2012-11-06 9:24 UTC (permalink / raw)
To: Alan Cox; +Cc: serial, russ.gorby, chao.bi, chuansheng.liu, jun.d.chen
The Medfield Platform implements a recovery procedure consisting in an escalation
from simple and light recovery procedures to stronger ones with increased visibility
and impact to end-user.After platform find some problem from Modem,such as no response,
platform will try do modem warm reset.If several tries failed, platform will try to
do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
blob (binary object containing PIN code and other necessary information).
Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of
prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs.
Reset_modem can be read and write by user space.When read the reset_modem,user space will
get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to
IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons.
Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
Cc: Bi Chao <chao.bi@intel.com>
Cc: Liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Chen Jun <jun.d.chen@intel.com>
---
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/ifx6x60.c | 194 +++++++++++++++++++++++++++++++++++++++++-
drivers/tty/serial/ifx6x60.h | 8 ++
3 files changed, 202 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 233fbaa..5ddff34 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1323,7 +1323,7 @@ config SERIAL_ALTERA_UART_CONSOLE
config SERIAL_IFX6X60
tristate "SPI protocol driver for Infineon 6x60 modem (EXPERIMENTAL)"
- depends on GPIOLIB && SPI
+ depends on GPIOLIB && SPI && X86_INTEL_MID && INTEL_SCU_IPC
help
Support for the IFX6x60 modem devices on Intel MID platforms.
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 769396a..d0259c1 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -60,6 +60,7 @@
#include <linux/pm_runtime.h>
#include <linux/spi/ifx_modem.h>
#include <linux/delay.h>
+#include <asm/intel_scu_ipc.h>
#include "ifx6x60.h"
@@ -72,6 +73,27 @@
#define IFX_SPI_HEADER_0 (-1)
#define IFX_SPI_HEADER_F (-2)
+
+/* Delays for powering up/resetting the modem, ms */
+#define PO_INTERLINE_DELAY 1
+#define PO_POST_DELAY 200
+
+#define IFX_COLD_RESET_REQ 1
+
+#define IFX_MDM_PWR_ON 3
+#define IFX_MDM_RST_PMU 4
+
+/* For modem cold boot */
+#define V1P35CNT_W 0x0E0 /* PMIC register used to power off */
+/* the modem */
+#define V1P35_OFF 4
+#define V1P35_ON 6
+#define COLD_BOOT_DELAY_OFF_MIN 20000 /* 20 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_OFF_MAX 25000 /* 25 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_ON_MIN 10000 /* 10 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_ON_MAX 15000 /* 15 ms (use of usleep_range) */
+
+
/* forward reference */
static void ifx_spi_handle_srdy(struct ifx_spi_device *ifx_dev);
@@ -81,6 +103,35 @@ static struct tty_driver *tty_drv;
static struct ifx_spi_device *saved_ifx_dev;
static struct lock_class_key ifx_spi_key;
+
+/**
+ * do_modem_power - activity required to bring up modem
+ *
+ * Toggle gpios required to bring up modem power and start modem.
+ */
+static void do_modem_power(void)
+{
+ gpio_set_value(IFX_MDM_PWR_ON, 1);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_PWR_ON, 0);
+ msleep(PO_POST_DELAY);
+}
+
+/**
+ * do_modem_reset - activity required to reset modem
+ *
+ * Toggle gpios required to reset modem.
+ */
+static void do_modem_reset(void)
+{
+ gpio_set_value(IFX_MDM_RST_PMU, 0);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_RST_PMU, 1);
+ msleep(PO_POST_DELAY);
+}
+
+
+
/* GPIO/GPE settings */
/**
@@ -193,7 +244,6 @@ static void mrdy_assert(struct ifx_spi_device *ifx_dev)
ifx_dev->spi_timer.expires =
jiffies + IFX_SPI_TIMEOUT_SEC*HZ;
add_timer(&ifx_dev->spi_timer);
-
}
}
ifx_spi_power_state_set(ifx_dev, IFX_SPI_POWER_DATA_PENDING);
@@ -229,6 +279,7 @@ static void ifx_spi_timeout(unsigned long arg)
struct ifx_spi_device *ifx_dev = (struct ifx_spi_device *)arg;
dev_warn(&ifx_dev->spi_dev->dev, "*** SPI Timeout ***");
+ saved_ifx_dev->hangup_reasons |= HU_TIMEOUT;
ifx_spi_ttyhangup(ifx_dev);
mrdy_set_low(ifx_dev);
clear_bit(IFX_SPI_STATE_TIMER_PENDING, &ifx_dev->flags);
@@ -881,6 +932,7 @@ static irqreturn_t ifx_spi_reset_interrupt(int irq, void *dev)
/* exited reset */
clear_bit(MR_INPROGRESS, &ifx_dev->mdm_reset_state);
if (solreset) {
+ clear_bit(MR_START, &ifx_dev->mdm_reset_state);
set_bit(MR_COMPLETE, &ifx_dev->mdm_reset_state);
wake_up(&ifx_dev->mdm_reset_wait);
}
@@ -1405,6 +1457,146 @@ static int __init ifx_spi_init(void)
module_init(ifx_spi_init);
module_exit(ifx_spi_exit);
+/*
+ * Module parameters to manage the modem status through sysfs
+ */
+
+/**
+ * reset_modem - modem reset command function
+ * @val: a reference to the string where the modem reset query is given
+ * @kp: an unused reference to the kernel parameter
+ */
+
+static int reset_modem(const char *val, const struct kernel_param *kp)
+{
+ unsigned long reset_request;
+ int err = 0;
+
+ u16 addr = V1P35CNT_W;
+ u8 data, def_value;
+
+ if (kstrtoul(val, 10, &reset_request) < 0)
+ return -EINVAL;
+
+ if (!saved_ifx_dev) {
+ dev_dbg(&saved_ifx_dev->spi_dev->dev,
+ "%s is called before probe\n", __func__);
+ return -ENODEV;
+ }
+
+ dev_dbg(&saved_ifx_dev->spi_dev->dev,
+ "%s requested !\n", __func__);
+
+ if (test_and_set_bit(MR_START, &saved_ifx_dev->mdm_reset_state))
+ goto out;
+
+ if (reset_request == IFX_COLD_RESET_REQ) {
+ gpio_set_value(IFX_MDM_RST_PMU, 0);
+
+ /* Save the current register value */
+ err = intel_scu_ipc_readv(&addr, &def_value, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - read error: %d", __func__, err);
+ goto out;
+ }
+
+ /* Write the new register value (V1P35_OFF) */
+ data = (def_value & 0xf8) | V1P35_OFF;
+ err = intel_scu_ipc_writev(&addr, &data, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+ usleep_range(COLD_BOOT_DELAY_OFF_MIN, COLD_BOOT_DELAY_OFF_MAX);
+
+ /* Write the new register value (V1P35_ON) */
+ data = (def_value & 0xf8) | V1P35_ON;
+ err = intel_scu_ipc_writev(&addr, &data, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+ usleep_range(COLD_BOOT_DELAY_ON_MIN, COLD_BOOT_DELAY_ON_MAX);
+
+ /* Write back the initial register value */
+ err = intel_scu_ipc_writev(&addr, &def_value, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+
+ }
+
+ /* Perform a complete modem reset */
+ do_modem_reset();
+ do_modem_power();
+
+out:
+
+ return err;
+}
+
+
+/**
+* is_modem_reset - modem reset status module parameter callback function
+ * @val: a reference to the string where the modem reset status is returned
+ * @kp: an unused reference to the kernel parameter
+ */
+static int is_modem_reset(char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev)
+ return sprintf(val, "%lu", saved_ifx_dev->mdm_reset_state);
+ else
+ return -ENOTTY;
+}
+
+
+/**
+ * clear_hangup_reasons - clearing all hangup reasons
+ * @val: a reference to the string where the hangup reasons clear query is given
+ * @kp: an unused reference to the kernel parameter
+ */
+static int clear_hangup_reasons(const char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev) {
+ saved_ifx_dev->hangup_reasons = 0;
+ return 0;
+ } else
+ return -ENOTTY;
+}
+
+/**
+ * hangup_reasons - modem hangup reasons module parameter callback function
+ * @val: a reference to the string where the hangup reasons are returned
+ * @kp: an unused reference to the kernel parameter
+ */
+
+static int hangup_reasons(char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev)
+ return sprintf(val, "%lu", saved_ifx_dev->hangup_reasons);
+ else
+ return -ENOTTY;
+}
+
+
+static struct kernel_param_ops reset_modem_ops = {
+ .set = reset_modem,
+ .get = is_modem_reset,
+};
+module_param_cb(reset_modem, &reset_modem_ops, NULL, 0644);
+
+static struct kernel_param_ops hangup_reasons_ops = {
+ .set = clear_hangup_reasons,
+ .get = hangup_reasons,
+};
+module_param_cb(hangup_reasons, &hangup_reasons_ops, NULL, 0644);
+
+
MODULE_AUTHOR("Intel");
MODULE_DESCRIPTION("IFX6x60 spi driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/tty/serial/ifx6x60.h b/drivers/tty/serial/ifx6x60.h
index e8464ba..ae48d28 100644
--- a/drivers/tty/serial/ifx6x60.h
+++ b/drivers/tty/serial/ifx6x60.h
@@ -66,6 +66,13 @@
#define IFX_SPI_POWER_DATA_PENDING 1
#define IFX_SPI_POWER_SRDY 2
+
+/* reasons for hanging up */
+#define HU_TIMEOUT 1 /* spi timer out */
+#define HU_RESET 2 /* modem initiative reset */
+#define HU_COREDUMP 4 /* modem crash coredump */
+#define HU_RORTUR 8 /* spi transfer error:ROR or TUR */
+
struct ifx_spi_device {
/* Our SPI device */
struct spi_device *spi_dev;
@@ -120,6 +127,7 @@ struct ifx_spi_device {
/* modem reset */
unsigned long mdm_reset_state;
+ unsigned long hangup_reasons;
#define MR_START 0
#define MR_INPROGRESS 1
#define MR_COMPLETE 2
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/8] ARM: zynq: move ttc timer code to drivers/clocksource
From: Josh Cartwright @ 2012-11-05 21:47 UTC (permalink / raw)
To: Michal Simek
Cc: Russell King, John Stultz,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Thomas Gleixner, Alan Cox,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mike Turquette
In-Reply-To: <CAHTX3d++0fGSw7GQHcc-S1X1Qh-rfekpr-E8Jkg2_vFqdCFFTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]
On Mon, Nov 05, 2012 at 12:22:55PM +0100, Michal Simek wrote:
> 2012/10/29 Josh Cartwright <josh.cartwright-acOepvfBmUk@public.gmane.org>:
> > Suggested cleanup by Arnd Bergmann. Move the ttc timer.c code to
> > drivers/clocksource, and out of the mach-zynq directory.
> >
> > The common.h (which only held the timer declaration) was renamed to
> > xilinx_ttc.h and moved into include/linux.
> >
> > Signed-off-by: Josh Cartwright <josh.cartwright-acOepvfBmUk@public.gmane.org>
> > Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > ---
> > arch/arm/mach-zynq/Makefile | 2 +-
> > arch/arm/mach-zynq/common.c | 2 +-
> > drivers/clocksource/Makefile | 1 +
> > arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c | 1 -
> > arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h | 4 ++--
> > 5 files changed, 5 insertions(+), 5 deletions(-)
> > rename arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c (99%)
> > rename arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h (91%)
>
> Not going to apply this patch till there is clean way how to move all
> drivers there. Especially I don't like to add xilinx_ttc.h to
> include/linux folder.
Okay; I think it's best to defer the moving of the ttc driver from this
patchset. It is not a dependency of the clk driver support stuff.
If you agree, I can spin up a v2 of the patchset w/o this change, and
without the serial CONFIG_OF stuff. Should v2 contain the patches
you've already pulled into testing?
I'll give Rob's irqchip-like suggestion a spin and see how that works
out in parallel.
Thanks,
Josh
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* [PATCH v2] serial: xilinx_uartps: kill CONFIG_OF conditional
From: Josh Cartwright @ 2012-11-05 21:24 UTC (permalink / raw)
To: Michal Simek; +Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
The Zynq platform requires the use of CONFIG_OF. Remove the #ifdef
conditionals in the uartps driver. Make dependency explicit in Kconfig.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
Michal-
Here's a version of this patch outside of my COMMON_CLK patchset as you
requested ontop of your arm-next branch. An explicit dependency was
added in Kconfig as you had suggested.
Thanks,
Josh
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/xilinx_uartps.c | 9 ---------
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2a53be5..8cb29b5 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1376,6 +1376,7 @@ config SERIAL_MXS_AUART_CONSOLE
config SERIAL_XILINX_PS_UART
tristate "Xilinx PS UART support"
+ depends on OF
select SERIAL_CORE
help
This driver supports the Xilinx PS UART port.
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index b627363..23efe17 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -946,15 +946,11 @@ static int __devinit xuartps_probe(struct platform_device *pdev)
struct resource *res, *res2;
int clk = 0;
-#ifdef CONFIG_OF
const unsigned int *prop;
prop = of_get_property(pdev->dev.of_node, "clock", NULL);
if (prop)
clk = be32_to_cpup(prop);
-#else
- clk = *((unsigned int *)(pdev->dev.platform_data));
-#endif
if (!clk) {
dev_err(&pdev->dev, "no clock specified\n");
return -ENODEV;
@@ -1044,16 +1040,11 @@ static int xuartps_resume(struct platform_device *pdev)
}
/* Match table for of_platform binding */
-
-#ifdef CONFIG_OF
static struct of_device_id xuartps_of_match[] __devinitdata = {
{ .compatible = "xlnx,xuartps", },
{}
};
MODULE_DEVICE_TABLE(of, xuartps_of_match);
-#else
-#define xuartps_of_match NULL
-#endif
static struct platform_driver xuartps_platform_driver = {
.probe = xuartps_probe, /* Probe method */
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 2/8] ARM: zynq: move ttc timer code to drivers/clocksource
From: Rob Herring @ 2012-11-05 14:49 UTC (permalink / raw)
To: Michal Simek
Cc: Josh Cartwright, Grant Likely, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <CAHTX3d++0fGSw7GQHcc-S1X1Qh-rfekpr-E8Jkg2_vFqdCFFTg@mail.gmail.com>
On 11/05/2012 05:22 AM, Michal Simek wrote:
> 2012/10/29 Josh Cartwright <josh.cartwright@ni.com>:
>> Suggested cleanup by Arnd Bergmann. Move the ttc timer.c code to
>> drivers/clocksource, and out of the mach-zynq directory.
>>
>> The common.h (which only held the timer declaration) was renamed to
>> xilinx_ttc.h and moved into include/linux.
>>
>> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/arm/mach-zynq/Makefile | 2 +-
>> arch/arm/mach-zynq/common.c | 2 +-
>> drivers/clocksource/Makefile | 1 +
>> arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c | 1 -
>> arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h | 4 ++--
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>> rename arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c (99%)
>> rename arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h (91%)
>
> Not going to apply this patch till there is clean way how to move all
> drivers there.
> Especially I don't like to add xilinx_ttc.h to include/linux folder.
>
A cleaner way is how we are doing irqchips [1]. This needs a single
function (or one each for clksrc and clkevt) that has a DT match list of
all known timers and calls their init function. It should be a bit
simpler than irqchips init function because you don't need to worry
about hierarchy init ordering. That doesn't solve non-DT though and if
there are any extra functions like we have with irqchips, you still need
the header in include/linux.
Rob
[1] http://www.spinics.net/lists/arm-kernel/msg203687.html
^ permalink raw reply
* Re: [PATCH 8/8] clocksource: xilinx_ttc: add OF_CLK support
From: Michal Simek @ 2012-11-05 13:02 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <0ea1ba71afb3f4551ac27a6dfa41bd97b63cef48.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> Add support for retrieving TTC configuration from device tree. This
> includes the ability to pull information about the driving clocks from
> the of_clk bindings.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 53 ++++++++
> arch/arm/boot/dts/zynq-zc702.dts | 10 ++
> drivers/clocksource/xilinx_ttc.c | 273 ++++++++++++++++++++++-----------------
> 3 files changed, 218 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
> index 5fb763f..9a2442c 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -109,5 +109,58 @@
> };
> };
> };
> +
> + ttc0: ttc0@f8001000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "xlnx,ttc";
> + reg = <0xF8001000 0x1000>;
> + clocks = <&cpu_clk 3>;
> + clock-names = "cpu_1x";
> + clock-ranges;
> +
> + ttc0_0: ttc0.0 {
> + status = "disabled";
> + reg = <0>;
> + interrupts = <0 10 4>;
> + };
> + ttc0_1: ttc0.1 {
> + status = "disabled";
> + reg = <1>;
> + interrupts = <0 11 4>;
> + };
> + ttc0_2: ttc0.2 {
> + status = "disabled";
> + reg = <2>;
> + interrupts = <0 12 4>;
> + };
> + };
> +
> + ttc1: ttc0@f8002000 {
Also this is ttc1: ttc1.
These type of faults can be simple removed by proper dts node generation.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Michal Simek @ 2012-11-05 12:31 UTC (permalink / raw)
To: Josh Cartwright
Cc: Lars-Peter Clausen, Grant Likely, Rob Herring, Russell King,
Mike Turquette, John Stultz, Thomas Gleixner, Alan Cox,
Greg Kroah-Hartman, John Linn, devicetree-discuss, linux-kernel,
linux-arm-kernel, linux-serial
In-Reply-To: <20121102152826.GQ5190@beefymiracle.amer.corp.natinst.com>
2012/11/2 Josh Cartwright <josh.cartwright@ni.com>:
> On Fri, Nov 02, 2012 at 04:12:21PM +0100, Lars-Peter Clausen wrote:
>> On 11/02/2012 02:38 PM, Josh Cartwright wrote:
>> > On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
>> >> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
> [...]
>> >>> +static void __init zynq_periph_clk_setup(struct device_node *np)
>> >>> +{
>> >>> + struct zynq_periph_clk *periph;
>> >>> + const char *parent_names[3];
>> >>> + struct clk_init_data init;
>> >>> + struct clk *clk;
>> >>> + int err;
>> >>> + u32 reg;
>> >>> + int i;
>> >>> +
>> >>> + err = of_property_read_u32(np, "reg", ®);
>> >>> + WARN_ON(err);
>> >>
>> >> Shouldn't the function abort if a error happens somewhere? Continuing here
>> >> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
>> >
>> > The way I see it is: the kernel is will be left in a bad state in the
>> > case of any failure, regardless of if we bail out or continue. AFAICT,
>> > there is no clean way to recover from a failure this early.
>> >
>> > Given that, it seems simpler (albeit marginally so) just to continue; so
>> > that's what I chose to do. I'm not opposed to bailing out, just not
>> > convinced it does anything for us.
>> >
>> The issue with this approach is that, while you get a warning, unexpected
>> seemingly unrelated side-effects may happen later on. E.g. if no reg
>> property for the clock is specified the reg variable will be uninitialized
>> and contain whatever was on the stack before. The clock will be registered
>> nonetheless and the boot process continues. Now if the clock is enabled a
>> bit in a random register will be modified, which could result in strange and
>> abnormal behavior, which can be very hard to track down.
>
> Okay.....but any reasonable person would start their debugging quest at
> the source of the WARN_ON. If someone sees the WARN_ON message but
> stupidly chooses to ignore it, they deserves to spend the time trying to
> track down abnormal behavior, so I'm still not convinced.
I am with Lars. You would be surprised how many people do no read bootlog.
It should be handled better.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 6/8] serial: xilinx_uartps: kill CONFIG_OF conditional
From: Michal Simek @ 2012-11-05 12:16 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <61e872b2cd4abc25c2dab82668e5094b590571a0.1351721190.git.josh.cartwright@ni.com>
2012/10/30 Josh Cartwright <josh.cartwright@ni.com>:
> The Zynq platform requires the use of CONFIG_OF. Remove the #ifdef
> conditionals in the uartps driver.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> drivers/tty/serial/xilinx_uartps.c | 9 ---------
> 1 file changed, 9 deletions(-)
Please send this separately out of this patchset.
Also if you do this change which is understandable, you should also
add
depends on OF
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Alan Cox @ 2012-11-05 11:43 UTC (permalink / raw)
To: Chen, Jun D
Cc: alan@linux.intel.com, linux-serial@vger.kernel.org, Gorby, Russ,
Liu, Chuansheng, Bi, Chao
In-Reply-To: <9E44E06DBBA23A489DED933DBC291A850FD6FE1F@SHSMSX102.ccr.corp.intel.com>
On Mon, 5 Nov 2012 08:26:08 +0000
"Chen, Jun D" <jun.d.chen@intel.com> wrote:
> Hi,Alan
> Thank your reply and advice.
> > + if (reset_request == IFX_COLD_RESET_REQ) {
> > + /* Need to add these action for modem cold reset:
> > + * - Set the RESET_BB_N to low (better SIM protection)
> > + * - Set the EXT1P35VREN field to low during 20ms (V1P35CNT_W register)
> > + * - set the EXT1P35VREN field to high during 10ms (V1P35CNT_W register)
> > + */
> I want to submit one finished version, but these code need to call the intel_scu_ipc_readv and intel_scu_ipc_writev function defined in the file <asm/intel_scu_ipc.h>
> But this module seem not to be maked. Now I add one macro to disable these functions. I will send the new patch to you and would you like to give more suggestion about this issue.
You probably need your Kconfig entry to have
depends on X86_INTEL_MID && INTEL_SCU_IPC
so that it can only be compiled when the feature is present.
Alan
^ permalink raw reply
* Re: [PATCH 3/8] ARM: zynq: dts: add description of the second uart
From: Michal Simek @ 2012-11-05 11:35 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <8c2fac7167cd7c5201d5e1d8e1ceeb183ee2f63f.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> The zynq-7000 has an additional UART at 0xE0001000. Describe it in the
> device tree.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/boot/dts/zynq-ep107.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
Applied to my testing branch.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 4/8] ARM: zynq: dts: split up device tree
From: Michal Simek @ 2012-11-05 11:32 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <1dc81a3260da0a911dbcabd737547b7bff16a99c.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> The purpose of the created zynq-7000.dtsi file is to describe the
> hardware common to all Zynq 7000-based boards. Also, get rid of the
> zynq-ep107 device tree, since it is not hardware anyone can purchase.
>
> Add a zc702 dts file based on the zynq-7000.dtsi. Add it to the
> dts/Makefile so it is built with the 'dtbs' target.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> .../boot/dts/{zynq-ep107.dts => zynq-7000.dtsi} | 19 +++-----------
> arch/arm/boot/dts/zynq-zc702.dts | 30 ++++++++++++++++++++++
> arch/arm/mach-zynq/common.c | 3 ++-
> 4 files changed, 36 insertions(+), 17 deletions(-)
> rename arch/arm/boot/dts/{zynq-ep107.dts => zynq-7000.dtsi} (79%)
> create mode 100644 arch/arm/boot/dts/zynq-zc702.dts
Not going to apply this. We need to finish our discussion in
"[PATCH v4 1/5] zynq: use GIC device tree bindings" before.
Definitely I like idea to use "xlnx,zynq-7000" generic model name.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 2/8] ARM: zynq: move ttc timer code to drivers/clocksource
From: Michal Simek @ 2012-11-05 11:22 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, devicetree-discuss, linux-kernel, linux-arm-kernel,
linux-serial
In-Reply-To: <c0347788fbad559a249a25128a23f40c85d9cbda.1351721190.git.josh.cartwright@ni.com>
2012/10/29 Josh Cartwright <josh.cartwright@ni.com>:
> Suggested cleanup by Arnd Bergmann. Move the ttc timer.c code to
> drivers/clocksource, and out of the mach-zynq directory.
>
> The common.h (which only held the timer declaration) was renamed to
> xilinx_ttc.h and moved into include/linux.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-zynq/Makefile | 2 +-
> arch/arm/mach-zynq/common.c | 2 +-
> drivers/clocksource/Makefile | 1 +
> arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c | 1 -
> arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h | 4 ++--
> 5 files changed, 5 insertions(+), 5 deletions(-)
> rename arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c (99%)
> rename arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h (91%)
Not going to apply this patch till there is clean way how to move all
drivers there.
Especially I don't like to add xilinx_ttc.h to include/linux folder.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 1/8] ARM: zynq: move arm-specific sys_timer out of ttc
From: Michal Simek @ 2012-11-05 11:20 UTC (permalink / raw)
To: Josh Cartwright
Cc: Russell King, John Stultz, devicetree-discuss, linux-kernel,
Rob Herring, Grant Likely, linux-serial, Greg Kroah-Hartman,
Thomas Gleixner, Alan Cox, John Linn, linux-arm-kernel,
Mike Turquette
In-Reply-To: <3ec3531d21c247ac3dcc76d91ff6be13ebfc733b.1351721190.git.josh.cartwright@ni.com>
2012/10/31 Josh Cartwright <josh.cartwright@ni.com>:
> Move the sys_timer definition out of ttc driver and make it part of the
> common zynq code. This is preparation for renaming and COMMON_CLK
> support.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/mach-zynq/common.c | 13 +++++++++++++
> arch/arm/mach-zynq/common.h | 4 +---
> arch/arm/mach-zynq/timer.c | 10 +---------
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Looks good to me. I have added it to my testing branch
and will provide path to mainline through xilinx arm-next branch
Thanks,
Michal
^ permalink raw reply
* [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Jun Chen @ 2012-11-05 16:31 UTC (permalink / raw)
To: alan; +Cc: linux-serial, russ.gorby, chuansheng.liu, chao.bi, jun.d.chen
The Medfield Platform implements a recovery procedure consisting in an escalation
from simple and light recovery procedures to stronger ones with increased visibility
and impact to end-user.After platform find some problem from Modem,such as no response,
platform will try do modem warm reset.If several tries failed, platform will try to
do modem cold boot procedure.For Modem Cold Boot, AP is responsible to generate
blob (binary object containing PIN code and other necessary information).
Blob is stored in AP volatile memory. AP decides to read PIN code from cache instead of
prompting end-user, and sends it to modem as if end-user had entered it.
This patch add module parameters to manage the modem status through sysfs.
Reset_modem can be read and write by user space.When read the reset_modem,user space will
get the mdm_reset_state which used to avoid to run twice at once.When set the reset_modem to
IFX_COLD_RESET_REQ,modem will do cold reset, other val value will trigger modem reset.
Hangup_reasons used to give one interface to user space to know and clear the modem reset reasons.
Now there are four reasons:SPI timeout, modem initiative reset,modem coredump,spi tranfer error.
Cc: Bi Chao <chao.bi@intel.com>
Cc: Liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Chen Jun <jun.d.chen@intel.com>
---
drivers/tty/serial/ifx6x60.c | 199 +++++++++++++++++++++++++++++++++++++++++-
drivers/tty/serial/ifx6x60.h | 8 ++
2 files changed, 206 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 769396a..ac718e1 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -60,6 +60,7 @@
#include <linux/pm_runtime.h>
#include <linux/spi/ifx_modem.h>
#include <linux/delay.h>
+#include <asm/intel_scu_ipc.h>
#include "ifx6x60.h"
@@ -72,6 +73,27 @@
#define IFX_SPI_HEADER_0 (-1)
#define IFX_SPI_HEADER_F (-2)
+
+/* Delays for powering up/resetting the modem, ms */
+#define PO_INTERLINE_DELAY 1
+#define PO_POST_DELAY 200
+
+#define IFX_COLD_RESET_REQ 1
+
+#define IFX_MDM_PWR_ON 3
+#define IFX_MDM_RST_PMU 4
+
+/* For modem cold boot */
+#define V1P35CNT_W 0x0E0 /* PMIC register used to power off */
+/* the modem */
+#define V1P35_OFF 4
+#define V1P35_ON 6
+#define COLD_BOOT_DELAY_OFF_MIN 20000 /* 20 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_OFF_MAX 25000 /* 25 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_ON_MIN 10000 /* 10 ms (use of usleep_range) */
+#define COLD_BOOT_DELAY_ON_MAX 15000 /* 15 ms (use of usleep_range) */
+
+
/* forward reference */
static void ifx_spi_handle_srdy(struct ifx_spi_device *ifx_dev);
@@ -81,6 +103,35 @@ static struct tty_driver *tty_drv;
static struct ifx_spi_device *saved_ifx_dev;
static struct lock_class_key ifx_spi_key;
+
+/**
+ * do_modem_power - activity required to bring up modem
+ *
+ * Toggle gpios required to bring up modem power and start modem.
+ */
+static void do_modem_power(void)
+{
+ gpio_set_value(IFX_MDM_PWR_ON, 1);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_PWR_ON, 0);
+ msleep(PO_POST_DELAY);
+}
+
+/**
+ * do_modem_reset - activity required to reset modem
+ *
+ * Toggle gpios required to reset modem.
+ */
+static void do_modem_reset(void)
+{
+ gpio_set_value(IFX_MDM_RST_PMU, 0);
+ mdelay(PO_INTERLINE_DELAY);
+ gpio_set_value(IFX_MDM_RST_PMU, 1);
+ msleep(PO_POST_DELAY);
+}
+
+
+
/* GPIO/GPE settings */
/**
@@ -193,7 +244,6 @@ static void mrdy_assert(struct ifx_spi_device *ifx_dev)
ifx_dev->spi_timer.expires =
jiffies + IFX_SPI_TIMEOUT_SEC*HZ;
add_timer(&ifx_dev->spi_timer);
-
}
}
ifx_spi_power_state_set(ifx_dev, IFX_SPI_POWER_DATA_PENDING);
@@ -229,6 +279,7 @@ static void ifx_spi_timeout(unsigned long arg)
struct ifx_spi_device *ifx_dev = (struct ifx_spi_device *)arg;
dev_warn(&ifx_dev->spi_dev->dev, "*** SPI Timeout ***");
+ saved_ifx_dev->hangup_reasons |= HU_TIMEOUT;
ifx_spi_ttyhangup(ifx_dev);
mrdy_set_low(ifx_dev);
clear_bit(IFX_SPI_STATE_TIMER_PENDING, &ifx_dev->flags);
@@ -881,6 +932,7 @@ static irqreturn_t ifx_spi_reset_interrupt(int irq, void *dev)
/* exited reset */
clear_bit(MR_INPROGRESS, &ifx_dev->mdm_reset_state);
if (solreset) {
+ clear_bit(MR_START, &ifx_dev->mdm_reset_state);
set_bit(MR_COMPLETE, &ifx_dev->mdm_reset_state);
wake_up(&ifx_dev->mdm_reset_wait);
}
@@ -1405,6 +1457,151 @@ static int __init ifx_spi_init(void)
module_init(ifx_spi_init);
module_exit(ifx_spi_exit);
+/*
+ * Module parameters to manage the modem status through sysfs
+ */
+
+/**
+ * reset_modem - modem reset command function
+ * @val: a reference to the string where the modem reset query is given
+ * @kp: an unused reference to the kernel parameter
+ */
+
+static int reset_modem(const char *val, const struct kernel_param *kp)
+{
+ unsigned long reset_request;
+ int err = 0;
+
+#ifdef CONFIG_INTEL_SCU_IPC
+ u16 addr = V1P35CNT_W;
+ u8 data, def_value;
+#endif
+
+ if (kstrtoul(val, 10, &reset_request) < 0)
+ return -EINVAL;
+
+ if (!saved_ifx_dev) {
+ dev_dbg(&saved_ifx_dev->spi_dev->dev,
+ "%s is called before probe\n", __func__);
+ return -ENODEV;
+ }
+
+ dev_dbg(&saved_ifx_dev->spi_dev->dev,
+ "%s requested !\n", __func__);
+
+ if (test_and_set_bit(MR_START, &saved_ifx_dev->mdm_reset_state))
+ goto out;
+
+#ifdef CONFIG_INTEL_SCU_IPC
+
+ if (reset_request == IFX_COLD_RESET_REQ) {
+ gpio_set_value(IFX_MDM_RST_PMU, 0);
+
+ /* Save the current register value */
+ err = intel_scu_ipc_readv(&addr, &def_value, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - read error: %d", __func__, err);
+ goto out;
+ }
+
+ /* Write the new register value (V1P35_OFF) */
+ data = (def_value & 0xf8) | V1P35_OFF;
+ err = intel_scu_ipc_writev(&addr, &data, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+ usleep_range(COLD_BOOT_DELAY_OFF_MIN, COLD_BOOT_DELAY_OFF_MAX);
+
+ /* Write the new register value (V1P35_ON) */
+ data = (def_value & 0xf8) | V1P35_ON;
+ err = intel_scu_ipc_writev(&addr, &data, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+ usleep_range(COLD_BOOT_DELAY_ON_MIN, COLD_BOOT_DELAY_ON_MAX);
+
+ /* Write back the initial register value */
+ err = intel_scu_ipc_writev(&addr, &def_value, 1);
+ if (err) {
+ dev_err(&saved_ifx_dev->spi_dev->dev,
+ " - %s - write error: %d", __func__, err);
+ goto out;
+ }
+
+ }
+#endif
+
+ /* Perform a complete modem reset */
+ do_modem_reset();
+ do_modem_power();
+
+out:
+
+ return err;
+}
+
+
+/**
+* is_modem_reset - modem reset status module parameter callback function
+ * @val: a reference to the string where the modem reset status is returned
+ * @kp: an unused reference to the kernel parameter
+ */
+static int is_modem_reset(char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev)
+ return sprintf(val, "%lu", saved_ifx_dev->mdm_reset_state);
+ else
+ return -ENOTTY;
+}
+
+
+/**
+ * clear_hangup_reasons - clearing all hangup reasons
+ * @val: a reference to the string where the hangup reasons clear query is given
+ * @kp: an unused reference to the kernel parameter
+ */
+static int clear_hangup_reasons(const char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev) {
+ saved_ifx_dev->hangup_reasons = 0;
+ return 0;
+ } else
+ return -ENOTTY;
+}
+
+/**
+ * hangup_reasons - modem hangup reasons module parameter callback function
+ * @val: a reference to the string where the hangup reasons are returned
+ * @kp: an unused reference to the kernel parameter
+ */
+
+static int hangup_reasons(char *val, const struct kernel_param *kp)
+{
+ if (saved_ifx_dev)
+ return sprintf(val, "%lu", saved_ifx_dev->hangup_reasons);
+ else
+ return -ENOTTY;
+}
+
+
+static struct kernel_param_ops reset_modem_ops = {
+ .set = reset_modem,
+ .get = is_modem_reset,
+};
+module_param_cb(reset_modem, &reset_modem_ops, NULL, 0644);
+
+static struct kernel_param_ops hangup_reasons_ops = {
+ .set = clear_hangup_reasons,
+ .get = hangup_reasons,
+};
+module_param_cb(hangup_reasons, &hangup_reasons_ops, NULL, 0644);
+
+
MODULE_AUTHOR("Intel");
MODULE_DESCRIPTION("IFX6x60 spi driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/tty/serial/ifx6x60.h b/drivers/tty/serial/ifx6x60.h
index e8464ba..ae48d28 100644
--- a/drivers/tty/serial/ifx6x60.h
+++ b/drivers/tty/serial/ifx6x60.h
@@ -66,6 +66,13 @@
#define IFX_SPI_POWER_DATA_PENDING 1
#define IFX_SPI_POWER_SRDY 2
+
+/* reasons for hanging up */
+#define HU_TIMEOUT 1 /* spi timer out */
+#define HU_RESET 2 /* modem initiative reset */
+#define HU_COREDUMP 4 /* modem crash coredump */
+#define HU_RORTUR 8 /* spi transfer error:ROR or TUR */
+
struct ifx_spi_device {
/* Our SPI device */
struct spi_device *spi_dev;
@@ -120,6 +127,7 @@ struct ifx_spi_device {
/* modem reset */
unsigned long mdm_reset_state;
+ unsigned long hangup_reasons;
#define MR_START 0
#define MR_INPROGRESS 1
#define MR_COMPLETE 2
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
From: Chen, Jun D @ 2012-11-05 8:26 UTC (permalink / raw)
To: Alan Cox
Cc: alan@linux.intel.com, linux-serial@vger.kernel.org, Gorby, Russ,
Liu, Chuansheng, Bi, Chao
In-Reply-To: <20121102112945.535bfea7@pyramind.ukuu.org.uk>
Hi,Alan
Thank your reply and advice.
> + if (reset_request == IFX_COLD_RESET_REQ) {
> + /* Need to add these action for modem cold reset:
> + * - Set the RESET_BB_N to low (better SIM protection)
> + * - Set the EXT1P35VREN field to low during 20ms (V1P35CNT_W register)
> + * - set the EXT1P35VREN field to high during 10ms (V1P35CNT_W register)
> + */
I want to submit one finished version, but these code need to call the intel_scu_ipc_readv and intel_scu_ipc_writev function defined in the file <asm/intel_scu_ipc.h>
But this module seem not to be maked. Now I add one macro to disable these functions. I will send the new patch to you and would you like to give more suggestion about this issue.
About the reset_ongoing variable and hangup_reasons variable, I have modify these codes, use mdm_reset_state variable(old ) and hangup_reasons
variable( add ) in the the device structure to realize the codes.
The variable mdm_reset_state used to tell the user space the status about modem reset status and void to run even twice at once.
The variable hangup_reasons used to give one interface to user space to know and clear the reason of modem reset, which don't need to locked.
I've update the patch as your suggestion, please check another PATCH mail.
Jun
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Friday, November 02, 2012 7:30 PM
To: Chen, Jun D
Cc: alan@linux.intel.com; linux-serial@vger.kernel.org; Gorby, Russ; Liu, Chuansheng; Bi, Chao
Subject: Re: [PATCH] serial: ifx6x60: Add module parameters to manage the modem status through sysfs.
> + if (reset_request == IFX_COLD_RESET_REQ) {
> + /* Need to add these action for modem cold reset:
> + * - Set the RESET_BB_N to low (better SIM protection)
> + * - Set the EXT1P35VREN field to low during 20ms (V1P35CNT_W register)
> + * - set the EXT1P35VREN field to high during 10ms (V1P35CNT_W register)
> + */
You seem to have submitted an unfinished version ?
Also can you explain the locking on your new reset_ongoing variable and hangup_reasons variable ? What stops the sysfs code being run in parallel with the other bits or even twice at once.
Looking at it I get the impression that
a) the variable should be in the device structure not a static global
b) it is write only which seems pointless
c) you probably want a mutex around the actual reset processes so that reset is single threaded in each case.
d) that mutex probably belongs in the device structure
The hangup reasons in this patch also appears to be write only ?
Alan
^ permalink raw reply
* Re: [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Huang Shijie @ 2012-11-05 3:16 UTC (permalink / raw)
To: Vinod Koul
Cc: vinod.koul, linux, gregkh, lauri.hintsala, linux-serial,
shawn.guo, linux-arm-kernel, alan
In-Reply-To: <1351163280.7077.11.camel@vkoul-udesk3>
于 2012年10月25日 19:08, Vinod Koul 写道:
> On Thu, 2012-10-25 at 17:15 +0800, Huang Shijie wrote:
>> yes. I have to setup the register. Could you told me which API is the
>> right API?
> dmaengine_slave_config() should be used to send the slave specfic
> parameters
It seems hard to set the registers by the
dmaengine_slave_config().
[1] firstly, there are several drivers use the mxs-dma, the gpmi-nand, mxs-mmc,spi-mxs, i2c-mxs.
If we set the registers by the dmaengine_slave_config(), we must have the register base address for gpmi, mxs, spi, i2c.
It's not a good idea to access these registers in the mxs-dma driver.
[2] secondly, take gpmi_read_page() for example, it uses the DMA_TRANS_NONE several times :
If we set the registers by the dmaengine_slave_config(), the gpmi_read_page() will become like:
.....................................
dmaengine_slave_config()
dmaengine_prep_slave_sg().
...................................
dmaengine_slave_config()
dmaengine_prep_slave_sg().
...................................
dmaengine_slave_config()
dmaengine_prep_slave_sg().
...................................
Is it a nice look?
[3] dma_slave_config{} does not have the fields to contain the registers value.
So I think the current code it's ok, we'd better do not change it.
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tty: serial: max310x: Add terminating entry for spi_device_id table
From: Axel Lin @ 2012-11-04 15:34 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman; +Cc: Alexander Shiyan, linux-serial, linux-kernel
The spi_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/tty/serial/max310x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 2bc28a5..1ab1d2c 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1239,6 +1239,7 @@ static int __devexit max310x_remove(struct spi_device *spi)
static const struct spi_device_id max310x_id_table[] = {
{ "max3107", MAX310X_TYPE_MAX3107 },
{ "max3108", MAX310X_TYPE_MAX3108 },
+ { }
};
MODULE_DEVICE_TABLE(spi, max310x_id_table);
--
1.7.9.5
^ permalink raw reply related
* Re: New serial card development
From: Alan Cox @ 2012-11-02 20:21 UTC (permalink / raw)
To: Matt Schulte; +Cc: Greg KH, Theodore Ts'o, linux-serial
In-Reply-To: <CAJp1Oe7Gsi_5jYQwj8xdLRBqTQEvOWMwAoa2e4CDZH5FD5ZbVw@mail.gmail.com>
On Fri, 2 Nov 2012 13:47:25 -0500
Matt Schulte <matts@commtech-fastcom.com> wrote:
> On Thu, Nov 1, 2012 at 5:26 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> Hello, the next question that I have is how to handle the interrupts
> >> on this UART. It has a more complex interrupt scheme than a
> >> traditional 8250 UART. There is a global ISR register that tells you
> >> which port had the interrupt and then there is another set of
> >> registers that hold the actual interrupts.
> >
> > port->handle_irq is half of what you need, but you probably need to be
> > able to hook serial8250_interruot and provide your own alternative. Given
> > you don't need the irq chain handling either probably the bit that wants
> > to be hookable is the calls to serial_link_irq_chain and
> > serial_unlink_irq_chain in the startup/shutdown methods.
> >
> > In yor case all that and all the irq scanning the chain becomes a simple
> > read of the port and call of the handlers (serial8250_handlee_irq(port,
> > iir)
>
> To be clear, I shouldn't put a custom irq handler inside 8250.c, correct?
>
> I would want to do something along the vein of 8250_dw.c with a custom
> probe and a custome handle_irq?
That's my first guess - there is an awful lot of stuff you simply don't
need in this situation.
^ permalink raw reply
* Re: New serial card development
From: Matt Schulte @ 2012-11-02 18:47 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg KH, Theodore Ts'o, linux-serial
In-Reply-To: <20121101222619.12bb9c50@pyramind.ukuu.org.uk>
On Thu, Nov 1, 2012 at 5:26 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Hello, the next question that I have is how to handle the interrupts
>> on this UART. It has a more complex interrupt scheme than a
>> traditional 8250 UART. There is a global ISR register that tells you
>> which port had the interrupt and then there is another set of
>> registers that hold the actual interrupts.
>
> port->handle_irq is half of what you need, but you probably need to be
> able to hook serial8250_interruot and provide your own alternative. Given
> you don't need the irq chain handling either probably the bit that wants
> to be hookable is the calls to serial_link_irq_chain and
> serial_unlink_irq_chain in the startup/shutdown methods.
>
> In yor case all that and all the irq scanning the chain becomes a simple
> read of the port and call of the handlers (serial8250_handlee_irq(port,
> iir)
To be clear, I shouldn't put a custom irq handler inside 8250.c, correct?
I would want to do something along the vein of 8250_dw.c with a custom
probe and a custome handle_irq?
Matt Schulte
^ permalink raw reply
* Re: [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Josh Cartwright @ 2012-11-02 15:28 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michal Simek, Russell King, John Stultz, devicetree-discuss,
Michal Simek, Rob Herring, linux-kernel, Grant Likely,
linux-serial, Greg Kroah-Hartman, Thomas Gleixner, Alan Cox,
John Linn, linux-arm-kernel, Mike Turquette
In-Reply-To: <5093E2D5.2000304@metafoo.de>
[-- Attachment #1.1: Type: text/plain, Size: 1976 bytes --]
On Fri, Nov 02, 2012 at 04:12:21PM +0100, Lars-Peter Clausen wrote:
> On 11/02/2012 02:38 PM, Josh Cartwright wrote:
> > On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
> >> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
[...]
> >>> +static void __init zynq_periph_clk_setup(struct device_node *np)
> >>> +{
> >>> + struct zynq_periph_clk *periph;
> >>> + const char *parent_names[3];
> >>> + struct clk_init_data init;
> >>> + struct clk *clk;
> >>> + int err;
> >>> + u32 reg;
> >>> + int i;
> >>> +
> >>> + err = of_property_read_u32(np, "reg", ®);
> >>> + WARN_ON(err);
> >>
> >> Shouldn't the function abort if a error happens somewhere? Continuing here
> >> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
> >
> > The way I see it is: the kernel is will be left in a bad state in the
> > case of any failure, regardless of if we bail out or continue. AFAICT,
> > there is no clean way to recover from a failure this early.
> >
> > Given that, it seems simpler (albeit marginally so) just to continue; so
> > that's what I chose to do. I'm not opposed to bailing out, just not
> > convinced it does anything for us.
> >
> The issue with this approach is that, while you get a warning, unexpected
> seemingly unrelated side-effects may happen later on. E.g. if no reg
> property for the clock is specified the reg variable will be uninitialized
> and contain whatever was on the stack before. The clock will be registered
> nonetheless and the boot process continues. Now if the clock is enabled a
> bit in a random register will be modified, which could result in strange and
> abnormal behavior, which can be very hard to track down.
Okay.....but any reasonable person would start their debugging quest at
the source of the WARN_ON. If someone sees the WARN_ON message but
stupidly chooses to ignore it, they deserves to spend the time trying to
track down abnormal behavior, so I'm still not convinced.
Josh
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Lars-Peter Clausen @ 2012-11-02 15:12 UTC (permalink / raw)
To: Josh Cartwright
Cc: Grant Likely, Rob Herring, Russell King, Mike Turquette,
John Stultz, Thomas Gleixner, Alan Cox, Greg Kroah-Hartman,
John Linn, Michal Simek, devicetree-discuss, linux-kernel,
linux-arm-kernel, linux-serial, Michal Simek
In-Reply-To: <20121102133850.GO5190@beefymiracle.amer.corp.natinst.com>
On 11/02/2012 02:38 PM, Josh Cartwright wrote:
> Thanks for the review.
>
> On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
>> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
>>> [...]
>>> +#define PERIPH_CLK_CTRL_SRC(x) (periph_clk_parent_map[((x)&3)>>4])
>>> +#define PERIPH_CLK_CTRL_DIV(x) (((x)&0x3F00)>>8)
>>
>> A few more spaces wouldn't hurt ;)
>
> Okay, sure.
>
>>> [...]
>>> +static void __init zynq_periph_clk_setup(struct device_node *np)
>>> +{
>>> + struct zynq_periph_clk *periph;
>>> + const char *parent_names[3];
>>> + struct clk_init_data init;
>>> + struct clk *clk;
>>> + int err;
>>> + u32 reg;
>>> + int i;
>>> +
>>> + err = of_property_read_u32(np, "reg", ®);
>>> + WARN_ON(err);
>>
>> Shouldn't the function abort if a error happens somewhere? Continuing here
>> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
>
> The way I see it is: the kernel is will be left in a bad state in the
> case of any failure, regardless of if we bail out or continue. AFAICT,
> there is no clean way to recover from a failure this early.
>
> Given that, it seems simpler (albeit marginally so) just to continue; so
> that's what I chose to do. I'm not opposed to bailing out, just not
> convinced it does anything for us.
>
The issue with this approach is that, while you get a warning, unexpected
seemingly unrelated side-effects may happen later on. E.g. if no reg
property for the clock is specified the reg variable will be uninitialized
and contain whatever was on the stack before. The clock will be registered
nonetheless and the boot process continues. Now if the clock is enabled a
bit in a random register will be modified, which could result in strange and
abnormal behavior, which can be very hard to track down.
Also if for example just one clock has its reg property missing the system
will continue to boot if we bail out here. It is just that the peripherals
using that clock won't work. Which will certainly be easier to diagnose than
random abnormal behavior.
>>> +
>>> + periph = kzalloc(sizeof(*periph), GFP_KERNEL);
>>> + WARN_ON(!periph);
>>> +
>>> + periph->clk_ctrl = slcr_base + reg;
>>> + spin_lock_init(&periph->clkact_lock);
>>> +
>>> + init.name = np->name;
>>> + init.ops = &zynq_periph_clk_ops;
>>> + for (i = 0; i < ARRAY_SIZE(parent_names); i++)
>>> + parent_names[i] = of_clk_get_parent_name(np, i);
>>> + init.parent_names = parent_names;
>>> + init.num_parents = ARRAY_SIZE(parent_names);
>>> +
>>> + periph->hw.init = &init;
>>> +
>>> + clk = clk_register(NULL, &periph->hw);
>>> + WARN_ON(IS_ERR(clk));
>>> +
>>> + err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
>>> + WARN_ON(err);
>>> +
>>> + for (i = 0; i < 2; i++) {
>>
>> Not all of the peripheral clock generators have two output clocks. I think
>> it makes sense to use the number entries in clock-output-names here.
>
> Yes, I agree. I'll also update the bindings documentation.
>
> Thanks again,
> Josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox