From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: Mark Brown <broonie@kernel.org>
Cc: SCSI <linux-scsi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jeffrey Hugo <jhugo@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Evan Green <evgreen@chromium.org>,
Douglas Anderson <dianders@chromium.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Avri Altman <avri.altman@wdc.com>,
Pedro Sousa <pedrom.sousa@synopsys.com>,
Joao Pinto <jpinto@synopsys.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Bart Van Assche <bart.vanassche@wdc.com>,
Stanislav Nijnikov <stanislav.nijnikov@wdc.com>,
Alex Lemberg <alex.lemberg@wdc.com>,
Ohad Sharabi <ohad.sharabi@wdc.com>,
Venkat Gopalakrishnan <venkatg@codeaurora.org>,
Subhash Jadavani <subhashj@codeaurora.org>,
Yaniv Gardi <ygardi@codeaurora.org>,
Raviv Shvili <rshvili@codeaurora.org>,
Hannes Reinecke <hare@suse.de>, Kyuho Choi <kyuho.choi@sk.com>,
Martin Petersen <martin.petersen@oracle.com>
Subject: Re: [PATCH v5 1/2] scsi: ufs: Do not disable vccq in UFSHC driver
Date: Wed, 13 Feb 2019 11:05:28 +0100 [thread overview]
Message-ID: <cc915cc2-722b-5cae-6c8b-b0d50d90c56d@free.fr> (raw)
In-Reply-To: <20190211172340.GG22391@sirena.org.uk>
On 11/02/2019 18:23, Mark Brown wrote:
> On Mon, Feb 11, 2019 at 02:32:15PM +0100, Marc Gonzalez wrote:
>
>> Unfortunately, this optimization breaks UFS on systems where vccq
>> powers not only the Flash chip, but the host controller as well,
>> such as APQ8098 MEDIABOX or MTP8998.
>>
>> In my opinion, the rationale for the original patch is questionable.
>> If neither the UFSHC, nor the Flash chip, require any load from vccq,
>> then that power rail should simply not be specified at all in the DT.
>
> If the supply is physically connected it should be valid to represent
> this in DT regardless of how or if the supply gets used at runtime.
> However it does sound like this support needs to be better thought
> through to make sure we have represented the supplies to the flash chip
> and the controller separately - it seems like right now there's no
> tracking of the supplies needed for the controller and the assumption is
> that only the flash chip needs managing which is breaking things.
As far as I'm aware, the conflation of host controller with their respective
storage medium occurs across several techs: UFS, NAND, SDHC, EMMC.
There might be room for improvement, but I don't think these considerations
should hold up this series, which fixes something that is broken *today*.
UFS reviewers (Alim, Avri, Pedro), can I get at least one Acked-by to remove
this small power optimization that breaks UFS on my system?
Regards.
next prev parent reply other threads:[~2019-02-13 10:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190211133457epcas3p2dc95fa2c93c3cf884a376f0282be8b8a@epcas3p2.samsung.com>
2019-02-11 13:31 ` [PATCH v5 0/2] Clean up " Marc Gonzalez
2019-02-11 13:32 ` [PATCH v5 1/2] scsi: ufs: Do not disable vccq in " Marc Gonzalez
2019-02-11 17:23 ` Mark Brown
2019-02-13 10:05 ` Marc Gonzalez [this message]
2019-02-26 9:05 ` Avri Altman
2019-02-26 14:44 ` Martin K. Petersen
2019-02-26 14:45 ` Marc Gonzalez
2019-02-26 14:52 ` Martin K. Petersen
2019-02-26 15:30 ` Marc Gonzalez
2019-02-26 16:26 ` Martin K. Petersen
2019-02-26 17:02 ` Marc Gonzalez
2019-02-26 20:00 ` Martin K. Petersen
2019-02-11 13:33 ` [PATCH v5 2/2] scsi: ufs: Remove unused device quirks Marc Gonzalez
2019-02-26 9:05 ` Avri Altman
2019-02-26 17:14 ` Evan Green
2019-02-13 10:25 ` [PATCH v5 0/2] Clean up UFSHC driver Alim Akhtar
2019-02-23 9:39 ` Marc Gonzalez
2019-02-26 8:57 ` Lee Jones
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=cc915cc2-722b-5cae-6c8b-b0d50d90c56d@free.fr \
--to=marc.w.gonzalez@free.fr \
--cc=alex.lemberg@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bart.vanassche@wdc.com \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=evgreen@chromium.org \
--cc=hare@suse.de \
--cc=jhugo@codeaurora.org \
--cc=jpinto@synopsys.com \
--cc=kyuho.choi@sk.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ohad.sharabi@wdc.com \
--cc=pedrom.sousa@synopsys.com \
--cc=robh+dt@kernel.org \
--cc=rshvili@codeaurora.org \
--cc=stanislav.nijnikov@wdc.com \
--cc=subhashj@codeaurora.org \
--cc=venkatg@codeaurora.org \
--cc=ygardi@codeaurora.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
all inboxes | Powered by JetHome®