On Wed 28 Aug 02:09 PDT 2019, Marc Gonzalez wrote:
> Hello,
>
> Someone posted a bug report for UFS on an sdm850 tablet:
> https://bugzilla.kernel.org/show_bug.cgi?id=204685
>
> If I'm reading the boot logs right, this board is EFI rather than DT.
It's UEFI-based and Linux will either operate b
On Fri 07 Jun 03:41 PDT 2019, Alim Akhtar wrote:
> Hi Marc
> Thanks for coping me.
>
> On 6/4/19 1:23 PM, Marc Gonzalez wrote:
> > [ Shuffling the recipients list ]
> >
> > On 04/06/2019 09:20, Bjorn Andersson wrote:
> >
> >> Acquire the devic
On Tue 04 Jun 00:53 PDT 2019, Marc Gonzalez wrote:
> [ Shuffling the recipients list ]
>
> On 04/06/2019 09:20, Bjorn Andersson wrote:
>
> > Acquire the device-reset GPIO and toggle this to reset the UFS device
> > during initialization and host reset.
> >
>
On Tue 05 Feb 02:52 PST 2019, Alim Akhtar wrote:
> Hi Bjorn,
>
> On 05/02/19 11:57 AM, Bjorn Andersson wrote:
> > On Mon 04 Feb 20:58 PST 2019, Alim Akhtar wrote:
> >
> >> Hi Marc,
> >>
> >> On 04/02/19 11:12 PM
On Mon 04 Feb 20:58 PST 2019, Alim Akhtar wrote:
> Hi Marc,
>
> On 04/02/19 11:12 PM, Marc Gonzalez wrote:
> > This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
> >
> > Calling ufshcd_set_vccq_rail_unused hangs my system.
> > It seems vccq is not *not* needed.
> >
> > Signed-off-by:
On Mon 04 Feb 11:51 PST 2019, Avri Altman wrote:
>
> > This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
> >
> > Calling ufshcd_set_vccq_rail_unused hangs my system.
> > It seems vccq is not *not* needed.
> This patch essentially implements the UFS_DEVICE_NO_VCCQ quirk,
> Which is ne
3c8/0x550
> [3.883264] ufs_qcom_probe+0x24/0x60
> [3.887188] platform_drv_probe+0x50/0xa0
>
> Assuming aligned 32-bit registers, let's use readl, after making sure
> that 'offset' and 'len' are indeed multiples of 4.
>
> Fixes: ba80917d9932d (
On Mon 14 Jan 09:36 PST 2019, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 09:30:51AM -0800, Bjorn Andersson wrote:
> > The problem here is that the capability bit states that the controller
> > itself claim to be able to deal with 64-bit addresses, which is probably
>
On Mon 14 Jan 03:11 PST 2019, Christoph Hellwig wrote:
> On Fri, Jan 11, 2019 at 02:54:02PM -0800, Bjorn Andersson wrote:
> > */
> > static int ufshcd_set_dma_mask(struct ufs_hba *hba)
> > {
> > - if (hba->capabilities & MASK_64_ADDRES
On Fri 11 Jan 15:33 PST 2019, Doug Anderson wrote:
> Hi,
>
> On Fri, Jan 11, 2019 at 2:54 PM Bjorn Andersson
> wrote:
> >
> > On Qualcomm SDM845 the capabilities of the UFS MEM controller states
> > that it's capable of dealing with 64 bit addresses, but DMA
range supported by the bus and device and not just
following what the controller's capabilities states.
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufshcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/uf
pat_ioctl = rpmsg_ctrldev_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
For rpmsg part
Acked-by: Bjorn Andersson
Regards,
Bjorn
On Tue 04 Sep 03:17 PDT 2018, Vivek Gautam wrote:
> Fork out separate configs for 14nm and 20nm qcom ufs qmp phys
> to declare the 20nm phy as broken.
>
> Signed-off-by: Vivek Gautam
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/phy/qual
fs phy.
> So remove these ufs_qcom_phy_*() calls from host to let further
> change declare the 20nm phy as broken.
> Also remove couple of stale enum defines for ufs phy.
>
> Signed-off-by: Vivek Gautam
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/p
On Tue 04 Sep 03:17 PDT 2018, Vivek Gautam wrote:
> Remove ufs_qcom_phy_enable/(disable)_dev_ref_clk() that
> are not being used by any code.
>
> Signed-off-by: Vivek Gautam
Thanks for the ping Vivek, I didn't spot these when you posted them.
Reviewed-by: Bjorn Andersson
registered.
The subsequent patch builds upon this to make UFS actually work again,
as it's been broken since f1d981eaecf8 ("PM / devfreq: Use the available
min/max frequency")
Also switch to use DEVFREQ_GOV_SIMPLE_ONDEMAND constant.
Reviewed-by: Chanwoo Choi
Signed-off-by: Bjorn A
now that it finally works again.
Bjorn Andersson (3):
scsi: ufs: Extract devfreq registration
scsi: ufs: Use freq table with devfreq
arm64: dts: qcom: msm8996: Add ufs related nodes
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 8 ++
arch/arm64/boot/dts/qcom/msm8996.dtsi| 85 +
e these to determine if we're trying to step up or down.
Reviewed-by: Chanwoo Choi [for devfreq & OPP part]
Reviewed-by: Subhash Jadavani
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Picked up R-b from Chanwoo and Subhash
Chances since v1:
- Register min_freq and max_freq as opp l
registered.
The subsequent patch builds upon this to make UFS actually work again,
as it's been broken since f1d981eaecf8 ("PM / devfreq: Use the available
min/max frequency")
Reviewed-by: Subhash Jadavani
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
a
clean fashion, and removes the kernel panic which previously happened when
devfreq initialization failed.
With this UFS is once again functional on the db820c, and is needed to get UFS
working on SDM845 (both tested).
Bjorn Andersson (2):
scsi: ufs: Extract devfreq registration
scsi: ufs:
e these to determine if we're trying to step up or down.
Signed-off-by: Bjorn Andersson
---
Chances since v1:
- Register min_freq and max_freq as opp levels.
- Unregister opp levels on removal, to make e.g. probe defer working
drivers/scsi/ufs/ufshcd.c | 47 +--
On Tue 24 Apr 15:08 PDT 2018, Subhash Jadavani wrote:
> On 2018-04-23 17:20, Bjorn Andersson wrote:
> > devfreq requires that the client operates on actual frequencies, not
> > only 0 and UMAX_INT and as such UFS brok with the introduction of
> > f1d981eaecf8 ("PM / devf
On Mon 23 Apr 23:09 PDT 2018, MyungJoo Ham wrote:
> >On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
> >
> >> Hi,
> >>
> >> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
> >> > The code in devfreq_add_device() handles the case where a
On Tue 24 Apr 00:26 PDT 2018, Chanwoo Choi wrote:
> Hi,
>
> On 2018??? 04??? 24??? 14:29, Bjorn Andersson wrote:
> > On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
> >
> >> Hi,
> >>
> >> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
&g
On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
> Hi,
>
> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
> > The code in devfreq_add_device() handles the case where a freq_table is
> > passed by the client, but then requests min and max frequences from
> > th
ese frequencies back to the step up/down actions.
With this UFS is once again functional on the db820c, and is needed to get UFS
working on SDM845 (both tested).
Bjorn Andersson (3):
PM / devfreq: Actually support providing freq_table
scsi: ufs: Extract devfreq registration
scsi: ufs: Use
registered.
The subsequent patch builds upon this to make UFS actually work again,
as it's been broken since f1d981eaecf8 ("PM / devfreq: Use the available
min/max frequency")
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufshcd.c | 31 ++-
1 fi
e these to determine if we're trying to step up or down.
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufshcd.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2253f24309e
, instead of querying the
opp table.
Signed-off-by: Bjorn Andersson
---
An alternative approach is to clarify in the devfreq code that it's not
possible to pass a freq_table and then in patch 3 create an opp table for the
device in runtime; although the error handling of this becomes non-tr
On Mon 09 Apr 23:31 PDT 2018, Vivek Gautam wrote:
>
>
> On 4/10/2018 1:39 AM, Bjorn Andersson wrote:
> > On Mon 09 Apr 10:38 PDT 2018, Vivek Gautam wrote:
> > > On 4/9/2018 10:21 PM, Bjorn Andersson wrote:
> > > > On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wr
On Mon 09 Apr 10:38 PDT 2018, Vivek Gautam wrote:
> On 4/9/2018 10:21 PM, Bjorn Andersson wrote:
> > On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote:
[..]
> > > diff --git a/include/linux/phy/phy-qcom-ufs.h
> > > b/include/linux/phy/phy-qcom-ufs.h
> > > ind
On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote:
> While we try to transition from a separate ufs phy driver to a
> more integrated qmp phy driver, don't let SCSI_UFS_QCOM to
> enable PHY_QCOM_UFS config by default.
> The users should enable this in their defconfigs.
> Also add inline definitions
failing WRITE_SAME command, which per the JEDEC UFS
specification is not a supported. Set the no_write_same flag on the
ufshcd SCSI host to let the SCSI layer know this.
Fixes: 7a3e97b0dc4b ("[SCSI] ufshcd: UFS Host controller driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Bjorn
On Sat 19 Aug 01:22 PDT 2017, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal
Applied, thanks.
Regards,
Bjorn
> ---
> drivers/remoteproc/remoteproc_core.c | 2 +-
>
On Wed 29 Mar 13:48 PDT 2017, Michael S. Tsirkin wrote:
> We are going to add more parameters to find_vqs, let's wrap the call so
> we don't need to tweak all drivers every time.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Bjorn Andersson
Regards,
Bjorn
ufs_qcom_init() sets the hba priv data before attempting to acquire the
phy handle, so make sure to clear this in the case of an error. Failing
to do this will make ufs_qcom_setup_clocks() operate on the uninitalized
host object.
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufs-qcom.c
On Sat 19 Nov 12:30 PST 2016, Subhash Jadavani wrote:
> On 2016-11-18 12:55, Bjorn Andersson wrote:
> >In the case where we fail to acquire the phy the hba priv will be set
> >already, so during cleanup ufs_qcom_setup_clocks() will dereference the
> >now free, but still &q
In the case where we fail to acquire the phy the hba priv will be set
already, so during cleanup ufs_qcom_setup_clocks() will dereference the
now free, but still "valid looking" pointer "host".
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufs-qcom.c | 2 +-
1 file
t;ufs: Rename of regulator_set_optimum_mode")
Reported-by: Akinobu Mita
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufshcd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 648a44675880..540e00df6
On Tue 14 Apr 05:11 PDT 2015, Akinobu Mita wrote:
> 2015-02-12 12:35 GMT+09:00 Bjorn Andersson :
> > The function regulator_set_optimum_mode() is changing name to
> > regulator_set_load(), so update the code accordingly. Also cleaned up
> > ufshcd_config_vreg_load() wh
On Wed, Feb 11, 2015 at 7:35 PM, Bjorn Andersson
wrote:
> Changing the name of the regulator_set_optimum_mode() to
> regulator_set_load() better reflects that the API is doing.
>
Any comments on this?
I'm going to propose a patch to the mmc framework calling this api, so
it wo
The function regulator_set_optimum_mode() is changing name to
regulator_set_load(), so update the code accordingly. Also cleaned up
ufshcd_config_vreg_load() while touching the code.
Signed-off-by: Bjorn Andersson
---
drivers/scsi/ufs/ufshcd.c | 27 +++
1 file changed, 7
Changing the name of the regulator_set_optimum_mode() to
regulator_set_load() better reflects that the API is doing.
This series does the name change and move the current consumers
over.
Bjorn Andersson (5):
regulator: s/regulator_set_optimum_mode/regulator_set_load/
ufs: Rename of
43 matches
Mail list logo
