All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Will Deacon <will@kernel.org>
Cc: "Mukesh, Savaliya" <msavaliy@codeaurora.org>,
	akashast@codeaurora.org, linux-serial@vger.kernel.org,
	saravanak@google.com, sspatil@google.com, tkjos@google.com
Subject: Re: [PATCH V2] serial: msm_geni_serial_console : Add Earlycon support
Date: Wed, 6 May 2020 14:59:04 +0200	[thread overview]
Message-ID: <20200506125904.GA3159967@kroah.com> (raw)
In-Reply-To: <20200506124845.GG8043@willie-the-truck>

On Wed, May 06, 2020 at 01:48:45PM +0100, Will Deacon wrote:
> On Wed, May 06, 2020 at 02:02:37PM +0200, Greg KH wrote:
> > On Wed, May 06, 2020 at 05:03:31PM +0530, Mukesh, Savaliya wrote:
> > > +static void msm_geni_serial_wr_char(struct uart_port *uport, int ch)
> > > +{
> > > +	writel_relaxed(ch, uport->membase+SE_GENI_TX_FIFOn);
> > > +	/*
> > > +	 * Ensure FIFO write clear goes through before
> > > +	 * next iteration.
> > > +	 */
> > > +	mb();
> > 
> > Can't you just write the above two lines as:
> > 	writel(ch, uport->membase+SE_GENI_TX_FIFOn);
> > ?
> > 
> > Why put a mb() after a _relaxed() call?
> 
> writel() usually puts the barrier /before/ the I/O write, since it's
> normally used to signal the readiness of a DMA buffer, e.g.:
> 
> 	ptr = dma_map(...);
> 	ptr->data = tx_data;
> 	writel(dev->ctrl_reg, SEND_DATA); // Device must see tx_data
> 
> but this driver looks like it only cares about PIO rather than DMA, in which
> case there's no need for mb() or writel(); writel_relaxed() should do the
> trick because we just need to ensure ordering of the writes hitting the
> device. From memory-barriers.txt:
> 
>   ... they [relaxed accesses] are still guaranteed to be ordered with
>   respect to other accesses from the same CPU thread to the same
>   peripheral when operating on __iomem pointers mapped with the default
>   I/O attributes.

Ok, that makes more sense, many thanks.

So, as writes are ordered here, Savaliya, I think all of the calls to
mb() can be dropped from this driver, right?

thanks,

greg k-h

  reply	other threads:[~2020-05-06 12:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 11:33 [PATCH V2] serial: msm_geni_serial_console : Add Earlycon support Mukesh, Savaliya
2020-05-06 12:02 ` Greg KH
2020-05-06 12:48   ` Will Deacon
2020-05-06 12:59     ` Greg KH [this message]
2020-05-14 13:33       ` Mukesh, Savaliya
2020-05-14 13:32   ` Mukesh, Savaliya
2020-05-14 14:02     ` Greg KH
2020-05-06 12:05 ` Greg KH
2020-05-14 13:33   ` Mukesh, Savaliya
2020-05-14 14:02     ` Greg KH

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=20200506125904.GA3159967@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akashast@codeaurora.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=msavaliy@codeaurora.org \
    --cc=saravanak@google.com \
    --cc=sspatil@google.com \
    --cc=tkjos@google.com \
    --cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.