From: "Alim Akhtar" <alim.akhtar@samsung.com> To: "'Paweł Chmiel'" <pawel.mikolaj.chmiel@gmail.com>, robh+dt@kernel.org, devicetree@vger.kernel.org, linux-scsi@vger.kernel.org Cc: <krzk@kernel.org>, <avri.altman@wdc.com>, <martin.petersen@oracle.com>, <kwmad.kim@samsung.com>, <stanley.chu@mediatek.com>, <cang@codeaurora.org>, <linux-samsung-soc@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: RE: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 Date: Sun, 5 Apr 2020 07:18:52 +0530 [thread overview] Message-ID: <000001d60aec$5ef39670$1cdac350$@samsung.com> (raw) In-Reply-To: <58f2996c7dfe70b226c5cafbd94d7b02a314d77a.camel@gmail.com> Hi Pawel, > -----Original Message----- > From: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> > Sent: 05 April 2020 01:56 > To: Alim Akhtar <alim.akhtar@samsung.com>; robh+dt@kernel.org; > devicetree@vger.kernel.org; linux-scsi@vger.kernel.org > Cc: krzk@kernel.org; avri.altman@wdc.com; martin.petersen@oracle.com; > kwmad.kim@samsung.com; stanley.chu@mediatek.com; > cang@codeaurora.org; linux-samsung-soc@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 > > On Sat, 2020-04-04 at 21:33 +0200, Paweł Chmiel wrote: > > On Sat, 2020-04-04 at 23:45 +0530, Alim Akhtar wrote: > > Hi Alim, > > > Hi Pawel, > > > > > > > -----Original Message----- > > > > From: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> > > > > Sent: 03 April 2020 22:22 > > > > To: Alim Akhtar <alim.akhtar@samsung.com>; robh+dt@kernel.org; > > > > devicetree@vger.kernel.org; linux-scsi@vger.kernel.org > > > > Cc: krzk@kernel.org; avri.altman@wdc.com; > > > > martin.petersen@oracle.com; kwmad.kim@samsung.com; > > > > stanley.chu@mediatek.com; cang@codeaurora.org; > > > > linux-samsung-soc@vger.kernel.org; linux-arm- > > > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > > > > Subject: Re: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 > > > > > > > > Hi Alim > > > > > > > > Looking at vendor sources, my device is using the same gpios for > > > > urfs_rst_n and ufs_refclk_out like Espresso (with one difference - > > > > ufs_rst_n shouldn't be pulled up). > > > > > > > > About regulators (it would be easier if dts would have all regulators). > > > > It's also using s2mps15 as Espresso, but it vendor dts had only 8 > > > > (of > > > > 10 possible bucks, one missing was for UFS) and 14 ldos (of 27 > > > > possible), where almost all rails are connected to something. > > > > > > > > I'm wondering how it's working on Espresso, because when adding > > > > correct regulators for ufs (vccq = buck10 from s2mps15, always > > > > enabled for testing plus vccq2 and vccq = two regulators enabled > > > > by one gpio, enabled at boot by firmware), ufs wasn't still > > > > working because it was then failing at defer probe (s2mps15 was > > > > probed after ufs) > > > > > > > > [ 0.962482] exynos-ufshc 15570000.ufs: ufshcd_get_vreg: vccq get > > > > failed, err=-517 > > > > > > > As I said, this is very specific to the board, on Espresso we have LDO12 > connected to UFS_RESETn. > > > Either make all of them as always-on, or just disabled s2mps15 > > > (default voltage supply should be ok, unless bootloader on your > > > board does have messed too much with PMIC) > > > > > > > After that boot would just stop/hang. > > > > > > > > After making a "dirty fix" by making s2mps15 regulator driver use > > > > subsys_initcall (like in vendor sources) and ufs late_initcall (to > > > > give it more time to setup and get it working and solve it later), > > > > i had to mark following clocks as CLK_IGNORE_UNUSED to be able to > > > > bring link up (it replicates setting done by vendor kernel, which > > > > enables them on boot): > > > > - "phyclk_ufs20_rx1_symbol_user" > > > > - "phyclk_ufs20_rx0_symbol_user" > > > > - "phyclk_ufs20_tx0_symbol_user" > > > > > > > Coming to these clocks, all these are supplied by default, my best > > > guess is since you are using an actual product (S6 edge), they might have > optimized for power saving And most likely all clock might be gated initially. In > my case all are set to default. > > > I have attached a small change in the exynos7 dts and phy driver clock > handling, please try this attached patch and let me know if this helps in removing > some of your hacks. > > > In the later SoCs these clocks are not in this form, so I didn't included in my > current patch set, If this works for your, will add as an optional for > exynos7/7420. > > > I also assume you are using clk-exynos7.c and my posted ufs driver. > > Yes, i'm using clk-exynos7 (and other exynos7 drivers/dts/etc). > > It would be great if someone could say how exynos7 and exynos7420 are > > similar. For now it looks like that only difference is that exynos7 > > has only 4 cores (a57) where 7420 has 4xa53 + 4xa57. > > It would be very valuable information for me so i could know how much > > i could reuse my device. > > > > Now it's able to bring both device and link, but it fails at > > > > ufshcd_uic_change_pwr_mode. > > > > > > > Can you please use the exact ufs and ufs-phy device node as in my patch? > > With Your patch + removed my changes to clocks (removed fix for wrong > > clock order in dts + removed CLK_IGNORE_UNUSED from symbol clocks in > > clk-exynos7) it's finally able to detect my UFS device!! > > Wow, great to know that UFS device started working for you on S6. > > (but of fails later...with constant error spam in kernel log). > > > > [ 1.383481] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: Unable > > to find vdd-hba-supply regulator, assuming enabled > > [ 1.390060] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vcc-max-microamp > > [ 1.398465] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vccq-max-microamp > > [ 1.406968] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vccq2-max-microamp > > [ 1.415569] exynos-ufshc 15570000.ufs: ufshcd_init_clocks: clk: > > core_clk, rate: 100000000 > > [ 1.423715] exynos-ufshc 15570000.ufs: ufshcd_init_clocks: clk: > > sclk_unipro_main, rate: 167000000 > > [ 1.432569] exynos-ufshc 15570000.ufs: __ufshcd_setup_clocks: clk: > > core_clk enabled > > [ 1.440205] exynos-ufshc 15570000.ufs: __ufshcd_setup_clocks: clk: > > sclk_unipro_main enabled > > [ 1.449613] scsi host0: ufshcd > > [ 1.452179] samsung-ufs-phy 15571800.ufs-phy: MPHY ref_clk_rate = > > 26000000 > > [ 1.458448] samsung-ufs-phy 15571800.ufs-phy: MPHY > > ref_parent_clk_rate = 26000000 > > [ 1.487288] exynos-ufshc 15570000.ufs: ufshcd_print_pwr_info:[RX, > > TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], > rate > > = > > 0 > > [ 2.025569] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd041 val > > 0x1fff error code 1 > > [ 2.025715] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd041 val > > 0x1fff failed 0 retries > > [ 2.025880] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd042 val > > 0xffff error code 1 > > [ 2.027354] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd042 val > > 0xffff failed 0 retries > > [ 2.035583] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd043 val > > 0x7fff error code 1 > > [ 2.043465] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd043 val > > 0x7fff failed 0 retries > > [ 2.054049] exynos-ufshc 15570000.ufs: Power mode change 0 : Fast > > series_B G_2 L_2 > > [ 2.059261] exynos-ufshc 15570000.ufs: ufshcd_print_pwr_info:[RX, > > TX]: gear=[2, 2], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 > > [ 2.071307] exynos-ufshc 15570000.ufs: ufshcd_init_icc_levels: > > setting icc_level 0x0 > > [ 2.081624] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 1 > > [ 2.087576] scsi 0:0:0:49488: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c150hN > > [ 2.098400] scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.107585] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 16 > > [ 2.115588] scsi 0:0:0:49476: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c144hN > > [ 2.126519] scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.135534] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 1 > > [ 2.143612] scsi 0:0:0:49456: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c130hN > > [ 2.154543] scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.163597] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 16 > > [ 2.171721] scsi 0:0:0:0: Direct-Access SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.180352] exynos-ufshc 15570000.ufs: OCS error from controller = 7 > > for tag 0 > > [ 2.186921] host_regs: 00000000: 0383ff0f 00000000 00000200 00000000 > > [ 2.193230] host_regs: 00000010: 00000101 00007fce 00000c96 00000000 > > [ 2.199565] host_regs: 00000020: 00000000 00030e75 00000000 00000000 > > [ 2.205899] host_regs: 00000030: 0000010f 00000000 80000010 00000000 > > [ 2.212234] host_regs: 00000040: 00000000 00000000 00000000 00000000 > > [ 2.218568] host_regs: 00000050: f8d64000 00000000 00000000 00000000 > > [ 2.224903] host_regs: 00000060: 00000001 00000000 00000000 00000000 > > [ 2.231237] host_regs: 00000070: f8da2000 00000000 00000000 00000000 > > [ 2.237572] host_regs: 00000080: 00000001 00000000 00000000 00000000 > > [ 2.243907] host_regs: 00000090: 00000002 95190000 00000000 00000000 > > [ 2.250242] exynos-ufshc 15570000.ufs: hba->ufs_version = 0x200, > > hba->capabilities = 0x383ff0f > > > > Full bootlog > > https://protect2.fireeye.com/url?k=edbae146-b069b8f8-edbb6a09-0cc47a31 > > ba82- > 8b13b1e4caed34d7&q=1&u=https%3A%2F%2Fgist.github.com%2FPabloPL%2F > > 0bcb24492f4ab6e9703c2a4ea20ceb18 kernel source: > > https://protect2.fireeye.com/url?k=75038dec-28d0d452-750206a3-0cc47a31 > > ba82- > 4c366bec6fc01e64&q=1&u=https%3A%2F%2Fgithub.com%2FPabloPL%2Flinux > > %2Ftree%2Fufs-mainline dts file: exynos7-zeroflt.dts (it should be > > zerolt, but will be fixed/changed later). > > Actually, after waiting enough time (about 15 or even more sec of that error > "spam"), was able to mount partitions and manipulate files there. > You need below patch and a change in the ufs driver: https://www.spinics.net/lists/linux-scsi/msg138501.html And diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c index ce2c3d674e4b..c6332deff03a 100644 --- a/drivers/scsi/ufs/ufs-exynos.c +++ b/drivers/scsi/ufs/ufs-exynos.c @@ -1359,7 +1359,8 @@ struct exynos_ufs_drv_data exynos_ufs_drvs = { .quirks = UFSHCD_QUIRK_PRDT_BYTE_GRAN | UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR | UFSHCI_QUIRK_BROKEN_HCE | - UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR, + UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR | + UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR, .opts = EXYNOS_UFS_OPT_HAS_APB_CLK_CTRL | EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL | EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX, > So for me the only issue to solve are defered probe when regulators are not yet > found (for example when pmic is probed after ufs) and not sure what about that > errors (despite working ufs). > The error will go away with the above changes, about regulators, you need to figure it out, as I am not aware of Galaxy S6 PMIC schemes. I also seek your Tested-by tag on these patches . > Thanks for all Thanks for helping in testing. > > > > Thanks
WARNING: multiple messages have this Message-ID (diff)
From: "Alim Akhtar" <alim.akhtar@samsung.com> To: "'Paweł Chmiel'" <pawel.mikolaj.chmiel@gmail.com>, robh+dt@kernel.org, devicetree@vger.kernel.org, linux-scsi@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org, martin.petersen@oracle.com, linux-kernel@vger.kernel.org, krzk@kernel.org, kwmad.kim@samsung.com, avri.altman@wdc.com, cang@codeaurora.org, stanley.chu@mediatek.com, linux-arm-kernel@lists.infradead.org Subject: RE: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 Date: Sun, 5 Apr 2020 07:18:52 +0530 [thread overview] Message-ID: <000001d60aec$5ef39670$1cdac350$@samsung.com> (raw) In-Reply-To: <58f2996c7dfe70b226c5cafbd94d7b02a314d77a.camel@gmail.com> Hi Pawel, > -----Original Message----- > From: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> > Sent: 05 April 2020 01:56 > To: Alim Akhtar <alim.akhtar@samsung.com>; robh+dt@kernel.org; > devicetree@vger.kernel.org; linux-scsi@vger.kernel.org > Cc: krzk@kernel.org; avri.altman@wdc.com; martin.petersen@oracle.com; > kwmad.kim@samsung.com; stanley.chu@mediatek.com; > cang@codeaurora.org; linux-samsung-soc@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 > > On Sat, 2020-04-04 at 21:33 +0200, Paweł Chmiel wrote: > > On Sat, 2020-04-04 at 23:45 +0530, Alim Akhtar wrote: > > Hi Alim, > > > Hi Pawel, > > > > > > > -----Original Message----- > > > > From: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> > > > > Sent: 03 April 2020 22:22 > > > > To: Alim Akhtar <alim.akhtar@samsung.com>; robh+dt@kernel.org; > > > > devicetree@vger.kernel.org; linux-scsi@vger.kernel.org > > > > Cc: krzk@kernel.org; avri.altman@wdc.com; > > > > martin.petersen@oracle.com; kwmad.kim@samsung.com; > > > > stanley.chu@mediatek.com; cang@codeaurora.org; > > > > linux-samsung-soc@vger.kernel.org; linux-arm- > > > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > > > > Subject: Re: [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 > > > > > > > > Hi Alim > > > > > > > > Looking at vendor sources, my device is using the same gpios for > > > > urfs_rst_n and ufs_refclk_out like Espresso (with one difference - > > > > ufs_rst_n shouldn't be pulled up). > > > > > > > > About regulators (it would be easier if dts would have all regulators). > > > > It's also using s2mps15 as Espresso, but it vendor dts had only 8 > > > > (of > > > > 10 possible bucks, one missing was for UFS) and 14 ldos (of 27 > > > > possible), where almost all rails are connected to something. > > > > > > > > I'm wondering how it's working on Espresso, because when adding > > > > correct regulators for ufs (vccq = buck10 from s2mps15, always > > > > enabled for testing plus vccq2 and vccq = two regulators enabled > > > > by one gpio, enabled at boot by firmware), ufs wasn't still > > > > working because it was then failing at defer probe (s2mps15 was > > > > probed after ufs) > > > > > > > > [ 0.962482] exynos-ufshc 15570000.ufs: ufshcd_get_vreg: vccq get > > > > failed, err=-517 > > > > > > > As I said, this is very specific to the board, on Espresso we have LDO12 > connected to UFS_RESETn. > > > Either make all of them as always-on, or just disabled s2mps15 > > > (default voltage supply should be ok, unless bootloader on your > > > board does have messed too much with PMIC) > > > > > > > After that boot would just stop/hang. > > > > > > > > After making a "dirty fix" by making s2mps15 regulator driver use > > > > subsys_initcall (like in vendor sources) and ufs late_initcall (to > > > > give it more time to setup and get it working and solve it later), > > > > i had to mark following clocks as CLK_IGNORE_UNUSED to be able to > > > > bring link up (it replicates setting done by vendor kernel, which > > > > enables them on boot): > > > > - "phyclk_ufs20_rx1_symbol_user" > > > > - "phyclk_ufs20_rx0_symbol_user" > > > > - "phyclk_ufs20_tx0_symbol_user" > > > > > > > Coming to these clocks, all these are supplied by default, my best > > > guess is since you are using an actual product (S6 edge), they might have > optimized for power saving And most likely all clock might be gated initially. In > my case all are set to default. > > > I have attached a small change in the exynos7 dts and phy driver clock > handling, please try this attached patch and let me know if this helps in removing > some of your hacks. > > > In the later SoCs these clocks are not in this form, so I didn't included in my > current patch set, If this works for your, will add as an optional for > exynos7/7420. > > > I also assume you are using clk-exynos7.c and my posted ufs driver. > > Yes, i'm using clk-exynos7 (and other exynos7 drivers/dts/etc). > > It would be great if someone could say how exynos7 and exynos7420 are > > similar. For now it looks like that only difference is that exynos7 > > has only 4 cores (a57) where 7420 has 4xa53 + 4xa57. > > It would be very valuable information for me so i could know how much > > i could reuse my device. > > > > Now it's able to bring both device and link, but it fails at > > > > ufshcd_uic_change_pwr_mode. > > > > > > > Can you please use the exact ufs and ufs-phy device node as in my patch? > > With Your patch + removed my changes to clocks (removed fix for wrong > > clock order in dts + removed CLK_IGNORE_UNUSED from symbol clocks in > > clk-exynos7) it's finally able to detect my UFS device!! > > Wow, great to know that UFS device started working for you on S6. > > (but of fails later...with constant error spam in kernel log). > > > > [ 1.383481] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: Unable > > to find vdd-hba-supply regulator, assuming enabled > > [ 1.390060] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vcc-max-microamp > > [ 1.398465] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vccq-max-microamp > > [ 1.406968] exynos-ufshc 15570000.ufs: ufshcd_populate_vreg: unable > > to find vccq2-max-microamp > > [ 1.415569] exynos-ufshc 15570000.ufs: ufshcd_init_clocks: clk: > > core_clk, rate: 100000000 > > [ 1.423715] exynos-ufshc 15570000.ufs: ufshcd_init_clocks: clk: > > sclk_unipro_main, rate: 167000000 > > [ 1.432569] exynos-ufshc 15570000.ufs: __ufshcd_setup_clocks: clk: > > core_clk enabled > > [ 1.440205] exynos-ufshc 15570000.ufs: __ufshcd_setup_clocks: clk: > > sclk_unipro_main enabled > > [ 1.449613] scsi host0: ufshcd > > [ 1.452179] samsung-ufs-phy 15571800.ufs-phy: MPHY ref_clk_rate = > > 26000000 > > [ 1.458448] samsung-ufs-phy 15571800.ufs-phy: MPHY > > ref_parent_clk_rate = 26000000 > > [ 1.487288] exynos-ufshc 15570000.ufs: ufshcd_print_pwr_info:[RX, > > TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], > rate > > = > > 0 > > [ 2.025569] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd041 val > > 0x1fff error code 1 > > [ 2.025715] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd041 val > > 0x1fff failed 0 retries > > [ 2.025880] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd042 val > > 0xffff error code 1 > > [ 2.027354] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd042 val > > 0xffff failed 0 retries > > [ 2.035583] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd043 val > > 0x7fff error code 1 > > [ 2.043465] exynos-ufshc 15570000.ufs: dme-set: attr-id 0xd043 val > > 0x7fff failed 0 retries > > [ 2.054049] exynos-ufshc 15570000.ufs: Power mode change 0 : Fast > > series_B G_2 L_2 > > [ 2.059261] exynos-ufshc 15570000.ufs: ufshcd_print_pwr_info:[RX, > > TX]: gear=[2, 2], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 > > [ 2.071307] exynos-ufshc 15570000.ufs: ufshcd_init_icc_levels: > > setting icc_level 0x0 > > [ 2.081624] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 1 > > [ 2.087576] scsi 0:0:0:49488: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c150hN > > [ 2.098400] scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.107585] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 16 > > [ 2.115588] scsi 0:0:0:49476: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c144hN > > [ 2.126519] scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.135534] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 1 > > [ 2.143612] scsi 0:0:0:49456: scsi_add_lun: correcting incorrect > > peripheral device type 0x0 for W-LUN 0x c130hN > > [ 2.154543] scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.163597] exynos-ufshc 15570000.ufs: ufshcd_set_queue_depth: > > activate tcq with queue depth 16 > > [ 2.171721] scsi 0:0:0:0: Direct-Access SAMSUNG KLUBG4G1BD- > > E0B1 0200 PQ: 0 ANSI: 6 > > [ 2.180352] exynos-ufshc 15570000.ufs: OCS error from controller = 7 > > for tag 0 > > [ 2.186921] host_regs: 00000000: 0383ff0f 00000000 00000200 00000000 > > [ 2.193230] host_regs: 00000010: 00000101 00007fce 00000c96 00000000 > > [ 2.199565] host_regs: 00000020: 00000000 00030e75 00000000 00000000 > > [ 2.205899] host_regs: 00000030: 0000010f 00000000 80000010 00000000 > > [ 2.212234] host_regs: 00000040: 00000000 00000000 00000000 00000000 > > [ 2.218568] host_regs: 00000050: f8d64000 00000000 00000000 00000000 > > [ 2.224903] host_regs: 00000060: 00000001 00000000 00000000 00000000 > > [ 2.231237] host_regs: 00000070: f8da2000 00000000 00000000 00000000 > > [ 2.237572] host_regs: 00000080: 00000001 00000000 00000000 00000000 > > [ 2.243907] host_regs: 00000090: 00000002 95190000 00000000 00000000 > > [ 2.250242] exynos-ufshc 15570000.ufs: hba->ufs_version = 0x200, > > hba->capabilities = 0x383ff0f > > > > Full bootlog > > https://protect2.fireeye.com/url?k=edbae146-b069b8f8-edbb6a09-0cc47a31 > > ba82- > 8b13b1e4caed34d7&q=1&u=https%3A%2F%2Fgist.github.com%2FPabloPL%2F > > 0bcb24492f4ab6e9703c2a4ea20ceb18 kernel source: > > https://protect2.fireeye.com/url?k=75038dec-28d0d452-750206a3-0cc47a31 > > ba82- > 4c366bec6fc01e64&q=1&u=https%3A%2F%2Fgithub.com%2FPabloPL%2Flinux > > %2Ftree%2Fufs-mainline dts file: exynos7-zeroflt.dts (it should be > > zerolt, but will be fixed/changed later). > > Actually, after waiting enough time (about 15 or even more sec of that error > "spam"), was able to mount partitions and manipulate files there. > You need below patch and a change in the ufs driver: https://www.spinics.net/lists/linux-scsi/msg138501.html And diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c index ce2c3d674e4b..c6332deff03a 100644 --- a/drivers/scsi/ufs/ufs-exynos.c +++ b/drivers/scsi/ufs/ufs-exynos.c @@ -1359,7 +1359,8 @@ struct exynos_ufs_drv_data exynos_ufs_drvs = { .quirks = UFSHCD_QUIRK_PRDT_BYTE_GRAN | UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR | UFSHCI_QUIRK_BROKEN_HCE | - UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR, + UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR | + UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR, .opts = EXYNOS_UFS_OPT_HAS_APB_CLK_CTRL | EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL | EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX, > So for me the only issue to solve are defered probe when regulators are not yet > found (for example when pmic is probed after ufs) and not sure what about that > errors (despite working ufs). > The error will go away with the above changes, about regulators, you need to figure it out, as I am not aware of Galaxy S6 PMIC schemes. I also seek your Tested-by tag on these patches . > Thanks for all Thanks for helping in testing. > > > > Thanks _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-05 1:49 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20200327171411epcas5p17f4457f9fd61800257607059b9506fb2@epcas5p1.samsung.com> 2020-03-27 17:06 ` [PATCH v4 0/5] exynos-ufs: Add support for UFS HCI Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar [not found] ` <CGME20200327171414epcas5p1460e932c0bc98f31ebdd115218b4fd49@epcas5p1.samsung.com> 2020-03-27 17:06 ` [PATCH v4 1/5] dt-bindings: phy: Document Samsung UFS PHY bindings Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar 2020-04-05 1:54 ` Rob Herring 2020-04-05 1:54 ` Rob Herring 2020-04-07 0:28 ` Alim Akhtar 2020-04-07 0:28 ` Alim Akhtar [not found] ` <CGME20200327171416epcas5p43133a28159ef24b145fcc8f3df102dde@epcas5p4.samsung.com> 2020-03-27 17:06 ` [PATCH v4 2/5] phy: samsung-ufs: add UFS PHY driver for samsung SoC Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar [not found] ` <CGME20200327171418epcas5p4b85bea273e17c05a7edca58f528c435a@epcas5p4.samsung.com> 2020-03-27 17:06 ` [PATCH v4 3/5] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar 2020-04-05 2:02 ` Rob Herring 2020-04-05 2:02 ` Rob Herring 2020-04-12 5:41 ` Alim Akhtar 2020-04-12 5:41 ` Alim Akhtar [not found] ` <CGME20200327171420epcas5p490e1e6d090a540eaf050e0728a39ba25@epcas5p4.samsung.com> 2020-03-27 17:06 ` [PATCH v4 4/5] scsi: ufs-exynos: add UFS host support for Exynos SoCs Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar 2020-03-28 11:28 ` Avri Altman 2020-03-28 11:28 ` Avri Altman 2020-04-02 15:08 ` Alim Akhtar 2020-04-02 15:08 ` Alim Akhtar [not found] ` <CGME20200327171423epcas5p485d227f19e45999ad9b42b21d2864e4a@epcas5p4.samsung.com> 2020-03-27 17:06 ` [PATCH v4 5/5] arm64: dts: Add node for ufs exynos7 Alim Akhtar 2020-03-27 17:06 ` Alim Akhtar 2020-03-28 13:30 ` Paweł Chmiel 2020-03-28 13:30 ` Paweł Chmiel 2020-03-28 15:35 ` Alim Akhtar 2020-03-28 15:35 ` Alim Akhtar 2020-03-28 17:46 ` Paweł Chmiel 2020-03-28 17:46 ` Paweł Chmiel 2020-03-29 15:35 ` Alim Akhtar 2020-03-29 15:35 ` Alim Akhtar 2020-04-03 16:52 ` Paweł Chmiel 2020-04-03 16:52 ` Paweł Chmiel 2020-04-04 18:15 ` Alim Akhtar 2020-04-04 18:15 ` Alim Akhtar 2020-04-04 19:33 ` Paweł Chmiel 2020-04-04 19:33 ` Paweł Chmiel 2020-04-04 20:25 ` Paweł Chmiel 2020-04-04 20:25 ` Paweł Chmiel 2020-04-05 1:48 ` Alim Akhtar [this message] 2020-04-05 1:48 ` Alim Akhtar 2020-04-05 8:11 ` Paweł Chmiel 2020-04-05 8:11 ` Paweł Chmiel
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='000001d60aec$5ef39670$1cdac350$@samsung.com' \ --to=alim.akhtar@samsung.com \ --cc=avri.altman@wdc.com \ --cc=cang@codeaurora.org \ --cc=devicetree@vger.kernel.org \ --cc=krzk@kernel.org \ --cc=kwmad.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=pawel.mikolaj.chmiel@gmail.com \ --cc=robh+dt@kernel.org \ --cc=stanley.chu@mediatek.com \ /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: linkBe 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.