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.
(Lee: EFI on qcom is one of your areas, right?
The UFSHC driver is DT-aware, but is it EFI-aware?)
[0.0
On 12/06/2019 13:10, Avri Altman wrote:
> On 12/06/2019 09:42, Stanley Chu wrote:
>
>> Fixes: e3ce73d (scsi: ufs: fix bugs related to null pointer access and array
>> size)
>
> This code was inserted before platform_set_drvdata in
> 6269473 [SCSI] ufs: Add runtime PM support for UFS host contr
[ 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.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/scsi/ufs/ufshcd.c | 44 ++
On 13/05/2019 16:36, Stanley Chu wrote:
> Currently auto-hibern8 is activated if host supports
> auto-hibern8 capability. However no error handlings are existed thus
> this feature is kind of risky.
This last sentence is not very idiomatic.
I would suggest:
"However, error-handling is not implem
*dev, const
> char *name,
> goto out;
> }
>
> - vreg->min_uA = 0;
> if (!strcmp(name, "vcc")) {
> if (of_property_read_bool(np, "vcc-supply-1p8")) {
> vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
>
Reviewed-by: Marc Gonzalez
On 13/03/2019 20:48, Rob Herring wrote:
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions:
- -fixed-regulator : boolean property specifying that -supply is a
fixed regulator.
> There are no users of that property in tree and doesn't look like
> adding it was ever reviewed. We have
On 13/03/2019 20:48, Rob Herring wrote:
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions:
- -fixed-regulator : boolean property specifying that -supply is a
fixed regulator.
> There are no users of that property in tree and doesn't look like
> adding it was ever reviewed. We have
On 27/02/2019 14:55, Martin K. Petersen wrote:
> On 27/02/2019 11:39, Marc Gonzalez wrote:
>
>> This mini-series removes the "disable-VCCQ-power-rail-for-some-Flash-chips"
>> quirk, and cleans up after the dust settles.
>
> Applied to 5.1/scsi-queue. Thank you!
Great! Thanks.
The UFSHC driver defines a few quirks that are not used anywhere:
UFS_DEVICE_QUIRK_BROKEN_LCC
UFS_DEVICE_NO_VCCQ
UFS_DEVICE_QUIRK_NO_LINK_OFF
UFS_DEVICE_NO_FASTAUTO
Let's remove them.
Acked-by: Avri Altman
Acked-by: Alim Akhtar
Reviewed-by: Evan Green
Signed-off-by: Marc Gon
r 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.
Working around that fact in the driver is detrimental, as evidenced
by the failure to initialize the host controller on MS
This mini-series removes the "disable-VCCQ-power-rail-for-some-Flash-chips"
quirk, and cleans up after the dust settles.
Differences between v5 and v6:
- Reword patch 1 commit message (per Martin)
- Collect tags
Marc Gonzalez (2):
Revert "scsi: ufs: disable vccq if it'
This mini-series removes the "disable-VCCQ-power-rail-for-some-Flash-chips"
quirk, and cleans up after the dust settles.
Differences between v5 and v6:
- Reword patch 1 commit message (per Martin)
- Collect tags
Marc Gonzalez (2):
Revert "scsi: ufs: disable vccq if it'
On 26/02/2019 17:26, Martin K. Petersen wrote:
>> I indeed started off from 'git revert'
>>
>> $ git revert 60f0187031c0
>> warning: inexact rename detection was skipped due to too many files.
>> warning: you may want to set your merge.renamelimit variable to at
>> least 18258 and retry the comman
[ Drop codeaurora.org devs ]
On 26/02/2019 15:52, Martin K. Petersen wrote:
Revert the original patch, and clean up loose ends in the next patch.
>>>
>>> This commit isn't a revert. Why not?
>>
>> What do you mean?
>
> Your commit states it reverts the original patch but the submission is
>
On 26/02/2019 15:44, Martin K. Petersen wrote:
> Hi Marc,
>
>> Commit 60f0187031c0 ("disable vccq if it's not needed by UFS device")
>> introduced a small power optimization as a driver quirk: ignore the
>> vccq load specified in the UFSHC DT node when said host controller
>> is connected to spec
Add host controller and PHY DT nodes.
Signed-off-by: Marc Gonzalez
---
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 19 +++
arch/arm64/boot/dts/qcom/msm8998.dtsi | 65 +++
2 files changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
b
The UFS host controller driver needs to set the load on 3 power rails
(l20, l26, s4) but the operation fails silently unless we specify the
regulator-allow-set-load property in the corresponding DT nodes.
Reviewed-by: Jeffrey Hugo
Signed-off-by: Marc Gonzalez
---
arch/arm64/boot/dts/qcom
Add "qcom,msm8998-ufshc" compatible string.
Signed-off-by: Marc Gonzalez
---
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/
r' + Add Review tags
- Drop UFS pinctrl gymnastics (not required, probably left enabled in
bootloader)
- Delete GCC_UFS_ICE_CORE_CLK (ICE not used upstream, I think)
- Fix sizes of ufsphy register areas based on Jeffrey's feedback
- Hack ufshcd_set_vccq_rail_unused into a NOP to work
Martin,
Could you send this series to -next so that it gets some exposure
and testing during the 5.1 RC cycle?
Regards.
On 11/02/2019 14:31, Marc Gonzalez wrote:
> Casting a wide net to get as many eyeballs on the subject as possible.
>
> I'm splitting this mini series off from
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
On 11/02/2019 18:27, Marc Gonzalez wrote:
> A colleague pointed out that some memory areas are reserved downstream.
> Perhaps the FW goes haywire once the kernel touches reserved memory?
Bingo! FW quirk.
https://patchwork.kernel.org/patch/10808173/
Once the reserved memory range is exten
On 11/02/2019 17:36, Marc Gonzalez wrote:
> On 08/02/2019 16:49, Bart Van Assche wrote:
>
>> Does this problem only occur with block devices backed by the UFS driver
>> or does this problem also occur with other block drivers?
>
> Yes, same issue with a USB3 mass stor
On 08/02/2019 16:49, Bart Van Assche wrote:
> Does this problem only occur with block devices backed by the UFS driver
> or does this problem also occur with other block drivers?
Yes, same issue with a USB3 mass storage device:
usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
usb
The UFSHC driver defines a few quirks that are not used anywhere:
UFS_DEVICE_QUIRK_BROKEN_LCC
UFS_DEVICE_NO_VCCQ
UFS_DEVICE_QUIRK_NO_LINK_OFF
UFS_DEVICE_NO_FASTAUTO
Let's remove them.
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufs_quirks.h | 29 -
dr
elevant patches:
60f0187031c05e04cbadffb62f557d0ff3564490
c58ab7aab71e2c783087115f0ce1623c2fdcf0b2
46c1cf706076500cdcde3445be97233793eec7f1
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufs.h| 1 -
drivers/scsi/ufs/ufshcd.c | 59 +++
2 files changed, 4 insertions(+), 56 del
h,
and/or voice your concerns ASAP.
This series removes the "disable-VCCQ-power-rail-for-some-Flash-chips" quirk,
and cleans up after the dust settles.
Marc Gonzalez (2):
scsi: ufs: Do not disable vccq in UFSHC driver
scsi: ufs: Remove unused device quirks
drivers/scsi/ufs/ufs.h
On 08/02/2019 16:49, Bart Van Assche wrote:
> On Fri, 2019-02-08 at 16:33 +0100, Marc Gonzalez wrote:
>
>> Does anyone see what's going sideways in the no-flag case?
>
> Does this problem only occur with block devices backed by the UFS driver
> or does this problem a
Adding DT & regulator maintainers.
FTR, we are discussing the revert of patch 60f0187031c0
in the UFSHC driver.
On 09/02/2019 09:42, Alim Akhtar wrote:
> On 08/02/19 8:29 PM, Jeffrey Hugo wrote:
>
>> The evidence seems simple. We have properly described in DT all the
>> regulators that are con
On 09/02/2019 10:07, Avri Altman wrote:
> On 08/02/2019 23:20, Marc Gonzalez wrote:
>
>> This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
>>
>> Calling ufshcd_set_vccq_rail_unused() breaks UFS init on two boards.
>> I would say that vccq is *not*
Add UFS host controller and PHY DT nodes for msm8998.
Signed-off-by: Marc Gonzalez
---
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 19 +++
arch/arm64/boot/dts/qcom/msm8998.dtsi | 62 +++
2 files changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998
This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
Calling ufshcd_set_vccq_rail_unused() breaks UFS init on two boards.
I would say that vccq is *not* not needed.
Reviewed-by: Jeffrey Hugo
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufs.h| 1 -
drivers/scsi/ufs/ufshcd.c
The UFS host controller driver needs to set the load on 3 power rails
(l20, l26, s4) but the operation fails silently unless we specify the
regulator-allow-set-load property in the corresponding DT nodes.
Reviewed-by: Jeffrey Hugo
Signed-off-by: Marc Gonzalez
---
arch/arm64/boot/dts/qcom
Add compatible string for QMP UFS phy on msm8998.
Signed-off-by: Marc Gonzalez
---
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
b/Documentation/devicetree/bindings/phy/qcom
Use same init sequence as sdm845.
Reviewed-by: Jeffrey Hugo
Signed-off-by: Marc Gonzalez
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index daf751500232..08d6f6f7f039
Add "qcom,msm8998-ufshc" compatible string.
Signed-off-by: Marc Gonzalez
---
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/
From: Douglas Anderson
If you look at the bindings for the UFS Host Controller it says:
- compatible: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
also list one or more of the following:
"qcom,msm8994-ufshc"
"qcom,msm8996-ufshc"
required, probably left enabled in
bootloader)
- Delete GCC_UFS_ICE_CORE_CLK (ICE not used upstream, I think)
- Fix sizes of ufsphy register areas based on Jeffrey's feedback
- Hack ufshcd_set_vccq_rail_unused into a NOP to work around lock up + reboot
Douglas Anderson (1):
dt-bindings: ufs: Fi
On 07/02/2019 17:56, Marc Gonzalez wrote:
> Saw a slightly different report from another test run:
> https://pastebin.ubuntu.com/p/jCywbKgRCq/
>
> [ 340.689764] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 340.689992] rcu: 1-...0: (8548 ticks this GP
+ Yaniv (just in case)
+ Hannes (if he remembers)
We're discussing commit 60f0187031c05e04cbadffb62f557d0ff3564490
On 08/02/2019 10:09, Alim Akhtar wrote:
> On 07/02/19 8:22 PM, Jeffrey Hugo wrote:
>
>> Did you see https://lkml.org/lkml/2019/2/5/659 where I indicated VCCQ
>> powers components
On 07/02/2019 11:44, Marc Gonzalez wrote:
> + linux-mm
>
> Summarizing the issue for linux-mm readers:
>
> If I read data from a storage device larger than my system's RAM, the system
> freezes
> once dd has read more data than available RAM.
>
> # dd if=/de
On 26/01/2019 08:52, Nathan Chancellor wrote:
> Clang warns several times in the scsi subsystem (trimmed for brevity):
>
> drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to
> switch condition type (2147762695 to 18446744071562347015) [-Wswitch]
> case CCISS_GETBUSTYPE
+ linux-mm
Summarizing the issue for linux-mm readers:
If I read data from a storage device larger than my system's RAM, the system
freezes
once dd has read more data than available RAM.
# dd if=/dev/sde of=/dev/null bs=1M & while true; do echo m >
/proc/sysrq-trigger; echo; echo; sleep 1; don
On 06/02/2019 17:16, Marc Gonzalez wrote:
> # dd if=/dev/sde of=/dev/null bs=1M & while true; do echo l >
> /proc/sysrq-trigger; sleep 1; done
> https://pastebin.ubuntu.com/p/Sx4hXRbHby/
>
> What other information can I provide to help debug this issue?
# dd if=/dev/
On 23/01/2019 04:10, jianchao.wang wrote:
> Looking through the log
> https://pastebin.ubuntu.com/p/YSm82GxhNW/
>
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> rcu:6-...0: (13995 ticks this GP) idle=e16/1/0x4000
> softirq=155/155 fqs=655
> rcu:(detected by 4, t=5
On 06/02/2019 16:27, Alim Akhtar wrote:
> On 06/02/19 8:29 PM, Marc Gonzalez wrote:
>
>> [2.405734] regulator_disable: ENTER vdd_l26
>> [2.405958] regulator_disable: EXIT vdd_l26
>> [2.406032] regulator_set_load: vdd_l26 = 0 uA
>> [3.930
[ Google, stop making email so hard. No, this is not spam, you twat of a
Bayesian filter ]
On 05/02/2019 18:51, Marc Gonzalez wrote:
> On 05/02/2019 18:24, Marc Gonzalez wrote:
>
> Silly me. The system crashes in ufshcd_dump_regs() which is a bug
> I fixed myself. Once I che
On 05/02/2019 18:51, Marc Gonzalez wrote:
> On 05/02/2019 18:24, Marc Gonzalez wrote:
>
> Silly me. The system crashes in ufshcd_dump_regs() which is a bug
> I fixed myself. Once I cherry-pick the appropriate fix, the board
> no longer reboots, but UFS init does fail.
>
&g
On 12/10/2018 23:39, Douglas Anderson wrote:
> If you look at the bindings for the UFS Host Controller it says:
>
> - compatible: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
> also list one or more of the following:
> "qcom,msm8994-ufshc"
>
On 06/02/2019 12:42, Kishon Vijay Abraham I wrote:
> On 06/02/19 12:29 AM, Evan Green wrote:
>
>> Expose a reset controller that the phy will later use to control its
>> own PHY reset in the UFS controller. This will enable the combining
>> of PHY init functionality into a single function.
>>
>>
On 05/02/2019 18:24, Marc Gonzalez wrote:
> /*** system hangs here for several seconds, then reboots ***/
Silly me. The system crashes in ufshcd_dump_regs() which is a bug
I fixed myself. Once I cherry-pick the appropriate fix, the board
no longer reboots, but UFS init does fail.
Full boot
On 05/02/2019 05:58, Alim Akhtar wrote:
> 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.
>
> AFAIK
This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
Calling ufshcd_set_vccq_rail_unused hangs my system.
It seems vccq is not *not* needed.
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufs.h| 1 -
drivers/scsi/ufs/ufshcd.c | 59 +++
2
According to git log and the linux-scsi archives, Vinayak has been
inactive for several years. Removing him as maintainer will make the
get_maintainer.pl script generate an extensive list of recipients.
Add three reviewers as well to vet future UFS patches.
Signed-off-by: Marc Gonzalez
---
Alim
On 22/01/2019 18:39, Joao Pinto wrote:
> On 1/22/2019 5:15 PM, Marc Gonzalez wrote:
>
>> Looking through git log and the linux-scsi archives, it seems that
>> Vinayak vanished after 2013. Removing him as a maintainer will make
>> get_maintainer.pl generate the list
es of 4.
Fixes: ba80917d9932d ("scsi: ufs: ufshcd_dump_regs to use memcpy_fromio")
Acked-by: Tomas Winkler
Reviewed-by: Jeffrey Hugo
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufshcd.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/uf
Looking through git log and the linux-scsi archives, it seems that
Vinayak vanished after 2013. Removing him as a maintainer will make
get_maintainer.pl generate the list of relevant contributors.
Signed-off-by: Marc Gonzalez
---
Martin, sorry for v1, it was a mistake.
---
MAINTAINERS | 3
+ Greg
On 22/01/2019 11:59, Marc Gonzalez wrote:
> FULL SESSION LOG: https://pastebin.ubuntu.com/p/YSm82GxhNW/
I finally got the hung_task detector to fire:
https://pastebin.ubuntu.com/p/XDDJjf7PTb/
Had a chat with GKH, who said that drivers/scsi/ufs is known to be not 100%
functional,
On 22/01/2019 11:59, Marc Gonzalez wrote:
> 4GB RAM. And the system hangs after reading 3.8GB
> I think this is not a coincidence.
> NB: swap is disabled (this might be relevant)
>
> On a freshly booted system, I get
>
> # free
> random: get_random_u64 called from cop
On 22/01/2019 04:12, Jianchao Wang wrote:
> On 1/21/19 11:22 PM, Marc Gonzalez wrote:
>
>> Well, now we know for sure that the clk_scaling_lock is a red herring.
>> I applied the patch below, and still the system locked up:
>>
>> # dd if=/dev/sde of=/dev/null bs=1M
On 19/01/2019 20:47, Marc Gonzalez wrote:
> On 19/01/2019 10:56, Christoph Hellwig wrote:
>
>> On Jan 18, 2019 at 10:48:15AM -0700, Jens Axboe wrote:
>>
>>> It's UFS that totally buggy, if you look at its queuecommand, it does:
>>>
>>>
Based on git log, it appears that Martin has been de facto maintainer
of drivers/scsi/ufs since 2015, while Vinayak seems to have vanished
after 2013. Help get_maintainer.pl pick the correct address.
Signed-off-by: Marc Gonzalez
---
Maybe someone from Linaro or Code Aurora should be added as
On 19/01/2019 20:47, Marc Gonzalez wrote:
> On 19/01/2019 10:56, Christoph Hellwig wrote:
>
>> On Jan 18, 2019 at 10:48:15AM -0700, Jens Axboe wrote:
>>
>>> It's UFS that totally buggy, if you look at its queuecommand, it does:
>>>
>>>
On 19/01/2019 10:56, Christoph Hellwig wrote:
> On Jan 18, 2019 at 10:48:15AM -0700, Jens Axboe wrote:
>
>> It's UFS that totally buggy, if you look at its queuecommand, it does:
>>
>> if (!down_read_trylock(&hba->clk_scaling_lock))
>>
>> return SC
On 18/01/2019 16:18, jianchao.wang wrote:
> It looks like the blk_mq_run_work_fn went to sleep with rcu lock (preempt),
> isn't it ?
> Can you share the symbol of the following address ?
Note: if I boot with 'nosmp', then the system reboots without logging anything.
(Perhaps some kind of HW watc
On 18/01/2019 14:39, Ming Lei wrote:
> On Fri, Jan 18, 2019 at 8:11 PM Marc Gonzalez wrote:
>
>> I'm running into an issue which I don't know how to debug.
>> So I'm open to ideas and suggestions :-)
>>
>> On my arm64 board, I have enabled Unive
Hello,
I'm running into an issue which I don't know how to debug.
So I'm open to ideas and suggestions :-)
On my arm64 board, I have enabled Universal Flash Storage support.
I wanted to benchmark read performance, and noticed that the system
locks up when I read partitions larger than 3.5 GB, un
On 09/01/2019 16:38, Jeffrey Hugo wrote:
>> On 11/12/2018 15:18, Marc Gonzalez wrote:
>>
>>> memcpy_fromio() doesn't provide any control over access size.
>>> For example, on arm64, it is implemented using readb and readq.
>>> This may trigger a synch
On 15/01/2019 13:37, Marc Gonzalez wrote:
> After adding the "regulator-allow-set-load" property to the vreg DT nodes,
> the UFSHC driver was finally able to talk to the Flash chip!
>
> However, all is not well yet :-)
>
> First, I had to turn ufshcd_set_vccq_rail_un
On 15/01/2019 13:37, Marc Gonzalez wrote:
> I had a look at "[8998] How to check PMIC PON reason" but I'm not sure how to
> read
> PM0=0x42420020:0x40 PM1=0x48480020:0x800
> PM2=0x48480020:0x800
AFAIU, the PM0 format is
[8c7][8c6][8c5][8c
On 14/01/2019 13:18, Marc Gonzalez wrote:
> On 14/01/2019 12:57, Marc Gonzalez wrote:
>
>> On 13/12/2018 15:24, Marc Gonzalez wrote:
>>
>>> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
>>> (I'm running v4.20-rc4
On 14/01/2019 12:57, Marc Gonzalez wrote:
> On 13/12/2018 15:24, Marc Gonzalez wrote:
>
>> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
>> (I'm running v4.20-rc4 with a few UFS patches taken off the MSM list.)
>>
>> I'm
On 13/12/2018 15:24, Marc Gonzalez wrote:
> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
> (I'm running v4.20-rc4 with a few UFS patches taken off the MSM list.)
>
> I'm hoping someone with experience with the UFSHC will spot the one thi
On 13/12/2018 15:24, Marc Gonzalez wrote:
> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
> (I'm running v4.20-rc4 with a few UFS patches taken off the MSM list.)
>
> I'm hoping someone with experience with the UFSHC will spot the one thi
Bjorn, Andy, Jeffrey,
What do you think about the patch below?
Regards.
On 11/12/2018 15:18, Marc Gonzalez wrote:
> memcpy_fromio() doesn't provide any control over access size.
> For example, on arm64, it is implemented using readb and readq.
> This may trigger a synchronous
On 21/12/2018 21:08, Marc Gonzalez wrote:
> I think I've checked every low-level thingamajig:
> clocks, regulators, power domains, gdsc, voltage spec
I'm printing all but a few writel's but I'm not seeing anything when the
regulators are being set up... Someth
On 13/12/2018 23:34, Winkler, Tomas wrote:
> On 11/12/2018 15:18, Marc Gonzalez wrote:
>
>> Fixes: ba80917d9932d ("scsi: ufs: ufshcd_dump_regs to use memcpy_fromio")
>> Signed-off-by: Marc Gonzalez
>
> LGTM
Vinayak, Joao,
What do you think?
Regards.
[ Dropping large CC list ]
On 20/12/2018 15:43, Marc Gonzalez wrote:
> I think I've checked every low-level thingamajig:
> clocks, regulators, power domains, gdsc, voltage spec
I found something else, by comparing the writes to the PHY and HC,
downstream
On 20/12/2018 13:38, Marc Gonzalez wrote:
> Found something fishy... [ufs_phy_aux_clk rate returned 0]
Even with that "fixed" [or rather hacked around, since the syntax of
drivers/clk/qcom/gcc-msm8998.c remains nebulous, even after staring
at it, literally, for hours] the UFS
On 19/12/2018 18:27, Marc Gonzalez wrote:
> On 18/12/2018 17:54, Marc Gonzalez wrote:
>
>> Now the fun begins, to find the tiny difference that makes/breaks everything
>> :-)
> I thought I had found the problem:
> "clk_set_rate: ufs_unipro_core_clk_src" wa
On 18/12/2018 17:54, Marc Gonzalez wrote:
> Now the fun begins, to find the tiny difference that makes/breaks everything
> :-)
I thought I had found the problem:
"clk_set_rate: ufs_unipro_core_clk_src" was not occurring.
But, in fact, I think the bootloader already set the pr
On 17/12/2018 10:28, Marc Gonzalez wrote:
> On 17/12/2018 08:14, Kyuho Choi wrote:
>
>> On Thursday, December 13, 2018, Marc Gonzalez wrote:
>>
>> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
>> (I'm running v4.20-rc4
Hello Kyuho,
On 17/12/2018 08:14, Kyuho Choi wrote:
> On Thursday, December 13, 2018, Marc Gonzalez wrote:
>
> Hello everyone,
>
> I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
> (I'm running v4.20-rc4 with a few UFS pa
Hello everyone,
I'm having trouble getting UFS working on an APQ8098 MEDIABOX dev board.
(I'm running v4.20-rc4 with a few UFS patches taken off the MSM list.)
I'm hoping someone with experience with the UFSHC will spot the one thing
missing that will make everything work!
Below is the full boot
es of 4.
Fixes: ba80917d9932d ("scsi: ufs: ufshcd_dump_regs to use memcpy_fromio")
Signed-off-by: Marc Gonzalez
---
drivers/scsi/ufs/ufshcd.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 535180c
On 23/10/2018 06:35, Can Guo wrote:
> From: Dov Levenglick
>
> Enables core reset support. Add full initialization of the PHY and the
> controller before initializing UFS PHY and during link recovery.
>
> Signed-off-by: Dov Levenglick
> Signed-off-by: Amit Nischal
> Signed-off-by: Subhash Jad
On 05/12/2018 08:01, Vivek Gautam wrote:
> On Tue, Oct 23, 2018 at 10:07 AM Can Guo wrote:
>>
>> This patch series adds support for UFS QMP PHY on SDM845 and the
>> compatible string for it. This patch series depends on the current
>> proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on
87 matches
Mail list logo
