Re: [PATCH V3 1/2] scsi: ufs: Add support for sending NOP OUT UPIU
+ * ufshcd_wait_for_register - wait for register value to change
+ * @hba - per-adapter interface
+ * @reg - mmio register offset
+ * @mask - mask to apply to read register value
+ * @val - wait condition
+ * @interval_us - polling interval in microsecs
+ * @timeout_ms - timeout in millisecs
+ *
+ * Returns final register value after iteration
+ */
+static u32 ufshcd_wait_for_register(struct ufs_hba *hba, u32 reg, u32 mask,
+ u32 val, unsigned long interval_us, unsigned long timeout_ms)
I feel like this function's role is to wait for clearing register (specially,
doorbells).
If you really don't intend to apply other all register, I think it would better
to change the
function name.
ex> ufshcd_wait_for_clear_doorbell or ufshcd_wait_for_clear_reg?
Although, this API is introduced in this patch and used only for
clearing the doorbell, I have intentionally made it generic to avoid
duplication of wait condition code in future (not just clearing but
also for setting a bit). For example, when we write to HCE.ENABLE we
wait for it turn to 1.
And if you like it, it could be more simple like below
static bool ufshcd_wait_for_clear_reg(struct ufs_hba *hba, u32 reg, u32 mask,
unsigned long interval_us,
unsigned int timeout_ms)
{
unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
Jiffies on 100Hz systems have minimum granularity of 10ms. So we really
wait for more 10ms even though the timeout_ms < 10ms.
Yes. Real timeout depends on system.
But normally actual wait will be maintained until 'ufshcd_readl' is done.
Timeout is valid for failure case. If we don't need to apply a strict timeout
value, it's not bad.
Hmm.. make sense. Will take care in the next patchset.
/* wakeup within 50us of expiry */
const unsigned int expiry = 50;
while (ufshcd_readl(hba, reg) & mask) {
usleep_range(interval_us, interval_us + expiry);
if (time_after(jiffies, timeout)) {
if (ufshcd_readl(hba, reg) & mask)
return false;
I really want the caller to decide on what to do after the timeout.
This helps in error handling cases where we try to clear off the entire
door-bell register but only a few of the bits are cleared after timeout.
I don't know what we can do with the report of the partial success on clearing
bit.
It's just failure case. Isn't enough with false/true?
The point is, if a bit can't be cleared it can be regarded as a
permanent failure (only for that request), otherwise, it can be
retried with the same tag value.
else
return true;
}
}
return true;
}
+{
+ u32 tmp;
+ ktime_t start;
+ unsigned long diff;
+
+ tmp = ufshcd_readl(hba, reg);
+
+ if ((val & mask) != val) {
+ dev_err(hba->dev, "%s: Invalid wait condition 0x%x\n",
+ __func__, val);
+ goto out;
+ }
+
+ start = ktime_get();
+ while ((tmp & mask) != val) {
+ /* wakeup within 50us of expiry */
+ usleep_range(interval_us, interval_us + 50);
+ tmp = ufshcd_readl(hba, reg);
+ diff = ktime_to_ms(ktime_sub(ktime_get(), start));
+ if (diff > timeout_ms) {
+ tmp = ufshcd_readl(hba, reg);
+ break;
+ }
+ }
+out:
+ return tmp;
+}
+
..
+static int
+ufshcd_clear_cmd(struct ufs_hba *hba, int tag)
+{
+ int err = 0;
+ unsigned long flags;
+ u32 reg;
+ u32 mask = 1 << tag;
+
+ /* clear outstanding transaction before retry */
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ ufshcd_utrl_clear(hba, tag);
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+
+ /*
+* wait for for h/w to clear corresponding bit in door-bell.
+* max. wait is 1 sec.
+*/
+ reg = ufshcd_wait_for_register(hba,
+ REG_UTP_TRANSFER_REQ_DOOR_BELL,
+ mask, 0, 1000, 1000);
4th argument should be (~mask) instead of '0', right?
True, but not really for this implementation. It breaks the check in
in wait_for_register -
if ((val & mask) != val)
dev_err(...);
Hmm, it seems complicated to use.
Ok. Is right the following about val as 4th argument?
- clear: val should be '0' regardless corresponding bit.
- set: val should be same with mask.
If the related comment is added, it will be helpful.
Thinking again it looks like it is complicated. How about changing
the check to -
val = val & mask; /* ignore the bits we don't intend to wait on */
while (ufshcd_readl() & mask != val) {
sleep
}
Usage will be ~mask for clearing the bits, mask for setting the bits
in
Re: [PATCH V3 1/2] scsi: ufs: Add support for host assisted background operations
> >I'm not sure that BKOPS with runtime-pm associates.
> >Do you think it's helpful for power management?
> >How about hibernation scheme for runtime-pm?
> >I'm testing and I can introduce soon.
>
>Well, I am thinking on following approach when we introduce
>power management.
>
>ufshcd_runtime_suspend() {
>if (bkops_status >= NON_CRITICAL) { /* 0x1 */
>ufshcd_enable_auto_bkops();
>hibernate(); /* only the link and the device
>should be able to cary out bkops */
>} else {
>hibernate(); /* Link and the device for more savings */
>}
>}
>
>Let me know if this is okay.
I still consider whether BKOPS is proper behavior with runtime-pm or not.
The BKOPS is something that host allows the card to carry out
when the host knows it is idle and not expecting back to back requests.
Runtime PM idle is the only way to know whether the device is
idle (unless we want to reinvent the wheel to detect the idleness of
host and trigger bkops). There was a discussion on this in MMC mailing
list as well, and folks have agreed to move idle time bkops to runtime
PM (http://thread.gmane.org/gmane.linux.kernel.mmc/19444/)
How about this scenario? It seems more simple.
If we concern a response latency of transfer requests, BKOPS can be disabled by
default.
And then BKOPS can be enabled whenever device requests in some exception.
If you have any idea, let me know.
Exceptions are raised only when the device is in critical need for
bkops. Also the spec. recommends, host should ensure that the device
doesn't go into such states.
With your suggestion, when we disable bkops, the exception is raised and
we enable bkops after which there is no way to disable it again?
--
Regards,
Sujit
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] msm_serial: add missing iounmap() on error in msm_request_port()
On Wed, 2013-07-17 at 13:34 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing iounmap() before return from msm_request_port()
> in the error handling case.
>
Reviewed-by: Ivan T. Ivanov
Regards,
Ivan
> Signed-off-by: Wei Yongjun
> ---
> drivers/tty/serial/msm_serial.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> index 2c6cfb3..0b38b28 100644
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -637,7 +637,7 @@ static int msm_request_port(struct uart_port *port)
> if (!request_mem_region(gsbi_resource->start, size,
>"msm_serial")) {
> ret = -EBUSY;
> - goto fail_release_port;
> + goto fail_release_port_membase;
> }
>
> msm_port->gsbi_base = ioremap(gsbi_resource->start, size);
> @@ -651,6 +651,8 @@ static int msm_request_port(struct uart_port *port)
>
> fail_release_gsbi:
> release_mem_region(gsbi_resource->start, size);
> +fail_release_port_membase:
> + iounmap(port->membase);
> fail_release_port:
> release_mem_region(port->mapbase, size);
> return ret;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 1/2] scsi: ufs: Add support for host assisted background operations
On Thu, July 11, 2013, Sujit Reddy Thumma wrote:
> On 7/10/2013 7:01 PM, Seungwon Jeon wrote:
> > I'm not sure that BKOPS with runtime-pm associates.
> > Do you think it's helpful for power management?
> > How about hibernation scheme for runtime-pm?
> > I'm testing and I can introduce soon.
>
> Well, I am thinking on following approach when we introduce
> power management.
>
> ufshcd_runtime_suspend() {
> if (bkops_status >= NON_CRITICAL) { /* 0x1 */
> ufshcd_enable_auto_bkops();
> hibernate(); /* only the link and the device
> should be able to cary out bkops */
> } else {
> hibernate(); /* Link and the device for more savings */
> }
> }
>
> Let me know if this is okay.
I still consider whether BKOPS is proper behavior with runtime-pm or not.
How about this scenario? It seems more simple.
If we concern a response latency of transfer requests, BKOPS can be disabled by
default.
And then BKOPS can be enabled whenever device requests in some exception.
If you have any idea, let me know.
Thanks,
Seungwon Jeon
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 2/2] scsi: ufs: Set fDeviceInit flag to initiate device initialization
Hi,
Sorry for the late response. I had a few days off.
On Thu, July 11, 2013, Dolev Raviv wrote:
> > On Tuesday, July 09, 2013, Sujit Reddy Thumma wrote:
> >> From: Dolev Raviv
> >> Allow UFS device to complete its initialization and accept
> >> SCSI commands by setting fDeviceInit flag. The device may take
> >> time for this operation and hence the host should poll until
> >> fDeviceInit flag is toggled to zero. This step is mandated by
> >> UFS device specification for device initialization completion.
> >> Signed-off-by: Dolev Raviv
> >> Signed-off-by: Sujit Reddy Thumma
> >> ---
> >> drivers/scsi/ufs/ufs.h| 88 +-
> >> drivers/scsi/ufs/ufshcd.c | 292
> >> -
> >> drivers/scsi/ufs/ufshcd.h | 14 ++
> >> drivers/scsi/ufs/ufshci.h |2 +-
> >> 4 files changed, 390 insertions(+), 6 deletions(-)
> >> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> >> index 14c0a4e..db5bde4 100644
> >> --- a/drivers/scsi/ufs/ufs.h
> >> +++ b/drivers/scsi/ufs/ufs.h
> >> @@ -43,6 +43,8 @@
> >> #define GENERAL_UPIU_REQUEST_SIZE 32
> >> #define UPIU_HEADER_DATA_SEGMENT_MAX_SIZE ((ALIGNED_UPIU_SIZE) - \
> >>(GENERAL_UPIU_REQUEST_SIZE))
> >> +#define QUERY_OSF_SIZE((GENERAL_UPIU_REQUEST_SIZE) - \
> >> + (sizeof(struct utp_upiu_header)))
> >> #define UPIU_HEADER_DWORD(byte3, byte2, byte1, byte0)\
> >>cpu_to_be32((byte3 << 24) | (byte2 << 16) |\
> >> @@ -68,7 +70,7 @@ enum {
> >>UPIU_TRANSACTION_COMMAND= 0x01,
> >>UPIU_TRANSACTION_DATA_OUT = 0x02,
> >>UPIU_TRANSACTION_TASK_REQ = 0x04,
> >> - UPIU_TRANSACTION_QUERY_REQ = 0x26,
> >> + UPIU_TRANSACTION_QUERY_REQ = 0x16,
> >> };
> >> /* UTP UPIU Transaction Codes Target to Initiator */
> >> @@ -97,8 +99,19 @@ enum {
> >>UPIU_TASK_ATTR_ACA = 0x03,
> >> };
> >> -/* UTP QUERY Transaction Specific Fields OpCode */
> >> +/* UPIU Query request function */
> >> enum {
> >> + UPIU_QUERY_FUNC_STANDARD_READ_REQUEST = 0x01,
> >> + UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST = 0x81,
> >> +};
> >> +
> >> +/* Flag idn for Query Requests*/
> >> +enum flag_idn {
> >> + QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
> >> +};
> >> +
> >> +/* UTP QUERY Transaction Specific Fields OpCode */
> >> +enum query_opcode {
> >>UPIU_QUERY_OPCODE_NOP = 0x0,
> >>UPIU_QUERY_OPCODE_READ_DESC = 0x1,
> >>UPIU_QUERY_OPCODE_WRITE_DESC= 0x2,
> >> @@ -110,6 +123,21 @@ enum {
> >>UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
> >> };
> >> +/* Query response result code */
> >> +enum {
> >> + QUERY_RESULT_SUCCESS= 0x00,
> >> + QUERY_RESULT_NOT_READABLE = 0xF6,
> >> + QUERY_RESULT_NOT_WRITEABLE = 0xF7,
> >> + QUERY_RESULT_ALREADY_WRITTEN= 0xF8,
> >> + QUERY_RESULT_INVALID_LENGTH = 0xF9,
> >> + QUERY_RESULT_INVALID_VALUE = 0xFA,
> >> + QUERY_RESULT_INVALID_SELECTOR = 0xFB,
> >> + QUERY_RESULT_INVALID_INDEX = 0xFC,
> >> + QUERY_RESULT_INVALID_IDN= 0xFD,
> >> + QUERY_RESULT_INVALID_OPCODE = 0xFE,
> >> + QUERY_RESULT_GENERAL_FAILURE= 0xFF,
> >> +};
> >> +
> >> /* UTP Transfer Request Command Type (CT) */
> >> enum {
> >>UPIU_COMMAND_SET_TYPE_SCSI = 0x0,
> >> @@ -127,6 +155,7 @@ enum {
> >>MASK_SCSI_STATUS= 0xFF,
> >>MASK_TASK_RESPONSE = 0xFF00,
> >>MASK_RSP_UPIU_RESULT= 0x,
> >> + MASK_QUERY_DATA_SEG_LEN = 0x,
> >> };
> >> /* Task management service response */
> >> @@ -160,13 +189,40 @@ struct utp_upiu_cmd {
> >> };
> >> /**
> >> + * struct utp_upiu_query - upiu request buffer structure for
> >> + * query request.
> >> + * @opcode: command to perform B-0
> >> + * @idn: a value that indicates the particular type of data B-1 + *
> @index: Index to further identify data B-2
> >> + * @selector: Index to further identify data B-3
> >> + * @reserved_osf: spec reserved field B-4,5
> >> + * @length: number of descriptor bytes to read/write B-6,7
> >> + * @value: Attribute value to be written DW-5
> >> + * @reserved: spec reserved DW-6,7
> >> + */
> >> +struct utp_upiu_query {
> >> + u8 opcode;
> >> + u8 idn;
> >> + u8 index;
> >> + u8 selector;
> >> + u16 reserved_osf;
> >> + u16 length;
> >> + u32 value;
> >> + u32 reserved[2];
> >> +};
> >> +
> >> +/**
> >> * struct utp_upiu_req - general upiu request structure
> >> * @header:UPIU header structure DW-0 to DW-2
> >> * @sc: fields structure for scsi command DW-3 to DW-7
> >> + * @qr: fields structure for query request DW-3 to DW-7
> >> */
> >> struct utp_upiu_req {
> >>struct utp_upiu_header header;
> >> - struct utp_upiu_cmd sc;
> >> + union {
> >> + struct utp_upiu_cmd sc;
> >> + struct utp_upiu_query qr;
> >> + };
> >> };
> >> /**
> >> @@ -187,10 +243,14 @@ struct utp_
RE: [PATCH V3 1/2] scsi: ufs: Add support for sending NOP OUT UPIU
On Thu, July 11, 2013, Sujit Reddy Thumma wrote:
> On 7/10/2013 6:58 PM, Seungwon Jeon wrote:
> > On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
> >> As part of device initialization sequence, sending NOP OUT UPIU and
> >> waiting for NOP IN UPIU response is mandatory. This confirms that the
> >> device UFS Transport (UTP) layer is functional and the host can configure
> >> the device with further commands. Add support for sending NOP OUT UPIU to
> >> check the device connection path and test whether the UTP layer on the
> >> device side is functional during initialization.
> >>
> >> A tag is acquired from the SCSI tag map space in order to send the device
> >> management command. When the tag is acquired by internal command the scsi
> >> command is rejected with host busy flag in order to requeue the request.
> >> To avoid frequent collisions between internal commands and scsi commands
> >> the device management command tag is allocated in the opposite direction
> >> w.r.t block layer tag allocation.
> >>
> >> Signed-off-by: Sujit Reddy Thumma
> >> Signed-off-by: Dolev Raviv
> >> ---
> >> drivers/scsi/ufs/ufs.h| 43 +++-
> >> drivers/scsi/ufs/ufshcd.c | 596
> >> +
> >> drivers/scsi/ufs/ufshcd.h | 29 ++-
> >> 3 files changed, 552 insertions(+), 116 deletions(-)
> >>
> >> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> >> index 139bc06..14c0a4e 100644
> >> --- a/drivers/scsi/ufs/ufs.h
> >> +++ b/drivers/scsi/ufs/ufs.h
> >> @@ -36,10 +36,16 @@
> >> #ifndef _UFS_H
> >> #define _UFS_H
> >>
> >> +#include
> >> +#include
> >> +
> >> #define MAX_CDB_SIZE 16
> >> +#define GENERAL_UPIU_REQUEST_SIZE 32
> >> +#define UPIU_HEADER_DATA_SEGMENT_MAX_SIZE ((ALIGNED_UPIU_SIZE) - \
> >> + (GENERAL_UPIU_REQUEST_SIZE))
> >>
> >> #define UPIU_HEADER_DWORD(byte3, byte2, byte1, byte0)\
> >> - ((byte3 << 24) | (byte2 << 16) |\
> >> + cpu_to_be32((byte3 << 24) | (byte2 << 16) |\
> >> (byte1 << 8) | (byte0))
> >>
> >> /*
> >> @@ -73,6 +79,7 @@ enum {
> >>UPIU_TRANSACTION_TASK_RSP = 0x24,
> >>UPIU_TRANSACTION_READY_XFER = 0x31,
> >>UPIU_TRANSACTION_QUERY_RSP = 0x36,
> >> + UPIU_TRANSACTION_REJECT_UPIU= 0x3F,
> >> };
> >>
> >> /* UPIU Read/Write flags */
> >> @@ -110,6 +117,12 @@ enum {
> >>UPIU_COMMAND_SET_TYPE_QUERY = 0x2,
> >> };
> >>
> >> +/* UTP Transfer Request Command Offset */
> >> +#define UPIU_COMMAND_TYPE_OFFSET 28
> >> +
> >> +/* Offset of the response code in the UPIU header */
> >> +#define UPIU_RSP_CODE_OFFSET 8
> >> +
> >> enum {
> >>MASK_SCSI_STATUS= 0xFF,
> >>MASK_TASK_RESPONSE = 0xFF00,
> >> @@ -138,26 +151,32 @@ struct utp_upiu_header {
> >>
> >> /**
> >>* struct utp_upiu_cmd - Command UPIU structure
> >> - * @header: UPIU header structure DW-0 to DW-2
> >>* @data_transfer_len: Data Transfer Length DW-3
> >>* @cdb: Command Descriptor Block CDB DW-4 to DW-7
> >>*/
> >> struct utp_upiu_cmd {
> >> - struct utp_upiu_header header;
> >>u32 exp_data_transfer_len;
> >>u8 cdb[MAX_CDB_SIZE];
> >> };
> >>
> >> /**
> >> - * struct utp_upiu_rsp - Response UPIU structure
> >> - * @header: UPIU header DW-0 to DW-2
> >> + * struct utp_upiu_req - general upiu request structure
> >> + * @header:UPIU header structure DW-0 to DW-2
> >> + * @sc: fields structure for scsi command DW-3 to DW-7
> >> + */
> >> +struct utp_upiu_req {
> >> + struct utp_upiu_header header;
> >> + struct utp_upiu_cmd sc;
> >> +};
> >> +
> >> +/**
> >> + * struct utp_cmd_rsp - Response UPIU structure
> >>* @residual_transfer_count: Residual transfer count DW-3
> >>* @reserved: Reserved double words DW-4 to DW-7
> >>* @sense_data_len: Sense data length DW-8 U16
> >>* @sense_data: Sense data field DW-8 to DW-12
> >>*/
> >> -struct utp_upiu_rsp {
> >> - struct utp_upiu_header header;
> >> +struct utp_cmd_rsp {
> >>u32 residual_transfer_count;
> >>u32 reserved[4];
> >>u16 sense_data_len;
> >> @@ -165,6 +184,16 @@ struct utp_upiu_rsp {
> >> };
> >>
> >> /**
> >> + * struct utp_upiu_rsp - general upiu response structure
> >> + * @header: UPIU header structure DW-0 to DW-2
> >> + * @sr: fields structure for scsi command DW-3 to DW-12
> >> + */
> >> +struct utp_upiu_rsp {
> >> + struct utp_upiu_header header;
> >> + struct utp_cmd_rsp sr;
> >> +};
> >> +
> >> +/**
> >>* struct utp_upiu_task_req - Task request UPIU structure
> >>* @header - UPIU header structure DW0 to DW-2
> >>* @input_param1: Input parameter 1 DW-3
> >> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> >> index b743bd6..3f482b6 100644
> >> --- a/drivers/scsi/ufs/ufshcd.c
> >> +++ b/drivers/scsi/ufs/ufshcd.c
> >> @@ -43,6 +43,11 @@
> >> /* UIC command timeout, unit: ms */
> >> #define UIC_CMD_TIMEOUT 500
> >>
> >> +/* NOP OUT retri
Re: [PATCH] tty: serial: Add initial MSM UART High Speed Lite driver
Hi Kumar,
On Tue, 2013-07-16 at 15:17 -0500, Kumar Gala wrote:
> On Jul 1, 2013, at 4:11 AM, Ivan T. Ivanov wrote:
>
> > From: "Ivan T. Ivanov"
> >
> > This is a tty driver with console support for Qualcomm's UART
> > controllers found in the MSM8974 chipsets. Driver is completely
> > based on implementation found in codeaurora.org msm_serial_hs_lite
> > with Android dependences removed. Other changes include, moved to
> > device managed resources and few cleanups.
> >
> > Driver functionality was tested in LEGACY_HSUART mode.
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > .../bindings/tty/serial/msm_serial_hsl.txt | 52 +
> > drivers/tty/serial/Kconfig | 18 +
> > drivers/tty/serial/Makefile|1 +
> > drivers/tty/serial/msm_serial_hsl.c| 1399
> >
> > drivers/tty/serial/msm_serial_hsl.h| 294
> > 5 files changed, 1764 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> > create mode 100644 drivers/tty/serial/msm_serial_hsl.c
> > create mode 100644 drivers/tty/serial/msm_serial_hsl.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> > b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> > new file mode 100644
> > index 000..972552f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> > @@ -0,0 +1,52 @@
> > +* Qualcomm MSM HSUART Lite
> > +
> > +Required properties:
> > +- compatible :
> > + "qcom,msm-lsuart-v14" to be used for UARTDM Core v1.4
>
> If its really v1.4 than the string should be "qcom,msm-lsuart-v1.4"
I am not sure which is the right number here. codeaurora code uses v14
string for compatible name and 1.4 here and there in the comments.
I am inclined to believe that 1.4 is true.
>
> > +
> > +- reg :
> > + offset and length of the register set for both the device,
> > + UART core and GBSI core
> > +
> > +- reg-names :
> > + "uart_mem" to be used as name of the UART core
> > + "gbsi_mem" to be used as name of the GBSI core
> > +
> > +The registers for the "qcom,msm-lsuart-v14" device have specify
> > +UART core block. GSBI reg is optional if specified driver will use
> > +GSBI specific functionality.
> > +
> > +- interrupts : interrupts for UART core
> > +
> > +- clocks : Must contain an entry for each entry in clock-names.
> > +
> > +- clock-names : Must include the following entries:
> > + "core_clk" - mandatory
> > + "iface_clk" - optional
> > +
> > +For details see:
> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Example:
> > +
> > + serial@f991e000 {
> > + compatible = "qcom,msm-lsuart-v14";
> > + reg = <0xf991e000 0x1000>;
> > + reg-names = "uart_mem";
> > + interrupts = <0 108 0>;
> > + clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>;
> > + clock-names = "core_clk", "iface_clk";
> > + };
> > +
> > +Aliases :
> > +An alias may be optionally used to bind the UART device to a TTY device
> > +(ttyHSL) with a given alias number. Aliases are of the form
> > +uart where is an integer representing the alias number to use.
> > +On systems with multiple UART devices present, an alias may optionally be
> > +defined for such devices. The alias value should be from 0 to 255.
> > +
> > +Example:
> > +
> > + aliases {
> > + uart4 = &uart7; // This device will be enumerated as ttyHSL4
> > + };
> > diff --git a/drivers/tty/serial/msm_serial_hsl.c
> > b/drivers/tty/serial/msm_serial_hsl.c
> > new file mode 100644
> > index 000..56c15a8
> > --- /dev/null
> > +++ b/drivers/tty/serial/msm_serial_hsl.c
> > @@ -0,0 +1,1399 @@
> > +/*
> > + * drivers/tty/serial/msm_serial_hsl.c - driver for serial device and
> > console
> > + *
> > + * Copyright (C) 2007 Google, Inc.
> > + * Copyright (c) 2010-2013, The Linux Foundation. All rights reserved.
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * 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.
> > + */
> > +
> > +/* Acknowledgements:
> > + * This file is based on msm_serial.c, originally
> > + * Written by Robert Love */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "msm_serial_hsl.h"
> > +
> > +/*
> > + * There are 3 different kind of UART Core available on MSM.
> > +
