linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stepanm@codeaurora.org (Stepan Moskovchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] serial: msm: Add support for UARTDM cores
Date: Wed, 19 Jan 2011 14:08:29 -0800	[thread overview]
Message-ID: <4D3760DD.1010609@codeaurora.org> (raw)
In-Reply-To: <20110119082534.GA9569@gallagher>

Hello Jamie

Thanks for the comments. Responses inline. I will have a v2 out once 
I've had a chance to retest everything.

Steve

On 1/19/2011 12:25 AM, Jamie Iles wrote:
> Hi Stepan,
>
> A couple of pedantic comments inline, otherwise looks good to me.
>
> Jamie
>
> On Tue, Jan 18, 2011 at 07:26:25PM -0800, Stepan Moskovchenko wrote:
>> @@ -38,9 +40,20 @@ struct msm_port {
>>   	struct uart_port	uart;
>>   	char			name[16];
>>   	struct clk		*clk;
>> +	struct clk		*pclk;
>>   	unsigned int		imr;
>> +	unsigned int            *gsbi_base;
>> +	int			is_dm;
>> +	unsigned int		old_snap_state;
>>   };
> Out of interest, what does .is_dm mean?  Is that obvious to someone who
> knows about msm?
It indicates the type of the UART block. I agree that it isn't a very 
good name, but there are no clear versions defined. Basically, the 
driver used to support the MSM UART block, but we are now adding support 
for the UARTDM block (which is very similar to the original, but had 
some DMA capabilities). I've renamed it to is_uartdm for more clarity.


>> +static inline void wait_for_xmitr(struct uart_port *port, int bits)
>> +{
>> +	if (!(msm_read(port, UART_SR)&  UART_SR_TX_EMPTY))
>> +		while ((msm_read(port, UART_ISR)&  bits) != bits)
>> +			cpu_relax();
>> +}
> Is it worth adding a timeout in here?
I don't think so. Other drivers generally don't have timeouts in their 
console path, since dropping characters or timing out in this case could 
be misleading (and if it's happening, you have bigger problems). As for 
the general transmit path, this would only be called when the TX FIFO 
interrupt happens, meaning this will be a fall-through.

>> +		/* Mask conditions we're ignorning. */
>> +		sr&= port->read_status_mask;
>> +		if (sr&  UART_SR_RX_BREAK)
>> +			flag = TTY_BREAK;
>> +		else if (sr&  UART_SR_PAR_FRAME_ERR)
>> +			flag = TTY_FRAME;
> It doesn't look like the flag is used anywhere after it has been
> assigned.
An artifact of an old driver. Removed.

>>   static void msm_init_clock(struct uart_port *port)
>>   {
>>   	struct msm_port *msm_port = UART_TO_MSM(port);
>>
>>   	clk_enable(msm_port->clk);
>> +	if (msm_port->pclk)
>> +		clk_enable(msm_port->pclk);
> NULL is a valid clk, so this should really be something like
>
> 	if (!IS_ERR(mem_port->pclk)
> 		clk_enable(...);
I don't think that will have the correct behavior. The clock is already 
checked with IS_ERR in the probe function, so we could not get here if 
the clk_get returned an error. Depending on the unit, there may or may 
not be a pclk associated with it. Thus, I use NULL to indicate that a 
pclk does not exist and should not be turned on. Regardless, at least in 
the MSM clock driver (and in drivers/clkdev) NULL is not a valid clock, 
I think this should be fine as is.

>>   	msm_serial_set_mnd_regs(port);
>>   }
>>
>> @@ -347,15 +455,32 @@ static int msm_startup(struct uart_port *port)
>>   		msm_write(port, data, UART_IPR);
>>   	}
>>
>> -	msm_reset(port);
>> +	data = 0;
>> +	if ((!port->cons) ||
>> +	    (port->cons&&  (!(port->cons->flags&  CON_ENABLED)))) {
> Safe to remove the extra parentheses here.
Done.

>> -	resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -	if (unlikely(!resource))
>> +	uart_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	if (unlikely(!uart_resource))
>>   		return;
>> -	size = resource->end - resource->start + 1;
>> +	size = uart_resource->end - uart_resource->start + 1;
> resource_size()?
Ooh, how useful :). Done, in all instances.

>> +
>> +		if (unlikely(!request_mem_region(gsbi_resource->start, size,
>> +						 "msm_serial"))) {
>> +			ret = -EBUSY;
>> +			goto fail_release_port;
>> +		}
> Is the unlikely() really worth it in this sort of path?  More
> particularly, why is request_mem_region() more special than the other
> calls that can fail here?

Cleaned up the unlikely stuff.

>>   static int msm_verify_port(struct uart_port *port, struct serial_struct *ser)
>> @@ -515,9 +697,13 @@ static void msm_power(struct uart_port *port, unsigned int state,
>>   	switch (state) {
>>   	case 0:
>>   		clk_enable(msm_port->clk);
>> +		if (msm_port->pclk)
>> +			clk_enable(msm_port->pclk);
> if (!IS_ERR(msm_port->pclk))
>
>>   		break;
>>   	case 3:
>>   		clk_disable(msm_port->clk);
>> +		if (msm_port->pclk)
>> +			clk_disable(msm_port->pclk);
> if (!IS_ERR(msm_port->pclk))
See the earlier comment. We are checking the clock for IS_ERR when we 
clk_get it (and bail if there is an error) so there is no use checking 
it here again. We need NULL to indicate that the clock is not present in 
this case (and null will not be something legitimately returned by clk_get).

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  parent reply	other threads:[~2011-01-19 22:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19  3:26 [PATCH 2/2] serial: msm: Add support for UARTDM cores Stepan Moskovchenko
2011-01-19  8:25 ` Jamie Iles
2011-01-19 17:31   ` David Brown
2011-01-19 17:37     ` Jamie Iles
2011-01-19 19:52       ` David Brown
2011-01-19 22:08   ` Stepan Moskovchenko [this message]
2011-01-19 22:24     ` Russell King - ARM Linux
2011-01-20  0:11       ` Stepan Moskovchenko
2011-01-20  2:38       ` Stepan Moskovchenko
2011-01-20  9:04         ` Russell King - ARM Linux
2011-01-20 21:56 ` [PATCH v2 " Stepan Moskovchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3760DD.1010609@codeaurora.org \
    --to=stepanm@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).